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 es. un PIN della schermata di blocco). L'hardware sicuro è progettato per impedire gli attacchi di forza bruta, rendendo le chiavi di crittografia memorizzate definitivamente non recuperabili dopo troppi tentativi non riusciti di 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 definizione. Man mano che il sistema si stabilizza e che viene prodotta più documentazione, aggiorneremo questo white paper con informazioni più dettagliate (in particolare in combinazione con le release open source pertinenti).

Panoramica

Tradizionalmente, la crittografia (utilizzata per garantire la privacy dei dati) richiede l'uso di secret con un'alta entropia dal punto di vista dell'attaccante. È necessaria un'alta entropia perché lo schema di crittografia deve resistere agli attacchi di forza bruta che esplorano lo spazio di tutti i segreti probabili fino a quando non viene trovato quello corretto. Data la disponibilità attuale di potenza di calcolo, un requisito di entropia minima ragionevole per i segreti crittografici potrebbe aggirarsi tra i 70 e gli 80 bit. Sfortunatamente, gli esseri umani trovano molto difficile memorizzare e ricordare in modo affidabile password o altri segreti con questa quantità di entropia¹, soprattutto se vengono utilizzati raramente (ma l'uso frequente di una password con un'entropia elevata è difficile e noioso). Questo ci pone di fronte a un problema complesso: come possiamo proteggere i dati privati con la tecnologia di crittografia, se vogliamo che il segreto sia un "fattore di conoscenza" molto probabile che venga ricordato dall'utente? Per una serie di motivi, questo problema è così difficile da risolvere che i servizi di archiviazione sul cloud in genere criptano i dati solo con i secret gestiti dal fornitore di archiviazione sul cloud stesso, anziché fare affidamento sull'utente per ricordare il proprio secret.

Un approccio per colmare il divario tra i requisiti per i secret crittografici e i secret memorabili è utilizzare un servizio Cloud Key Vault (CKV) per memorizzare una "chiave di ripristino" ad alta entropia, protetta da un secret memorabile a bassa entropia. Il servizio CKV rilascerà la chiave di recupero solo a una parte che dimostri di conoscere il segreto memorabile corretto per le persone. Gli attacchi di forza bruta contro il segreto memorabile per l'utente possono essere sventati dal servizio CKV, che impone un limite assoluto al numero di tentativi falliti per dimostrare la conoscenza del segreto. La chiave di ripristino stessa è una chiave di crittografia simmetrica standard, adatta per l'utilizzo con uno schema di crittografia (autenticato) che può criptare facilmente un grande volume di dati (ad esempio un backup del disco) che possono essere archiviati in sicurezza ovunque. Questi dati criptati sono inutili per chiunque non possa ottenere la chiave di ripristino.

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 ripristino con il fattore di conoscenza della schermata di blocco (LSKF) dell'utente, ovvero il PIN segreto, la password o la sequenza di scorrimento 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 un'entropia sufficiente per resistere a un 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 sarà abilitare i backup di Android con crittografia lato client. In precedenza, i file criptati localmente sul dispositivo Android utilizzavano una chiave protetta con la chiave LSKF dell'utente, ma i backup di questi file archiviati (e criptati) nel cloud non erano protetti dalla chiave 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 il LSKF dell'utente può decriptare i backup.

Concetti fondamentali

Inizialmente, l'unica piattaforma client supportata per il servizio Cloud Key Vault è il sistema operativo Android 9 Pie e quando in questo white paper facciamo riferimento al client, ci riferiamo a un dispositivo che esegue il sistema operativo Android 9 Pie con Google Play Services. La nostra implementazione lato server viene eseguita su server Google appositamente designati su cui è installato un chip Titan aggiuntivo². Il chip Titan progettato da Google funge da componente hardware nel nostro Modulo hardware attendibile e lo configuriamo appositamente con un bootloader e un firmware personalizzati che implementano i nostri protocolli e meccanismi di applicazione della sicurezza (come descritto in questo documento). Utilizziamo tecniche di attestazione hardware per assicurarci che il nostro protocollo sia effettivamente in esecuzione sull'hardware di Titan.

