In che modo Google applica l'integrità del boot sulle macchine di produzione

Questi contenuti sono stati aggiornati a maggio 2024 e rappresentano lo status quo al momento della loro redazione. I criteri e i sistemi di sicurezza di Google potranno variare in futuro, in virtù del costante miglioramento della protezione per i nostri clienti.

Questo documento descrive i controlli dell'infrastruttura utilizzati da Google per applicare la 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 del data center dalle vulnerabilità durante lo stack di avvio e riportarle da stati di avvio arbitrari a configurazioni valide note.

Introduzione

La security posture 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 e inizializza il sistema operativo, garantendo al contempo l'esecuzione sicura della macchina nell'ambiente di produzione di Google.

In ogni fase della procedura di avvio, Google implementa controlli di primo livello per contribuire a applicare lo stato di avvio previsto e a proteggere i dati dei clienti. Questi controlli contribuiscono a garantire che le nostre macchine vengano avviate con il software previsto, consentendoci di rimuovere le vulnerabilità che potrebbero compromettere la postura di sicurezza iniziale della macchina.

Questo documento descrive la procedura di avvio e mostra come funzionano i nostri controlli durante il flusso di avvio. Gli obiettivi principali dei nostri controlli sono i seguenti:

Sfondo

Questa sezione definisce e fornisce il contesto per i termini credenziali della macchina, radice di attendibilità hardware, credenziali sigillate e sigillo crittografico.

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 dell'autorità di certificazione di Google. Ogni macchina dispone inoltre di una propria coppia di chiave pubblica/privata, nonché di un certificato per quella coppia di chiavi.

La coppia di chiave pubblica/privata di ogni macchina, insieme al certificato firmato dall'autorità di certificazione, è nota come credenziale della macchina, che la macchina utilizza per autenticarsi presso le altre macchine del parco. 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 di calcolo diventano più sofisticati, cresce anche la superficie di attacco di ciascun dispositivo. Per questo motivo, i dispositivi dispongono sempre più di root of trust (RoT) hardware, ovvero piccoli ambienti di esecuzione attendibili che proteggono i dati sensibili della macchina. I malware di tipo rootkit vengono visualizzati anche su dispositivi mobili come laptop o cellulari e su dispositivi più tradizionali 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 funzionalità di sigillatura di Titan sono simili a quelle riportate nella specifica del Trusted Platform Module (TPM), pubblicata dal Trusted Computing Group. La sigillatura di Titan ha un vantaggio aggiuntivo, in quanto offre una migliore capacità di misurare e attestare il firmware a basso livello.

Il sigillamento crittografico 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 la sigillatura crittografica per criptare le credenziali della macchina inattive con una chiave controllata dalla radice di attendibilità hardware della macchina. La chiave privata della credenziale criptata e il corrispondente certificato sono noti come credenziali sigillate. Oltre alle credenziali delle macchine, Google utilizza questo meccanismo di sigillatura anche per proteggere altri elementi di dati sensibili.

Ogni macchina può decriptare e accedere alla propria credenziale solo se può soddisfare un criterio di decrittografia che specifica il software che la macchina deve aver avviato. Ad esempio, il sigillo della credenziale di una macchina a un criterio che specifica la release prevista del kernel del sistema operativo contribuisce ad assicurare che la macchina non possa partecipare al proprio cluster di macchine a meno che non abbia avviato la versione del kernel prevista.

I criteri di decrittografia vengono applicati tramite 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 la procedura di avvio misurata utilizzata dalle macchine Google. Il seguente diagramma illustra questo flusso.

Il flusso di sigillatura delle credenziali.

Per sigillare le credenziali di una macchina a un determinato criterio di avvio, vengono eseguiti i seguenti passaggi:

  1. L'infrastruttura di automazione delle macchine di Google avvia un aggiornamento del software sulla macchina. Trasmette le versioni software previste all'infrastruttura delle credenziali.
  2. 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.
  3. 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.
  4. L'infrastruttura delle credenziali cripta questa credenziale utilizzando la chiave di sigillatura acquisita nel passaggio 2.
  5. La credenziale criptata viene archiviata su disco per la decrittografia da parte di Titan agli avviamenti successivi.

