Questi contenuti sono stati aggiornati a maggio 2024 e rappresentano lo status quo al momento della loro stesura. Le norme e i 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 dotate di Titan. Questi controlli, basati su un processo di avvio con misurazioni, contribuiscono a garantire che Google possa ripristinare le macchine dei data center dalle vulnerabilità in tutto lo stack di avvio e restituire le macchine da stati di avvio arbitrari a configurazioni valide note.
Introduzione
La strategia di sicurezza di una macchina del data center dipende molto dalla configurazione della macchina al momento dell'avvio. Il processo di avvio della macchina configura l'hardware della macchina e inizializza il relativo sistema operativo, mantenendo la macchina sicura per l'esecuzione nell'ambiente di produzione di Google.
In ogni fase del processo di avvio, Google implementa controlli leader di settore per contribuire ad applicare lo stato di avvio previsto e a mantenere al sicuro i dati dei clienti. Questi controlli aiutano a garantire l'avvio delle nostre macchine nel software previsto, consentendoci di rimuovere le vulnerabilità che potrebbero compromettere la strategia di sicurezza iniziale della macchina.
Questo documento descrive il processo di avvio e dimostra il funzionamento dei 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 il contesto per i termini credenziali macchina, root of trust hardware, credenziali protette 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 interna e altri elementi del piano di controllo responsabili del coordinamento dei flussi di rotazione delle credenziali.
Le macchine del parco risorse di produzione 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 anche di una propria coppia di chiave pubblica/privata e di un certificato.
La coppia di chiave pubblica/privata di ogni macchina, insieme al certificato firmato dalla CA, è nota come credenziale macchina, che la macchina utilizza per autenticarsi 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.
Radice di attendibilità hardware e sigillatura crittografica
Man mano che i dispositivi informatici diventano più sofisticati, cresce anche la superficie di attacco di ogni dispositivo. Per tenere conto di ciò, i dispositivi presentano sempre più spesso i radice di attendibilità (RoT) hardware, ovvero ambienti di esecuzione di piccole dimensioni e attendibili che proteggono i dati sensibili per la macchina. I RoT compaiono anche nei dispositivi mobili, come laptop o cellulari, e nei dispositivi più convenzionali, come i computer.
Le macchine dei data center di Google sono caratterizzate da una radice di attendibilità hardware personalizzata e progettata da Google, e integrata nei livelli più profondi di ogni macchina, noti come Titan. Utilizziamo Titan, insieme a un meccanismo chiamato sigillatura crittografica, per garantire che su ogni macchina sia in esecuzione la configurazione e le versioni software previste.
La sigillatura crittografica è un servizio offerto da Titan che viene utilizzato per salvaguardare i segreti. Le capacità di sigillatura di Titan sono simili a quelle presenti nella specifica Trusted Platform Module (TPM), pubblicata dal Trusted Computing Group. La sigillatura crittografica di Titan presenta un ulteriore vantaggio, in quanto Titan offre una migliore capacità di misurazione e attestazione di 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 dalla radice di attendibilità hardware della macchina. La chiave privata delle credenziali criptate e il certificato corrispondente è nota come credenziale protetta. Oltre alle credenziali della macchina, Google utilizza questo meccanismo di chiusura anche per proteggere altri dati sensibili.
Ogni macchina può decriptare e accedere alle credenziali della macchina solo se è in grado di soddisfare un criterio di decrittografia che specifica il software che la macchina deve essere stata avviata. Ad esempio, proteggere le credenziali di una macchina in base a un criterio che specifica la release prevista del kernel del sistema operativo contribuisce ad assicurare che la macchina non possa partecipare al cluster della macchina a meno che non abbia avviato la versione del kernel prevista.
Il criterio di decriptazione viene applicato tramite un processo chiamato avvio misurato. Ogni livello dello stack di avvio misura lo strato successivo e la macchina attesta questa catena di misurazioni alla fine dell'avvio. Questa misurazione è spesso un hash crittografico.
Procedura di chiusura delle credenziali
Questa sezione descrive il processo di sigillatura delle credenziali e di avvio misurato utilizzato dalle macchine Google. Il seguente diagramma illustra questo flusso.
Per sigillare le credenziali di una macchina a un determinato criterio di avvio, si verificano i seguenti passaggi:
- L'infrastruttura di automazione delle macchine di Google avvia un aggiornamento del software sulla macchina. Passa le versioni del software previste all'infrastruttura delle credenziali.
- L'infrastruttura delle credenziali di Google richiede una chiave di chiusura a Titan, vincolata ai 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'intento comunicato dall'infrastruttura di automazione della macchina. Se l'infrastruttura delle credenziali verifica che il criterio corrisponda all'intent, invia una credenziale di macchina certificata alla macchina.
- L'infrastruttura delle credenziali cripta questa credenziale utilizzando la chiave di chiusura fornita nel passaggio 2.
- La credenziale criptata viene archiviata su disco per essere decriptata da Titan ad avvii successivi.
Processo di avvio misurato
Lo stack di avvio delle macchine Google è costituito da quattro livelli, che vengono visualizzati 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 allo spazio utente delle funzionalità hardware come il networking, il file system o la memoria virtuale.
- 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 lo strato 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 ai criteri di decrittografia delle credenziali sigillate, come specificato dall'infrastruttura delle credenziali di Google. Pertanto, se la macchina è in grado di eseguire operazioni con le sue credenziali sigillate, questa è la prova che la macchina ha soddisfatto il suo criterio di 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 per operare 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 azioni di riparazione automatiche.
Recupero dalle vulnerabilità nel kernel
Supponiamo che una macchina esegua la versione A del kernel, ma i ricercatori della sicurezza scoprino che questa versione del kernel presenta una vulnerabilità. In questi scenari, Google applica le patch alla vulnerabilità e implementa una versione B del kernel aggiornata nel parco risorse.
Oltre ad applicare la patch alla vulnerabilità, Google emette anche nuove credenziali della macchina a ogni macchina del parco risorse. Come descritto in Procedura di chiusura delle credenziali, le credenziali della nuova macchina sono associate a un criterio di decriptazione che viene soddisfatto solo se nella macchina viene avviata 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 soddisferanno il criterio di avvio della macchina. Nell'ambito di questo processo, vengono revocate anche le credenziali della macchina precedente.
Di conseguenza, queste macchine non sono in grado di partecipare al cluster delle macchine fino a quando il kernel non viene aggiornato in modo da essere conforme all'intent 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 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 consentono a Google di 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 possa determinare se il firmware di avvio soddisfa i criteri di avvio delle credenziali della macchina. Qualsiasi macchina su cui non è in esecuzione il firmware di avvio previsto non può ottenere nuove credenziali della macchina e tale macchina non può partecipare al cluster della macchina finché il firmware di avvio non è conforme all'intent 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 si accende un chip Titan, il suo hardware misura in modo crittografico il bootloader di Titan, che a sua volta misura il firmware di Titan. Analogamente al firmware di avvio e del kernel della macchina, il firmware Titan è firmato tramite crittografia con un numero di versione. Il bootloader di Titan convalida la firma ed estrae il numero di versione del firmware Titan, inserendolo 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 cui il firmware Titan con versione X può ottenere chiavi uniche di chip associate a tutte le versioni inferiori o uguali a X. L'hardware Titan consente al firmware con versione X di accedere alle chiavi associate a versioni inferiori o uguali a X, ma non superiori a X. Tutti i secret sigillati in Titan, incluse le credenziali della macchina, sono criptati utilizzando una chiave con controllo delle versioni.
Le chiavi di attestazione e di chiusura sono univoche per ciascun chip Titan. Le chiavi univoche consentono a Google di fidarsi solo dei chip Titan che dovrebbero essere in esecuzione in un data center di Google.
Il seguente diagramma mostra Titan con i tasti di versione. La chiave della versione X+1 non è accessibile dal firmware versione X, ma sono accessibili tutte le chiavi precedenti.
In caso di grave vulnerabilità nel firmware Titan, Google implementa una patch con un numero di versione maggiore, quindi emette nuove credenziali della macchina che sono associate alla versione del firmware Titan superiore. I firmware Titan meno recenti e vulnerabili non sono in grado di decriptare le 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 ha avviato il firmware Titan aggiornato.
Garantire la radice di attendibilità e autenticità
I controlli descritti in questo documento si basano tutti sulla funzionalità del sistema RoT hardware stesso. L'infrastruttura delle credenziali di Google si basa sulle firme emesse da questi 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 quest'ultimo esegue un firmware aggiornato.
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. Un elemento di sicurezza nella linea di produzione Titan approva questa chiave univoca per i chip, in modo che Google la riconosca come chip Titan legittimo.
Il seguente diagramma illustra questo processo di approvazione.
In fase di produzione, Titan utilizza la chiave univoca del dispositivo per approvare la firma che emette. I chip Titan utilizzano un flusso simile al Device Identifier Compose Engine (DICE). La raccomandazione include le informazioni sulla versione del firmware Titan. Questa attestazione contribuisce 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 consentono a Google di verificare che le firme ricevute da Titan siano state emesse da un hardware Titan autentico che esegue firmware Titan autentico.
Creazione sull'integrità in fase 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 a un chip radice di attendibilità hardware.
Il modello di minaccia di Google include utenti malintenzionati che potrebbero intercettarsi fisicamente sul bus tra la CPU e 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 interpositori 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 disaggregate complesse, consulta Attestazione remota di macchine disaggregate.
- Per informazioni generali sull'infrastruttura di sicurezza di Google, consulta Panoramica sulla progettazione della sicurezza dell'infrastruttura Google.
- Per ulteriori informazioni su come Google sta contribuendo alle soluzioni di sicurezza Titan agli standard di settore, guarda la discussione sul TPM Attested Boot in Big, Distributed Environments sul canale YouTube di Trusted Computing Group.
Autori: Jeff Andersen, Kevin Plybon