Il servizio CKV deve essere scalabile per gestire il traffico di miliardi³ di dispositivi Android, senza perdere una quantità significativa di dati utente a causa di guasti hardware (ad es. chip bruciati) o di interruzioni prolungate dovute alla manutenzione del centro di dati. Per questo motivo, i server con i chip Titan sono organizzati in coorti, dove ogni coorte è composta da diversi THM indipendenti che contengono ciascuno una copia dello stesso materiale della chiave. Una determinata coorte verrà distribuita in data center fisicamente diversi in diverse zone di manutenzione, in modo da garantire che il sistema possa raggiungere i suoi obiettivi di disponibilità e affidabilità. Per la scalabilità, i client verranno suddivisi in una serie di coorti diverse, in modo da poter regolare la capacità del servizio semplicemente aggiungendo altri server per aumentare il numero di coorti disponibili.

Ora siamo pronti a elencare i componenti principali dell'architettura del servizio Cloud Key Vault.

Componenti dell'architettura / Glossario

Fattore di conoscenza della schermata di blocco (LSKF): un segreto memorabile da un essere umano, ad esempio un breve PIN, una sequenza di scorrimento su una griglia di punti 3 x 3 o una password. Questo segreto viene utilizzato per proteggere la capacità di sbloccare il dispositivo localmente ed è considerato un fattore di autenticazione principale (o "sicuro") per il blocco schermo del dispositivo locale dell'utente.

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

Framework Android: utilizziamo questo termine generico (o semplicemente il Framework) per fare riferimento alle API in Android 9 Pie o versioni successive e non è inteso per fare riferimento a release precedenti.

Google Play Services:una raccolta di servizi e app in esecuzione sul dispositivo dell'utente finale, che consente il funzionamento con il sistema di account di Google e le API di server personalizzate.

Agente di recupero:un'applicazione di sistema in esecuzione nell'ambito di Google Play Services nello spazio utente su un dispositivo Android 9 Pie (o simile). L'agente di recupero è responsabile dell'esecuzione del lato client dei vari protocolli e dell'interfaccia con il sistema operativo Android, se necessario, per creare i messaggi di protocollo che coinvolgono il LSKF.

Richiesta di recupero:quando l'utente vuole recuperare la chiave di recupero, deve creare una richiesta di recupero contenente una copia criptata della chiave LSKF che dichiara di conoscere. In genere, all'utente viene chiesto di inserire il codice LSKF del vecchio dispositivo su un nuovo dispositivo che sta tentando di accedere alla chiave di ripristino del vecchio dispositivo.

Chiave di ripristino:una chiave segreta criptata protetta dal servizio Cloud Key Vault e utilizzata per criptare (e autenticare) i dati sul dispositivo client. Una volta inserita la chiave di ripristino in un vault (vedi di seguito), la copia locale può essere eliminata non appena il client ha terminato di utilizzarla per criptare i dati.

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

Coorte: una raccolta di server Vault/THM in grado di fungere da repliche ridondanti l'una dell'altra.

Coppia di chiavi pubblica della coorte: la chiave pubblica di una coppia di chiavi generata da una coorte specifica di THM. La chiave privata corrispondente è disponibile solo all'interno dei THM che erano nel gruppo al momento della generazione della chiave.

Trusted Hardware Module (THM): un modulo di sicurezza dedicato (microcontroller) progettato per fornire un ambiente di calcolo minimo e attendibile. Come minimo, l'elemento sicuro deve essere in grado di generare e/o memorizzare chiavi segrete e mantenere uno stato in evoluzione non volatile (in modo da poter prevenire attacchi che prevedono reimpostazioni a uno stato precedente).

Vault:una determinata voce nel database del servizio CKV, contenente la chiave di ripristino protetta LSKF di un singolo dispositivo. Un utente finale può avere più Vault registrati, ciascuno corrispondente a un dispositivo o a un LSKF diverso. Solo il THM in un server Vault può esaminare o estrarre i contenuti di un Vault.

Server Vault:una macchina generica in esecuzione in un data center di Google che è stata appositamente sottoposta a retrofit per aggiungere un modulo hardware attendibile (THM).

Progettazione del protocollo

Il protocollo CKV è costituito da diverse fasi, come segue:

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 attendibile è memorizzata offline e protetta con attenzione in modo da richiedere la partecipazione di più dipendenti per la firma. La chiave pubblica di questa radice di attendibilità è integrata nel sistema operativo Android e può essere modificata solo tramite un aggiornamento del sistema operativo.

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

Creazione di Vault

