Sicurezza

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

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

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

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

Modello di sicurezza

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

  • La riservatezza è un insieme di regole che limitano l’accesso alle informazioni.
  • L’integrità è la garanzia che le informazioni siano affidabili e accurate.
  • La disponibilità è una garanzia di accesso affidabile alle informazioni da parte dei soggetti autorizzati.

Riservatezza e integrità

La riservatezza deriva dalle proprietà di isolamento della memoria applicate dall'hypervisor pKVM. pKVM tiene traccia della proprietà della memoria delle singole pagine di memoria fisica e di qualsiasi richiesta da parte dei proprietari di pagine da condividere. pKVM garantisce che solo le pVM autorizzate (host e guest) abbiano la pagina specificata mappata nelle tabelle delle pagine della fase 2 controllate dall'hypervisor. Questa architettura mantiene che il contenuto della memoria posseduto da una pVM rimane privato a meno che il proprietario non lo condivida esplicitamente con un altro 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 e servizi compatibili con DMA in esecuzione su livelli più privilegiati. I fornitori di System-on-Chip (SoC) devono soddisfare una nuova serie di requisiti prima di poter supportare pKVM. In caso contrario, non è possibile garantire la riservatezza.

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

  • Modificare la memoria dell'altro senza consenso.
  • Influiscono reciprocamente sullo stato della CPU.

Questi requisiti vengono applicati dall'hypervisor. Tuttavia, anche con l'archiviazione virtuale dei dati sorgono problemi relativi all'integrità dei dati quando devono essere utilizzate 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 tabelle di pagine della fase 1 e il contesto del kernel cambia tra i processi. Tuttavia, la porzione EL2 di pKVM, che impone queste proprietà, ha circa la metà della superficie di attacco rispetto all'intero kernel Linux (circa 10mila contro 20 milioni di righe di codice) e quindi offre una maggiore garanzia di utilizzare casi troppo sensibili per fare affidamento sull'isolamento del processo.

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

Il resto di questa pagina affronta le garanzie di riservatezza e integrità fornite da ciascun componente attorno a un pKVM.

Hypervisor

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

  • Una pVM non può accedere a una pagina appartenente a un'altra entità, come una pVM o un hypervisor, a meno che non sia esplicitamente condivisa 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 pVM venga restituita all'host, ad esempio quando la pVM viene distrutta, viene cancellata.

  • La memoria di tutti i pVM e del firmware pVM dall'avvio di un dispositivo viene cancellata prima che il bootloader del sistema operativo venga eseguito nel successivo avvio del dispositivo.

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

  • Il firmware pVM non si avvia se non è in grado di verificare l'immagine iniziale.

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

  • La catena di certificati di avvio (BCC) e gli identificatori di dispositivi composti (CDI) forniti a un'istanza pVM possono essere derivati ​​solo da quella particolare istanza.

Sistema operativo ospite

Microdroid è un esempio di sistema operativo in esecuzione all'interno di un pVM. Microdroid è costituito da un bootloader basato su U-boot, GKI, un sottoinsieme di spazio utente Android e un launcher di payload. Queste proprietà restano valide 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.

  • Microdroid non si avvierà se boot.img , super.img , vbmeta.img o vbmeta\_system.img non possono essere verificati.

  • Microdroid non si avvierà se la verifica dell'APK fallisce.

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

  • Microdroid non si avvierà se uno qualsiasi degli APEX non supera la verifica.

  • Microdroid non si avvierà (o si avvierà con uno stato iniziale pulito) se instance.img viene modificato all'esterno della pVM guest.

  • Microdroid fornisce l'attestazione della catena di avvio.

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

  • I BCC e i CDI forniti a un'istanza pVM possono essere derivati ​​solo da quella particolare istanza.

  • Le scritture su un volume di archiviazione crittografato sono confidenziali, tuttavia non esiste alcuna protezione di rollback alla granularità di un blocco di crittografia. Inoltre, altre manomissioni esterne arbitrarie di un blocco di dati fanno sì che tale blocco venga visualizzato come spazzatura da Microdroid, anziché essere rilevato esplicitamente come errore I/O.

Androide

Queste sono proprietà gestite da Android come host ma non valgono in caso di compromissione dell'host:

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

  • Solo il VirtualizationService nell'host pVM può creare un canale di comunicazione con un pVM.

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

  • L'identificatore, chiamato identificatore di contesto (CID), utilizzato nella configurazione delle connessioni vsock tra l'host e pVM non viene riutilizzato quando l'host pVM è in esecuzione. Ad esempio, non è possibile sostituire una pVM in esecuzione con un'altra.

Disponibilità

Nel contesto delle pVM, la disponibilità si riferisce all'host che assegna risorse sufficienti agli ospiti in modo che gli ospiti possano eseguire le attività per cui sono progettati.

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

Allo stesso modo, pKVM delega anche la gestione fisica degli interrupt al kernel host per ridurre la complessità dell'hypervisor e lasciare all'host il compito di pianificare. Viene fatto uno sforzo per garantire che l'inoltro delle interruzioni dell'ospite si traduca solo in una negazione del servizio (troppo pochi, troppi o interruzioni errate).

Infine, il processo VMM (Virtual Machine Monitor) dell'host è responsabile dell'allocazione della memoria e della fornitura di dispositivi virtuali, come una scheda di rete. Un VMM dannoso può trattenere le risorse dal guest.

Sebbene pKVM non fornisca disponibilità ai guest, il design protegge la disponibilità dell'host da guest malintenzionati perché l'host può sempre anticipare o terminare un guest e recuperarne le risorse.

Avvio sicuro

I dati sono legati alle istanze di una pVM e l'avvio 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 sale segreto per la pVM ed estraendo dettagli, come chiavi pubbliche e hash di verifica, dalle immagini caricate. Queste informazioni vengono utilizzate per verificare i successivi avvii dell'istanza pVM e garantire che i segreti dell'istanza vengano rilasciati solo alle immagini che superano la verifica. Questo processo si verifica per ogni fase di caricamento all'interno del pVM: firmware pVM, pVM ABL, Microdroid e così via.

DICE fornisce a ciascuna fase di caricamento una coppia di chiavi di attestazione, la cui parte pubblica è certificata nella voce BCC per quella fase. Questa coppia di chiavi può cambiare tra un avvio e l'altro, quindi viene derivato anche un segreto di sigillatura che è stabile per l'istanza VM dopo i riavvii e, come tale, è adatto a proteggere lo stato persistente. Il segreto di sigillatura è molto prezioso per la VM, pertanto non deve essere utilizzato direttamente. Invece, le chiavi di sigillatura dovrebbero essere derivate dal segreto di sigillatura e il segreto di sigillatura dovrebbe essere distrutto il prima possibile.

Ciascuna fase trasmette un oggetto CBOR codificato deterministicamente alla fase successiva. Questo oggetto contiene segreti e BCC, 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 dell'utente vengono cancellati. Questo processo protegge i dati dell'utente da accessi non autorizzati. Anche i dati privati ​​di un pVM vengono invalidati quando si verifica lo sblocco del dispositivo.

Una volta sbloccato, il proprietario del dispositivo è libero di eseguire nuovamente il flashing delle partizioni che solitamente sono protette dall'avvio verificato, comprese le partizioni che contengono l'implementazione pKVM. Pertanto, pKVM su un dispositivo sbloccato non sarà ritenuto affidabile per sostenere il modello di sicurezza.

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