Casi d'uso

Questo documento contiene casi d'uso comuni per AVF.

Compilazione isolata

In qualità di enclave sicura dal punto di vista del software, una VM protetta fornisce un ambiente sicuro per compilare il codice sensibile alla 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 è in APEX com.android.compos. Questo componente è facoltativo e può essere incluso utilizzando un makefile.

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. Tutti i file di input e i parametri si presume provengano da un client non attendibile e devono essere verificati e sottoposti a controlli 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'algoritmofs-verity. Affinché un file di input diventi disponibile nella VM, il suo hash di root 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 tramite firma.