Servizio Google Cloud Key Vault

Descriviamo un servizio cloud che utilizza hardware sicuro per archiviare le chiavi di crittografia in modo che l'accesso sia protetto da un fattore di conoscenza a bassa entropia (ad esempio, un PIN di schermata di blocco). L'hardware sicuro è progettato per prevenire attacchi di forza bruta, rendendo le chiavi di crittografia archiviate definitivamente irrecuperabili dopo troppi tentativi non riusciti per fornire il fattore di conoscenza corretto.

Autore: Shabsi Walfish
Data versione: 06-03-2018

Nota: questo documento è ancora in fase di sviluppo e i dettagli dell'implementazione sono ancora in fase di finalizzazione. Man mano che il sistema si stabilizza e sarà possibile produrre ulteriore documentazione, aggiorneremo questo white paper con informazioni più dettagliate (in particolare in combinazione con le release open source pertinenti).

Panoramica

Tradizionalmente, la crittografia (che viene utilizzata per garantire la privacy dei dati) richiede l'uso di secret che abbiano un'alta entropia dal punto di vista dell'utente malintenzionato. È necessaria un'alta entropia perché lo schema di crittografia deve resistere agli attacchi di forza bruta che esplorano lo spazio di tutti i probabili secret fino a trovare quello corretto. Data la disponibilità attuale di potenza di calcolo, un requisito di entropia minima ragionevole per i secret di crittografia potrebbe essere compreso tra 70 e 80 bit. Purtroppo, per gli esseri umani è molto difficile memorizzare e ricordare in modo affidabile le password o altri secret con quella quantità di entropia1, soprattutto se vengono utilizzati raramente (ma l'uso frequente di una password ad alta entropia è difficile e noioso). Questo ci lascia un problema impegnativo: come possiamo proteggere i dati privati con la tecnologia di crittografia se vogliamo che il segreto sia un "fattore di conoscenza" che con molta probabilità venga ricordato dall'utente? Per una varietà di motivi, il problema è così difficile da risolvere che i servizi di Cloud Storage in genere criptano i dati solo con secret gestiti dal fornitore di spazio di archiviazione Cloud, invece di affidarsi all'utente per ricordare il proprio secret.

Un approccio per colmare il divario tra i requisiti per i secret di crittografia e i secret memorabili a livello umano consiste nell'utilizzare un servizio Cloud Key Vault (CKV) per archiviare una "chiave di recupero" ad alta entropia, protetta da un secret a bassa entropia facile da ricordare. Il servizio CKV rilascerà il codice di recupero soltanto a un utente che dimostra di conoscere il secret corretto e facile da ricordare. Gli attacchi di forza bruta contro il segreto memorabile a livello umano possono essere sventati dal servizio CKV, che applicherà un limite assoluto al numero di tentativi non riusciti per dimostrare la conoscenza del segreto. La chiave di recupero stessa è una chiave simmetrica crittografica standard adatta all'utilizzo con uno schema di crittografia (autenticato) in grado di criptare facilmente un grande volume di dati (ad esempio un backup su disco) che possono essere archiviati in sicurezza ovunque. Questi dati criptati sono inutili per chiunque non possa ottenere la chiave di recupero.

Questo white paper descrive il nostro approccio alla creazione di un servizio Cloud Key Vault utilizzando i moduli hardware attendibili (THM). La nostra prima implementazione del servizio CKV è progettata per proteggere le chiavi di recupero con il Lock Screen Knowledge Factor (LSKF) dell'utente, ovvero il PIN, la password o la sequenza di scorrimento segreta utilizzata per sbloccare gli smartphone. Gli esseri umani possono ricordare in modo affidabile il proprio LSKF. Allo stesso tempo, questi secret LSKF hanno in genere abbastanza entropia per resistere a un utente malintenzionato che ha un numero molto limitato di tentativi, il che li rende adatti al servizio CKV.

La prima applicazione del nostro servizio Cloud Key Vault prevede l'abilitazione dei backup di Android con crittografia lato client. In precedenza, i file criptati in locale sul dispositivo Android utilizzavano una chiave protetta con l'LSKF dell'utente, ma i backup dei file archiviati (e criptati) nel cloud non erano protetti dalla LSKF. Per la prima volta, Cloud Key Vault consente la protezione della schermata di blocco anche per i backup di Android archiviati nel cloud. Ciò significa che i server di Google non hanno la possibilità di accedere o ripristinare i contenuti dei backup criptati: solo un dispositivo con l'LSKF dell'utente può decriptare i backup.

Concetti principali

Inizialmente, l'unica piattaforma client supportata per il servizio Cloud Key Vault è il sistema operativo Android 9 Pie. In questo white paper, ci riferiamo al client con il sistema operativo Android 9 Pie con Google Play Services. La nostra implementazione lato server viene eseguita su server Google appositamente designati in cui è installato un chip Titan2 aggiuntivo. Il chip Titan progettato da Google funge da componente hardware nel nostro Trusted Hardware Module, di cui viene eseguito il provisioning speciale con un bootloader e un firmware personalizzati che implementano i nostri protocolli e meccanismi di applicazione della sicurezza (come descritto nel presente documento). Utilizziamo tecniche di attestazione hardware per avere la certezza che il nostro protocollo sia effettivamente in esecuzione sull'hardware Titan.

Il servizio CKV deve scalare per gestire il traffico da miliardi3 di dispositivi Android, senza perdere quantità significative di dati utente a causa di guasti hardware (ad esempio chip bruciati) o di eventuali interruzioni prolungate dovute alla manutenzione dei data center. Per questo motivo, i server con i chip Titan al loro interno sono organizzati in coorti, in cui ogni coorte è costituita da diversi THM indipendenti, ciascuno dei quali contiene una copia dello stesso materiale della chiave. Una determinata coorte verrà distribuita tra data center fisicamente disparati in zone di manutenzione diverse, in modo che il sistema possa raggiungere gli obiettivi di disponibilità e affidabilità. Per la scalabilità, i client verranno suddivisi in una serie di coorti diverse, in modo da poter modificare la capacità del servizio semplicemente aggiungendo altri server per aumentare il numero di coorti disponibili.

Ora siamo pronti per enumerare i componenti principali dell'architettura del servizio Cloud Key Vault.

Componenti architettonici / Glossario

Fattore di conoscenza schermata di blocco (LSKF): un secret memorizzabile dall'uomo, ad esempio un PIN breve, una sequenza di scorrimento su una griglia 3 x 3 punti o una password. Questo secret viene utilizzato per proteggere la possibilità di sbloccare il dispositivo localmente ed è considerato un fattore di autenticazione principale (o "efficace") per il blocco schermo locale del dispositivo dell'utente.

Client: un dispositivo di un utente finale con il sistema operativo Android 9 Pie e Google Play Services o software equivalente.

Framework Android: usiamo questo termine generico (o solo il Framework) per fare riferimento alle API di Android 9 Pie o versioni successive e non intende riferirsi ad alcuna release precedente.

Google Play Services: una raccolta di servizi e app eseguiti sul dispositivo dell'utente finale, che ne consentono l'utilizzo con le API di sistema dell'account Google e server personalizzate.

Agente di recupero: un'applicazione di sistema in esecuzione come parte di Google Play Services nello spazio utente su un dispositivo Android 9 Pie (o simile). L'agente di recupero è responsabile dell'esecuzione sul lato client dei vari protocolli e dell'interfaccia con il Sistema operativo Android secondo necessità al fine di creare qualsiasi messaggio di protocollo che coinvolga l'LSKF.

Richiesta di recupero. Se l'utente vuole recuperare il codice di recupero, deve creare una richiesta di recupero contenente una copia criptata dell'LSKF e dichiarata dall'utente. In genere, all'utente viene chiesto di inserire l'LSKF del vecchio dispositivo su un nuovo dispositivo che sta tentando di accedere al codice di recupero del vecchio dispositivo.

Chiave di recupero: una chiave segreta di crittografia protetta dal servizio Cloud Key Vault e utilizzata per criptare (e autenticare) i dati sul dispositivo client. Una volta che il codice di recupero è stato inserito in un Vault (vedi sotto), la copia locale può essere eliminata non appena il client ne ha terminato l'utilizzo per criptare i dati.

Servizio Cloud Key Vault (CKV):un servizio internet che consente ai dispositivi client di archiviare chiavi di crittografia protette da una chiave LSKF memorabile.

Coorte:una raccolta di server/THM Vault che possono fungere da repliche ridondanti gli uni degli altri.

Chiave pubblica di coorte: la chiave pubblica di una coppia di chiavi generata da una specifica coorte di THM. La chiave privata corrispondente è disponibile solo all'interno dei THM presenti nella coorte al momento della generazione della chiave.

Trusted Hardware Module (THM): un modulo di sicurezza dedicato (microcontroller) progettato per fornire un ambiente informatico affidabile e minimo. Come minimo, l'elemento secure deve essere in grado di generare e/o archiviare chiavi secret e mantenere uno stato in evoluzione non volatile (in modo da evitare attacchi che comportano il ripristino a uno stato precedente).

Vault: una voce specifica nel database del servizio CKV, contenente un codice di recupero protetto LSKF di un singolo dispositivo. Un utente finale può avere più Vault archiviati, ciascuno corrispondente a un dispositivo o LSKF diverso. Solo la THM in un server Vault può esaminare o estrarre i contenuti di un Vault.

Server Vault:una macchina per uso generico funzionante in un data center di Google che è stata appositamente adattata per aggiungere un modulo THM (Trusted Hardware Module).

Progettazione del protocollo

Il protocollo CKV è costituito da diverse fasi, descritte di seguito:

Inizializzazione

Per inizializzare il sistema, Google fornirà una chiave pubblica per una "radice di attendibilità" che il framework utilizzerà per verificare le attestazioni hardware di Google. La chiave di firma per questa radice di attendibilità viene archiviata offline e protetta con cura in modo da richiedere la partecipazione di più dipendenti per la firma. La chiave pubblica per questa radice di attendibilità è integrata nel sistema operativo Android e può essere modificata solo tramite un aggiornamento del sistema operativo.

Inoltre, Google pubblica periodicamente un elenco di chiavi pubbliche per ogni coorte di THM, insieme a un'attestazione nell'elenco. L'attestazione nell'elenco utilizza una firma che si concatena alla radice di attendibilità. Ogni aggiornamento dell'elenco pubblicato contiene anche un numero di sequenza, per impedire i rollback. L'agente di recupero recupererà l'elenco pubblicato più recente di chiavi pubbliche della coorte e lo fornirà al framework. Il framework verifica quindi l'attestazione e seleziona in modo casuale dall'elenco una chiave pubblica di coorte da utilizzare nella fase di creazione di Vault.

Creazione Vault

Dopo aver aiutato il framework a completare l'inizializzazione recuperando l'elenco di chiavi pubbliche della coorte, l'agente di recupero richiederà al framework di creare un nuovo Vault. Ogni volta che l'utente inserisce l'LSKF in seguito, il framework genera un nuovo codice di recupero e lo cripta prima con una chiave derivata da un hash dell'LSKF, quindi con la chiave pubblica di coorte selezionata dal framework durante l'inizializzazione. Il blob criptato risultante è il Vault che viene restituito dal framework all'agente di ripristino, che poi lo carica nel servizio CKV di Google.

Apertura di Vault

Quando l'agente di recupero sul nuovo dispositivo deve accedere al codice di recupero archiviato in un determinato Vault, chiede innanzitutto all'utente di inserire l'LSKF del dispositivo originale che ha creato Vault. L'agente di recupero chiederà quindi al framework di creare una richiesta di recupero utilizzando l'LSKF. Il framework genera una nuova chiave dell'autore della rivendicazione e cripterà la chiave dell'autore della rivendicazione e l'hash dell'LSKF rivendicato, con la stessa chiave pubblica di coorte con cui Vault è stato originariamente criptato. Il BLOB criptato risultante è denominato Richiesta di recupero e il framework la passa all'agente di recupero, che la presenta al servizio CKV.

Il CKV inoltra la richiesta di recupero (e il relativo Vault) ai server Vault che fanno parte della coorte corretta. Il THM nei server Vault poi decripta la richiesta di recupero e tenta di estrarre la chiave di recupero dal Vault originale utilizzando l'hash LSKF rivendicato (per ricavare la chiave di crittografia interna). Se l'hash LSKF originale e l'hash LSKF rivendicato corrispondono, il THM estrarrà il codice di recupero da Vault e lo cripterà nuovamente con la chiave del richiedente indicata nella richiesta di recupero. In caso contrario, THM spingerà un contatore di tentativi non riusciti. Una volta che il contatore dei tentativi non riusciti raggiunge il limite, il THM si rifiuterà di elaborare eventuali richieste di recupero successive per Vault.

Infine, se non si è verificato alcun problema, la chiave di recupero criptata nuovamente (ora criptata con la chiave richiedente) viene rinviata dal server Vault fino al framework. Il framework utilizza la propria copia della chiave richiedente per decriptare la chiave di recupero. Ora il protocollo è completo.

Misure di sicurezza

L'obiettivo del sistema Cloud Key Vault è fornire una "difesa in profondità" includendo protezioni di sicurezza a più livelli del nostro stack. Per dare un'idea del funzionamento di queste protezioni, inizieremo descrivendo il client e ci avviciniamo al servizio Cloud Key Vault.

Sicurezza client

A seconda dell'OEM e del dispositivo specifici, il fattore di conoscenza della schermata di blocco (LSKF) viene solitamente archiviato e protetto sul dispositivo tramite una varietà di metodi che variano in base all'OEM. Ad esempio, i dispositivi Pixel 2 di Google utilizzano un modulo di sicurezza hardware a prova di manomissione per archiviare l'LSKF at-rest e per applicare limiti di frequenza basati sull'hardware alla convalida dell'LSKF. Le nuove API framework introdotte per abilitare l'utilizzo di Cloud Key Vault sono progettate per preservare le garanzie di sicurezza esistenti nella misura massima possibile, anche quando il dispositivo utilizza un modulo di sicurezza hardware di questo tipo per proteggere l'archiviazione dell'LSKF.

Ci concentreremo in questa sezione in modo specifico sui problemi di sicurezza e sulle protezioni pertinenti che interessano la nuova funzionalità di Cloud Key Vault, anziché tentare di fornire un quadro completo di tutti i meccanismi di sicurezza associati all'LSKF.

Protezione delle API Framework

Le nuove API Framework aggiunte per supportare il servizio CKV sono contrassegnate come @SystemApi e richiedono autorizzazioni speciali, che ne garantiscono la disponibilità solo per le app di sistema approvate dagli OEM, come Google Play Services. In questo modo viene rimossa in gran parte qualsiasi superficie di attacco diretto che potrebbe essere esposta alle app che l'utente installa sul dispositivo.

Le API Framework assicurano inoltre che i Vault vengano creati solo per le chiavi pubbliche di coorte attestate da una radice di attendibilità. La radice di attendibilità è integrata nel framework dall'OEM al momento della spedizione e non può essere modificata senza un aggiornamento del sistema operativo. Ciò garantisce che l'LSKF venga utilizzato solo per creare Vault che applicheranno correttamente le protezioni contro la forza bruta basate su hardware. Affidandoci ai THM del servizio Cloud Key Vault per la protezione contro la forza bruta per l'LSKF, possiamo ottenere una sicurezza paragonabile all'utilizzo di hardware sicuro sul dispositivo per la stessa cosa (come fanno i dispositivi Google Pixel 2).

Poiché non presupponiamo che l'LSKF venga archiviata sul dispositivo al di fuori dell'hardware protetto, è possibile creare un nuovo Vault solo subito dopo lo sblocco del dispositivo. Nel momento in cui l'utente accede all'LSKF per sbloccare il dispositivo, questa viene resa brevemente disponibile al framework nella RAM. È in questa fase che viene utilizzata dalla nuova API per la creazione di Vault. Non è possibile creare un nuovo Vault protetto da LSKF mentre il dispositivo è bloccato perché l'LSKF non è disponibile.

Protezione dell'agente di recupero

La principale protezione di sicurezza che offriamo all'agente di ripristino è che il protocollo è progettato per impedire all'agente di ripristino di vedere mai l'LSKF del dispositivo corrente o qualsiasi chiave di recupero. Solo il framework dovrebbe vedere queste informazioni sul lato client, rendendo molto più difficile lo sfruttamento di potenziali bug o vulnerabilità di sicurezza nell'agente di ripristino. L'agente di ripristino viene utilizzato principalmente per gestire gli eventi del ciclo di vita e il passaggio di dati tra il cloud e il framework. L'unica eccezione a questo problema si verifica durante il recupero appena prima del protocollo di apertura di Vault, quando l'utente deve inserire l'LSKF del vecchio dispositivo. La UI che raccoglie l'LSKF rivendicato per il vecchio dispositivo viene implementata nell'agente di recupero4. Tuttavia, l'implementazione dell'agente di recupero "dimentica" l'LSKF rivendicato non appena il framework prende in carico la creazione della richiesta di recupero.

Funzionalità di sicurezza del protocollo

Sebbene un'analisi completa del protocollo non rientri nell'ambito di questo documento, vogliamo evidenziare alcune delle protezioni integrate nel protocollo. In particolare, il protocollo utilizza solo l'hash dell'LSKF. Ciò significa che, se l'LSKF ha un'entropia elevata (ad esempio, se è una password valida ad alta entropia), archiviare Vault è strettamente meglio che archiviare un hash della password. In questo caso, l'hash della password può fornire una misura di sicurezza indipendente dalla sicurezza dei THM. Per questo motivo, supportiamo l'hashing "con memoria hard" con salt dell'LSKF come parte del protocollo. Inoltre, associamo Vault tramite crittografia a un identificatore del dispositivo che l'ha creato e associamo la richiesta di recupero a un nonce che viene utilizzato come verifica durante il protocollo di apertura di Vault per garantire che la richiesta di recupero sia aggiornata.

Poiché il codice di recupero viene generato di recente a ogni creazione di Vault, implementiamo la rotazione della chiave sovrascrivendo una voce esistente di Vault con un Vault appena creato. L'indirizzo del contatore dei tentativi non riusciti utilizzato dal Vault viene selezionato durante la creazione di Vault e il framework garantisce che l'indirizzo del contatore utilizzato per eventuali Vault successivi non cambi a meno che l'LSKF non sia stato modificato o non sia presente un nuovo elenco attestato di chiavi pubbliche di coorte. Pertanto, la rotazione del codice di recupero può essere eseguita senza danneggiare la protezione dalla forza bruta dell'LSKF.

Sicurezza dei server per il servizio Cloud Key Vault

Il server viene implementato utilizzando una combinazione di software in esecuzione sull'hardware del server ordinario e firmware in esecuzione su hardware specializzato (chip Titan). Descriveremo le protezioni offerte in ogni livello.

Protezioni hardware

La principale protezione di sicurezza implementata sul lato server del servizio CKV è costituita dai Trusted Hardware Module (THM), creati utilizzando i chip Titan progettati su misura di Google. I chip eseguono un firmware che espone le API necessarie per implementare i protocolli CKV. In particolare, possono generare e condividere in modo sicuro una coppia di chiavi con altri membri della coorte, in modo che la logica del firmware protegga la fuoriuscita della chiave privata dai chip Titan nella coorte. Possono inoltre eseguire l'operazione di apertura di Vault e mantenere un contatore di tentativi non riusciti per Vault con un incremento rigoroso (in cui il contatore è supportato dallo stato archiviato all'interno del chip Titan). Una descrizione più dettagliata del protocollo eseguito dal firmware del chip CKV Titan verrà fornita in una versione futura di questo documento.

