Przykłady zastosowań

Ten dokument zawiera typowe zastosowania AVF.

Kompilacja izolowana

Jest to enklawa zabezpieczona programowo, dzięki której chroniona maszyna wirtualna zapewnia bezpieczne środowisko do kompilowania kodu zapewniającego bezpieczeństwo. To środowisko umożliwia przeniesienie kompilacji bootclasspath i plików JAR serwera systemu (wywoływanych przez aktualizację APEX) z fazy wczesnego uruchamiania do fazy przed ponownym uruchomieniem. Dzięki temu znacznie skraca się czas uruchamiania po aktualizacji APEX.

Implementacja jest w wersji com.android.compos APEX. Ten komponent jest opcjonalny i można go uwzględnić za pomocą makefile.

Kompilacja izolowana

Rysunek 1. Kompilowanie plików JAR w aktualizacjach Mainline

Celem bezpieczeństwa jest rzetelne skompilowanie zweryfikowanych danych wejściowych i wygenerowanie danych wyjściowych w izolacji. Android jako niesprawdzony klient nie może zmienić danych wyjściowych kompilacji w żaden inny sposób niż przez spowodowanie jej niepowodzenia (gdy Android przełączy się na kompilację w czasie uruchamiania).

Usługa kompilacji na maszynie wirtualnej generuje podpis tylko wtedy, gdy nie wystąpił żaden błąd podczas całego procesu kompilacji. Android może pobrać klucz publiczny z wirtualnej maszyny na potrzeby weryfikacji podpisu.

Klucz maszyny wirtualnej jest generowany na podstawie profilu DICE maszyny wirtualnej zdefiniowanego przez zamontowane w niej pliki APEX i APK, a także innych parametrów maszyny wirtualnej, takich jak możliwość debugowania.

Aby ustalić, czy klucz publiczny nie pochodzi z nieoczekiwanej maszyny wirtualnej, Android uruchamia maszynę wirtualną w celu sprawdzenia, czy klucz jest prawidłowy. Maszyna wirtualna jest uruchamiana przy wczesnym uruchomieniu po każdej aktualizacji APEX.

Dzięki zweryfikowanemu rozruchowi chronionej maszyny wirtualnej usługa kompilacji uruchamia tylko zweryfikowany kod. Kod może więc akceptować tylko dane wejściowe, które spełniają określone warunki, na przykład akceptować plik wejściowy tylko wtedy, gdy jego nazwa i fs-verity digest są zdefiniowane na liście dozwolonych.

Wszystkie ujawnione interfejsy API z maszyny wirtualnej są powierzchniami ataku. Wszystkie pliki wejściowe i parametry są uznawane za pochodzące z niezaufanego klienta i przed przetworzeniem muszą zostać zweryfikowane.

Integralność pliku wejściowego/wyjściowego jest weryfikowana przez maszynę wirtualną, przy czym pliki są przechowywane na Androidzie jako niezaufany serwer plików w ten sposób:

  • Treść pliku wejściowego musi zostać zweryfikowana przed użyciem za pomocą algorytmu fs-verity. Aby plik wejściowy został udostępniony w maszynie wirtualnej, jego hasz główny musi być podany w kontenerze (APK), który wspiera profil DICE maszyny. Dzięki zaufanemu łańcuchowi głównyemu osoba przeprowadzająca atak nie może modyfikować danych wejściowych bez wykrycia.
  • Integralność pliku wyjściowego musi być zachowana na maszynie wirtualnej. Nawet jeśli plik wyjściowy jest przechowywany na urządzeniu z Androidem, podczas generowania jego integralność jest zachowana w tym samym formacie drzewa fs-verity, ale może być dynamicznie aktualizowana. Ostateczny plik wyjściowy można zidentyfikować za pomocą hasha głównego, który jest izolowany w maszynie wirtualnej. Usługa na maszynie wirtualnej chroni pliki wyjściowe za pomocą podpisu.