Questi contenuti sono stati aggiornati a maggio 2024 e rappresentano lo status quo. al momento in cui è stata scritta. 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 con misurazioni, aiutano a garantire che Google può recuperare i computer dei data center dalle vulnerabilità durante il proprio stack di avvio e restituiscono le macchine da stati di avvio arbitrari a configurazioni adeguate.
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 dell'hardware della macchina virtuale e inizializza il proprio sistema operativo, mantenendo in un ambiente sicuro per l'esecuzione 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:
- Consolida l'attendibilità delle credenziali della macchina tramite le radice di attendibilità hardware
- Applica 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
Contesto
Questa sezione definisce e fornisce contesto per i termini credenziali macchina, root of trust hardware, credenziali sigillate e sigillatura crittografica.
Credenziali macchina
Uno dei componenti centrali del sistema di gestione dei computer di Google è infrastruttura delle credenziali, ovvero un'autorità di certificazione interna (CA) e altri elementi del piano di controllo responsabili del coordinamento di rotazione delle credenziali.
Le macchine del parco risorse di produzione Google eseguono l'autenticazione reciproca quando instaurando canali sicuri. Per eseguire l'autenticazione reciproca, ogni macchina possiede le chiavi pubbliche CA di Google. Ogni macchina ha anche il suo una coppia di chiave pubblica/privata, nonché un certificato per quella coppia.
La coppia di chiave pubblica/privata di ogni macchina, insieme al certificato firmato da la CA, è nota come credenziale macchina, che la macchina utilizza per si autenticano con altre macchine del parco risorse. Nell'ambito della produzione rete, le macchine controllano che le altre macchine le chiavi pubbliche sono certificate CA di Google prima di scambiare il traffico.
Radice 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.
I data center di Google sono caratterizzati da una radice hardware personalizzata progettata da Google fiducia integrata nei livelli più profondi di ogni macchina, Titan. Utilizziamo Titan, insieme a un meccanismo chiamato sigillatura crittografica, per garantire che ogni macchina stia eseguendo la configurazione e la versione software previste.
La sigillatura crittografica è un servizio offerto da Titan che viene utilizzato per salvaguardare secrets. Le capacità di sigillatura di Titan sono simili a quelle presenti nei Trusted Platform Module (TPM) che viene pubblicata dal Trusted Computing Group. La sigillatura crittografica di Titan ha un ulteriore vantaggio, in quanto offre una 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 corrispondente certificato, è nota come credenziale protetta. Oltre a delle credenziali della macchina, Google usa questo meccanismo di chiusura per proteggere 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 decriptazione viene applicato in modo forzato attraverso un processo chiamato avvio con misurazioni. Ogni livello dello stack di avvio misura lo strato successivo e la macchina attesta a questa catena di misurazioni alla fine dello stivale. Questa misurazione spesso un hash di crittografia.
Procedura di chiusura 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, segui questi passaggi: 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 chiusura a Titan, vincolato a criteri, in modo che Titan lo utilizzi solo se la macchina si avvia per il software previsto.
- L'infrastruttura delle credenziali confronta il criterio della chiave restituita con l'intento comunicato dall'infrastruttura di automazione delle macchine. Se l'infrastruttura delle credenziali verifica che il criterio invia una credenziale di macchina certificata alla macchina.
- L'infrastruttura delle credenziali cripta questa credenziale usando il token 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 daemon 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 BIOS e bootloader.
- Radice di attendibilità hardware: nelle macchine Google, un chip Titan che misura in modo crittografico il firmware e altri servizi della CPU di basso livello.
Durante l'avvio, ogni livello misura lo strato successivo prima di passare il controllo per quel livello. La credenziale sigillata della macchina viene resa disponibile solo al operativo se tutte le misurazioni acquisite durante l'avvio sono conformi i criteri di decrittografia delle credenziali sigillate, come specificato dalle credenziali di Google dell'infrastruttura. 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 necessarie all'interno del parco risorse. Queste macchine non possono partecipare al carico di lavoro pianificazione finché l'infrastruttura di gestione delle macchine non attiva la riparazione automatica azioni.
Recupero dalle vulnerabilità nel kernel
Supponiamo che una macchina esegua il kernel in versione A, ma che i ricercatori di sicurezza che questa versione del kernel presenta una vulnerabilità. In questi scenari, Google corregge la vulnerabilità e implementa la versione B del kernel aggiornata nel parco risorse.
Oltre ad applicare la patch alla vulnerabilità, Google invia anche e credenziali per ogni macchina nel parco risorse. 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 che non sia che esegue il kernel desiderato non è in grado di decriptare le nuove credenziali della macchina, le misurazioni del firmware di avvio non soddisferanno 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 loro cluster di macchine fino a quando il kernel non viene aggiornato per renderlo 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.
Recupero dalle 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 per 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. Le macchine su cui non è in esecuzione il firmware di avvio previsto non possono ottenere le nuove credenziali e che la macchina non può partecipare di macchine finché il firmware di avvio non è conforme alle specifiche l'intento.
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 un codice modificabile.
Lo stack di avvio di Titan implementa un proprio flusso di avvio sicuro e misurato. Quando si accende un chip Titan, il suo hardware misura crittograficamente bootloader, che a sua volta misura il firmware di Titan. In modo simile all'interfaccia utente firmware di avvio e kernel, il firmware Titan è firmato in modo crittografico con 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 supporta il firmware con versione X alle chiavi di accesso associate a versioni inferiori o uguali a X, ma non superiori a X. Tutti i segreti riservati a Titan, inclusa la macchina credenziali, sono criptate con una chiave con controllo delle versioni.
Le chiavi di attestazione e di chiusura sono univoche per ciascun 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 i tasti 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. Un titano più vecchio e vulnerabile firmware 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 la radice di attendibilità e autenticità
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 di basso livello di Titan trasforma questa entropia in una chiave univoca del 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 questo processo di approvazione.
In fase di produzione, Titan utilizza la chiave univoca del dispositivo per firmare qualsiasi firma che emette. I chip Titan utilizzano un flusso simile Motore di composizione dell'identificatore dispositivo (DICE). La raccomandazione include le informazioni sulla versione del firmware Titan. Questa attestazione aiuta a impedire a un aggressore di simulare l'identità di 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
Il presente documento descrive i meccanismi per garantire che le macchine applicazione processori 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 intercettarsi fisicamente tra la CPU e RoT, con l'obiettivo di ottenere in modo improprio la la credenziale decriptata. Per ridurre al minimo questo rischio, Google sta promuovendo lo sviluppo di una basato su standard per sconfiggere gli interpositori attivi, riunendo TPM e DPE le API di Trusted Computing Group e Caliptra la radice di attendibilità integrata.
Passaggi successivi
- Per informazioni su come Google contribuisce a garantire l'integrità dei "macchine disaggregate" gli stack di avvio, vedi Attestazione remota di macchine disaggregate.
- Per informazioni generali sull'infrastruttura di sicurezza di Google, vedi 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