Dopo aver aiutato il Framework a completare l'inizializzazione recuperando l'elenco delle chiavi pubbliche della coorte, l'agente di recupero richiederà al Framework di creare un nuovo vault. Ogni volta che l'utente inserirà nuovamente il LSKF, il Framework genererà una nuova chiave di ripristino e la cripterà prima con una chiave derivata da un hash del LSKF e poi con la chiave pubblica del gruppo selezionata dal Framework durante l'inizializzazione. Il blob criptato risultante è il vault che viene nuovamente trasmesso dal framework all'agente di recupero, che lo carica nel servizio CKV di Google.

Apertura del caveau

Quando l'agente di recupero sul nuovo dispositivo deve accedere alla chiave di ripristino memorizzata in un determinato vault, chiede prima all'utente di inserire la LSKF del dispositivo originale che ha creato il vault. L'agente di recupero chiederà quindi al framework di creare una richiesta di recupero utilizzando il file LSKF. Il Framework genererà una nuova chiave di autore della rivendicazione e la crittograferà, insieme all'hash della chiave pubblica LSKF rivendicata, con la stessa chiave pubblica del gruppo con cui è stata originariamente criptata la cassaforte. Il blob criptato risultante è chiamato Recovery Claim (Richiesta di recupero) e il Framework lo passa al Recovery Agent, che lo presenta al servizio CKV.

Il CKV inoltra la Rivendicazione di recupero (e il relativo Vault) ai server Vault che fanno parte della coorte corretta. Il THM nei server Vault decripta quindi il Recovery Claim e tenta di estrarre la Recovery Key dal Vault originale utilizzando l'hash LSKF rivendicato (per dedurre la chiave di crittografia interna). Se l'hash LSKF originale e l'hash LSKF rivendicato corrispondono, il THM estrae la chiave di recupero dalla Vault e la cripta di nuovo con la chiave del richiedente presente nella richiesta di recupero. In caso contrario, il THM incrementerà un contatore dei tentativi non riusciti. Quando il contatore dei tentativi non riusciti raggiunge il limite, il THM rifiuta di elaborare eventuali richieste di recupero successive per questo Vault.

Infine, se tutto è andato a buon fine, la chiave di ripristino sottoposta a nuova crittografia (ora criptata con la chiave del richiedente) viene inviata di nuovo dal server Vault al Framework. Il framework utilizza la propria copia della chiave del richiedente per decriptare la chiave di recupero e il protocollo è ora completo.

Misure di sicurezza

Lo scopo del sistema Cloud Key Vault è fornire una "difesa in profondità" includendo protezioni di sicurezza su più livelli del nostro stack. Per farti capire come funzionano queste protezioni, inizieremo descrivendo il client e risaliremo la gerarchia fino a Cloud Key Vault Service.

Sicurezza del cliente

A seconda del particolare OEM e del dispositivo, il fattore di conoscenza della schermata di blocco (LSKF) viene normalmente memorizzato e protetto sul dispositivo utilizzando una serie 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 la chiave LSKF in stato inattivo e applicare limiti di frequenza basati sull'hardware alla convalida della chiave LSKF. Le nuove API Framework introdotte per abilitare l'utilizzo di Cloud Key Vault sono progettate per preservare al massimo le garanzie di sicurezza esistenti, anche quando il dispositivo utilizza un modulo di sicurezza hardware di questo tipo per proteggere lo spazio di archiviazione del LSKF.

In questa sezione ci concentreremo specificamente sui problemi e sulle protezioni di sicurezza pertinenti che interessano la nuova funzionalità Cloud Key Vault, anziché tentare di fornire un quadro completo di tutti i meccanismi di sicurezza associati a LSKF.

Protezione delle API del framework

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

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

Poiché non si presume che la chiave LSKF venga archiviata in un punto del dispositivo diverso dall'hardware protetto, è possibile creare un nuovo Vault solo immediatamente dopo lo sblocco del dispositivo. Nel momento in cui l'utente inserisce il codice LSKF per sbloccare il dispositivo, questo viene reso brevemente disponibile al Framework in RAM. È il momento in cui la nuova API per la creazione del vault ne fa uso. Non è possibile creare un nuovo Vault protetto da LSKF mentre il dispositivo è bloccato perché il LSKF non è disponibile.

Protezione dell'agente di ripristino

