Casi d'uso

Questo documento contiene casi d'uso comuni per la funzionalità AVF.

Compilazione isolata

Essendo un'enclave sicura dal software, una VM protetta offre un ambiente sicuro in cui compilare il codice sensibile per la sicurezza. Questo ambiente consente di spostare la compilazione dei file JAR di bootclasspath e del server di sistema (attivata da un aggiornamento APEX) dall'avvio iniziale a prima del riavvio e riduce notevolmente il tempo di avvio post-aggiornamento APEX.

L'implementazione è nell'APEX com.android.compos. Questo componente è facoltativo e può essere incluso utilizzando un makefile.

Compilazione isolata

Figura 1. Compilazione di JAR sugli aggiornamenti di Mainline

L'obiettivo di sicurezza è compilare in modo veritiero l'input verificato e produrre l'output in isolamento. Android, in quanto client non attendibile, non può alterare l'output della compilazione in alcun modo diverso dal causare un errore (quando Android torna alla compilazione al momento dell'avvio).

Il servizio di compilazione nella VM genera una firma solo se non si verificano errori durante l'intera compilazione. Android può recuperare la chiave pubblica dalla VM per la verifica della firma.

La chiave della VM viene generata dal profilo DICE della VM, definito dagli APEX e dagli APK montati sulla VM, oltre ad altri parametri della VM, come la possibilità di eseguire il debug.

Per determinare se la chiave pubblica non proviene da una VM inaspettata, Android avvia la VM per verificare se la chiave è corretta. La VM viene avviata all'avvio iniziale dopo ogni aggiornamento di APEX.

Con l'avvio verificato della VM protetta, il servizio di compilazione esegue solo codice verificato. Il codice può quindi decidere di accettare solo input che soddisfano determinate condizioni, ad esempio accettare un file di input solo se il nome e il digest fs-verity sono definiti in una lista consentita.

Eventuali API esposte dalla VM sono superfici di attacco. Si presume che tutti i file e i parametri di input provengano da un client non attendibile e che devono essere verificati e controllati prima dell'elaborazione.

L'integrità dei file di input/output viene verificata dalla VM, con i file archiviati su Android come file server non attendibile, come segue:

  • I contenuti di un file di input devono essere verificati prima dell'uso utilizzando l'algoritmo fs-verity. Affinché un file di input diventi disponibile nella VM, il relativo hash radice deve essere fornito in un contenitore (APK) che contribuisce al profilo DICE della VM. Con l'hash root attendibile, un utente malintenzionato non può manomettere l'input senza essere rilevato.
  • L'integrità del file di output deve essere mantenuta nella VM. Anche se un file di output viene archiviato su Android, durante la generazione l'integrità viene mantenuta con lo stesso formato dell'albero fs-verity, ma può essere aggiornata dinamicamente. Il file di output finale può essere identificato con l'hash principale, che è isolato nella VM. Il servizio nella VM protegge i file di output per firma.