Servizio Google Cloud Key Vault

Descrivi 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 gli 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 della versione: 2018-03-06

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 ed è possibile generare 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 con 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 quando non viene trovato quello corretto. Data la disponibilità attuale di potenza di calcolo, un requisito di entropia minimo ragionevole per i secret di crittografia potrebbe essere nell'ordine dei 70-80 bit. Purtroppo per gli esseri umani è molto difficile memorizzare e ricordare in modo affidabile le password o altri segreti con quella quantità di entropia¹, soprattutto se sono utilizzati raramente (ma l'uso frequente di una password ad alta entropia è difficile e noioso). Questo ci crea un problema impegnativo: come possiamo proteggere i dati privati con la tecnologia di crittografia, se vogliamo che il secret sia un "fattore di conoscenza" che abbia molte probabilità di essere ricordato dall'utente? Per una serie di motivi, questo problema è talmente difficile da risolvere che i servizi di Cloud Storage in genere criptano solo i dati con secret gestiti dal fornitore di spazio di archiviazione Cloud stesso, invece di affidarsi all'utente per ricordare il proprio secret.

Un approccio per colmare il divario tra i requisiti per i segreti crittografici e i secret memorabili per l'utente è utilizzare un servizio Cloud Key Vault (CKV) per archiviare una "chiave di ripristino" ad alta entropia, protetta da un secret a bassa entropia e facile da ricordare. Il servizio CKV rilascerà il codice di recupero solo a una parte che dimostri di conoscere il segreto umano corretto e facile da ricordare. Gli attacchi di forza bruta contro il segreto memorabile possono essere sventati dal servizio CKV, che applicherà un limite assoluto al numero di tentativi non riusciti per dimostrare la conoscenza del secret. La chiave di recupero è una chiave simmetrica crittografica standard, adatta all'utilizzo con uno schema di crittografia (autenticato) che può criptare facilmente un grande volume di dati (ad esempio un backup su disco) che possono essere archiviati in sicurezza ovunque. Tali 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 moduli hardware attendibili (THM). La nostra prima implementazione del servizio CKV è progettata per proteggere le chiavi di recupero con il fattore di conoscenza della schermata di blocco (LSKF) dell'utente, ovvero il PIN segreto, la password o la sequenza di scorrimento utilizzati per sbloccare gli smartphone. Gli esseri umani possono ricordare in modo affidabile il loro LSKF. Allo stesso tempo, questi secret LSKF in genere hanno un'entropia sufficiente a 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 localmente sul dispositivo Android utilizzavano una chiave protetta con l'LSKF dell'utente, ma i backup di questi file archiviati (e criptati) nel cloud non erano protetti dall'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 possono 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. Quando in questo white paper facciamo riferimento al client, ci riferiamo a un dispositivo 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 Titan² aggiuntivo. Il chip Titan progettato da Google funge da componente hardware nel nostro Trusted Hardware Module e ne viene eseguito appositamente il provisioning 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 davvero in esecuzione sull'hardware Titan.

Il servizio CKV deve scalare per gestire il traffico proveniente da miliardi³ di dispositivi Android, senza perdere quantità significative di dati utente a causa di guasti hardware (ad es. chip bruciati) o 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 ciascuna coorte è composta da diversi THM indipendenti, ciascuno dei quali contiene una copia dello stesso materiale della chiave. Una determinata coorte verrà distribuita tra data center fisicamente dislocati in diverse zone di manutenzione, in modo da garantire che il sistema possa raggiungere gli obiettivi di disponibilità e affidabilità. Per garantire la scalabilità, i clienti verranno suddivisi in diverse coorti, in modo da poter regolare la capacità del servizio semplicemente aggiungendo altri server per aumentare il numero di coorti disponibili.

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

Componenti architettonici / Glossario

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

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

Framework Android: usiamo questo termine generico (o solo il framework) per fare riferimento alle API in Android 9 Pie o versioni successive e non in riferimento a release precedenti.