Procedura di avvio con misurazioni

La struttura di avvio delle macchine Google è composta da quattro livelli, visualizzati nel seguente diagramma.

I quattro livelli del processo di avvio con misurazioni.

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 di software che fornisce un'astrazione delle funzionalità hardware come la rete, il file system o la 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 criptato il firmware e altri servizi della CPU a 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 le sue credenziali sigillate, è la prova che ha soddisfatto il 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 di cui ha bisogno per operare all'interno del parco macchine. Queste macchine non possono partecipare alla pianificazione dei carichi di lavoro finché l'infrastruttura di gestione delle macchine non attiva le 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 procedura di sigillatura delle credenziali, le credenziali della nuova macchina sono associate a un criterio di decrittografia soddisfatto solo se sulla macchina viene avviata 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 le norme di avvio della macchina. Nell'ambito di questa procedura, 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 controlli contribuiscono a garantire che le macchine che eseguono la versione del kernel A vulnerabile non possano ricevere job o dati utente finché non viene eseguito l'upgrade alla versione del kernel B.

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 Ripristino da vulnerabilità nel kernel aiutano Google a recuperare 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 possa determinare se il firmware di avvio soddisfa le norme di avvio della credenziale della macchina. 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.

Ripristino da vulnerabilità nel firmware della radice di attendibilità

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 di Titan, passandolo al sottosistema di derivazione delle chiavi basato sull'hardware di Titan.

Il sottosistema hardware di Titan implementa uno schema di derivazione delle chiavi con versione, in base al quale il firmware di Titan con la versione X può ottenere chiavi univoche per il chip associate a tutte le 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 a Google di considerare attendibili solo i chip Titan che dovrebbero essere in esecuzione in un data center Google.

Il seguente diagramma mostra Titan con le chiavi di versione. Non è possibile accedere alla chiave della versione X+1 con il firmware della versione X, ma tutte le chiavi precedenti sono accessibili.

Versioni di Titan.

In caso di una grave vulnerabilità nel firmware di Titan, Google implementa una patch con un numero di versione maggiore, quindi emette nuove credenziali della macchina associate alla versione del firmware di Titan successiva. 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ò affermare con certezza che il chip Titan della macchina ha avviato il firmware Titan aggiornato.

Garantire l'autenticità della radice di attendibilità

I controlli descritti in questo documento si basano tutti sulla funzionalità del RoT hardware stesso. L'infrastruttura delle credenziali di Google si basa sulle firme generate 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 sul RoT è in esecuzione un firmware aggiornato.

Quando ogni chip Titan viene prodotto, viene programmato con un'entropia univoca. La routine di avvio a basso livello di Titan trasforma questa entropia in una chiave univoca per il dispositivo. Un elemento di sicurezza sulla linea di produzione di Titan convalida questa chiave univoca del chip in modo che Google lo riconosca come chip Titan legittimo.

Il seguente diagramma illustra questa procedura di raccomandazione.

La procedura di raccomandazione di Titan.

In produzione, Titan utilizza la propria chiave univoca del dispositivo per convalidare qualsiasi firma che emette. I chip Titan utilizzano un flusso simile a DICE (Device Identifier Composition Engine). L'approvazione include le informazioni sulla versione del firmware di Titan. Questa attestazione contribuisce a impedire a un malintenzionato di rubare l'identità di una firma emessa da un chip Titan, di eseguire il rollback a un firmware Titan precedente e di rubare l'identità di un 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 firmware Titan autentico.

Migliorare l'integrità dell'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, accoppiato a un chip root-of-trust hardware.

Il modello di minacce di Google include attaccanti che potrebbero interporsi fisicamente sul bus tra la CPU e la RoT, con l'obiettivo di ottenere in modo improprio la credenziale decriptata della macchina. 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 del Trusted Computing Group e la radice di attendibilità integrata di Caliptra.

Passaggi successivi

Autori: Jeff Andersen, Kevin Plybon