Dato che la sicurezza del server deriva dalla logica del firmware nei chip Titan, dobbiamo assicurarci che la logica non cambi in modo da consentire ai chip di rivelare i secret o ignorare i limiti dei contatori. Per raggiungere questo obiettivo, modifichiamo anche il bootloader Titan per garantire che i dati archiviati del chip (come la chiave privata della coorte) vengano cancellati completamente prima dell'applicazione di qualsiasi aggiornamento. Lo svantaggio di questa protezione è che non possiamo correggere i bug nel firmware senza subire perdite di dati: l'aggiornamento del firmware equivale a distruggere l'hardware esistente e sostituirlo con nuovi chip. Nel caso in cui sia necessaria una patch del firmware critica, Google dovrà produrre e pubblicare un elenco completamente nuovo di chiavi pubbliche di coorte attestate ed eseguire gradualmente la migrazione di tutti gli utenti al nuovo elenco. Per mitigare questo rischio, cerchiamo di mantenere il codebase del firmware abbastanza minimo e lo controlliamo attentamente per individuare eventuali potenziali problemi di sicurezza.

Protezioni software

Oltre ai limiti di errore rigidi per Vault imposti dai THM, il servizio CKV implementa anche la limitazione della frequenza basata su software. Il limite di frequenza è progettato per impedire a un malintenzionato di accedere all'account di un utente e di esaurire rapidamente il limite di tentativi di ripristino non riusciti, bloccando di fatto l'accesso dell'utente reale alle proprie chiavi di recupero. Analogamente ai ritardi imposti dal dispositivo dell'utente dopo troppi tentativi non riusciti di sbloccare lo schermo, il servizio CKV applicherà un ritardo crescente dopo ogni successiva richiesta di apertura di Vault non riuscita.

