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
per compilare codice sensibile per la sicurezza. Questo ambiente consente di spostare
di bootclasspath e JAR del server di sistema (attivati da un aggiornamento APEX)
l'avvio anticipato prima del riavvio e riduce notevolmente
aggiornare il tempo di avvio.
L'implementazione è
com.android.compos APEX. 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 da soli; Android, in quanto client non attendibile, non è in grado di modificare la compilazione l'output in modo diverso dall'errore (quando Android torna all'avvio) compilazione dell'orario).
Il servizio di compilazione nella VM genera una firma solo se non sono presenti durante l'intera compilazione. Android può recuperare la chiave pubblica da la VM per la verifica della firma.
La chiave della VM viene generata dal profilo DICE della VM, definito dagli APEX e APK montati sulla VM, oltre ad altri parametri VM, come la possibilità di eseguire il debug.
Per determinare se la chiave pubblica non proviene da una VM imprevista, Android si avvia sulla VM per determinare se la chiave è corretta. La VM viene avviata in fase iniziale dopo ogni aggiornamento APEX.
Con l'Avvio verificato di Protected VM, il servizio di compilazione esegue solo
le API nel tuo codice. Il codice può quindi determinare di accettare solo gli input che soddisfano
determinate condizioni, ad esempio, accetta un file di input solo nel punto in cui il suo nome
il digest fs-verity è definito in una lista consentita.
Tutte le API esposte dalla VM sono superfici di attacco. Tutti i file di input e si presume che i parametri provengano da un client non attendibile, che devono essere verificati e esaminati prima dell'elaborazione.
L'integrità dei file di input/output viene verificata dalla VM, con i file archiviati su Android come server di file non attendibile, come indicato di seguito:
- I contenuti di un file di input devono essere verificati prima dell'uso mediante il metodo
Algoritmo
fs-verity. Affinché un file di input diventi disponibile nella VM, l'hash radice deve essere fornito in un contenitore (APK) che contribuisce alla Profilo DICE della VM. Con l'hash root attendibile, un utente malintenzionato non può manomettere con l'input senza che vengano rilevati. - L'integrità del file di output deve essere mantenuta nella VM. Anche se
un file di output viene archiviato su Android, durante la generazione,
viene mantenuta con lo stesso formato ad albero
fs-verity, ma può essere eseguita in modo dinamico aggiornato. Il file di output finale può essere identificato con l'hash radice, che è isolato nella VM. Il servizio nella VM protegge l'output i file per firma.