Application Layer Transport Security

Di Cesar Ghali, Adam Stubblefield, Ed Knapp, Jiangtao Li, Benedikt Schmidt, Julien Boeuf

I contenuti del presente documento sono aggiornati a dicembre 2017. Questo white paper rappresenta lo stato dell'arte al momento in cui è stato redatto. I criteri e i sistemi di sicurezza di Google Cloud potrebbero variare in futuro, in virtù del costante miglioramento della protezione per i nostri clienti.

Riepilogo a livello di CIO

  • Application Layer Transport Security (ALTS) è un sistema di autenticazione reciproca e crittografia di trasporto sviluppato da Google, utilizzato di solito per proteggere le comunicazioni RPC (Remote Procedure Call, chiamata di procedura remota) all'interno dell'infrastruttura di Google. Concettualmente, ALTS è simile al protocollo TLS con autenticazione reciproca, ma è stato progettato e ottimizzato per far fronte alle esigenze degli ambienti dei data center di Google.
  • Il modello di attendibilità di ALTS è stato pensato appositamente per applicazioni containerizzate di tipo cloud. Le identità sono associate a entità invece che a un nome server o a un host specifico. Questo modello di attendibilità favorisce la replica perfetta dei microservizi, il bilanciamento del carico e la ripianificazione tra host.
  • ALTS si basa su due protocolli: Handshake (con ripresa della sessione) e Record. Questi protocolli determinano in che modo le sessioni vengono stabilite, autenticate, criptate e riprese.
  • ALTS è una soluzione personalizzata del protocollo Transport Layer Security utilizzata da Google. Abbiamo adattato ALTS al nostro ambiente di produzione, perciò esistono alcune differenze rispetto al protocollo TLS, che è lo standard di settore. Per ulteriori dettagli, consulta la sezione Varianti.

Introduzione

I sistemi di produzione di Google sono composti da una serie di microservizi1 che complessivamente inviano O(1010) chiamate di procedura remota (RPC) al secondo. Quando un tecnico Google pianifica un carico di lavoro di produzione2, le RPC inviate o ricevute dal carico di lavoro vengono protette per impostazione predefinita con ALTS. Questa protezione automatica a configurazione zero è fornita dal protocollo ALTS (Application Layer Transport Security) di Google. Oltre a proteggere automaticamente le RPC, ALTS semplifica anche la replica dei servizi, il bilanciamento del carico e la ripianificazione su più macchine di produzione. Questo documento descrive ALTS e ne esplora il deployment all'interno dell'infrastruttura di produzione di Google.

Destinatari: questo documento è rivolto ai professionisti della sicurezza delle infrastrutture che vogliono scoprire in che modo la sicurezza per autenticazione e trasporto viene applicata su larga scala in Google.

Prerequisiti: oltre a questa introduzione, è necessaria una conoscenza di base della gestione dei cluster in Google.

Sicurezza a livello di applicazione e ALTS

Molte applicazioni, dai browser web alle VPN, si basano su protocolli di comunicazione sicuri come TLS (Transport Layer Security) e IPSec per proteggere i dati in transito3. Per proteggere le comunicazioni RPC, Google utilizza ALTS, un sistema di autenticazione reciproca e crittografia di trasporto che viene eseguito a livello di applicazione. L'uso della sicurezza a livello di applicazioni, consente a queste ultime di avere un'identità peer remota autenticata, che può essere utilizzata per implementare criteri di autorizzazione dettagliati.

Perché non il protocollo TLS?

