Sicurezza

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

  • Android garantisce che solo le app con autorizzazioni per le VM private siano autorizzate a creare o ispezionare le VM private.

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

  • La pVM fornisce una difesa in profondità, ad esempio con SELinux, per i payload eseguiti nella pVM. La difesa in profondità non consente di mappare i dati come eseguibili (neverallow execmem) e garantisce che W^X sia valido per tutti i tipi di file.

Modello di sicurezza

La riservatezza, l'integrità e la disponibilità (triade CIA) costituiscono un modello pensato per orientare 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 siano attendibili 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 qualsiasi richiesta dei proprietari di pagine da condividere. pKVM garantisce che solo le pVM autorizzate (host ed esterne) abbiano la pagina specificata mappata nelle tabelle di pagine di secondo livello controllate dall'hypervisor. Questa architettura prevede che i contenuti della memoria di proprietà di una VM privata rimangano privati, a meno che il proprietario non la condivida esplicitamente con un'altra VM privata.

Le restrizioni per il mantenimento della riservatezza si applicano anche a qualsiasi entità nel sistema che esegue accessi alla memoria per conto delle pVM, ovvero dispositivi e servizi compatibili con DMA in esecuzione in livelli più privilegiati. I fornitori di SoC (System-on-Chip) devono soddisfare una nuova serie di requisiti prima di poter supportare la pKVM. In caso contrario, non è possibile garantire la riservatezza.

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

  • Modificare la memoria l'uno dell'altro senza consenso.
  • Influenzano lo stato della CPU l'uno dell'altro.

Questi requisiti vengono applicati dall'hypervisor. Tuttavia, i problemi relativi all'integrità dei dati si verificano anche con lo spazio di archiviazione dei dati virtuali quando devono essere applicate 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 con le tabelle di pagine di primo livello e il kernel esegue il contesto tra i processi. Tuttavia, la parte EL2 di pKVM, che applica queste proprietà, ha un'area di attacco tre ordini di grandezza inferiore rispetto all'intero kernel di Linux (circa 10.000 rispetto a 20 milioni di righe di codice) e pertanto offre una garanzia maggiore per i casi d'uso troppo sensibili per fare affidamento sull'isolamento dei processi.

Date le sue dimensioni, il pKVM si presta alla verifica formale. Stiamo supportando attivamente la ricerca accademica, che mira a dimostrare formalmente queste proprietà sul codice binario pKVM effettivo.

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

Hypervisor

pKVM è un hypervisor basato su KVM che isola le pVM e Android in ambienti di esecuzione mutuamente non attendibili. Queste proprietà si applicano in caso di compromissione all'interno di qualsiasi VM privata, incluso l'host. Gli hypervisor alternativi conformi all'AVF devono fornire proprietà simili.

  • Una VM privata non può accedere a una pagina appartenente a un'altra entità, ad esempio un'altra VM privata o un ipervisore, a meno che non sia stata condivisa esplicitamente dal proprietario della pagina. Questa regola include la pVM host e si applica sia agli accessi CPU che DMA.

  • Prima che una pagina utilizzata da una VM personale venga restituita all'host, ad esempio quando la VM personale viene distrutta, viene cancellata.

  • La memoria di tutte le pVM e il firmware delle pVM di un avvio del dispositivo vengono cancellati prima dell'esecuzione del bootloader del sistema operativo nell'avvio successivo del dispositivo.

  • Quando è collegato un debugger hardware, come SJTAG, una pVM non può accedere alle sue chiavi coniate 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à del instance.img è compromessa.

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

Sistema operativo guest

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

  • 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 verrà avviata 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.

  • Microdroid fornisce l'attestazione alla catena di avvio.

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

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

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

Android

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

  • Una VM guest non può interagire direttamente con altre VM guest (ad esempio per effettuare una vsock connessione).

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

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

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

Disponibilità

Nel contesto delle pVM, la disponibilità si riferisce all'allocazione da parte dell'host di risorse sufficienti agli ospiti in modo che possano svolgere le attività per le quali sono progettate.

Le responsabilità dell'host includono la pianificazione delle CPU virtuali della pVM. KVM, diversamente dagli hypervisor di tipo 1 convenzionali (come Xen), prende la decisione di progettazione esplicita di delegare la pianificazione del carico di lavoro al kernel host. Date le dimensioni e la complessità degli attuali pianificatori, questa decisione di progettazione riduce notevolmente le dimensioni della base di calcolo attendibile (TCB) e consente all'host di prendere decisioni di pianificazione più consapevoli per ottimizzare le prestazioni. Tuttavia, un host malintenzionato può scegliere di non pianificare mai un ospite.

Analogamente, pKVM delega anche la gestione delle interruzioni fisiche al kernel dell'host per ridurre la complessità dell'hypervisor e lasciare all'host la responsabilità della pianificazione. Viene fatto il possibile per garantire che il reindirizzamento delle interruzioni degli ospiti provochi solo un rifiuto di servizio (interruzioni troppo poche, troppe o con instradamento errato).

Infine, il processo del monitor delle macchine virtuali (VMM) dell'host è responsabile dell'allocazione della memoria e della fornitura di dispositivi virtuali, come una scheda di rete. Un VMM malevolo può trattenere le risorse dall'ospite.

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

Avvio protetto

I dati sono associati alle istanze di una pVM e il boot sicuro 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 valore di salt segreto per la pVM ed estraendo dettagli, come chiavi pubbliche di verifica e hash, 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 alle immagini che superano la verifica. Questo procedura si verifica per ogni fase di caricamento all'interno della pVM: firmware della pVM, ABL della pVM, 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, quindi viene derivata anche una chiave segreta di sigillatura stabile per l'istanza VM durante i riavvii e, pertanto, è adatta per proteggere lo stato permanente. Il secret di sigillatura è di grande valore per la VM, pertanto non deve essere utilizzato direttamente. Le chiavi di sigillatura devono invece essere ricavate dal secret di sigillatura e questo deve essere distrutto il prima possibile.

Ogni fase passa un oggetto CBOR codificato in modo deterministico alla fase successiva. Questo oggetto contiene i 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. Anche i dati privati per una pVM vengono invalidati quando si verifica uno sblocco del dispositivo.

Una volta sbloccato, il proprietario del dispositivo è libero di eseguire il reflash delle partizioni solitamente protette dall'avvio verificato, incluse le partizioni che contengono l'implementazione di pKVM. Pertanto, 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 ispezionando il stato di avvio verificato del dispositivo in un certificato di attestazione delle chiavi.