Google Play Services: una raccolta di servizi e app eseguiti sul dispositivo dell'utente finale, che ne consentono l'utilizzo con le API del sistema di account di Google e le API 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 Recovery è responsabile dell'esecuzione dei vari protocolli sul lato client e dell'interfaccia con il Sistema operativo Android secondo necessità per 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 che dichiara di essere a conoscenza. In genere, all'utente verrà chiesto di inserire l'LSKF del vecchio dispositivo su un nuovo dispositivo che tenta di accedere al codice di recupero di quello precedente.

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 ha finito di utilizzarla per criptare i dati.

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

Coorte:una raccolta di server/THM Vault in grado di fungere da repliche ridondanti tra loro.

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

Trusted Hardware Module (THM): un modulo di sicurezza dedicato (microcontroller) progettato per fornire un ambiente informatico minimo e affidabile. Come minimo, Secure Element deve essere in grado di generare e/o archiviare le chiavi secret e mantenere uno stato in evoluzione permanente (in modo da evitare attacchi che implicano la reimpostazione a uno stato precedente).

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

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

Progettazione del protocollo

Il protocollo CKV consiste in diverse fasi, come segue:

Inizializzazione

Per inizializzare il sistema, Google fornisce 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 accuratamente protetta 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.

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, che consente di impedire i rollback. L'agente Recovery recupererà l'elenco pubblicato più di recente di chiavi pubbliche di 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 di 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 la volta successiva, il framework genera una nuova chiave di recupero e la 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 per il recupero chiederà quindi al framework di creare una richiesta di recupero utilizzando l'LSKF. Il framework genererà una nuova chiave del richiedente e cripterà la chiave del richiedente e l'hash dell'LSKF rivendicata, con la stessa chiave pubblica di coorte con cui Vault era stato originariamente criptato. Il BLOB criptato risultante è chiamato attestazione di recupero e il framework la passa all'agente di recupero, che lo presenta al servizio CKV.

