Sicurezza

Per impedire l'esecuzione di payload arbitrari all'interno di una pVM, il framework di virtualizzazione di Android (AVF) utilizza un approccio alla sicurezza a più livelli in cui ogni livello aggiunge ulteriori applicazioni delle norme. Di seguito è riportato un elenco dei livelli di sicurezza AVF:

  • Android garantisce che solo le app con autorizzazioni pVM possano creare o ispezionare le pVM.

  • Bootloader: il bootloader garantisce che solo le immagini pVM firmate da Google o dai fornitori di dispositivi siano autorizzate e rispetti la procedura di Avvio verificato Android. Questa architettura implica che le app che eseguono pVM non possono raggruppare i propri kernel.

  • pVM fornisce una difesa in profondità, come con SELinux, per i payload eseguiti sulla pVM. La difesa in profondità non consente la mappatura dei dati come eseguibili (neverallow execmem) e garantisce che W^X rimanga per tutti i tipi di file.

Modello di sicurezza

Riservatezza, integrità e disponibilità (triade CIA) costituiscono un modello progettato per guidare i criteri di sicurezza delle informazioni:

  • La riservatezza è un insieme di regole che limita l'accesso alle informazioni.
  • L'integrità è la garanzia che le informazioni sono affidabili e accurate.
  • La disponibilità è una garanzia di accesso affidabile alle informazioni da parte di persone giuridiche autorizzate.

Riservatezza e integrità

La riservatezza deriva dalle proprietà di isolamento della memoria applicate dall'hypervisor pKVM. pKVM monitora la proprietà della memoria delle singole pagine di memoria fisica e le eventuali richieste dei proprietari di pagine da condividere. pKVM garantisce che solo le pVM autorizzate (host e ospiti) abbiano la pagina specifica mappata nelle tabelle di pagina della fase 2 controllate dall'hypervisor. Questa architettura garantisce che i contenuti della memoria di proprietà di una pVM rimangano privati, a meno che il proprietario non la condivida esplicitamente con un'altra pVM.

Le restrizioni per il mantenimento della riservatezza si estendono anche a qualsiasi entità nel sistema che esegue accessi alla memoria per conto di pVM, ovvero dispositivi con capacità DMA e servizi in esecuzione in livelli con più privilegi. I fornitori system-on-chip (SoC) devono soddisfare una nuova serie di requisiti prima di poter supportare pKVM. In caso contrario, non sarà possibile fornire la riservatezza.

L'integrità si applica ai dati in memoria e nel calcolo. Le pVM non possono:

  • Modificano la memoria degli altri senza consenso.
  • Influenzano a vicenda lo stato della CPU.

Questi requisiti vengono applicati dall'hypervisor. Tuttavia, si presentano anche problemi relativi all'integrità dei dati con l'archiviazione virtuale dei dati, quando è necessario applicare altre soluzioni, come dm-verity o AuthFS.

Questi principi non sono diversi dall'isolamento dei processi offerto da Linux, dove l'accesso alle pagine di memoria è controllato mediante tabelle di pagina di fase 1 e i cambi di contesto del kernel da un processo all'altro. Tuttavia, la parte EL2 di pKVM, che applica queste proprietà, ha tre ordini di grandezza in meno della superficie di attacco rispetto all'intero kernel Linux (circa 10.000 rispetto a 20 milioni di righe di codice) e quindi offre una maggiore garanzia ai casi d'uso troppo sensibili per fare affidamento sull'isolamento dei processi.

Date le sue dimensioni, pKVM si presta alla verifica formale. Sosteniamo attivamente la ricerca accademica, che mira a dimostrare formalmente queste proprietà sull'effettivo codice binario pKVM.

Il resto di questa pagina tratta le garanzie di riservatezza e integrità fornite da ogni componente di una pKVM.

Hypervisor

pKVM è un hypervisor basato su KVM che isola le pVM e Android in ambienti di esecuzione muti attendibili. Queste proprietà rimangono valide in caso di compromissione all'interno di qualsiasi pVM, incluso l'host. Gli hypervisor alternativi conformi alle AVF devono fornire proprietà simili.

  • Una pVM non può accedere a una pagina appartenente a un'altra entità, come una pVM o hypervisor, a meno che non venga condivisa esplicitamente dal proprietario della pagina. Questa regola include la pVM dell'host e si applica sia agli accessi alla CPU che al DMA.

  • Prima che una pagina utilizzata da una pVM venga restituita all'host, ad esempio quando viene eliminata, questa viene cancellata.

  • La memoria di tutte le pVM e del firmware pVM dall'avvio di un dispositivo viene cancellata prima dell'esecuzione del bootloader del sistema operativo al successivo avvio del dispositivo.

  • Quando viene collegato un debugger hardware, come SJTAG, una pVM non può accedere alle chiavi utilizzate in precedenza.

  • Il firmware della pVM non si avvia se non riesce a verificare l'immagine iniziale.

  • Il firmware della pVM non si avvia se l'integrità di instance.img è compromessa.

  • La catena di certificati DICE e gli identificatori di dispositivi composti (CDI) forniti a un'istanza pVM possono essere derivati solo da quell'istanza specifica.

Sistema operativo guest