Implementiamo inoltre misure di sicurezza standard per i servizi Cloud che ospitano i dati utente, tra cui controlli di accesso, monitoraggio e controllo rigorosi.

Specifiche di protocollo dettagliate

Le specifiche dettagliate del protocollo sono ancora in corso e questo documento verrà aggiornato per includere questi dettagli insieme alla pubblicazione del codice client nel progetto open source Android entro la fine dell'anno.

Notes

  1. "Towards Reliable Storage of 56-bit Secrets in Human Memory | USENIX." 1 agosto 2014, https://www.usenix.org/node/184458.
  2. "Blog della piattaforma Google Cloud: Approfondimento: sicurezza in testo non crittografato." 24 agosto 2017, https://cloudplatform.googleblog.com/2017/08/Titan-in-depth-security-in-plaintext.html.
  3. "Google annuncia oltre 2 miliardi di dispositivi attivi al mese su Android..." 17 maggio. 2017, https://www.theverge.com/2017/5/17/15654454/android-reaches-2-billion-monthly-active-users.
  4. In questo modo possiamo fornire UI flessibili per l'inserimento dell'LSKF di un altro dispositivo. Il framework del dispositivo attuale potrebbe non avere un'interfaccia utente appropriata per l'inserimento dell'LSKF del dispositivo precedente.