Przypadki użycia

Ten dokument zawiera typowe zastosowania AVF.

Kompilacja izolowana

Chroniony komputer z systemem operacyjnym to enklawa oprogramowania zapewniającego bezpieczeństwo, która zapewnia bezpieczne środowisko do kompilowania kodu o znaczeniu krytycznym dla bezpieczeństwa. To środowisko umożliwia przeniesienie kompilacji bootclasspath i plików JAR serwera systemowego (wywoływanych przez aktualizację APEX) z fazy wczesnego uruchamiania do fazy przed ponownym uruchomieniem, a także znacznie skraca czas uruchamiania po aktualizacji APEX.

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

Kompilacja izolowana

Rysunek 1. Kompilowanie plików JAR w ramach aktualizacji Mainline

Celem bezpieczeństwa jest rzetelne skompilowanie zweryfikowanych danych wejściowych i utworzenie 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 podczas kompilacji nie wystąpił żaden błąd. 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 sprawdzić, czy klucz publiczny nie pochodzi z nieoczekiwanej maszyny wirtualnej, Android uruchamia tę maszynę, aby sprawdzić, czy klucz jest prawidłowy. Po każdej aktualizacji APEX maszyna wirtualna jest uruchamiana w ramach wczesnego uruchamiania.

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 interfejsy API dostępne z maszyny wirtualnej są powierzchniami ataków. Wszystkie pliki wejściowe i parametry są uznawane za pochodzące z niezaufanego klienta i przed przetworzeniem muszą zostać zweryfikowane.

Integralność plików wejściowych i wyjściowych jest weryfikowana przez maszynę wirtualną, a pliki są przechowywane na Androidzie jako niezaufanym serwerze 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 był dostępny w VM, jego hasz główny musi być podany w kontenerze (APK), który przyczynia się do profilu DICE VM. Dzięki zaufanemu haszowi głównemu osoba przeprowadzająca atak nie może bez wykrycia modyfikować danych wejściowych.
  • 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 w maszynie wirtualnej chroni pliki wyjściowe za pomocą podpisu.