Aby zapobiec uruchamianiu w pVM dowolnych ładunków, platforma wirtualizacji Androida (AVF) stosuje wielowarstwowe podejście do bezpieczeństwa, w którym każda warstwa dodaje dodatkowe zabezpieczenia. Poniżej znajdziesz listę warstw zabezpieczeń AVF:
Android dba o to, aby tylko aplikacje z uprawnieniami pVM mogły tworzyć lub sprawdzać pVM.
Program rozruchowy – program rozruchowy zapewnia, że uruchamiane są tylko obrazy pVM podpisane przez Google lub dostawców urządzeń, i przestrzega procedury zweryfikowanego rozruchu Androida. Ta architektura oznacza, że aplikacje działające na pVM nie mogą dołączać własnych jąder.
pVM zapewnia wielowarstwową ochronę, np. za pomocą SELinux, w przypadku ładunków uruchamianych w pVM. Ochrona wielowarstwowa uniemożliwia mapowanie danych jako plików wykonywalnych (
neverallow execmem) i zapewnia, że W^X obowiązuje w przypadku wszystkich typów plików.
Model zabezpieczeń
Poufność, integralność i dostępność (triada CIA) to model, który ma stanowić wytyczne dla zasad bezpieczeństwa informacji:
- Poufność to zbiór reguł, które ograniczają dostęp do informacji.
- Integralność to pewność, że informacje są wiarygodne i dokładne.
- Dostępność to gwarancja niezawodnego dostępu do informacji przez upoważnione podmioty.
Poufność i integralność
Poufność wynika z właściwości izolacji pamięci wymuszanych przez hiperwizor pKVM. pKVM śledzi własność pamięci poszczególnych stron pamięci fizycznej oraz wszelkie żądania udostępnienia stron od właścicieli. pKVM zapewnia, że tylko uprawnione maszyny pVM (host i goście) mają daną stronę mapowaną w tabelach stron drugiego etapu, które są kontrolowane przez hiperwizor. Ta architektura zakłada, że zawartość pamięci należącej do pVM pozostaje prywatna, chyba że właściciel wyraźnie udostępni ją innemu pVM.
Ograniczenia dotyczące zachowania poufności obejmują też wszystkie podmioty w systemie, które wykonują dostęp do pamięci w imieniu pVM, czyli urządzenia obsługujące DMA i usługi działające na warstwach o większych uprawnieniach. Zanim dostawcy układów SoC będą mogli obsługiwać pKVM, muszą spełnić nowy zestaw wymagań. W przeciwnym razie nie możemy zapewnić poufności.
Integralność dotyczy danych w pamięci i obliczeń. Maszyny wirtualne chronione nie mogą:
- modyfikować nawzajem swoje wspomnienia bez zgody.
- wpływać na stan procesora.
Te wymagania są wymuszane przez hiperwizor. Jednak w przypadku wirtualnego przechowywania danych pojawiają się też problemy z integralnością danych, gdy trzeba zastosować inne rozwiązania, takie jak dm-verity czy AuthFS.
Te zasady nie różnią się od izolacji procesów oferowanej przez system Linux, w której dostęp do stron pamięci jest kontrolowany za pomocą tabel stron poziomu 1, a jądro przełącza konteksty między procesami. Jednak część EL2 pKVM, która wymusza te właściwości, ma o 3 rzędy wielkości mniejszą powierzchnię ataku w porównaniu z całym jądrem systemu Linux (około 10 tys. wierszy kodu w porównaniu z 20 mln), a tym samym zapewnia większą pewność w przypadkach użycia, które są zbyt wrażliwe, aby polegać na izolacji procesów.
Ze względu na swój rozmiar pKVM nadaje się do formalnej weryfikacji. Aktywnie wspieramy badania naukowe, których celem jest formalne udowodnienie tych właściwości w rzeczywistym pliku binarnym pKVM.
W dalszej części tej strony omówimy gwarancje poufności i integralności, jakie zapewnia każdy komponent pKVM.
Hipernadzorca
pKVM to hiperwizor oparty na KVM, który izoluje pVM i Androida w wzajemnie nieufnych środowiskach wykonawczych. Te właściwości są zachowywane w przypadku naruszenia bezpieczeństwa w dowolnej pVM, w tym na hoście. Alternatywne hiperwizory zgodne z AVF muszą zapewniać podobne właściwości.
pVM nie ma dostępu do strony należącej do innego podmiotu, np. pVM lub hiperwizora, chyba że właściciel strony wyraźnie ją udostępni. Ta reguła obejmuje hosta pVM i dotyczy dostępu do procesora oraz DMA.
Zanim strona używana przez pVM zostanie zwrócona do hosta, np. gdy pVM zostanie zniszczona, jest czyszczona.
Pamięć wszystkich maszyn pVM i oprogramowanie układowe pVM z jednego uruchomienia urządzenia są czyszczone przed uruchomieniem programu rozruchowego systemu operacyjnego podczas kolejnego uruchomienia urządzenia.
Gdy podłączony jest debugger sprzętowy, np. SJTAG, pVM nie może uzyskać dostępu do wcześniej wygenerowanych kluczy.
Oprogramowanie pVM nie uruchomi się, jeśli nie będzie można zweryfikować obrazu początkowego.
Oprogramowanie pVM nie uruchomi się, jeśli integralność
instance.imgzostanie naruszona.Łańcuch certyfikatów DICE i złożone identyfikatory urządzeń (CDI) udostępniane instancji pVM mogą być wyprowadzane tylko przez tę instancję.
System operacyjny gościa
Microdroid to przykład systemu operacyjnego działającego w ramach maszyny wirtualnej z ochroną. Microdroid składa się z programu rozruchowego opartego na U-boot, GKI, podzbioru przestrzeni użytkownika Androida i programu uruchamiającego ładunek. Te właściwości obowiązują w przypadku naruszenia bezpieczeństwa w dowolnej maszynie pVM, w tym na hoście. Alternatywne systemy operacyjne działające na maszynie pVM powinny mieć podobne właściwości.
Mikroandroid nie uruchomi się, jeśli nie będzie można zweryfikować
boot.img,super.img,vbmeta.imglubvbmeta\_system.img.Jeśli weryfikacja pliku APK się nie powiedzie, Microdroid się nie uruchomi.
Ta sama instancja Microdroida nie uruchomi się nawet po zaktualizowaniu pliku APK.
Jeśli weryfikacja któregokolwiek z pakietów APEX się nie powiedzie, Microdroid się nie uruchomi.
Mikroandroid nie uruchomi się (lub uruchomi się w czystym stanie początkowym), jeśli
instance.imgzostanie zmodyfikowany poza gościnną maszyną wirtualną pVM.Microdroid zapewnia atestowanie łańcucha rozruchu.
Każda (niepodpisana) modyfikacja obrazów dysków udostępnionych gościowi pVM powoduje błąd wejścia/wyjścia po stronie pVM.
Łańcuch certyfikatów DICE i identyfikatory CDI dostarczane do instancji pVM mogą być wyprowadzane tylko przez tę konkretną instancję.
Zapisywanie na zaszyfrowanym woluminie pamięci masowej jest poufne, ale nie ma ochrony przed wycofaniem na poziomie bloku szyfrowania. Ponadto inne dowolne zewnętrzne manipulowanie blokiem danych powoduje, że blok ten wygląda dla Microdroida jak śmieci, zamiast być wyraźnie wykrywany jako błąd wejścia/wyjścia.
Android
Są to właściwości utrzymywane przez Androida jako hosta, ale nie są prawdziwe w przypadku naruszenia bezpieczeństwa hosta:
Gościnna maszyna wirtualna nie może bezpośrednio wchodzić w interakcje z innymi gościnnymi maszynami wirtualnymi (np. nawiązywać z nimi połączenia).
vsockTylko
VirtualizationServicew pVM hosta może utworzyć kanał komunikacji z pVM.Tylko aplikacje podpisane kluczem platformy mogą prosić o uprawnienia do tworzenia, posiadania lub używania pVM.
Identyfikator używany podczas konfigurowania połączeń
vsockmiędzy hostem a maszyną wirtualną chronioną (nazywany identyfikatorem kontekstu) nie jest ponownie używany, gdy działa maszyna wirtualna chroniona hosta. Nie możesz na przykład zastąpić działającej maszyny pVM inną.
Dostępność
W przypadku maszyn pVM dostępność oznacza, że host przydziela gościom wystarczającą ilość zasobów, aby mogli oni wykonywać zadania, do których są przeznaczeni.
Obowiązki hosta obejmują planowanie wirtualnych procesorów pVM. W przeciwieństwie do konwencjonalnych hipernadzorców typu 1 (takich jak Xen) KVM podejmuje wyraźną decyzję projektową o delegowaniu planowania zadań do jądra hosta. Biorąc pod uwagę rozmiar i złożoność współczesnych harmonogramów, ta decyzja projektowa znacznie zmniejsza rozmiar zaufanej bazy obliczeniowej (TCB) i umożliwia hostowi podejmowanie bardziej świadomych decyzji dotyczących harmonogramowania w celu optymalizacji wydajności. Jednak złośliwy host może nigdy nie zaplanować gościa.
Podobnie pKVM przekazuje obsługę przerwań fizycznych do jądra hosta, aby zmniejszyć złożoność hiperwizora i pozostawić hostowi kontrolę nad planowaniem. Dokładamy starań, aby przekazywanie przerwań gościa powodowało jedynie odmowę usługi (zbyt mało, zbyt dużo lub nieprawidłowo przekierowane przerwania).
Proces monitora maszyny wirtualnej (VMM) hosta odpowiada za przydzielanie pamięci i udostępnianie urządzeń wirtualnych, takich jak karta sieciowa. Złośliwy menedżer maszyn wirtualnych może wstrzymać zasoby gościa.
Chociaż pKVM nie zapewnia dostępności gościom, jego konstrukcja chroni dostępność hosta przed złośliwymi gośćmi, ponieważ host może zawsze wyprzedzić lub zakończyć działanie gościa i odzyskać jego zasoby.
Bezpieczny rozruch
Dane są powiązane z instancjami pVM, a bezpieczny rozruch zapewnia kontrolę dostępu do danych instancji. Podczas pierwszego uruchomienia instancji jest ona inicjowana przez losowe wygenerowanie tajnego klucza salt dla pVM i wyodrębnienie szczegółów, takich jak klucze publiczne weryfikacji i wartości hash, z załadowanych obrazów. Te informacje są używane do weryfikacji kolejnych uruchomień instancji pVM i zapewnienia, że tajne dane instancji są udostępniane tylko obrazom, które przejdą weryfikację. Ten proces zachodzi na każdym etapie ładowania w pVM: oprogramowanie sprzętowe pVM, ABL pVM, Microdroid itp.
DICE udostępnia na każdym etapie ładowania parę kluczy atestacyjnych, której część publiczna jest certyfikowana w certyfikacie DICE na tym etapie. Ta para kluczy może się zmieniać między uruchomieniami, dlatego wyprowadzany jest też klucz szyfrujący, który jest stabilny dla instancji maszyny wirtualnej między ponownymi uruchomieniami i dlatego nadaje się do ochrony trwałego stanu. Klucz szyfrowania jest bardzo ważny dla maszyny wirtualnej, dlatego nie należy go używać bezpośrednio. Zamiast tego klucze szyfrujące powinny być wyprowadzane z klucza tajnego szyfrowania, a klucz tajny szyfrowania powinien zostać zniszczony jak najszybciej.
Każdy etap przekazuje następnemu etapowi obiekt CBOR zakodowany w sposób deterministyczny. Ten obiekt zawiera klucze tajne i łańcuch certyfikatów DICE, który zawiera zgromadzone informacje o stanie, np. czy ostatni etap został załadowany w bezpieczny sposób.
Odblokowane urządzenia
Gdy urządzenie zostanie odblokowane za pomocą fastboot oem unlock, dane użytkownika zostaną wyczyszczone.
Ten proces chroni dane użytkowników przed nieuprawnionym dostępem. Dane prywatne maszyny wirtualnej profilu są też unieważniane, gdy urządzenie jest odblokowywane.
Po odblokowaniu właściciel urządzenia może ponownie flashować partycje, które są zwykle chronione przez weryfikację podczas uruchamiania, w tym partycje zawierające pvmfw i implementację pKVM. Dlatego odblokowane urządzenie nie jest zaufane w zakresie utrzymywania modelu zabezpieczeń pVM.
Zdalne podmioty mogą zaobserwować ten potencjalnie niebezpieczny stan, sprawdzając stan zweryfikowanego rozruchu urządzenia w certyfikacie atestu klucza.