Bezpieczeństwo

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 do pVM mogą tworzyć i przeglądać te pliki.

  • 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 prawidłowe.
  • 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 prośby właścicieli o udostępnienie stron. pKVM zapewnia, że tylko uprawnione procesy VM (gospodarz 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żąca 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.

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 tys. w porównaniu z 20 mln wierszy kodu), a więc zapewnia większą ochronę w przypadku zastosowań, które są zbyt wrażliwe na ataki, 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 nieufnych środowiskach wykonawczych. 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ł. Reguła ta 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 i oprogramowania pVM z jednego urządzenia zostaje wyczyszczona przed uruchomieniem programu rozruchowego systemu operacyjnego podczas kolejnego uruchamiania 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 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.img lub vbmeta\_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.img zostanie 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. 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ć vsockpołączenia).

  • Tylko VirtualizationService w 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) służy do konfigurowania połączeń vsock między hostem a pVM. Nie jest on 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śliwa maszyna wirtualna może odmówić udostępnienia zasobów użytkownikowi.

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 saltu dla pVM i wyodrębniane są szczegóły, takie jak klucze publiczne i sumy kontrolne, 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 wyodrębniany jest też sekret zamykający, który jest stabilny dla instancji maszyny wirtualnej podczas ponownego uruchamiania i jako taki nadaje się do ochrony stanu trwałego. Tajemnica 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, które są prywatne dla pVM, są również nieważne, 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 wdrożeniem pKVM. Dlatego pKVM na odblokowanym urządzeniu nie będzie zaufane w zakresie przestrzegania modelu zabezpieczeń.

Osoby z zewnątrz mogą zauważyć ten potencjalnie niebezpieczny stan, sprawdzając stan rozruchu zweryfikowanego w certyfikacie klucza.