Przypadki użycia

Zadbaj o dobrą organizację dzięki kolekcji Zapisuj i kategoryzuj treści zgodnie ze swoimi preferencjami.

Ten dokument zawiera typowe przypadki użycia AVF.

Izolowana kompilacja

Jako enklawa bezpieczna programowo, chroniona maszyna wirtualna zapewnia bezpieczne środowisko do kompilowania kodu wrażliwego na zabezpieczenia. To środowisko umożliwia przeniesienie kompilacji bootclasspath i plików JAR serwera systemowego (wyzwolonych przez aktualizację APEX) z wczesnego rozruchu na czas przed ponownym uruchomieniem i znacznie skraca czas rozruchu po aktualizacji APEX.

Implementacja znajduje się w APEX com.android.compos . Ten składnik jest opcjonalny i można go dołączyć za pomocą pliku makefile .

Izolowana kompilacja

Rysunek 1. Kompilowanie plików JAR w aktualizacjach Mainline

Celem bezpieczeństwa jest wierne skompilowanie zweryfikowanych danych wejściowych i wytworzenie danych wyjściowych w izolacji; Android jako niezaufany klient nie może zmienić danych wyjściowych kompilacji w żaden inny sposób niż spowodowanie jej niepowodzenia (gdy system Android powraca do kompilacji podczas rozruchu).

Usługa kompilacji w maszynie wirtualnej generuje podpis tylko wtedy, gdy podczas całej kompilacji nie ma błędu. Android może pobrać klucz publiczny z maszyny wirtualnej w celu weryfikacji podpisu.

Klucz maszyny wirtualnej jest generowany na podstawie profilu DICE maszyny wirtualnej, zdefiniowanego przez APEX i pakiety APK zamontowane na maszynie wirtualnej, oprócz innych parametrów maszyny wirtualnej, takich jak możliwość debugowania.

Aby ustalić, czy klucz publiczny nie pochodzi z nieoczekiwanej maszyny wirtualnej, system Android uruchamia maszynę wirtualną w celu ustalenia, czy klucz jest poprawny. Maszyna wirtualna jest uruchamiana przy wczesnym rozruchu po każdej aktualizacji APEX.

W przypadku zweryfikowanego rozruchu chronionej maszyny wirtualnej usługa kompilacji uruchamia tylko zweryfikowany kod. Kod może zatem określić, że akceptuje tylko dane wejściowe, które spełniają określone warunki, na przykład akceptują plik wejściowy tylko wtedy, gdy jego nazwa i skrót fs-verity są zdefiniowane na liście dozwolonych.

Wszystkie ujawnione interfejsy API z maszyny wirtualnej są powierzchniami ataku. Zakłada się, że wszystkie pliki wejściowe i parametry pochodzą od niezaufanego klienta i muszą zostać zweryfikowane i sprawdzone przed przetwarzaniem.

Integralność plików wejściowych/wyjściowych jest weryfikowana przez maszynę wirtualną, a pliki są przechowywane w systemie Android jako niezaufany serwer plików w następujący sposób:

  • Zawartość pliku wejściowego musi zostać zweryfikowana przed użyciem przy użyciu algorytmu fs-verity . Aby plik wejściowy był dostępny w maszynie wirtualnej, jego główny skrót musi być dostarczony w kontenerze (APK), który ma udział w profilu DICE maszyny wirtualnej. Dzięki zaufanemu hashowi root atakujący nie może manipulować danymi wejściowymi bez wykrycia.
  • Integralność pliku wyjściowego musi być zachowana w maszynie wirtualnej. Nawet jeśli plik wyjściowy jest przechowywany w systemie Android, podczas generowania integralność jest zachowywana przy użyciu tego samego formatu drzewa fs-verity , ale można go dynamicznie aktualizować. Ostateczny plik wyjściowy można zidentyfikować za pomocą głównego skrótu, który jest izolowany w maszynie wirtualnej. Usługa w maszynie wirtualnej chroni pliki wyjściowe za pomocą podpisu.