Aby zapobiec uruchamianiu dowolnych ładunków w maszynie pVM, Android Virtualization Framework (AVF) wykorzystuje warstwowe podejście do zabezpieczeń, w którym każda warstwa dodaje dodatkowe elementy wymuszające. Poniżej znajduje się lista warstw zabezpieczeń AVF:
Android gwarantuje, że tylko aplikacje z uprawnieniami pVM mogą tworzyć i sprawdzać maszyny pVM.
Program ładujący — moduł ładujący zapewnia, że tylko obrazy pVM podpisane przez firmę Google lub dostawców urządzeń będą mogły zostać uruchomione i będą zgodne z procedurą zweryfikowanego rozruchu systemu Android . Ta architektura oznacza, że aplikacje działające na maszynach pVM nie mogą łączyć własnych jąder.
pVM zapewnia głęboką obronę, taką jak SELinux , dla ładunków uruchamianych w pVM. Dogłębna obrona nie pozwala na mapowanie danych jako plików wykonywalnych (
neverallow execmem) i zapewnia, że W^X zachowuje się dla wszystkich typów plików.
Model bezpieczeństwa
Poufność, integralność i dostępność (triada CIA) tworzą model mający kierować polityką bezpieczeństwa informacji:
- Poufność to zbiór zasad ograniczających dostęp do informacji.
- Uczciwość oznacza pewność, że informacje są godne zaufania i dokładne.
- Dostępność jest gwarancją rzetelnego dostępu do informacji przez uprawnione 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 i wszelkie żądania właścicieli dotyczące udostępniania stron. pKVM zapewnia, że tylko uprawnione maszyny pVM (host i goście) mają daną stronę zmapowaną w tabelach stron etapu 2, które są kontrolowane przez hiperwizor. Architektura ta utrzymuje, ż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ą również wszelkie podmioty w systemie, które wykonują dostęp do pamięci w imieniu maszyn pVM, a mianowicie urządzenia i usługi obsługujące DMA działające w bardziej uprzywilejowanych warstwach . Dostawcy systemów typu System-on-Chip (SoC) muszą spełnić nowy zestaw wymagań, zanim będą mogli obsługiwać pKVM. W przeciwnym razie nie można zapewnić poufności.
Integralność dotyczy danych w pamięci i obliczeniach. maszyny pVM nie mogą:
- Wzajemną modyfikację pamięci bez zgody.
- Wzajemny wpływ na stan procesora.
Wymagania te są egzekwowane przez hiperwizora. Jednak problemy z integralnością danych pojawiają się również w przypadku wirtualnego przechowywania danych, gdy konieczne jest zastosowanie innych rozwiązań, takich jak dm-verity lub AuthFS.
Zasady te nie różnią się od izolacji procesów oferowanej przez Linuksa, gdzie dostęp do stron pamięci jest kontrolowany za pomocą tabel stron etapu 1 i przełączników kontekstu jądra pomiędzy procesami. Jednak część EL2 pKVM, która wymusza te właściwości, ma mniej więcej połowę powierzchni ataku w porównaniu z całym jądrem Linuksa (około 10 tysięcy w porównaniu z 20 milionami linii kodu), a zatem zapewnia większą pewność użycia przypadków, które są zbyt wrażliwe, aby na nich polegać na izolacji procesu.
Biorąc pod uwagę jego rozmiar, pKVM nadaje się do formalnej weryfikacji. Aktywnie wspieramy badania akademickie, których celem jest formalne udowodnienie tych właściwości na rzeczywistym pliku binarnym pKVM.
Pozostała część tej strony dotyczy gwarancji poufności i integralności, jakie zapewnia każdy komponent pKVM.
Hiperwizor
pKVM to hiperwizor oparty na KVM, który izoluje maszyny pVM i system Android w środowiskach wykonawczych, do których nie mają zaufania. Te właściwości obowiązują w przypadku kompromisu w dowolnej maszynie pVM, w tym na hoście. Alternatywne hypervisory zgodne z AVF muszą zapewniać podobne właściwości.
PVM nie może uzyskać dostępu do strony należącej do innego podmiotu, takiego jak pVM lub hypervisor, chyba że właściciel strony wyraźnie to udostępni. Ta reguła obejmuje maszynę pVM hosta i ma zastosowanie zarówno do dostępu do procesora, jak i DMA.
Zanim strona używana przez pVM zostanie zwrócona do hosta, na przykład w przypadku zniszczenia pVM, jest ona czyszczona.
Pamięć wszystkich maszyn pVM i oprogramowanie układowe pVM z jednego rozruchu urządzenia są czyszczone przed uruchomieniem programu ładującego systemu operacyjnego podczas kolejnego rozruchu urządzenia.
Po podłączeniu debugera sprzętowego, takiego jak SJTAG, maszyna pVM nie może uzyskać dostępu do wcześniej utworzonych kluczy.
Oprogramowanie sprzętowe pVM nie uruchamia się, jeśli nie może zweryfikować obrazu początkowego.
Oprogramowanie układowe pVM nie uruchamia się, jeśli integralność
instance.imgzostanie naruszona.Łańcuch certyfikatów rozruchowych (BCC) i złożone identyfikatory urządzeń (CDI) dostarczone do instancji pVM można wyprowadzić tylko z tej konkretnej instancji.
System operacyjny gościa
Microdroid jest przykładem systemu operacyjnego działającego w maszynie pVM. Microdroid składa się z bootloadera opartego na U-boocie, GKI, podzbioru przestrzeni użytkownika Androida i programu uruchamiającego ładunki. Te właściwości obowiązują w przypadku kompromisu w dowolnej maszynie pVM, w tym na hoście. Alternatywne systemy operacyjne działające na maszynie pVM powinny zapewniać podobne właściwości.
Microdroid nie uruchomi się, jeśli nie można zweryfikować
boot.img,super.img,vbmeta.imglubvbmeta\_system.img.Microdroid nie uruchomi się, jeśli weryfikacja pliku APK nie powiedzie się.
Ta sama instancja Microdroid nie uruchomi się, nawet jeśli plik APK został zaktualizowany.
Microdroid nie uruchomi się, jeśli którykolwiek z APEX-ów nie przejdzie weryfikacji.
Microdroid nie uruchomi się (lub uruchomi się z czystym stanem początkowym), jeśli
instance.imgzostanie zmodyfikowany poza maszyną pVM gościa.Microdroid zapewnia atest łańcucha rozruchowego.
Wszelkie (niepodpisane) modyfikacje obrazów dysków współdzielonych z maszyną pVM gościa powodują błąd we/wy po stronie pVM.
Kody BCC i CDI dostarczone do instancji pVM można wyprowadzić tylko z tej konkretnej instancji.
Zapisy na zaszyfrowanym woluminie pamięci są poufne, jednak nie ma ochrony przed wycofaniem w przypadku szczegółowości bloku szyfrowania. Co więcej, inna dowolna zewnętrzna ingerencja w blok danych powoduje, że blok ten wydaje się być śmieciem dla Microdroid, zamiast być jawnie wykrywany jako błąd we/wy.
Android
Są to właściwości obsługiwane przez system Android jako hosta, ale nie obowiązują w przypadku naruszenia bezpieczeństwa hosta:
Maszyna pVM gościa nie może bezpośrednio wchodzić w interakcję (np. nawiązywać połączenia
vsock) z innymi maszynami pVM gościa.Tylko
VirtualizationServicew maszynie pVM hosta może utworzyć kanał komunikacyjny z maszyną pVM.Tylko aplikacje podpisane kluczem platformy mogą prosić o pozwolenie na tworzenie maszyn pVM, posiadanie ich lub interakcję z nimi.
Identyfikator, zwany identyfikatorem kontekstu (CID), używany podczas konfigurowania połączeń
vsockmiędzy hostem a maszyną pVM nie jest ponownie używany, gdy maszyna pVM hosta jest uruchomiona. Na przykład nie można zastąpić działającej maszyny pVM inną.
Dostępność
W kontekście maszyn pVM dostępność oznacza, że gospodarz przydziela gościom wystarczające zasoby, aby goście mogli wykonywać zadania, do których zostali stworzeni.
Do obowiązków hosta należy planowanie wirtualnych procesorów pVM. KVM, w przeciwieństwie do konwencjonalnych hypervisorów typu 1 (takich jak Xen), podejmuje wyraźną decyzję projektową o delegowaniu planowania obciążenia do jądra hosta. Biorąc pod uwagę rozmiar i złożoność współczesnych programów planujących, ta decyzja projektowa znacznie zmniejsza rozmiar zaufanej bazy obliczeniowej (TCB) i umożliwia hostowi podejmowanie bardziej świadomych decyzji dotyczących planowania w celu optymalizacji wydajności. Jednak złośliwy host może zdecydować, że nigdy nie planuje gościa.
Podobnie pKVM deleguje obsługę przerwań fizycznych do jądra hosta, aby zmniejszyć złożoność hiperwizora i pozostawić hostowi odpowiedzialność za planowanie. Podejmowane są wysiłki, aby zapewnić, że przekazywanie przerwań gościa spowoduje jedynie odmowę usługi (za mało, za dużo lub źle przekierowane przerwania).
Wreszcie proces monitorowania maszyny wirtualnej (VMM) hosta jest odpowiedzialny za alokację pamięci i udostępnianie urządzeń wirtualnych, takich jak karta sieciowa. Złośliwy VMM może zablokować zasoby gościowi.
Chociaż pKVM nie zapewnia dostępności dla gości, projekt chroni dostępność hosta przed złośliwymi gośćmi, ponieważ host może zawsze wywłaszczyć lub zakończyć gościa i odzyskać jego zasoby.
Bezpieczny rozruch
Dane są powiązane z instancjami maszyny pVM, a bezpieczny rozruch zapewnia kontrolę dostępu do danych instancji. Pierwsze uruchomienie instancji zapewnia to poprzez losowe wygenerowanie tajnej soli dla pVM i wyodrębnienie szczegółów, takich jak weryfikacyjne klucze publiczne i skróty, z załadowanych obrazów. Informacje te służą do weryfikacji kolejnych uruchomień instancji pVM i zapewnienia, że klucze tajne instancji zostaną ujawnione tylko obrazom, które przejdą weryfikację. Ten proces zachodzi na każdym etapie ładowania w pVM: oprogramowanie sprzętowe pVM, pVM ABL, Microdroid i tak dalej.
DICE zapewnia każdemu etapowi ładowania parę kluczy atestacyjnych, których część publiczna jest certyfikowana we wpisie BCC dla tego etapu. Ta para kluczy może zmieniać się między rozruchami, więc wyprowadzany jest również sekret pieczętowania , który jest stabilny dla instancji maszyny wirtualnej po ponownym uruchomieniu i jako taki nadaje się do ochrony stanu trwałego. Sekret pieczętowania jest bardzo cenny dla maszyny wirtualnej, dlatego nie należy go używać bezpośrednio. Zamiast tego klucze pieczętujące powinny zostać wyprowadzone z tajemnicy pieczętującej, a tajemnica pieczętująca powinna zostać zniszczona tak szybko, jak to możliwe.
Każdy etap przekazuje deterministycznie zakodowany obiekt CBOR do następnego etapu. Obiekt ten zawiera wpisy tajne i kod BCC, który zawiera zgromadzone informacje o statusie, takie jak to, czy ostatni etap został bezpiecznie załadowany.
Odblokowane urządzenia
Gdy urządzenie zostanie odblokowane za pomocą fastboot oem unlock , dane użytkownika zostaną usunięte. Proces ten chroni dane użytkownika przed nieuprawnionym dostępem. Dane prywatne dla maszyny pVM również zostają unieważnione w przypadku odblokowania urządzenia.
Po odblokowaniu właściciel urządzenia może ponownie zaktualizować partycje, które są zwykle chronione przez zweryfikowany rozruch, w tym partycje zawierające implementację pKVM. Dlatego pKVM na odblokowanym urządzeniu nie będzie uznawany za podtrzymujący model bezpieczeństwa.
Strony zdalne mogą zaobserwować ten potencjalnie niebezpieczny stan, sprawdzając zweryfikowany stan rozruchu urządzenia w certyfikacie klucza.