Casi d'uso

Questa pagina contiene casi d'uso comuni per AVF.

Compilazione isolata

In quanto enclave protetta dal software, una macchina virtuale (VM) protetta fornisce un ambiente sicuro per compilare codice sensibile alla sicurezza. Questo ambiente consente di spostare la compilazione dei file JAR bootclasspath e del server di sistema (attivata da un aggiornamento APEX) dall'avvio anticipato a prima del riavvio e riduce significativamente il tempo di avvio post-aggiornamento APEX.

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

Compilazione isolata

Figura 1. Compilazione di file JAR sugli aggiornamenti Mainline. Compilazione di file JAR negli aggiornamenti Mainline

L'obiettivo di sicurezza è compilare in modo veritiero l'input verificato e produrre l'output in isolamento; Android come client non attendibile non può alterare la compilazione in alcun modo, se non causarne l'errore (quando Android esegue il fallback 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 imprevista, Android avvia la VM per verificare 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. Di conseguenza, il codice può determinare di accettare solo input che soddisfano determinate condizioni, ad esempio accettare un file di input solo se il suo nome e il digest fs-verity sono definiti in una lista consentita.

Qualsiasi API esposta dalla VM è una superficie di attacco. Si presume 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 e output viene verificata dalla VM, con i file archiviati su Android come server di file non attendibile, nel seguente modo:

  • 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 radice deve essere fornito in un container (APK) che contribuisce al profilo DICE della VM. Con l'hash della radice attendibile, un 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 è memorizzato su Android, durante la generazione l'integrità viene mantenuta con lo stesso formato ad albero fs-verity, ma può essere aggiornata dinamicamente. Il file di output finale può essere identificato con l'hash radice, che è isolato nella VM. Il servizio nella VM protegge i file di output tramite firma.

Ambiente di sviluppo Linux

Android è sempre stato l'unico sistema operativo principale che non consente agli utenti di sviluppare app sulla piattaforma stessa. Con l'introduzione dell'ambiente di sviluppo Linux, il nostro obiettivo è fornire un ambiente di sviluppo basato su Linux agli utenti Android che sono sviluppatori. In futuro, prevediamo di ampliare l'impegno per consentire ai nostri partner di implementare casi d'uso innovativi delle VM, come l'esecuzione di app con interfaccia utente grafica e persino di giochi.

L'ambiente di sviluppo Linux è disponibile su alcuni dispositivi e viene eseguito in una macchina virtuale non protetta.

Caso d'uso dell'ambiente di sviluppo Linux

Figura 2. Caso d'uso dell'ambiente di sviluppo Linux.

Il flusso generale è il seguente:

  1. Per utilizzare l'ambiente di sviluppo Linux, attiva le opzioni sviluppatore.
  2. Dopo aver attivato le opzioni sviluppatore, l'app Terminale viene visualizzata nel launcher della schermata Home.
  3. Avvia l'app Terminale da Avvio app.
  4. Se necessario, l'app Terminal scarica l'immagine del sistema operativo da Google Play.
  5. L'app Terminale utilizza Android Virtualization Framework (AVF) per creare una macchina virtuale (VM).
  6. AVF esegue quindi la VM con l'immagine del sistema operativo.
  7. La macchina virtuale avvia il sistema operativo dall'immagine.
  8. Dopo l'avvio della VM, WebView nell'app Terminale si connette a un servizio web nella macchina virtuale. Questo servizio fornisce l'accesso al terminale tramite HTTP.
  9. Interagisci con il terminale inserendo comandi e visualizzando l'output nell'app.

I componenti di alto livello della VM Linux sono i seguenti:

  • App Terminale:un'applicazione Android che fornisce un'interfaccia di terminale. Utilizza una WebView per connettersi a un servizio web in esecuzione nella VM per l'interazione. Questa app è disattivata per impostazione predefinita. Attivalo nelle Impostazioni sviluppatore.
  • Framework di virtualizzazione di Android (AVF): il sottosistema esistente di Android per la creazione e la gestione di VM. Richiede modifiche minime per supportare immagini del sistema operativo personalizzate per questa funzionalità.
  • macchina virtuale:una VM generata da AVF. Ospita il servizio terminale e AVF lo crea appositamente per la funzionalità dell'app Terminale.
  • Immagine del sistema operativo:un'immagine del sistema operativo basata su Debian leggermente modificata da Debian upstream. L'app Terminal scarica questa immagine da un server Google esterno. Funge da base per il funzionamento della VM.
  • Guest Agent: nuovo software nella VM. Comunica lo stato del sistema operativo ad AVF e fornisce il controllo della macchina virtuale.
  • ttyd: software open source in esecuzione nella VM che implementa l'emulazione del terminale tramite HTTP. Il componente WebView dell'app Terminal si connette.
  • Tethering Manager:un sottosistema Android esistente. Fornisce l'accesso alla rete alla macchina virtuale eseguendo il tethering della VM al dispositivo Android.

Sicurezza dei contenuti sul dispositivo

Content Safety On-device è una soluzione per la sicurezza dei contenuti che tutela la privacy creata dal team di Content Safety On-device. Esegue la classificazione della sicurezza dei contenuti per vari prodotti Google su dispositivi proprietari/di terze parti e protegge oltre 1 miliardo di utenti da contenuti illeciti, senza richiedere l'invio dei dati utente ai server di Google. È progettato per rispettare i principi di Private Compute Core (PCC) per garantire una comunicazione trasparente e rispettosa della privacy tra il client, la macchina virtuale (VM) e impedire qualsiasi esfiltrazione dei dati utente. Può essere utilizzato per attività quali l'attivazione del rilevamento abusi sui dispositivi, come il rilevamento minacce in tempo reale di Play Protect.

In questo caso d'uso, il sistema utilizza macchine virtuali protette per eseguire la classificazione dei modelli per il rilevamento minacce in tempo reale di Play Protect, il che migliora significativamente la sicurezza dei suoi modelli e delle sue protezioni. In questo modo si impedisce il reverse engineering e la manipolazione da parte degli autori degli attacchi, anche sui dispositivi con rooting, garantendo che venga eseguito solo il codice approvato e che le sue operazioni siano nascoste ai processi esterni.

I flussi di alto livello sono i seguenti:

  1. Il rilevamento minacce in tempo reale esegue il ping di Private Compute Services per avviare la VM. Private Compute Services è un intermediario incentrato sulla privacy tra il PCC e il server cloud
  2. Private Compute Services avvia la VM e recupera la relativa chiave pubblica
  3. Private Compute Services trasferisce la proprietà della VM al rilevamento minacce in tempo reale di Play Protect
  4. Private Compute Services invia l'attestazione e la chiave pubblica al server
  5. Il server verifica l'attestazione e cripta le protezioni con la chiave pubblica della VM
  6. Il server invia quindi le protezioni criptate al dispositivo
  7. Dopodiché, il rilevamento minacce in tempo reale sul dispositivo può utilizzare la protezione criptata all'interno della VM. La VM è l'unica entità con la chiave privata che può decriptare le protezioni

I componenti di alto livello sono i seguenti:

  • Server: cripta e distribuisci protezioni criptate alla VM
  • Private Compute Services: utilizzato per avviare la VM e mediare la comunicazione con la VM e mostrare la trasparenza che nessun dato utente passa attraverso Astrea al server
  • Rilevamento minacce in tempo reale di Play Protect:
    • Contiene e utilizza classificatori di modelli forniti da Content Safety sul dispositivo
    • Accetta la proprietà della VM e la conserva per l'utilizzo della classificazione
    • Avvia e arresta la VM in base alle esigenze.