La protezione di sicurezza principale che forniamo all'agente di recupero è che il protocollo è progettato per impedire all'agente di recupero di vedere la chiave LSKF del dispositivo corrente o qualsiasi chiave di recupero. Solo il Framework dovrebbe vedere questi elementi lato client, il che rende molto più difficile sfruttare eventuali bug o vulnerabilità di sicurezza nell'agente di recupero. L'agente di recupero viene utilizzato principalmente per gestire gli eventi del ciclo di vita e il trasferimento dei dati tra il cloud e il framework. L'unica eccezione si verifica durante un recupero, appena prima del protocollo di apertura del caveau, quando l'utente deve inserire il LSKF del vecchio dispositivo. L'interfaccia utente che raccoglie il LSKF rivendicato per il vecchio dispositivo è implementata in Recovery Agent⁴. Tuttavia, l'implementazione dell'agente di recupero "dimentica" il LSKF rivendicato non appena il framework assume il controllo della creazione della rivendicazione 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 la chiave LSKF ha un'entropia elevata (ad es. se è una buona password ad alta entropia), la memorizzazione della Vault è nettamente migliore rispetto alla memorizzazione di un hash della password e, in questo caso, l'hash della password può fornire una misura di sicurezza indipendente dalla sicurezza dei THM. Per questo motivo, supportiamo l'hashing "memory hard" con sale della chiave LSKF nell'ambito del protocollo. Inoltre, vincoliamo criptatologicamente la cassetta di sicurezza a un identificatore del dispositivo che l'ha creata e vincoliamo la richiesta di recupero a un nonce utilizzato come verifica durante il protocollo di apertura della cassetta di sicurezza per garantire che la richiesta di recupero sia aggiornata.

Poiché la chiave di ripristino viene generata di nuovo a ogni creazione del vault, implementiamo la rotazione delle chiavi sovrascrivendo una voce del vault esistente con un vault appena creato. L'indirizzo del contatore dei tentativi non riusciti utilizzato dal vault viene selezionato durante la creazione del vault e il framework garantisce che l'indirizzo del contatore utilizzato per i vault successivi non cambierà a meno che la chiave pubblica LSKF non sia stata modificata o non sia presente un nuovo elenco autenticato delle chiavi pubbliche della coorte. Pertanto, la rotazione della chiave di recupero può essere eseguita senza danneggiare la protezione contro l'attacco di forza bruta per la chiave LSKF.

Sicurezza del server per il servizio Cloud Key Vault

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

Protezioni hardware

La protezione di sicurezza principale implementata lato server del servizio CKV è costituita dai moduli hardware attendibili (THM) realizzati utilizzando i chip Titan progettati su misura da Google. I chip girano su 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 del loro gruppo in modo che la logica del firmware protegga la chiave privata da fughe al di fuori dei chip Titan del gruppo. Possono anche eseguire l'operazione di apertura del caveau e mantenere un contatore per ogni caveau che incrementa rigorosamente i tentativi non riusciti (il contatore è supportato dallo stato memorizzato all'interno del chip Titan). Una descrizione più dettagliata del protocollo eseguito dal firmware del chip CKV Titan verrà fornita in una release futura di questo documento.

Poiché 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 divulgare i secret o ignorare i limiti dei contatori. Per raggiungere questo obiettivo, modifichiamo anche il bootloader di Titan per assicurarci che i dati memorizzati sul chip (ad esempio la chiave privata per il gruppo) vengano completamente cancellati prima dell'applicazione di qualsiasi aggiornamento. Lo svantaggio di questa protezione è che non possiamo correggere i bug nel firmware senza subire una perdita di dati. L'aggiornamento del firmware è funzionalmente equivalente alla distruzione dell'hardware esistente e alla sua sostituzione 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 della coorte attestate e eseguire gradualmente la migrazione di tutti gli utenti al nuovo elenco. Per ridurre questo rischio, cerchiamo di mantenere la base di codice del firmware abbastanza ridotta e di sottoporla a un'attenta verifica per rilevare eventuali potenziali problemi di sicurezza.

Protezioni software

Oltre ai limiti rigidi di errori per vault imposti dai THM, il servizio CKV implementa anche la limitazione di frequenza basata su software. Il limite di frequenza è progettato per impedire a un malintenzionato di accedere all'account di un utente ed esaurire rapidamente il limite di tentativi di recupero non riusciti, bloccando di fatto l'accesso dell'utente reale alle relative 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 richiesta di apertura della cassaforte non riuscita successiva.

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

Specifiche del protocollo dettagliate

La specifica dettagliata del protocollo è ancora in corso e questo documento verrà aggiornato per includere questi dettagli insieme alla pubblicazione del codice client nel progetto Android Open Source entro la fine dell'anno.

Note