Il CKV instrada la richiesta di recupero (e l'elemento Vault corrispondente) ai server Vault che fanno parte della coorte corretta. Il THM nei server Vault decripta quindi l'attestazione di recupero e tenta di estrarre la chiave di recupero dal file 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à la chiave di recupero da Vault e la cripterà nuovamente con la chiave richiedente presente nella rivendicazione di recupero. In caso contrario, THM sposterà un contatore di tentativi non riusciti. Una volta che il contatore dei tentativi falliti raggiunge il limite, il THM si rifiuterà di elaborare eventuali richieste di recupero successive per Vault.

Infine, se non si sono verificati problemi, la chiave di recupero ricrittografata (che ora è criptata con la chiave richiedente) viene inviata da Vault Server fino al framework. Il framework utilizza la propria copia della chiave richiedente per decriptare la chiave di recupero e il protocollo è ora completo.

Misure di sicurezza

Il sistema Cloud Key Vault mira a fornire una "difesa approfondita" includendo protezioni di sicurezza a più livelli del nostro stack. Per dare un'idea di come funzionano queste protezioni, inizieremo descrivendo il client e procedendo fino allo stack fino al servizio Cloud Key Vault.

Sicurezza client

A seconda dell'OEM e del dispositivo, il fattore di conoscenza della schermata di blocco (LSKF) viene normalmente memorizzato e protetto sul dispositivo mediante una serie di metodi diversi che variano in base all'OEM. Ad esempio, i dispositivi Pixel 2 di Google utilizzano un modulo di sicurezza hardware antimanomissione per archiviare l'LSKF at-rest e per applicare limiti di frequenza basati su hardware per la convalida dell'LSKF. Le nuove API framework introdotte per consentire l'utilizzo di Cloud Key Vault sono progettate per preservare il più possibile le garanzie di sicurezza esistenti, anche quando il dispositivo utilizza un modulo di sicurezza hardware di questo tipo per proteggere l'archiviazione dell'LSKF.

In questa sezione ci concentreremo in modo specifico sui problemi di sicurezza e sulle protezioni pertinenti che interessano la nuova funzionalità di Cloud Key Vault, anziché cercare 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 assicurano la disponibilità solo per le app di sistema approvate 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 quando viene spedito e non può essere modificata senza un aggiornamento del sistema operativo. In questo modo, viene garantito che l'LSKF venga utilizzato solo per creare Vault che applichino in modo adeguato le protezioni contro la forza bruta basate su hardware. Utilizzando i THM nel servizio Cloud Key Vault per la protezione contro la forza bruta per l'LSKF, possiamo ottenere una sicurezza paragonabile a quella di utilizzare per la stessa cosa l'hardware sicuro sul dispositivo (come fanno i dispositivi Google Pixel 2).

Poiché non si presume che l'LSKF venga archiviato in qualsiasi posizione 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, l'LSKF viene resa brevemente disponibile al framework in RAM. È in questa fase che viene utilizzata dalla nuova API per la creazione di Vault. Non è possibile creare un nuovo Vault protetto dall'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 recupero è che il protocollo è progettato per evitare che l'agente di recupero veda mai l'LSKF del dispositivo corrente o eventuali chiavi 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 Recovery 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 un ripristino appena prima del protocollo di apertura di Vault, quando l'utente deve inserire l'LSKF del vecchio dispositivo. L'interfaccia utente che raccoglie l'LSKF rivendicato per il vecchio dispositivo viene implementata nell'agente di recupero.⁴ Tuttavia, l'implementazione dell'agente di recupero "dimentica" l'LSKF dichiarata 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 mettere in evidenza alcune delle protezioni integrate nel protocollo. In particolare, il protocollo utilizza solo l'hash dell'LSKF in tutto. Ciò significa che, se l'LSKF ha un'entropia elevata (ad esempio se è una password ad alta entropia buona), l'archiviazione di Vault è strettamente meglio che archiviare 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 "con memoria forte" con salt dell'LSKF come parte del protocollo. Inoltre, associamo crittograficamente Vault a un identificatore del dispositivo che l'ha creato e associamo la richiesta di recupero a un nonce 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 automaticamente a ogni creazione di Vault, implementiamo la rotazione della chiave sovrascrivendo una voce di Vault esistente con una nuova creazione di Vault. L'indirizzo del contatore dei tentativi non riusciti utilizzato da Vault viene selezionato durante la creazione del 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 da forza bruta dell'LSKF.

Sicurezza del server per il servizio Cloud Key Vault

Il server viene implementato utilizzando una combinazione di software in esecuzione sul normale hardware del server 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 moduli hardware attendibili (THM, Trusted Hardware Modules, 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 impedisca la perdita della chiave privata all'esterno dei chip Titan nella coorte. Possono inoltre eseguire l'operazione di apertura di Vault e mantenere un contatore di tentativi non riusciti per Vault con incremento rigoroso (in cui il contatore sia 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 divulgare 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 una perdita di dati, poiché l'aggiornamento del firmware equivale a distruggere l'hardware esistente e sostituirlo con nuovi chip. Nel caso in cui sia necessaria una patch firmware critica, Google dovrà generare 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 limitare questo rischio, cerchiamo di mantenere il codebase del firmware abbastanza minimo e lo controlliamo attentamente per individuare potenziali problemi di sicurezza.

Protezioni software

Oltre ai limiti rigidi di errore per Vault imposti dai THM, il servizio CKV implementa anche la limitazione di frequenza basata su software. La limitazione di frequenza è progettata 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 proprie chiavi di recupero. Analogamente ai ritardi imposti dal dispositivo dell'utente dopo troppi tentativi non riusciti di sbloccare lo schermo, il servizio CKV imporrà 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 audit rigorosi.

Specifiche di 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 nell'Android Open Source Project entro la fine dell'anno.

Notes