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ć i przeglądać pVM.
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 korzystające z pVM nie mogą zawierać własnych jąder.
pVM zapewnia zaawansowaną ochronę, np. SELinux, dla ładunku wykonywanego w pVM. Zabezpieczenia wielowarstwowe nie zezwalają na mapowanie danych jako plików wykonywalnych (
neverallow execmem) i zapewniają, że W^X jest stosowane do 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 zbiór zasad, 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 obejmują również wszystkie elementy systemu, które wykonują operacje dostępu do pamięci w imieniu pVM, a więc urządzenia z obsługą DMA i usługi działające 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.
Integralność dotyczy danych w pamięci i obliczeń. Procesory pVM nie mogą:
- modyfikować pamięć innych bez ich zgody;
- wpływają na stan procesora innych urządzeń.
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ęść pKVM na poziomie EL2, która zapewnia te właściwości, ma o 3 rzędy wielkości mniejszą powierzchnię ataku niż cały jądro Linuksa (około 10 tysięcy w porównaniu z 20 milionami wierszy kodu), a więc zapewnia większą ochronę w przypadku zastosowań, które są zbyt wrażliwe, aby można było 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-y i Androida w ramach wzajemnie nieufnych środowisk wykonywania. Te właściwości są zachowane w przypadku naruszenia bezpieczeństwa w dowolnym pVM, w tym w hostie. Alternatywne hypervisory zgodne z AVF muszą zapewniać podobne właściwości.
pVM nie może uzyskać dostępu do strony należącej do innej istoty, takiej jak pVM lub hypervisor, chyba że właściciel strony wyraźnie ją udostępnił. Ta reguła obejmuje hosta pVM i dotyczy dostępu zarówno do procesora CPU, jak i DMA.
Zanim strona używana przez pVM zostanie zwrócona do hosta, na przykład gdy pVM zostanie zniszczony, jest 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łączony jest debuger sprzętowy, np. SJTAG, pVM nie może uzyskać dostępu do wcześniej wygenerowanych kluczy.
Oprogramowanie pVM nie uruchamia się, jeśli nie może 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
Microdroid to przykład systemu operacyjnego działającego w pVM. Microdroid składa się z bootloadera opartego na U-boot, GKI, podzbioru przestrzeni użytkownika Androida i ładowarki ładunku. 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.
Microdroid nie uruchomi się (lub uruchomi się w czystym stanie początkowym), jeśli
instance.imgzostanie zmodyfikowany poza gościnnym procesorem VM.Microdroid zapewnia uwierzytelnianie łańcucha rozruchu.
Każda (niepodpisana) modyfikacja obrazów dysków udostępnionych gościowi pVM powoduje błąd we/wy 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 zmian na poziomie bloku szyfrowania. Co więcej, inna dowolna zewnętrzna modyfikacja bloku danych powoduje, że blok ten jest traktowany przez Microdroida jako śmieci, a nie jest wykrywany jako błąd wejścia/wyjścia.
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ć
vsockpołączenia).Tylko
VirtualizationServicew hostowanym pVM może tworzyć kanał komunikacji z pVM.Tylko aplikacje podpisane kluczem platformy mogą prosić o uprawnienia do tworzenia, posiadania i interagowania 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 dla użytkowników zewnętrznych dostępność oznacza przydzielenie przez hosta wystarczających zasobów użytkownikom zewnętrznym, aby mogli oni wykonywać przypisane im zadania.
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. Biorąc pod uwagę rozmiar i złożoność dzisiejszych harmonogramistów, to rozwiązanie techniczne znacznie zmniejsza rozmiar zaufanej bazy obliczeniowej (TCB) i umożliwia hostowi podejmowanie bardziej świadomych decyzji dotyczących harmonogramu 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 zatrzymać 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. Podczas pierwszego uruchomienia instancji generowany jest losowo tajny ciąg znaków salt dla pVM oraz wyodrębnia się szczegóły, takie jak klucze publiczne i hashe weryfikacyjne, z załadowanych obrazów. 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 występuje na każdym etapie wczytywania w pVM: pVM firmware, pVM ABL, Microdroid 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 tworzony jest też sekret pieczętujący, który jest stabilny dla instancji maszyny wirtualnej podczas ponownego uruchamiania i jako taki nadaje się do ochrony stanu stał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 zaprogramować partycje, które są zwykle chronione przez weryfikowany rozruch, w tym partycje z implementacją pKVM. Dlatego pKVM na odblokowanym urządzeniu nie będzie zaufane do przestrzegania modelu zabezpieczeń.
Osoby z zewnątrz mogą zauważyć ten potencjalnie niebezpieczny stan, sprawdzając stan rozruchu zweryfikowanego w certyfikacie klucza.