Potrebbe sembrare insolito che Google utilizzi una soluzione di sicurezza personalizzata come ALTS quando la maggior parte del traffico Internet odierno è criptata tramite TLS. Google ha iniziato a sviluppare il protocollo ALTS nel 2007. All'epoca, TLS supportava molti protocolli legacy che non soddisfacevano i nostri standard minimi di sicurezza. Avremmo potuto progettare la nostra soluzione di sicurezza adottando i componenti TLS di cui avevamo bisogno e implementando quelli che volevamo. Tuttavia, i vantaggi della creazione di un sistema completamente nuovo e più adatto a Google superavano quelli dell'adattamento di un sistema esistente. Inoltre, ALTS è più idoneo per le nostre esigenze e storicamente più sicuro rispetto alle versioni precedenti di TLS. Di seguito sono elencate le principali differenze tra TLS e ALTS.

  • Esiste una differenza fondamentale tra i modelli di attendibilità4 di TLS con semantiche HTTPS e ALTS. Nel primo caso, le identità server sono associate a un nome specifico e al corrispondente schema di denominazione. In ALTS, la stessa identità può essere utilizzata con più schemi di denominazione. Questo livello di riferimento indiretto offre maggiore flessibilità e semplifica notevolmente il processo di replica dei microservizi, bilanciamento del carico e ripianificazione tra host.
  • La progettazione e l'implementazione di ALTS sono più semplici rispetto a TLS. Di conseguenza, è più facile monitorare i bug e le vulnerabilità della sicurezza mediante l'ispezione manuale del codice sorgente o il fuzzing su larga scala.
  • ALTS utilizza Protocol Buffer per serializzare i certificati e i messaggi di protocollo, mentre TLS utilizza certificati X.509 codificati con ASN.1. La maggior parte dei nostri servizi di produzione utilizza i buffer di protocollo per le comunicazioni (e talvolta l'archiviazione), il che rende ALTS una soluzione migliore per l'ambiente Google.

Progettazione di ALTS

ALTS è progettato per essere un sistema altamente attendibile e sicuro che consente l'autenticazione e la sicurezza tra servizi con interventi minimi da parte degli utenti. Per raggiungere questo obiettivo, la progettazione di ALTS include le proprietà elencate di seguito.

  • Trasparenza: la configurazione di ALTS è trasparente a livello di applicazione. Per impostazione predefinita, le RPC di servizio sono protette tramite ALTS. Ciò consente agli sviluppatori di applicazioni di concentrarsi sulla logica funzionale dei propri servizi senza doversi preoccupare della gestione delle credenziali o delle configurazioni della sicurezza. Quando viene stabilita una connessione tra servizi, ALTS fornisce alle applicazioni un'identità peer remota autenticata che può essere utilizzata per audit e controlli di autorizzazione granulari.
  • Crittografia all'avanguardia: tutti i protocolli e le primitive di crittografia utilizzati da ALTS sono aggiornati in modo da fronteggiare gli attacchi noti esistenti. ALTS viene eseguito su macchine controllate da Google, perciò tutti i protocolli crittografici supportati possono essere aggiornati facilmente e implementati rapidamente.
  • Modello di identità: ALTS esegue l'autenticazione principalmente in base all'identità, piuttosto che al nome host. In Google, a ogni entità di rete (ad esempio un utente aziendale, una macchina fisica, un servizio di produzione o un carico di lavoro) è associata un'identità. Tutte le comunicazioni tra servizi vengono autenticate reciprocamente.
  • Distribuzione delle chiavi: ALTS si basa sul fatto ogni carico di lavoro ha un'identità, espressa da una serie di credenziali. Queste vengono applicate a ciascun carico di lavoro durante l'inizializzazione, senza che l'utente debba fare nulla. Parallelamente, per queste credenziali vengono stabilite una radice e una catena di attendibilità per macchine e carichi di lavoro. Il sistema consente la rotazione e la revoca automatiche dei certificati senza l'intervento degli sviluppatori di applicazioni.
  • Scalabilità: ALTS è progettato per essere molto scalabile al fine di supportare le enormi dimensioni dell'infrastruttura di Google. Questo requisito ha portato allo sviluppo di una ripresa delle sessioni efficace.
  • Connessioni molto durature: le operazioni crittografiche con scambio di chiavi autenticate richiedono molte risorse di calcolo. Per soddisfare le dimensioni dell'infrastruttura di Google, dopo l'handshake ALTS iniziale, le connessioni possono essere conservate più a lungo per migliorare le prestazioni generali del sistema.
  • Semplicità: per impostazione predefinita, TLS supporta la compatibilità con le versioni precedenti del protocollo. ALTS è nettamente più semplice poiché Google controlla sia i client che i server, che abbiamo progettato in modo da supportare ALTS in maniera nativa.

Modello di attendibilità ALTS

ALTS esegue l'autenticazione principalmente in base all'identità, piuttosto che all'host. In Google, a ogni entità di rete (ad esempio un utente aziendale, una macchina fisica o un servizio di produzione) è associata un'identità. Queste identità sono incorporate nei certificati ALTS e utilizzate per l'autenticazione peer durante la creazione di connessioni sicure. Il modello che seguiamo mira a eseguire i nostri servizi di produzione come entità di produzione che possono essere gestite dai nostri tecnici SRE (Site Reliability Engineer)5. Le versioni di sviluppo di questi servizi di produzione vengono eseguite come entità di test che possono essere gestite sia dagli SRE che dagli sviluppatori.

Supponiamo, ad esempio, di avere un prodotto con due servizi: service-frontend e service-backend. Gli SRE possono rilasciare la versione di produzione dei servizi service-frontend-prod e service-backend-prod. Gli sviluppatori possono creare e lanciare le versioni di sviluppo di questi servizi, service-frontend-dev e service-backend-dev, ai fini di test. La configurazione delle autorizzazioni nei servizi di produzione verrà impostata in modo da non considerare attendibili le versioni di sviluppo dei servizi.

Credenziali ALTS

Esistono tre tipi di credenziali ALTS, tutte espresse nel formato dei messaggi Protocol Buffer.

  • Certificato master: è firmato da un servizio di firma remoto e viene utilizzato per verificare i certificati di handshake. Il certificato master contiene una chiave pubblica associata a una chiave privata master, ad esempio, una coppia di chiavi RSA. Questa chiave privata viene utilizzata per firmare i certificati di handshake. Questi, se utilizzati insieme alle norme ALTS descritte di seguito, sono in pratica dei certificati vincolati intermedi dell'autorità di certificazione (CA). I certificati master di solito vengono emessi per macchine di produzione e programmi di pianificazione di carichi di lavoro containerizzati come il Borgmaster6.
  • Certificato di handshake: viene creato e firmato localmente dalla chiave privata master. Questo certificato contiene i parametri utilizzati durante l'handshake ALTS (creazione di una connessione sicura), ad esempio i parametri statici Diffie-Hellman (DH) e la crittografia dell'handshake. Inoltre, il certificato di handshake contiene il certificato master da cui deriva, ovvero quello associato alla chiave privata master che firma il certificato di handshake.
  • Chiave di ripresa: è un secret utilizzato per criptare i ticket di ripresa. Questa chiave è identificata da un identificatore di ripresa (IDR) univoco e condiviso tra tutti i carichi di lavoro di produzione in esecuzione con la stessa identità e nella medesima cella del data center. Per ulteriori dettagli sulla ripresa delle sessioni in ALTS, consulta la sezione in basso.

La Figura 1 mostra la catena di certificati ALTS, composta da una chiave di verifica del servizio di firma, un certificato master e un certificato di handshake. Le chiavi di verifica del servizio di firma sono la radice di attendibilità in ALTS e sono installate su tutte le macchine di Google nelle nostre reti di produzione e aziendali.

Figura 1: catena di certificati ALTS

In ALTS, un servizio di firma convalida i certificati master che a loro volta convalidano i certificati di handshake. Poiché questi ultimi vengono creati più spesso dei certificati master, questa architettura riduce il carico per il servizio di firma. La rotazione dei certificati avviene frequentemente in Google, in particolare per i certificati di handshake7. Questa rotazione frequente serve a compensare le coppie di scambio di chiavi statiche incluse nei certificati di handshake8.

Emissione dei certificati

Per partecipare a un handshake sicuro ALTS, le entità sulla rete devono disporre di certificati di handshake. Innanzitutto, l'emittente ottiene un certificato master firmato dal servizio di firma e, facoltativamente, lo passa all'entità. In seguito, viene creato un certificato di handshake che viene firmato dalla chiave privata master associata.

Di solito, l'emittente è la nostra autorità di certificazione (CA) interna, per l'emissione di certificati a macchine e persone, oppure il Borgmaster, per l'emissione di certificati ai carichi di lavoro. Tuttavia, potrebbe anche essere un'altra entità, ad esempio un Borgmaster limitato per una cella di data center di prova.

La Figura 2 mostra come viene utilizzato il servizio di firma per creare un certificato master. Il processo prevede i passaggi seguenti.

Figura 2: emissione dei certificati

  1. L'emittente del certificato invia una richiesta di firma del certificato (CSR) al servizio di firma. A tale servizio viene richiesto di creare un certificato per l'identità A, che potrebbe essere, ad esempio, un utente aziendale o l'identità di un servizio di produzione Google.
  2. Il servizio di firma imposta come emittente del certificato (incluso nella CSR) il richiedente (l'emittente del certificato, in questo caso) e firma il certificato. Ricorda che la corrispondente chiave pubblica (di verifica) del servizio di firma è installata su tutti i computer di Google.
  3. Il servizio di firma restituisce il certificato firmato.
  4. Viene creato un certificato di handshake per l'identità A, firmato dalla chiave privata associata al certificato master.

Come mostrato nella procedura in alto, in ALTS l'emittente e il firmatario di un certificato sono due entità logiche diverse. In questo caso, l'emittente è l'entità che emette il certificato, mentre il firmatario è il servizio di firma.

Esistono tre categorie comuni di certificati in ALTS, ovvero per persone, per macchine e per carichi di lavoro. Nelle sezioni seguenti viene descritto come viene creato e utilizzato in ALTS ciascuno di questi certificati.

Certificati per persone

In Google utilizziamo ALTS per proteggere le RPC inviate dagli utenti umani ai servizi di produzione. Per inviare una RPC, un utente deve fornire un certificato di handshake valido. Ad esempio, se Alice vuole utilizzare un'applicazione per inviare una RPC protetta con ALTS, può effettuare l'autenticazione con la nostra CA interna utilizzando i propri nome utente, password e autenticazione a due fattori. In questo modo, Alice potrà ricevere un certificato di handshake valido 20 ore.

Certificati per macchine

Ogni macchina di produzione nei data center di Google ha un certificato master specifico che viene utilizzato per creare certificati di handshake per le applicazioni principali su quella macchina, ad esempio i daemon di gestione della macchina. L'identità principale incorporata in un certificato per macchine fa riferimento allo scopo tipico della macchina. Ad esempio, quelle utilizzate per eseguire tipi diversi di carichi di lavoro di produzione e sviluppo possono avere identità diverse. I certificati master possono essere utilizzati solo da macchine che eseguono stack software verificati. In alcuni casi, questa radice di attendibilità è incorporata in hardware di sicurezza personalizzato9. Tutti i certificati master per macchine di produzione sono emessi dalla CA e ruotati nel corso di alcuni mesi. Inoltre, tutti i certificati di handshake vengono ruotati con una frequenza di alcune ore.

Certificati per carichi di lavoro

Uno dei vantaggi fondamentali di ALTS è che si basa sulle identità dei carichi di lavoro, il che semplifica la replica dei servizi, il bilanciamento del carico e la ripianificazione su più macchine. Nella nostra rete di produzione, utilizziamo un sistema chiamato Borg10 per la gestione dei cluster e l'allocazione delle risorse delle macchine su larga scala. Il modo in cui Borg emette i certificati fa parte dell'implementazione da parte di ALTS di identità per carichi di lavoro indipendenti dalle macchine.

Ogni carico di lavoro nella nostra rete di produzione viene eseguito in una cella Borg. Ogni cella contiene un controller centralizzato logicamente chiamato Borgmaster, nonché diversi processi agente chiamati Borglet che vengono eseguiti su ogni macchina all'interno della cella. I carichi di lavoro vengono inizializzati con certificati di handshake associati specificatamente ed emessi dal Borgmaster. La Figura 3 mostra il processo di certificazione dei carichi di lavoro in ALTS con Borg.

Figura 3: creazione dei certificati di handshake nella rete di produzione di Google

Il Borgmaster adesso è pronto a pianificare i carichi di lavoro che devono utilizzare ALTS. I passaggi seguenti si verificano quando un client pianifica l'esecuzione di un carico di lavoro su Borg utilizzando un'identità specifica.

  1. In ogni Borgmaster è preinstallato un certificato master per macchine e una chiave privata associata (non mostrata nel diagramma).
  2. ALTSd11 genera un certificato di handshake Borgmaster e lo firma utilizzando la chiave privata master per macchine. Questo certificato di handshake consente al Borgmaster di inviare RPC protette con ALTS.
  3. Il Borgmaster crea un certificato master per carichi di lavoro di base e la chiave privata corrispondente. Il Borgmaster invia una richiesta (una RPC protetta con ALTS) per far sì che il certificato master per carichi di lavoro di base venga firmato dal servizio di firma. Di conseguenza, il servizio di firma indica sul certificato che il Borgmaster ne è l'emittente.
  4. Il Borgmaster verifica che il client sia autorizzato a eseguire carichi di lavoro utilizzando l'identità specificata nella configurazione del carico di lavoro. Se è così, il Borgmaster pianifica il carico di lavoro Borg sul Borglet e invia un certificato di handshake per carichi di lavoro e la chiave privata corrispondente. Questo certificato è concatenato al certificato master per carichi di lavoro di base. Successivamente, il certificato di handshake per carichi di lavoro e la rispettiva chiave privata vengono consegnati in modo sicuro al Borglet tramite un canale protetto da ALTS con autenticazione reciproca tra il Borgmaster e il Borglet. Il Borgmaster ruota il proprio certificato master per carichi di lavoro di base e invia di nuovo i certificati di handshake per tutti i carichi di lavoro in esecuzione con un intervallo di circa due giorni. Inoltre, ogni carico di lavoro in esecuzione con l'identità dello stesso utente nella medesima cella riceve la stessa chiave di ripresa e il medesimo identificatore di ripresa (IDR) di cui il Borgmaster aveva eseguito il provisioning.
  5. Quando il carico di lavoro deve effettuare una RPC protetta con ALTS, utilizza il certificato di handshake per carichi di lavoro nel protocollo di handshake. Viene anche utilizzato l'IDR all'interno dell'handshake per avviare la ripresa della sessione. Per ulteriori informazioni sulla ripresa delle sessioni in ALTS, consulta la sezione in basso.

Applicazione dei criteri ALTS

Le norme ALTS sono raccolte in un documento che elenca quali emittenti sono autorizzati a rilasciare determinate categorie di certificati per identità specifiche. Sono distribuite su ogni macchina della nostra rete di produzione. Ad esempio, le norme ALTS permettono alla CA di rilasciare certificati a macchine e persone. Inoltre, consentono al Borgmaster di emettere certificati per carichi di lavoro.

Abbiamo riscontrato che l'applicazione delle norme durante la verifica dei certificati, invece che al momento dell'emissione, è un approccio più flessibile perché permette di implementare norme distinte su diversi tipi di distribuzioni. Ad esempio, una norma in un cluster di test potrebbe essere più permissiva di una per un cluster di produzione.

Durante l'handshake ALTS, la convalida dei certificati include il controllo delle norme ALTS. Queste garantiscono che l'emittente elencato nel certificato in corso di convalida sia autorizzato a rilasciare tale certificato. In caso contrario, il certificato viene rifiutato e il processo di handshake non riesce. La Figura 4 mostra come funziona l'applicazione dei criteri in ALTS. Seguendo lo scenario nella Figura 2, supponiamo che Maria, un'utente aziendale che ha intenzione di aumentare i propri privilegi, voglia emettere un certificato master per l'amministratore di rete, che rappresenta un'identità di alto livello in grado di riconfigurare la rete. Va da sé che, secondo i criteri ALTS, Maria non è autorizzata a eseguire questa operazione.

Figura 4: emissione e utilizzo dei certificati

  1. Maria emette un certificato master per l'identità dell'amministratore di rete e lo fa firmare dal servizio di firma. Questa fase è simile ai primi tre passaggi nella Figura 2.
  2. Maria crea e firma localmente un certificato di handshake per l'amministratore di rete utilizzando la chiave privata master associata al certificato master creato.
  3. Se Maria tenta di impersonare l'identità dell'amministratore di rete utilizzando il certificato di handshake creato, il responsabile delle norme ALTS, allo stesso livello con cui Maria tenta di comunicare, bloccherà l'operazione.

Revoca dei certificati

In Google, un certificato viene annullato quando scade o se viene incluso nel nostro elenco revoche certificati. Questa sezione descrive come funzionano i meccanismi interni di revoca dei certificati da parte di Google il cui deployment, al momento della stesura di questo documento, è ancora in fase di prova.

Tutti i certificati inviati a utenti aziendali umani hanno un timestamp di scadenza giornaliera che obbliga gli utenti a riautenticarli quotidianamente. Molti certificati concessi alle macchine di produzione non utilizzano timestamp di scadenza. Non utilizziamo i timestamp per la scadenza dei certificati di produzione perché ciò può portare a interruzioni causate da problemi di sincronizzazione oraria. Utilizziamo, invece, l'elenco revoche certificati come fonte attendibile per la rotazione e la gestione dei certificati in caso di incidenti. La Figura 5 mostra come funziona l'elenco revoche certificati.

Figura 5: creazione di un certificato master con un ID di revoca

  1. Quando viene inizializzata12 un'istanza, la nostra CA contatta il servizio di elenco revoche certificati e chiede un intervallo di ID di revoca. Si tratta di un ID con lunghezza di 64 bit e due componenti: una categoria di certificato a 8 bit (ad esempio per persone o macchine) e un identificatore di certificato a 56 bit. Il servizio di elenco revoche certificati sceglie un intervallo di ID e lo restituisce alla CA.
  2. Quando la CA riceve una richiesta di certificato master, lo crea e incorpora un ID di revoca scelto nell'intervallo.
  3. Allo stesso tempo, la CA associa il nuovo certificato all'ID di revoca e invia queste informazioni al servizio di elenco revoche certificati.
  4. La CA emette il certificato master.

Gli ID di revoca assegnati ai certificati di handshake dipendono da come viene usato il certificato. Ad esempio, i certificati di handshake per utenti aziendali umani ereditano l'ID di revoca del certificato master dell'utente. Nel caso dei certificati di handshake per carichi di lavoro Borg, l'ID di revoca viene assegnato dall'intervallo di ID di revoca del Borgmaster. Questo intervallo di ID viene assegnato al Borgmaster dal servizio di elenco revoche certificati con una procedura simile a quella mostrata nella Figura 5. Ogni volta che un peer è coinvolto in un handshake ALTS, controlla una copia locale del file dell'elenco revoche certificati per assicurarsi che il certificato del peer remoto non sia stato revocato.

Il servizio di elenco revoche certificati compila tutti gli ID di revoca in un singolo file, che può essere inviato a tutte le macchine Google che utilizzano ALTS. Sebbene il database dell'elenco revoche certificati abbia una dimensione di molte centinaia di megabyte, il file CRL generato è solo di pochi megabyte grazie a una serie di tecniche di compressione.

Protocolli ALTS

ALTS si basa su due protocolli: Handshake (con ripresa della sessione) e Record. Questa sezione fornisce una panoramica generale di ciascun protocollo. Queste informazioni non descrivono i dettagli specifici dei protocolli.

Protocollo Handshake

Si tratta di un protocollo di scambio di chiavi autenticate basato su Diffie-Hellman che supporta sia la Perfect Forward Secrecy (PFS) sia la ripresa delle sessioni. L'infrastruttura ALTS garantisce che ogni client e server disponga di un certificato con le rispettive identità e di una chiave Ellie Curve Diffie-Hellman (ECDH) concatenata a una chiave di verifica attendibile del servizio di firma. In ALTS, la PFS non è abilitata per impostazione predefinita perché le chiavi statiche ECDH vengono aggiornate di frequente per rinnovare la forward secrecy anche se la PFS non viene utilizzata nell'handshake. Durante un handshake, il client e il server negoziano in modo sicuro una chiave di crittografia di transito condivisa che verrà protetta con il protocollo Record. Ad esempio, il client e il server potrebbero accettare una chiave a 128 bit che verrà utilizzata per proteggere una sessione RPC mediante AES-GCM. L'handshake è costituito da quattro messaggi del buffer di protocollo serializzati. La Figura 6 ne mostra una panoramica.

Figura 6: messaggi del protocollo Handshake ALTS

  1. Il client avvia l'handshake mediante l'invio di un messaggio ClientInit. Questo messaggio contiene il certificato di handshake del client, nonché un elenco di dati criptati relativi all'handshake e i protocolli Record supportati dal client. Se il client sta tentando di riprendere una sessione terminata, includerà un identificatore di ripresa e un ticket di ripresa crittografato del server.

  2. Una volta ricevuto il messaggio ClientInit, il server verifica il certificato del client. Se valido, il server sceglie una crittografia dell'handshake e un protocollo Record dall'elenco fornito dal client. Il server utilizza una combinazione di informazioni contenute nel messaggio ClientInit e di proprie informazioni locali per calcolare il risultato dello scambio DH. Questo risultato viene utilizzato come input per le funzioni di derivazione delle chiavi13 insieme alla trascrizione del protocollo per generare i seguenti secret di sessione:

    • Una chiave secret M del protocollo Record utilizzata per criptare e autenticare i messaggi del payload.
    • Un secret di ripresa R da utilizzare nel ticket di ripresa per le sessioni future.
    • Un secret dell'autenticatore A.

    Il server invia un messaggio ServerInit contenente il proprio certificato, la cifratura di handshake scelta, il protocollo Record e un ticket di ripresa criptato facoltativo.

  3. Il server invia un messaggio ServerFinished contenente un autenticatore di handshake14. Il valore per questo autenticatore viene calcolato utilizzando un codice HMAC (Hash-based Message Authentication Code) in base a una stringa di bit predefinita e al secret dell'autenticatore A.

  4. Quando il client riceve il messaggio ServerInit, verifica il certificato del server, calcola il risultato dello scambio DH in modo simile al server e ricava gli stessi secret M, R e A. Il client utilizza il secret derivato A per verificare il valore dell'autenticatore nel messaggio ServerFinished ricevuto. A questo punto del processo di handshake, il client può iniziare a utilizzare il secret M per criptare i messaggi. Poiché ora il client è in grado di inviare messaggi criptati, possiamo dire che ALTS ha un singolo protocollo Handshake RTT.

  5. Alla fine dell'handshake, il client invia un messaggio ClientFinished con un valore simile per l'autenticatore (vedi il passaggio 3), calcolato in base a una diversa stringa di bit predefinita. Se necessario, il client può includere un ticket di ripresa criptato per sessioni future. Una volta che questo messaggio viene ricevuto e verificato dal server, il protocollo Handshake ALTS viene concluso e il server può iniziare a utilizzare il secret M per criptare e autenticare ulteriori messaggi di payload.

Il protocollo Handshake è stato rivisto da Thai Duong, appartenente al team interno di analisi della sicurezza di Google, e verificato formalmente utilizzando lo strumento Proverif15 di Bruno Blanchet con l'assistenza di Martin Abadi.

Protocollo Record

Nella sezione Protocollo Handshake abbiamo descritto in che modo viene utilizzato il protocollo Handshake per negoziare un secret del protocollo Record. Questo secret di protocollo viene utilizzato per criptare e autenticare il traffico di rete. Il livello dello stack che esegue queste operazioni è chiamato ALTS Record Protocol (ALTSRP).

ALTSRP contiene una suite di schemi di crittografia con varie dimensioni di chiavi e funzionalità di sicurezza. Durante l'handshake, il client invia il proprio elenco di schemi preferiti, ordinati per preferenza. Il server sceglie il primo protocollo nell'elenco del client che corrisponde alla configurazione locale del server. Questo metodo di selezione dello schema consente a client e server di avere preferenze di crittografia diverse, il che ci consente di introdurre (o rimuovere) schemi di crittografia.

Utilizzo dei frame

I frame sono la più piccola unità di dati in ALTS. A seconda delle dimensioni, ciascun messaggio ALTSRP può essere costituito da uno o più frame. Ogni frame contiene i seguenti campi:

  • Length (Lunghezza): un valore non firmato a 32 bit che indica la lunghezza del frame in byte. Questo campo della lunghezza di 4 byte non è incluso nella lunghezza totale del frame.
  • Type (Tipo): un valore a 32 bit che specifica il tipo di frame, ad esempio un frame di dati.
  • Payload: i dati effettivi autenticati e, facoltativamente, criptati che vengono inviati.

La lunghezza massima di un frame è di 1 MB più 4 byte di lunghezza. Per gli attuali protocolli RPC, limitiamo ulteriormente la lunghezza dei frame poiché quelli più corti richiedono meno memoria per il buffering. Inoltre, frame più grandi potrebbero essere sfruttati da un potenziale utente malintenzionato durante un attacco di tipo Denial of Service (DoS) nel tentativo di sottrarre risorse a un server. Oltre a limitare la lunghezza dei frame, esiste anche un numero massimo di frame che possono essere criptati utilizzando lo stesso secret M del protocollo Record. Il limite varia a seconda dello schema di crittografia utilizzato per criptare e decriptare il payload dei frame. Una volta raggiunto questo limite, la connessione deve essere chiusa.

Payload

In ALTS, ogni frame contiene un payload protetto per garantirne l'integrità e, facoltativamente, criptato16. A momento della pubblicazione di questo documento, ALTS supporta le seguenti modalità.

  • AES-128-GCM e AES-128-VCM: modalità AES-GCM e AES-VCM con chiavi a 128 bit. Queste modalità proteggono la riservatezza e l'integrità del payload utilizzando rispettivamente gli schemi GCM e VCM17.
  • AES-128-GMAC e AES-128-VMAC: supportano la protezione solo per l'integrità e utilizzano rispettivamente GMAC e VMAC per il calcolo dei tag. Il payload viene trasferito in testo non crittografato con un tag crittografico che ne protegge l'integrità.

In Google, utilizziamo diverse modalità di protezione a seconda del modello di rischio e dei requisiti delle prestazioni. Se le entità coinvolte nelle comunicazioni si trovano all'interno dello stesso confine fisico controllato da o per conto di Google, viene utilizzata solo la protezione dell'integrità. Queste entità possono comunque scegliere di eseguire l'upgrade alla crittografia autenticata a seconda di quanto siano sensibili i loro dati. Se le entità coinvolte nelle comunicazioni si trovano in confini fisici diversi controllati da o per conto di Google e, di conseguenza, le comunicazioni passano attraverso la wide area network, eseguiamo automaticamente l'upgrade della sicurezza della connessione impostando la crittografia autenticata, indipendentemente dalla modalità scelta. Google applica tipi diversi di protezione ai dati in transito se vengono trasmessi al di fuori di un confine fisico controllato da o per conto di Google, poiché non è possibile applicare le stesse rigorose misure di sicurezza.

Ogni singolo frame è protetto e, facoltativamente, criptato per proteggerne l'integrità. Entrambi i peer gestiscono contatori di richieste e risposte, che vengono sincronizzati durante il normale funzionamento. Se il server riceve una richiesta con ordine non corretto o ripetuta, la verifica dell'integrità crittografica non riesce e la richiesta viene eliminata. Allo stesso modo, il client annulla le risposte ripetute o con ordine non corretto. Inoltre, il fatto che entrambi i peer gestiscano i contatori (invece di includere i loro valori nell'intestazione del frame) consente di risparmiare ulteriori byte in transito.

Ripresa delle sessioni

ALTS consente agli utenti di riprendere le sessioni precedenti senza la necessità di eseguire operazioni crittografiche asimmetriche gravose. La ripresa delle sessioni è una funzionalità incorporata del protocollo Handshake ALTS.

L'handshake ALTS consente a client e server di scambiare (e memorizzare nella cache) in modo sicuro i ticket di ripresa da utilizzare per riprendere connessioni future18. Ogni ticket di ripresa memorizzato nella cache è indicizzato da un identificatore di ripresa (IDR) univoco per tutti i carichi di lavoro in esecuzione con la stessa identità e nella medesima cella del data center. Questi ticket sono criptati mediante chiavi simmetriche associate agli identificatori corrispondenti.

ALTS supporta due tipi di ripresa delle sessioni:

  1. Ripresa delle sessioni sul lato server: un client crea e cripta un ticket di ripresa contenente l'identità del server e il secret di ripresa R derivato. Il ticket di ripresa viene inviato al server al termine dell'handshake nel messaggio ClientFinished. Nelle sessioni future, il server potrà scegliere di riprendere la sessione mediante il reinvio al client del ticket nel messaggio ServerInit. Una volta ricevuto il ticket, il client può recuperare sia il secret di ripresa R sia l'identità del server. Il client può utilizzare queste informazioni per riprendere la sessione.

    L'IDR è sempre associato a un'identità e non a connessioni specifiche. In ALTS, più client possono utilizzare la stessa identità nel medesimo data center. In questo modo, i client possono riprendere le sessioni con server con cui potrebbero non aver comunicato in precedenza, ad esempio se un bilanciatore del carico invia il client a un server diverso che esegue la stessa applicazione.

  2. Ripresa delle sessioni sul lato client: al termine dell'handshake, il server invia al client un ticket di ripresa criptato nel messaggio ServerFinished. Questo ticket include il secret di ripresa R e l'identità del client, che può utilizzare il ticket per riprendere una connessione con qualsiasi server che condivide lo stesso IDR.

Quando una sessione viene ripresa, il secret di ripresa R viene utilizzato per derivare i nuovi secret di sessione M′, R′ e A′. M′ è utilizzato per criptare e autenticare i messaggi di payload, A′ per autenticare i messaggi ServerFinished e ClientFinished, mentre R′ è incapsulato in un nuovo ticket di ripresa. Nota: lo stesso secret di ripresa R non viene mai utilizzato più di una volta.

Varianti

Attacchi di tipo Key Compromise Impersonation

Per via della sua progettazione, il protocollo Handshake ALTS è suscettibile ad attacchi di tipo Key Compromise Impersonation (KCI). Se un utente malintenzionato viola la chiave privata DH o la chiave di ripresa di un carico di lavoro, potrebbe utilizzarla per impersonare altri carichi di lavoro in quello soggetto ad attacco19. Questo è previsto in modo esplicito nel nostro modello di rischio per la ripresa delle sessioni poiché vogliamo che i ticket di ripresa inviati da un'istanza di un'identità possano essere utilizzati da altre istanze della stessa identità.

Esiste una variante del protocollo Handshake ALTS che protegge da attacchi KCI, ma vale la pena utilizzarla solo in ambienti in cui non si desidera usare la ripresa delle sessioni.

Privacy dei messaggi di handshake

ALTS non è progettato per mascherare le identità interne coinvolte nelle comunicazioni, perciò non cripta alcun messaggio di handshake per nascondere le identità dei peer.

Perfect Forward Secrecy

In ALTS, la Perfect Forward Secrecy (PFS) è supportata, ma non abilitata per impostazione predefinita. Utilizziamo, invece, rotazioni frequenti dei certificati per stabilire la forward secrecy per la maggior parte delle applicazioni. Con TLS 1.2 (e le versioni precedenti), la ripresa delle sessioni non è protetta con la PFS. Quando quest'ultima è abilitata con ALTS, è attiva anche per le sessioni riprese.

Ripresa senza round trip

TLS 1.3 fornisce la ripresa delle sessioni senza round trip (0-RTT), tuttavia questo metodo offre caratteristiche di sicurezza più deboli20. Abbiamo deciso di non includere un'opzione 0-RTT in ALTS perché le connessioni RPC su Google sono generalmente di lunga durata. Di conseguenza, la riduzione della latenza di impostazione dei canali non era una soluzione ottimale per la maggiore complessità e/o la minore sicurezza richiesta dagli handshake 0-RTT.

Ulteriori riferimenti

Note a piè di pagina

1 Un microservizio è uno stile architetturale che struttura un'applicazione come raccolta di servizi con accoppiamento libero che implementano le funzionalità aziendali.
2 Un carico di lavoro di produzione è un'applicazione che i tecnici Google pianificano per l'esecuzione nei data center Google.
3 Per ulteriori informazioni sul modo in cui Google protegge i dati in transito, consulta il nostro white paper Crittografia dei dati in transito in Google Cloud.
4 Un modello di attendibilità è il meccanismo mediante il quale un protocollo di sicurezza identifica, distribuisce e ruota credenziali e identità.
5 Alcuni servizi sono gestiti direttamente dagli sviluppatori.
6 Il Borgmaster è responsabile della pianificazione e dell'inizializzazione dei carichi di lavoro di produzione Google. Per ulteriori informazioni consulta Large-scale cluster management at Google with Borg.
7 Per ulteriori informazioni sulle frequenze di rotazione dei certificati, consulta il white paper Crittografia dei dati in transito in Google Cloud.
8 Se una chiave viene violata, l'utente malintenzionato può rilevare solo il traffico per la durata della coppia di chiavi.
11 ALTSd: un daemon responsabile, tra le altre operazioni ALTS, della creazione dei certificati di handshake.
12 In pratica, la CA ha accesso alle chiavi private del servizio di firma, perciò le due entità logiche diventano una singola entità fisica.
13 In particolare, HKDF-Extract e HKDF-Expand, secondo quanto definito in RFC-5869.
14 L'implementazione del protocollo Handshake ALTS concatena i messaggi ServerInit e ServerFinished in un singolo payload in transito.
16 La crittografia del payload viene negoziata dal protocollo Record durante l'handshake.
17 Lo schema AES-GCM a 128 bit si basa su NIST 800-38D. Lo schema AES-VCM viene discusso in dettaglio nella pubblicazione AES-VCM, An AES-GCM Construction Using an Integer-Based Universal Hash Function.
18 La ripresa delle sessioni comporta operazioni simmetriche leggere solo se non vengono utilizzati parametri temporanei.