Aby zapobiec uruchamianiu dowolnych ładunków w pVM, platforma Android Virtualization Framework (AVF) stosuje podejście do zabezpieczeń oparte na warstwach, w których każda warstwa dodaje dodatkowe zabezpieczenia. Oto lista warstw zabezpieczeń AVF:
Android zapewnia, że tylko aplikacje z uprawnieniami pVM mogą tworzyć lub sprawdzać maszyny wirtualne.
Bootloader – bootloader zapewnia, że tylko obrazy pVM podpisane przez Google lub dostawców urządzeń mogą się uruchamiać, i przestrzega procedury Android Verified Boot. Ta architektura oznacza, że aplikacje działające w pVM nie mogą zawierać własnych jąder.
pVM zapewnia zaawansowaną ochronę, np. SELinux, dla ładunku wykonywanego w pVM. Szczegółowa obrona nie zezwala na dane mapowania jako wykonywalne (
neverallow execmem) i gwarantuje, że W^X przechowuje dane wszystkich typów plików.
Model zabezpieczeń
Poufność, integralność i dostępność (triada CIA) to model służący do tworzenia zasad bezpieczeństwa informacji:
- Poufność to zestaw reguł, które ograniczają dostęp do informacji.
- Całościowość to gwarancja, że informacje są wiarygodne i poprawne.
- 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 wymuszonych przez hypervisor pKVM. pKVM śledzi własność pamięci poszczególnych stron pamięci fizycznej oraz wszelkie żądania dotyczące udostępniania stron przez właścicieli. pKVM zapewnia, że tylko uprawnione procesy pVM (host i goście) mają daną stronę zmapowaną w swoich tabelach stron etapu 2, które są kontrolowane przez hypervisor. Ta architektura zapewnia, ż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 dotyczą również wszystkich elementów systemu, które wykonują operacje dostępu do pamięci w imieniu pVM, a więc urządzeń z obsługą DMA i usług działających na bardziej uprzywilejowanych poziomach. Dostawcy systemów na chipie (SoC) muszą spełnić nowy zestaw wymagań, zanim będą mogli obsługiwać pKVM. W przeciwnym razie nie możemy zagwarantować poufności.
Całościowość dotyczy danych w pamięci i obliczeń. Procesory pVM nie mogą:
- modyfikować pamięć innych bez ich zgody;
- Wpływają na wzajemny stan procesora.
Te wymagania są wymuszane przez hypervisora. Problemy dotyczące integralności danych pojawiają się jednak również w przypadku wirtualnego przechowywania danych, gdy trzeba zastosować inne rozwiązania, takie jak dm-verity lub AuthFS.
Te zasady nie różnią się od izolacji procesów oferowanej przez system Linux, w którym dostęp do stron pamięci jest kontrolowany za pomocą tabel stron etapu 1 i przełączania kontekstu jądra między procesami. Jednak część EL2 pKVM, która wymusza stosowanie tych właściwości, ma 3 rzędy mniejszej powierzchni ataku w porównaniu z całym jądrem Linuksa (około 10 tys. w porównaniu z 20 milionami wierszy kodu), co zapewnia większą pewność w przypadku przypadków użycia, które są zbyt wrażliwe, aby polegać na izolacji procesów.
Ze względu na rozmiar, pKVM nadaje się do formalnej weryfikacji. Aktywnie wspieramy badania naukowe, których celem jest formalne udowodnienie tych właściwości w przypadku binarnego pKVM.
Pozostała część tej strony dotyczy gwarancji poufności i integralności, które zapewniają poszczególne komponenty w ramach pKVM.
Hipernadzorca
pKVM to hypervisor oparty na KVM, który izoluje pVM i Androida w ramach wzajemnie nieufnych środowisk wykonawczych. Te właściwości są przechowywane w przypadku naruszenia zabezpieczeń jakiejkolwiek maszyny wirtualnej, w tym hosta. 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 czy hipernadzorca, chyba że jej właściciel wyraźnie ją udostępnisz. Reguła ta obejmuje hosta pVM i dotyczy zarówno dostępu do procesora CPU, jak i DMA.
Zanim strona używana przez pVM zostanie zwrócona do hosta, na przykład po zniszczeniu tej maszyny wirtualnej, zostanie wyczyszczona.
Pamięć wszystkich pVM-ów i oprogramowania pVM z jednego uruchomienia urządzenia jest wyczyszczona, zanim program rozruchowy systemu operacyjnego uruchomi się podczas kolejnego uruchomienia urządzenia.
Gdy podłączysz debuger sprzętowy, taki jak SJTAG, nie może ona uzyskać dostępu do swoich wcześniej wygenerowanych kluczy.
Oprogramowanie pVM nie uruchomi się, jeśli nie można zweryfikować obrazu początkowego.
Oprogramowanie pVM nie uruchamia się, jeśli integralność
instance.imgzostanie naruszona.Łańcuch certyfikatów DICE i złożone identyfikatory urządzeń (CDI) udostępnione instancji pVM mogą być wyprowadzone tylko przez tę konkretną instancję.
System operacyjny gościa
Przykładem systemu operacyjnego działającego w maszynie wirtualnej jest mikrodroid. Microdroid składa się z bootloadera opartego na U-boot, GKI, podzbioru przestrzeni użytkownika Androida oraz programu uruchamiającego ładunek. Te właściwości są zachowane w przypadku naruszenia bezpieczeństwa w dowolnym pVM, w tym w hostie. Alternatywny system operacyjny działający w pVM powinien mieć podobne właściwości.
Microdroid nie uruchomi się, jeśli nie uda się zweryfikować
boot.img,super.img,vbmeta.imglubvbmeta\_system.img.Microdroid nie uruchomi się, jeśli weryfikacja pliku APK się nie powiedzie.
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.
Mikrodroid nie uruchomi się (lub uruchomi się z nienaruszonym stanem początkowym), jeśli
instance.imgzostanie zmodyfikowany poza maszyną wirtualną gościa.Microdroid zapewnia uwierzytelnianie łańcucha rozruchu.
Każda (bez podpisu) modyfikacja obrazów dysków udostępnianych pVM gościa powoduje wystąpienie błędu wejścia-wyjścia po stronie pVM.
Łańcuch certyfikatów DICE i identyfikatory CDi dostarczone do instancji pVM mogą być wyprowadzone tylko przez tę konkretną instancję.
Dane zapisywane na zaszyfrowanym woluminie są poufne, ale nie ma ochrony przed cofnięciem na poziomie bloku szyfrowania. Ponadto dowolne zewnętrzne manipulowanie blokiem danych powoduje, że blok ten jest traktowany przez Microdroida jako śmieci, a nie jako błąd we/wy.
Android
Te właściwości są obsługiwane przez Androida jako hosta, ale nie są prawdziwe w przypadku naruszenia bezpieczeństwa hosta:
Wirtualna maszyna gościa nie może bezpośrednio wchodzić w interakcje z innymi wirtualnymi maszynami gościa (np. nawiązywać połączenia
vsock).Tylko
VirtualizationServicew maszynie wirtualnej hosta może utworzyć kanał komunikacji z maszyną wirtualną.Tylko aplikacje podpisane kluczem platformy mogą prosić o uprawnienia do tworzenia, posiadania i interakcji z pVM.
Identyfikator zwany identyfikatorem kontekstu (CID), który służy do konfigurowania połączeń
vsockmiędzy hostem a pVM, nie jest ponownie używany, gdy host pVM jest uruchomiony. Nie możesz na przykład zastąpić działającej maszyny pVM inną.
Dostępność
W kontekście maszyn wirtualnych dostępność oznacza, że host przydziela gościom wystarczającą ilość zasobów, aby mogli oni wykonywać zadania, do których zostały zaprojektowane.
Obowiązki gospodarza obejmują harmonogramowanie wirtualnych procesorów VM. KVM, w przeciwieństwie do konwencjonalnych hipernadzorców typu 1 (takich jak Xen), podejmuje wyraźną decyzję projektową o delegowaniu harmonogramowania zadań do jądra hosta. Ze względu na rozmiar i złożoność współczesnych algorytmów szeregowania ta decyzja projektowa znacznie zmniejsza wielkość zaufanej bazy obliczeniowej (TCB) i umożliwia hostowi podejmowanie trafniejszych decyzji dotyczących planowania w celu optymalizacji wydajności. Jednak szkodliwy host może zdecydować, że nigdy nie zaprosi gościa.
Podobnie pKVM deleguje obsługę przerwań fizycznych do jądra hosta, aby zmniejszyć złożoność hiperwizora i pozostawić hostowi kontrolę nad harmonogramowaniem. Dokładamy wszelkich starań, aby przekierowywanie przerwania przez gościa skutkowało tylko odmową usługi (zbyt mało, zbyt dużo lub źle przekierowane przerwania).
Na koniec proces monitora maszyny wirtualnej (VMM) hosta odpowiada za przydzielanie pamięci i udostępnianie urządzeń wirtualnych, takich jak karta sieciowa. Złośliwy VMM może wstrzymać zasoby gościa.
Chociaż pKVM nie udostępnia dostępności gościom, projekt chroni dostępność hosta przed złośliwymi gośćmi, ponieważ host może zawsze przerwać lub zakończyć sesję gościa i odzyskać zasoby.
Bezpieczny rozruch
Dane są powiązane z instancjami pVM, a bezpieczny rozruch zapewnia kontrolę dostępu do danych instancji. Pierwszy rozruch instancji udostępnia ją przez losowe generowanie ciągu solnego dla maszyny wirtualnej i wyodrębnianie z wczytanych obrazów szczegółów, takich jak weryfikacyjny klucz publiczny i hasze. Te informacje są używane do weryfikacji kolejnych uruchomień instancji pVM i upewnienia się, że sekrety instancji są udostępniane tylko obrazom, które przeszły weryfikację. Ten proces ma miejsce dla każdego etapu wczytywania w maszynie wirtualnej: oprogramowania pVM, narzędzia ABL pVM, mikrodroida itd.
Na każdym etapie wczytywania DICE udostępnia parę kluczy weryfikacyjnych, której część publiczna jest certyfikowana w certyfikacie DICE dla danego etapu. Ten klucz może się zmieniać podczas kolejnych rozruchów, dlatego wyprowadzamy też sekret do zapieczętowania, który jest stabilny dla instancji maszyny wirtualnej podczas ponownego uruchamiania i jako taki nadaje się do ochrony stanu trwałego. Tajemnica pieczętowania jest bardzo cenna dla maszyny wirtualnej, dlatego nie należy jej używać bezpośrednio. Zamiast tego klucze pieczętujące powinny być wyprowadzone z klucza tajnego pieczętującego, a klucz tajny pieczętujący powinien zostać zniszczony jak najszybciej.
Każdy etap przekazuje obiekt CBOR z zakodowanymi w sposób deterministyczny danymi do następnego etapu. Obiekt ten zawiera sekrety i łańcuch certyfikatów DICE, który zawiera nagromadzone informacje o stanie, takie jak informacje o tym, czy ostatni etap został załadowany bezpiecznie.
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 nieupoważnionym dostępem. Dane prywatne dla pVM są również unieważniane, gdy nastąpi odblokowanie urządzenia.
Po odblokowaniu właściciel urządzenia może ponownie załadować partycje, które są zwykle chronione przez weryfikację podczas uruchamiania, w tym partycje zawierające implementację pKVM. Z tego powodu pKVM na odblokowanym urządzeniu nie będzie zaufane w utrzymywaniu modelu zabezpieczeń.
Osoby z zewnątrz mogą zauważyć ten potencjalnie niebezpieczny stan, sprawdzając stan rozruchu zweryfikowanego w certyfikacie klucza.