Questi contenuti sono stati aggiornati l'ultima volta a ottobre 2023 e rappresentano lo status quo del momento in cui sono stati redatti. Criteri e sistemi di sicurezza di Google possono variare in futuro, grazie al costante miglioramento della protezione per i nostri clienti.
Questo documento descrive i controlli dell'infrastruttura utilizzati da Google per applicare l'integrità del processo di avvio sulle macchine di produzione. Questi controlli, basati su un processo di avvio misurato, aiutano Google a ripristinare le macchine dei data center dalle vulnerabilità in tutto lo stack di avvio e a ripristinare le macchine da stati di avvio arbitrari a configurazioni note.
Introduzione
La strategia di sicurezza di una macchina di un data center viene stabilita in fase di avvio. Il processo di avvio della macchina configura l'hardware della macchina e inizializza il relativo sistema operativo, garantendo al contempo la sicurezza dell'esecuzione della macchina nell'ambiente di produzione di Google.
In ogni fase del processo di avvio, Google implementa controlli leader del settore per applicare lo stato di avvio previsto e mantenere i dati dei clienti al sicuro. Questi controlli aiutano a garantire che le nostre macchine si avviino nel software previsto, consentendoci di rimuovere le vulnerabilità che potrebbero compromettere il livello di sicurezza iniziale della macchina.
Questo documento descrive il processo di avvio e mostra come i nostri controlli funzionano a ogni passaggio del flusso di avvio.
Contesto
Questa sezione definisce e fornisce il contesto per i termini credenziali macchina, radice di attendibilità hardware, credenziali sigillate e sigillatura crittografica.
Credenziali macchina
Uno dei componenti centrali del sistema di gestione delle macchine di Google è l'infrastruttura delle credenziali, che è composta da un'autorità di certificazione (CA) interna e da altri elementi del piano di controllo responsabili del coordinamento dei flussi di rotazione credenziali.
Le macchine nel parco di produzione di Google eseguono l'autenticazione reciproca quando stabiliscono canali sicuri. Per eseguire l'autenticazione reciproca, ogni macchina possiede le chiavi pubbliche della CA di Google. Ogni macchina dispone anche di una propria coppia di chiave pubblica/privata, nonché di un certificato per la coppia.
La coppia di chiave pubblica/privata di ogni macchina, insieme al certificato firmato dalla CA, è detta credenziale della macchina, che la macchina utilizza per eseguire l'autenticazione su altre macchine del parco risorse. All'interno della rete di produzione, le macchine controllano che le chiavi pubbliche di altre macchine siano certificate dalla CA di Google prima di scambiare il traffico.
Radici hardware di attendibilità e sigillatura crittografica
Man mano che i dispositivi informatici diventano sempre più sofisticati, aumenta anche la superficie di attacco di ogni dispositivo. Per tenere conto di ciò, i dispositivi sono sempre più dotati di radice di attendibilità hardware (RoT), che sono ambienti di esecuzione piccoli e affidabili che salvaguardano i dati sensibili della macchina. Il RoT compare anche su dispositivi mobili come laptop o cellulari, e su dispositivi più convenzionali come i PC.
I data center di Google dispongono di radici di attendibilità hardware personalizzate e progettate da Google, integrate nei livelli più profondi di ogni macchina, note come Titan. Utilizziamo Titan, insieme a un meccanismo chiamato sigillatura crittografica, per garantire che ogni macchina esegua la configurazione e le versioni software previste.
La sigillatura crittografica è simile a quella con un Trusted Platform Module (TPM), una specifica pubblicata dal Trusted Computing Group, ma offre alcuni vantaggi aggiuntivi. Titan offre una migliore capacità di misurazione e attestazione del firmware di basso livello.
La sigillatura crittografica comprende i seguenti due controlli:
- Crittografia dei dati sensibili
- Un criterio che deve essere soddisfatto prima che i dati possano essere decriptati
Credenziali sigillate
L'infrastruttura delle credenziali di Google utilizza il sigillatura crittografica per criptare le credenziali at-rest della macchina con una chiave controllata dalla radice di attendibilità hardware della macchina. La chiave privata delle credenziali criptate e il certificato corrispondente sono noti come credenziali sigillate. Oltre alle credenziali automatiche, Google utilizza questo meccanismo di sigillatura anche per proteggere altri dati sensibili.
Ogni macchina può decriptare e accedere alle relative credenziali solo se è in grado di soddisfare un criterio di decrittografia che specifica il software che la macchina deve avere avviato. Ad esempio, l'unione delle credenziali di una macchina a un criterio che specifica la release desiderata del kernel del sistema operativo garantisce che la macchina non possa partecipare al suo cluster della macchina a meno che non abbia avviato la versione del kernel richiesta.
Il criterio di decrittografia viene applicato tramite una procedura chiamata avvio con misurazioni. Ogni livello nello stack di avvio misura il livello successivo e la macchina attesta questa catena di misurazioni alla fine dell'avvio. Questa misurazione è spesso un hash di crittografia.
Procedura di sigillatura delle credenziali
Questa sezione descrive il processo di sigillatura delle credenziali e avvio misurato utilizzato dai computer di Google. Il seguente diagramma illustra questo flusso.
Per sigillare le credenziali di una macchina in base a un determinato criterio di avvio, vengono eseguiti i seguenti passaggi:
- L'infrastruttura di automazione delle macchine di Google avvia un aggiornamento software sulla macchina. Passa le versioni software previste all'infrastruttura delle credenziali.
- L'infrastruttura delle credenziali di Google richiede una chiave di conservazione a Titan, vincolata a criteri in modo che Titan la utilizzi solo se la macchina si avvia nel software previsto.
- L'infrastruttura delle credenziali confronta il criterio della chiave restituita con l'intent comunicato dall'infrastruttura di automazione delle macchine. Se l'infrastruttura delle credenziali ritiene che il criterio corrisponda all'intent, invia alla macchina una credenziale di macchina certificata.
- L'infrastruttura delle credenziali cripta questa credenziale utilizzando la chiave di sigillatura acquisita nel passaggio 2.
- La credenziale criptata viene archiviata sul disco per la decrittografia da parte di Titan agli avvii successivi.
Processo di avvio misurato
Lo stack di avvio delle macchine Google è composto da quattro livelli, mostrati nel diagramma seguente.
I livelli sono i seguenti:
- Spazio utente: applicazioni come daemon o carichi di lavoro.
- Software di sistema: un hypervisor o un kernel. Il livello più basso di software che fornisce un'astrazione rispetto a funzionalità hardware come networking, file system o memoria virtuale nello spazio utente.
- Firmware di avvio: il firmware che inizializza il kernel, ad esempio un BIOS e un bootloader.
- Radice di attendibilità hardware: nelle macchine Google, un chip Titan che misura in modo crittografico il firmware e altri servizi CPU di basso livello.
Durante l'avvio, ogni livello misura il livello successivo prima di passare il controllo a quel livello. La credenziale sigillata della macchina viene resa disponibile al sistema operativo solo se tutte le misurazioni acquisite durante l'avvio sono conformi al criterio di decrittografia delle credenziali sigillate, come specificato dall'infrastruttura delle credenziali di Google. Pertanto, se la macchina può eseguire operazioni con le sue credenziali sigillate, questa è la prova che la macchina ha soddisfatto il criterio di avvio misurato. Questo processo è una forma di attestazione implicita.
Se una macchina avvia un software che devia dallo stato previsto, non può decriptare ed eseguire operazioni con le credenziali necessarie per funzionare all'interno del parco risorse. Queste macchine non possono partecipare alla pianificazione dei carichi di lavoro finché l'infrastruttura di gestione delle macchine non attiva le azioni di riparazione automatiche.
Ripristino dalle vulnerabilità nel kernel
Supponiamo che su una macchina sia in esecuzione la versione A del kernel, ma i ricercatori della sicurezza scoprono che la versione del kernel presenta una vulnerabilità. In questi scenari, Google patch la vulnerabilità e implementa una versione B del kernel aggiornata nel parco risorse.
Oltre ad applicare le patch alla vulnerabilità, Google rilascia nuove credenziali per ogni macchina del parco risorse. Come descritto in Processo di sigillatura delle credenziali, le credenziali della nuova macchina sono associate a un criterio di decrittografia che viene soddisfatto solo se nella macchina si avvia la versione B del kernel. Qualsiasi macchina che non esegue il kernel previsto non può decriptare le nuove credenziali della macchina, poiché le misurazioni del firmware di avvio non soddisfano i criteri di avvio della macchina. Nell'ambito di questo processo, vengono revocate anche le credenziali della vecchia macchina.
Di conseguenza, queste macchine non sono in grado di partecipare al cluster delle macchine finché il loro kernel non viene aggiornato in modo da conformarsi all'intento del piano di controllo. Questi controlli aiutano a garantire che le macchine che eseguono la versione vulnerabile del kernel A non possano ricevere job o dati utente fino a quando non viene eseguito l'upgrade alla versione B del kernel.
Ripristino delle vulnerabilità nel firmware di avvio
Supponiamo che esista una vulnerabilità nel firmware di avvio, anziché nel kernel del sistema operativo. Gli stessi controlli descritti in Ripristino dalle vulnerabilità nel kernel aiutano Google a recuperare da questa vulnerabilità.
Il chip Titan di Google misura il firmware di avvio di una macchina prima dell'esecuzione, in modo che Titan possa determinare se il firmware di avvio soddisfa i criteri di avvio delle credenziali della macchina. Qualsiasi macchina che non esegue il firmware di avvio previsto non può ottenere nuove credenziali per la macchina, né può partecipare al suo cluster di macchina finché il firmware di avvio non è conforme all'intento del piano di controllo.
Recupero dalle vulnerabilità nel firmware root-of-trust
I RoT non sono immuni alle vulnerabilità, ma i controlli di avvio di Google consentono il ripristino dai bug anche a questo livello dello stack di avvio, all'interno del codice modificabile del RoT.
Lo stack di avvio di Titan implementa un proprio flusso di avvio sicuro e misurato. Quando un chip Titan si accende, il suo hardware misura in modo crittografico il bootloader di Titan, che a sua volta misura il firmware di Titan. In modo simile al kernel e al firmware di avvio della macchina, il firmware Titan è firmato crittograficamente con un numero di versione. Il bootloader di Titan convalida la firma ed estrae il numero di versione del firmware Titan, inserendo il numero di versione nel sottosistema di derivazione delle chiavi basato su hardware di Titan.
Il sottosistema hardware di Titan implementa uno schema di derivazione delle chiavi con controllo delle versioni, in base al quale il firmware Titan con versione X può ottenere chiavi univoche per chip associate a tutte le versioni minori o uguali a X. L'hardware Titan consente al firmware con versione X di accedere a chiavi di accesso associate a versioni inferiori o uguali a X, ma non maggiori di X. Tutti i secret sigillati in Titan, incluse le credenziali della macchina, vengono criptati utilizzando una chiave con controllo delle versioni.
Le chiavi di attestazione e di sigillatura sono univoche per ogni chip Titan. Le chiavi univoche consentono a Google di considerare attendibili solo i chip Titan che dovrebbero essere in esecuzione all'interno di un data center di Google.
Il seguente diagramma mostra Titan con le chiavi di versione. Il firmware della versione X non può accedere alla chiave della versione X+1, ma è possibile accedere a tutte le chiavi precedenti.
In caso di grave vulnerabilità del firmware Titan, Google implementa una patch con un numero di versione maggiore, quindi emette nuove credenziali per le macchine associate alla versione successiva del firmware Titan. Nessun firmware Titan più vecchio e vulnerabile è in grado di decriptare queste nuove credenziali. Pertanto, se una macchina esegue operazioni con le sue nuove credenziali in produzione, Google può affermare con sicurezza che il chip Titan della macchina esegue il firmware Titan aggiornato.
Garantire la radice di autenticità della fiducia
Tutti i controlli descritti in questo documento si basano sulla funzionalità del RoT dell'hardware. L'infrastruttura delle credenziali di Google si basa sulle firme emesse da questi RoT per sapere se sulla macchina è in esecuzione il software previsto.
Pertanto, è fondamentale che l'infrastruttura delle credenziali possa determinare se un RoT hardware sia autentico e se il RoT esegue il firmware aggiornato.
La produzione di ogni chip Titan è programmata con un'entropia unica. La routine di avvio di basso livello di Titan trasforma quell'entropia in una chiave univoca del dispositivo. Un secure elemento nella linea di produzione Titan approva questa chiave univoca, in modo che Google la riconosca come un chip Titan legittimo.
Il seguente diagramma illustra questo processo di approvazione.
Durante la fase di produzione, Titan utilizza la sua chiave univoca del dispositivo per approvare qualsiasi firma che emette, utilizzando un flusso simile a DICE (Device Identifier Resolution Engine). L'approvazione include le informazioni sulla versione del firmware Titan. Questa attestazione aiuta a impedire a un utente malintenzionato di impersonare una firma emessa da un chip Titan, di eseguire il rollback al firmware Titan meno recente e di impersonare il firmware Titan più recente. Questi controlli aiutano Google a verificare che le firme ricevute da Titan siano state emesse da hardware Titan autentico, che esegue l'autentico firmware Titan.
Integrazione dell'integrità di avvio
Questo documento descrive i meccanismi per garantire che i processori delle applicazioni delle macchine avviino il codice previsto. Questi meccanismi si basano su un flusso di avvio misurato accoppiato con un chip di root-of-trust hardware.
Il modello di minaccia di Google include utenti malintenzionati che potrebbero intromettersi fisicamente sul bus tra la CPU e il RoT, con l'obiettivo di ottenere in modo improprio le credenziali decriptate della macchina. Per ridurre al minimo questo rischio, Google sta promuovendo lo sviluppo di un approccio basato su standard per eliminare gli interposanti attivi, riunendo le API TPM e DPE di Trusted Computing Group e la radice di attendibilità integrata di Caliptra.
Passaggi successivi
- Per informazioni su come Google contribuisce a garantire l'integrità degli stack di avvio di macchine complesse non aggregate, consulta Attestazione remota di macchine disaggregate.
- Per informazioni generali sull'infrastruttura di sicurezza di Google, consulta la panoramica sulla progettazione della sicurezza dell'infrastruttura di Google.
- Per ulteriori informazioni su come Google contribuisce con le soluzioni di sicurezza Titan agli standard di settore, consulta la discussione su TPM Attested Boot in Big, Distributed Environments sul canale YouTube di Trusted Computing Group.
- Per altri white paper sulla sicurezza, consulta i white paper sulla sicurezza.
Autori: Jeff Andersen, Kevin Plybon