Questi contenuti sono stati aggiornati a maggio 2024 e rappresentano lo status quo al momento della loro redazione. Le norme e i sistemi di sicurezza di Google potrebbero cambiare 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 dotate di Titan. Questi controlli, basati su un processo di avvio misurato, contribuiscono a garantire che Google possa recuperare le macchine dei data center dalle vulnerabilità durante lo stack di avvio e riportarle da stati di avvio arbitrari a configurazioni valide note.
Introduzione
Il livello di sicurezza di una macchina di un data center dipende fortemente della macchina virtuale al momento dell'avvio. Il processo di avvio della macchina configura l'hardware e inizializza il sistema operativo, garantendo al contempo l'esecuzione sicura 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 per mantenere i dati dei clienti in tutta sicurezza. Questi controlli aiutano a garantire che le nostre macchine si avviino nei percorsi previsti software, il che ci consente di rimuovere le vulnerabilità che potrebbero compromettere la security posture iniziale della macchina.
Questo documento descrive il processo di avvio e dimostra come i nostri controlli durante il flusso di avvio. Gli obiettivi principali dei nostri controlli sono i seguenti:
- Stabilire la fiducia nelle credenziali della macchina tramite root of trust hardware
- Sigilla le credenziali della macchina a un criterio di avvio che specifica le versioni del firmware e del software consentite
- Applica il criterio di avvio sulle macchine tramite un processo di avvio misurato.
Sfondo
Questa sezione definisce e fornisce contesto per i termini credenziali macchina, root of trust hardware, credenziali sigillate e sigillatura crittografica.
Credenziali della macchina
Uno dei componenti centrali del sistema di gestione delle macchine di Google è la nostra infrastruttura delle credenziali, costituita da un'autorità di certificazione (CA) interna e da altri elementi del piano di controllo responsabili del coordinamento dei flussi di rotazione delle credenziali.
Le macchine del parco produzione di Google eseguono l'autenticazione reciproca quando stabiliscono canali sicuri. Per eseguire l'autenticazione reciproca, ogni macchina possiede le chiavi pubbliche CA di Google. Ogni macchina dispone inoltre di una propria coppia di chiavi pubblica/privata, nonché di un certificato per quella coppia di chiavi.
La coppia di chiavi pubblica/privata di ogni computer, insieme al certificato firmato dalla CA, è nota come credenziale del computer, che il computer utilizza per autenticarsi agli altri computer del parco macchine. 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 traffico.
Radici di attendibilità hardware e sigillatura crittografica
Man mano che i dispositivi informatici diventano più sofisticati, anche la superficie di attacco di ciascun dispositivo cresce. Di conseguenza, i dispositivi presentano sempre più spesso radice hardware trust (RoT), ovvero piccoli ambienti di esecuzione affidabili che proteggono sensibili per la macchina. I RoT vengono visualizzati anche nei dispositivi mobili come i laptop. o cellulari e in dispositivi più convenzionali come i computer.
Le macchine dei data center di Google sono dotate di hardware di attendibilità di primo livello personalizzato progettato da Google e integrato nei livelli più profondi di ogni macchina, noto come Titan. Utilizziamo Titan, insieme a un meccanismo chiamato sigillo crittografico, per garantire che su ogni macchina vengano eseguite le configurazioni e le versioni software previste.
La sigillatura crittografica è un servizio offerto da Titan che viene utilizzato per proteggere i segreti. Le capacità di sigillatura di Titan sono simili a quelle presenti nei Trusted Platform Module (TPM) che viene pubblicata dal Trusted Computing Group. Il sigillamento crittografico di Titan offre un ulteriore vantaggio, in quanto Titan offre un capacità di misurare e attestare firmware di basso livello.
La sigillatura crittografica comprende i due controlli seguenti:
- Crittografia dei dati sensibili
- Un criterio che deve essere soddisfatto prima di poter decriptare i dati
Credenziali sigillate
L'infrastruttura delle credenziali di Google utilizza la sigillatura crittografica per criptare le credenziali at-rest della macchina con una chiave controllata la radice di attendibilità hardware. La chiave privata delle credenziali criptate certificato corrispondente, è nota come credenziale protetta. Oltre alle credenziali della macchina, Google utilizza questo meccanismo di sigillatura per proteggere anche altri elementi di dati sensibili.
Ogni macchina può decriptare e accedere alla relativa credenziale solo se può soddisfare un criterio di decrittografia che specifica il software che la macchina deve avere avviato. Ad esempio, sigilla la credenziale di una macchina a un criterio che specifichi la release prevista del kernel del sistema operativo aiuta ad assicurare che la macchina non può partecipare al suo cluster della macchina a meno che non abbia avviato il kernel previsto completamente gestita.
Il criterio di decrittografia viene applicato in modo forzato attraverso un processo chiamato avvio con misurazioni. Ogni livello dello stack di avvio misura il livello successivo e la macchina attesta questa catena di misurazioni al termine dell'avvio. Questa misurazione è spesso un hash crittografico.
Procedura di sigillatura delle credenziali
Questa sezione descrive la sigillatura delle credenziali e il processo di avvio misurato utilizzato Macchine Google. Il seguente diagramma illustra questo flusso.
Per sigillare le credenziali di una macchina 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 del software previste alla credenziale dell'infrastruttura.
- L'infrastruttura delle credenziali di Google richiede una chiave di sigillatura da Titan, vincolata alle norme 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 lo scopo comunicato dall'infrastruttura di automazione delle macchine. Se l'infrastruttura delle credenziali ritiene che i criteri corrispondano allo scopo, emette una credenziale della macchina certificata per la macchina.
- L'infrastruttura delle credenziali cripta questa credenziale utilizzando la chiave di sigillatura acquisita nel passaggio 2.
- La credenziale criptata viene archiviata su disco per essere decriptata da Titan su stivali successivi.
Processo di avvio misurato
Google Machines è costituito da quattro strati, che vengono visualizzati in nel diagramma seguente.
I livelli sono i seguenti:
- Spazio utente: applicazioni come demoni o carichi di lavoro.
- Software di sistema: un hypervisor o un kernel. Il livello più basso che fornisce un'astrazione sulle funzionalità hardware, come networking, file system o memoria virtuale allo 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 trasferire 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 alle norme di decrittografia della credenziale sigillata, come specificato dall'infrastruttura delle credenziali di Google. Pertanto, se la macchina può eseguire operazioni con il suo le credenziali, ovvero la prova che la macchina ha soddisfatto il suo avvio misurato . Questo processo è una forma di attestazione implicita.
Se una macchina avvia un software che si discosta dallo stato previsto, non può decriptare ed eseguire operazioni con le credenziali di cui ha bisogno per operare all'interno del parco macchine. Queste macchine non possono partecipare alla programmazione dei carichi di lavoro finché l'infrastruttura di gestione delle macchine non attiva azioni di riparazione automatica.
Ripristino da vulnerabilità nel kernel
Supponiamo che una macchina esegua la versione del kernel A, ma che i ricercatori in materia di sicurezza scoprano che questa versione del kernel presenta una vulnerabilità. In questi scenari, Google corregge la vulnerabilità ed esegue il deployment di una versione B del kernel aggiornata nel fleet.
Oltre a correggere la vulnerabilità, Google emette anche nuove credenziali per ogni macchina del parco macchine. Come descritto nella sezione Procedura di sigillatura delle credenziali. le credenziali della nuova macchina sono associate a un criterio di decrittografia è soddisfatto se nella macchina si avvia la versione B del kernel. Qualsiasi macchina su cui non è in esecuzione il kernel previsto non può decriptare le credenziali della nuova 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 possono partecipare al cluster di macchine fino a quando il kernel non viene aggiornato in modo da essere conforme all'intent del piano di controllo. Questi aiutano a garantire che le macchine che eseguono la versione A del kernel vulnerabile non possono ricevere job o dati utente finché non viene eseguito l'upgrade alla versione B del kernel.
Ripristino da 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 Recupero dalle vulnerabilità nel kernel aiutare Google a riprendersi da una vulnerabilità di questo tipo.
Il chip Titan di Google misura il firmware di avvio di una macchina prima dell'esecuzione, in modo che Titan può determinare se il firmware di avvio soddisfa le credenziali della macchina criterio di avvio. Qualsiasi macchina su cui non è in esecuzione il firmware di avvio previsto non può ottenere nuove credenziali della macchina e non può partecipare al proprio cluster di macchine finché il firmware di avvio non è conforme alle intenzioni del piano di controllo.
Recupero dalle vulnerabilità nel firmware root-of-trust
I sistemi operativi di root non sono immuni alle vulnerabilità, ma i controlli di avvio di Google consentono di recuperare dai bug anche a questo livello dello stack di avvio, all'interno del codice mutabile del sistema operativo di root.
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 criptato il bootloader di Titan, che a sua volta misura il firmware di Titan. Analogamente al kernel e al firmware di avvio della macchina, il firmware di Titan è firmato crittograficamente con un numero di versione. Il bootloader di Titan convalida la firma ed estrae il numero di versione del firmware Titan, fornendo il numero di versione al un sottosistema di derivazione delle chiavi basato su hardware.
Il sottosistema hardware di Titan implementa uno schema di derivazione delle chiavi con controllo delle versioni, mentre il firmware Titan con versione X è in grado di ottenere chiavi univoche relative ai chip associate versioni precedenti o uguali a X. L'hardware Titan consente al firmware con versione X di accedere alle chiavi associate a versioni precedenti o uguali a X, ma non superiori a X. Tutti i secret sigillati su Titan, inclusa la credenziale della macchina, sono criptati utilizzando una chiave con versione.
Le chiavi di attestazione e di sigillatura sono univoche per ogni chip Titan. Le chiavi univoche consentono Google si fida solo dei chip Titan che dovrebbero essere in esecuzione data center di Google.
Il seguente diagramma mostra Titan con le chiavi di versione. La chiave della versione X+1 non può è accessibile dalla versione X del firmware, ma tutte le chiavi precedenti alla versione accessibili.
In caso di grave vulnerabilità nel firmware Titan, Google implementa una con un numero di versione maggiore, quindi emette nuove credenziali sono vincolati alla versione del firmware Titan più recente. Qualsiasi firmware Titan vulnerabile meno recente non è in grado di decriptare queste nuove credenziali. Pertanto, se una macchina esegue operazioni con le sue nuove credenziali in produzione, Google può con la certezza che il chip Titan della macchina ha avviato le versioni aggiornate completamente gestito di Google Cloud.
Garantire l'autenticità della radice di attendibilità
I controlli descritti in questo documento si basano tutti sulla funzionalità del l'hardware di Google. L'infrastruttura delle credenziali di Google si basa sulle firme emessi da queste RoT per sapere se la macchina esegue il software previsto.
È quindi fondamentale che l'infrastruttura delle credenziali possa determinare se un RoT hardware è autentico e se il RoT è aggiornato completamente gestito di Google Cloud.
Quando viene prodotto ogni chip Titan, è programmato con entropia unica. La routine di avvio a basso livello di Titan trasforma questa entropia in una chiave univoca per il dispositivo. R l'elemento di sicurezza della linea di produzione Titan approva questa chiave univoca in chip in modo che Google lo riconosca come un chip Titan legittimo.
Il seguente diagramma illustra questa procedura di raccomandazione.
In fase di produzione, Titan utilizza la chiave univoca del dispositivo per firmare qualsiasi firma che emette. I chip Titan utilizzano un flusso simile Device Identifier Compose Engine (DICE). La raccomandazione include informazioni sulla versione del firmware Titan. Questa attestazione aiuta a impedire a un aggressore di impersonare una firma emessa da un chip Titan, rollback al firmware Titan meno recente e furto d'identità firmware Titan più recente. Questi controlli aiutano Google a verificare che le firme ricevute di Titan sono stati emessi da un autentico hardware Titan su cui sono installati i modelli completamente gestito di Google Cloud.
Creazione sull'integrità in fase di avvio
Questo documento descrive i meccanismi per garantire che i processori di applicazioni delle macchine avviano il codice previsto. Questi meccanismi si basano su un flusso di avvio misurato, abbinato a un chip radice di attendibilità hardware.
Il modello di minaccia di Google include utenti malintenzionati che possono intercettare fisicamente tra la CPU e RoT, al fine di ottenere in modo improprio la la credenziale decriptata. Per contribuire a ridurre al minimo questo rischio, Google sta promuovendo lo sviluppo di un approccio basato su standard per sconfiggere gli interpositori attivi, combinando 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 delle macchine disaggregate complesse, consulta Attestazione remota delle macchine disaggregate.
- Per informazioni generali sull'infrastruttura di sicurezza di Google, consulta la panoramica sulla progettazione della sicurezza dell'infrastruttura Google.
- Per saperne di più su come Google sta contribuendo con le soluzioni di sicurezza Titan a standard di settore, consulta le Avvio attestato TPM in ambienti grandi e distribuiti parliamo del canale YouTube di Trusted Computing Group.
Autori: Jeff Andersen, Kevin Plybon