Microdroid è un esempio di sistema operativo in esecuzione all'interno di una pVM. Microdroid è costituito da un bootloader basato su U-boot, GKI, un sottoinsieme dello spazio utente Android e un launcher di payload. Queste proprietà si applicano in caso di compromissione all'interno di qualsiasi pVM, incluso l'host. I sistemi operativi alternativi in esecuzione in una pVM dovrebbero fornire proprietà simili.

  • Il microdroid non si avvia se non è possibile verificare boot.img, super.img, vbmeta.img o vbmeta\_system.img.

  • Microdroid non si avvia se la verifica dell'APK non va a buon fine.

  • La stessa istanza di Microdroid non si avvia anche se l'APK è stato aggiornato.

  • Microdroid non si avvia se uno degli APEX non supera la verifica.

  • Microdroid non si avvia (o si avvia con uno stato iniziale pulito) se instance.img viene modificato al di fuori della pVM guest.

  • Il microdroide fornisce l'attestazione della catena di avvio.

  • Qualsiasi modifica (non firmata) alle immagini disco condivise con la pVM guest genera un errore di I/O sul lato pVM.

  • La catena di certificati DICE e i CDI forniti a un'istanza pVM possono essere derivati solo da quell'istanza specifica.

  • Le scritture in un volume di archiviazione criptato sono riservate, ma non esiste una protezione rollback alla granularità di un blocco di crittografia. Inoltre, altre manomissioni esterne arbitrarie di un blocco dati fanno sì che il blocco venga visualizzato come rifiuto in Microdroid, anziché essere rilevato esplicitamente come un errore di I/O.

Android

Si tratta di proprietà gestite da Android come host, ma non valide in caso di compromissione dell'host:

  • Una pVM guest non può interagire direttamente con altre pVM guest, ad esempio per creare una connessione vsock.

  • Solo VirtualizationService nella pVM host può creare un canale di comunicazione verso una pVM.

  • Solo le app firmate con la chiave della piattaforma possono richiedere l'autorizzazione per creare, possedere o interagire con le pVM.

  • L'identificatore, chiamato identificatore di contesto (CID), utilizzato per configurare le connessioni vsock tra l'host e la VM pVM non viene riutilizzato quando la pVM dell'host è in esecuzione. Ad esempio, non puoi sostituire una pVM in esecuzione con un'altra.

Disponibilità

Nel contesto delle pVM, con disponibilità si intende l'host che assegna risorse sufficienti ai guest affinché gli ospiti possano eseguire le attività per cui sono stati progettati.

Le responsabilità dell'host includono la pianificazione delle CPU virtuali della pVM. KVM, a differenza degli hypervisor convenzionali di tipo 1 (come Xen), la decisione di progettazione esplicita di delegare la pianificazione dei carichi di lavoro al kernel host. Date le dimensioni e la complessità degli odierni scheduler, questa decisione di progettazione riduce significativamente le dimensioni della base di computing attendibile (TCB) e consente all'host di prendere decisioni di pianificazione più informate per ottimizzare le prestazioni. Tuttavia, un host dannoso può decidere di non pianificare mai un ospite.

Analogamente, pKVM delega anche la gestione degli interrupt fisici al kernel host per ridurre la complessità dell'hypervisor e lasciare che l'host si occupi della pianificazione. È necessario fare in modo che l'inoltro di interruzioni relative agli ospiti provochi solo un denial of service (numero insufficiente, eccessivo o errato).

Infine, il processo di monitoraggio delle macchine virtuali (VMM) dell'host è responsabile dell'allocazione della memoria e della fornitura di dispositivi virtuali, ad esempio una scheda di rete. Un VMM dannoso può trattenere risorse dall'ospite.

Sebbene pKVM non fornisca disponibilità agli ospiti, il design protegge la disponibilità dell'host da ospiti malintenzionati, poiché l'host può sempre prerilasciare o terminare un guest e recuperare le sue risorse.

Avvio protetto

I dati sono collegati alle istanze di una pVM e l'avvio protetto garantisce che l'accesso ai dati di un'istanza possa essere controllato. Il primo avvio di un'istanza ne esegue il provisioning generando in modo casuale un sale secret per la pVM ed estraendo dettagli, come chiavi pubbliche e hash di verifica, dalle immagini caricate. Queste informazioni vengono utilizzate per verificare gli avvii successivi dell'istanza pVM e garantire che i secret dell'istanza vengano rilasciati solo per le immagini che superano la verifica. Questo processo si verifica per ogni fase di caricamento all'interno della pVM: firmware pVM, pVM ABL, Microdroid e così via.

DICE fornisce a ogni fase di caricamento una coppia di chiavi di attestazione, la cui parte pubblica è certificata nel certificato DICE per quella fase. Questa coppia di chiavi può cambiare da un avvio all'altro, per cui viene derivato anche un secret di tenuta stabile per l'istanza VM ai riavvii e, come tale, adatto alla protezione dello stato permanente. Il secret di tenuta è molto importante per la VM, quindi non deve essere utilizzato direttamente. Le chiavi di sigillatura dovrebbero invece essere ricavate dal secret di sigillatura e distruggerlo il prima possibile.

Ogni fase passa un oggetto CBOR con codifica deterministica alla fase successiva. Questo oggetto contiene secret e la catena di certificati DICE, che contiene informazioni sullo stato accumulate, ad esempio se l'ultima fase è stata caricata in modo sicuro.

Dispositivi sbloccati

Quando un dispositivo viene sbloccato con fastboot oem unlock, i dati utente vengono cancellati. Questo processo protegge i dati utente da accessi non autorizzati. I dati privati per una pVM vengono invalidati anche quando si verifica lo sblocco di un dispositivo.

Una volta sbloccato, il proprietario del dispositivo può eseguire nuovamente il flashing delle partizioni solitamente protette da avvio verificato, incluse le partizioni che contengono l'implementazione pKVM. Di conseguenza, la pKVM su un dispositivo sbloccato non sarà considerata attendibile per mantenere il modello di sicurezza.

Le parti remote possono osservare questo stato potenzialmente non sicuro esaminando lo stato di avvio verificato del dispositivo in un certificato di attestazione della chiave.