Casi d'uso

Questo documento contiene casi d'uso comuni per AVF.

Compilazione isolata

Essendo un'enclave sicura dal punto di vista software, una VM protetta fornisce un ambiente sicuro per compilare codice sensibile alla sicurezza. Questo ambiente consente di spostare la compilazione del bootclasspath e dei JAR del server di sistema (attivati ​​da un aggiornamento APEX) dall'avvio anticipato a prima del riavvio e riduce significativamente il tempo di avvio successivo all'aggiornamento APEX.

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

Compilazione isolata

Figura 1. Compilazione di JAR sugli aggiornamenti Mainline

L'obiettivo della sicurezza è compilare in modo veritiero l'input verificato e produrre l'output in modo isolato; Android come client non attendibile non può alterare l'output della compilazione in alcun modo se non provocandone il fallimento (quando Android torna alla compilazione all'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 debug.

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

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

Tutte le API esposte dalla VM sono superfici di attacco. Si presuppone che tutti i file di input e i parametri provengano da un client non attendibile e 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:

  • Il contenuto di un file di input deve essere verificato prima dell'uso utilizzando l'algoritmo fs-verity . Affinché un file di input diventi disponibile nella VM, il suo hash 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 è archiviato su Android, durante la generazione l'integrità viene mantenuta con lo stesso formato fs-verity tree ma può essere aggiornata dinamicamente. Il file di output finale può essere identificato con l'hash root, che è isolato nella VM. Il servizio nella VM protegge i file di output tramite firma.