Panoramica dell'attestazione remota

L'attestazione remota è il processo di verifica che l'identità di un'istanza Confidential VM sia legittima e che funzioni nello stato previsto. L'attestazione può aiutarti a valutare l'affidabilità di un sistema prima di concedergli l'accesso alle tue risorse protette.

Parti e modelli di attestazione

Di solito, nel processo di attestazione sono coinvolte tre parti:

• Un attestatore. Su Google Cloud, questo è un workload su un'istanza Confidential VM che richiede l'accesso alle risorse protette. Per aumentare la fiducia che l'istanza Confidential VM non sia stata compromessa e non sia un impostore, la VM e il relativo host misurano lo stato dell'hardware e del software virtuali della VM durante la procedura di avvio.

• Un verificatore. Un verificatore è un sistema esterno che convalida le prove di un'istanza Confidential VM e le confronta con la relativa policy di attestazione per assicurarsi che la configurazione della VM sia quella prevista. Se la prova supera i controlli richiesti, lo strumento di verifica restituisce una versione firmata della prova nota come risultato dell'attestazione.

  Un verificatore può essere un servizio preesistente, ad esempio Google Cloud Attestation o Intel Trust Authority, o qualcosa che hai creato tu.

• Una relying party. La relying party controlla l'accesso alle risorse protette di cui ha bisogno l'attestatore. Una volta ricevuto un risultato di attestazione, la relying party controlla i valori nella prova in base alla sua norma di accesso. Se i valori corrispondono, l'attestatore può accedere alle risorse.

  In Google Cloud la relying party è spesso un pool di identità del workload, con il verificatore aggiunto come provider OpenID Connect (OIDC).

Il modo in cui le parti interagiscono dipende dal modello di attestazione seguito dalla tua architettura. L'RFC sull'architettura delle procedure di attestazione remota (RATS) definisce due modelli di attestazione principali: il modello di passaporto e il modello di controllo in background. La principale differenza tra i due è chi possiede l'identità verificata dell'attestatore: l'attestatore o la parte che fa affidamento.

Modello di passaporto

Il modello di passaporto utilizza la seguente procedura per confermare l'identità di un attestatore e concedere l'accesso alle risorse richieste:

1. L'attestatore invia una prova della sua identità a un verificatore.

2. Se le prove sono ritenute attendibili, lo strumento di verifica invia all'autore dell'attestazione il risultato dell'attestazione, che potrebbe assumere la forma di un token di attestazione.

3. L'attestatore invia il risultato dell'attestazione a una parte autorizzata.

4. La parte che fa affidamento verifica che il risultato dell'attestazione soddisfi determinate condizioni. Se il risultato soddisfa le aspettative, la relying party consente all'attestatore di accedere alle risorse richieste.

Nel modello del passaporto, l'autore dell'attestazione e la parte che fa affidamento devono concordare l'aspetto dei risultati dell'attestazione, il che significa che devono concordare un verificatore.

Modello di controllo dei precedenti

Il modello di controllo in background utilizza la seguente procedura per confermare l'identità di un attestatore e concedere l'accesso alle risorse richieste:

1. L'attestatore invia una prova della sua identità a una parte che fa affidamento.

2. La parte autorizzata inoltra la prova a un verificatore.

3. Se le prove vengono ritenute attendibili, lo strumento di verifica invia alla parte che fa affidamento il risultato dell'attestazione, spesso sotto forma di token di attestazione.

4. La parte che fa affidamento verifica che il risultato dell'attestazione soddisfi determinate condizioni. Se il risultato soddisfa le aspettative, la relying party consente all'attestatore di accedere alle risorse richieste.

Con il modello di controllo dei precedenti, una relying party determina le prove di attestazione che richiede e sceglie il verificatore.

Architettura e prove dell'attestatore

Questa sezione descrive in che modo un'istanza Confidential VM come attestatore fornisce prove a prova di manomissione della sua identità.

Radici di attendibilità

In un Trusted Execution Environment (TEE) come un'istanza Confidential VM, una root of trust è un componente di sicurezza fondamentale da cui viene stabilita un'altra attendibilità. Una radice di attendibilità fornisce funzioni crittografiche, è a prova di manomissione e non può essere modificata da un sistema operativo host.

Le radici di attendibilità si trovano all'interno di un confine di attendibilità in un TEE noto come Trusted Computing Base (TCB). Il TCB è una raccolta di hardware e software in una VM guest e nel relativo host responsabili di attività quali l'isolamento dell'ambiente (tramite meccanismi come la crittografia della memoria e l'isolamento dell'hypervisor) e l'esecuzione di misurazioni per mantenere l'integrità dell'ambiente.

Un TEE supporta le radici di attendibilità per le funzioni di misurazione, archiviazione e generazione di report:

• La radice di attendibilità per la misurazione è il codice che avvia le misurazioni della procedura di avvio del TEE.

• La root of trust per l'archiviazione fornisce memoria protetta per le misurazioni sotto forma di registri di misurazione.

• La radice di attendibilità per i report fornisce protezione dell'integrità e dell'autenticità per la catena di misurazione. Recupera le misurazioni dalla radice di attendibilità per l'archiviazione e le raggruppa in un pacchetto di prove firmato chiamato preventivo o report di attestazione. Questo pacchetto è firmato con una chiave di attestazione residente in TEE e può includere un nonce crittografico per garantire che la prova sia recente e protetta dagli attacchi di riproduzione.

  Termine chiave: un attacco di replay si verifica quando un malintenzionato copia le prove che verificano un'identità e le utilizza per ottenere l'accesso illegittimo alle risorse. Un modo per contrastare gli attacchi di replay è utilizzare un nonce: un numero casuale di breve durata e monouso fornito da una delle parti che proteggono le risorse, nel caso del Confidential Computing, il verificatore. L'entità che dimostra la propria identità deve incorporare il nonce nella prova prima che questa venga inviata. Se un malintenzionato tenta di utilizzare prove rubate per accedere alle risorse, è probabile che non ci riesca perché il nonce incluso nelle prove è già stato utilizzato o è scaduto.

Le seguenti informazioni descrivono in dettaglio i diversi approcci alle radici di attendibilità per le diverse tecnologie di Confidential Computing.

AMD SEV

Un'istanza Confidential VM con AMD SEV attesta il proprio ambiente e la propria configurazione utilizzando misurazioni basate su vTPM di Shielded VM. AMD Secure Processor e AMD SEV vengono utilizzati esclusivamente per la crittografia della memoria.

Le radici di attendibilità sono le seguenti:

• Radice di attendibilità per la misurazione: firmware dell'istanza VM

• Radice di attendibilità per l'archiviazione: vTPM di Shielded VM

• Radice di attendibilità per la generazione di report: vTPM di Shielded VM, che utilizza una chiave di attestazione privata per firmare i report di attestazione

Per scoprire quali misurazioni vengono registrate dove nel vTPM di Shielded VM, consulta Registri di configurazione della piattaforma vTPM.

AMD SEV-SNP

Un'istanza Confidential VM con AMD SEV-SNP attesta principalmente il suo ambiente e la sua configurazione tramite AMD Secure Processor, che gestisce le misurazioni di avvio iniziali.

Per le misurazioni di bootloader, kernel e spazio utente, è possibile utilizzare le misurazioni basate su vTPM di Shielded VM.

Le radici di attendibilità sono le seguenti:

• Radice di attendibilità per la misurazione: AMD Secure Processor + firmware dell'istanza VM

• Radice di attendibilità per l'archiviazione: AMD Secure Processor + vTPM di Shielded VM

• Radice di attendibilità per i report:

  • Misurazioni di avvio iniziali: il processore AMD Secure, che utilizza la chiave di approvazione del chip (VCEK) residente nel chip per firmare i report di attestazione

  • Misurazioni di bootloader, kernel e spazio utente: vTPM di Shielded VM

Per scoprire quali misurazioni vengono registrate nel processore AMD Secure, consulta Registro di misurazione AMD SEV-SNP.

Per scoprire quali misurazioni vengono registrate dove nel vTPM di Shielded VM, consulta Registri di configurazione della piattaforma vTPM.

Intel TDX

Un'istanza Confidential VM con Intel TDX attesta il proprio ambiente e la propria configurazione tramite il modulo Intel TDX. Il modulo Intel TDX misura il firmware guest della VM all'interno di un dominio di attendibilità isolato e archivia queste misure in Measurement of the Trust Domain (MRTD). Le misurazioni successive nella catena di avvio vengono misurate nei registri di misurazione in fase di esecuzione (RTMR).

Le radici di attendibilità sono le seguenti:

• Radice di attendibilità per la misurazione: modulo Intel TDX

• Radice di attendibilità per l'archiviazione: misurazione del dominio di trust (MRTD) e registri di misurazione in fase di runtime (RTMR)

• Root of trust per i report: l'enclave di citazione del dominio attendibile (TDQE) all'interno del modulo Intel TDX, che genera una chiave di attestazione per firmare le citazioni di attestazione

Per scoprire quali misurazioni vengono registrate nei registri di misurazione TDX, consulta Registri di misurazione Intel TDX.

Attestazione di software e hardware

Le tecnologie di Confidential Computing in Google Cloud possono essere considerate software o hardware attestati, a seconda delle loro radici di attendibilità.

Software attested significa che le radici di attendibilità sono basate sul software: il firmware virtuale è la radice di attendibilità per la misurazione e la radice di attendibilità per l'archiviazione è vTPM di Shielded VM. Il vTPM è gestito dall'hypervisor dell'host, mentre il firmware è gestito dalla VM guest. Su Google Cloud, entrambi questi componenti sono controllati da Google.

Attestato hardware significa che le misurazioni sono gestite e protette da hardware dedicato al di fuori del controllo del tuo fornitore di servizi. Su Google Cloud, questo hardware include AMD Secure Processor per AMD SEV-SNP (solo per le misurazioni di avvio) e il modulo Intel TDX per Intel TDX.

L'attestazione hardware rimuove l'hypervisor del service provider dalla radice di attendibilità per la misurazione e l'archiviazione e isola le misurazioni in hardware dedicato. Anche se un malintenzionato ottiene il controllo dell'hypervisor dell'host, non può falsificare un report o una citazione di attestazione perché non ha accesso per modificare i registri dell'hardware dedicato.

Le tecnologie di Confidential Computing fornite da Google Cloud sono classificate come segue:

• AMD SEV: software attestato. Il firmware virtuale si misura e le misurazioni vengono archiviate nel vTPM della Shielded VM.

• AMD SEV-SNP: hardware e software ibridi attestati. Le misurazioni di avvio, incluse le misurazioni del firmware virtuale, vengono registrate e archiviate nel processore sicuro AMD, il che le rende attestate dall'hardware. Le misurazioni del bootloader, del kernel e dello spazio utente vengono archiviate nel vTPM di Shielded VM, il che le rende attestate dal software. Puoi scegliere di utilizzare solo le misurazioni attestate dall'hardware, quelle attestate dal software o entrambe.

• Intel TDX: hardware attestato. Il modulo TDX misura il firmware virtuale e tutte le misurazioni vengono archiviate nel modulo Intel TDX. Il vTPM di Shielded VM fa ancora parte del sistema, ma non fa parte del TCB, a meno che tu non esegua software che richiede un'interfaccia TPM.

Registri di misurazione

Le radici di attendibilità per Confidential VM forniscono spazio di archiviazione schermato e resistente alla manomissione per le misurazioni sotto forma di registri di misurazione (MR). Il nome di questi registri di misurazione cambia a seconda della tecnologia di Confidential Computing in uso:

• AMD SEV: registri di configurazione della piattaforma (PCR). Si trovano all'interno del vTPM della Shielded VM.

  I vTPM di Shielded VM utilizzano tre banchi di PCR che memorizzano le stesse misurazioni, ma vengono sottoposti ad hashing con algoritmi diversi: SHA-1, SHA-256 e SHA-384.

• AMD SEV-SNP: il lancio MEASUREMENT register. Si trova all'interno del processore sicuro AMD.

  I PCR all'interno del vTPM della Shielded VM vengono utilizzati anche per archiviare le misurazioni di bootloader, kernel e spazio utente.

• Intel TDX: la misurazione in fase di compilazione del dominio attendibile (MRTD) e i registri di misurazione in fase di runtime (RTMR).

  Le misurazioni sono disponibili anche nei PCR vTPM di Shielded VM per il software che prevede un'interfaccia TPM.

Solo una radice di attendibilità può modificare un valore del registro. I registri di misurazione in genere contengono un singolo digest crittografico, che rappresenta un singolo evento o un insieme di eventi.

Per singoli eventi, come la misurazione dell'avvio o del tempo di compilazione di una VM, una radice di attendibilità in genere scrive direttamente nel registro e lo rende immutabile per il resto del ciclo di vita del TEE.

I componenti caricati in un secondo momento nella catena di avvio, come il bootloader, il kernel e lo spazio utente, potrebbero registrare misurazioni per più eventi in un unico registro. Per memorizzare le misurazioni per i set di eventi, i registri di misurazione espongono un comando extend che concatena il valore del registro esistente con un nuovo digest dell'evento, esegue l'hashing del valore concatenato e poi memorizza il digest risultante. Questo processo è rappresentato dalla seguente formula:

\(MR_{new}=hash(MR_{old}\;∥\;hash(measured\;data))\)

Poiché le funzioni hash sono unidirezionali, è difficile replicare gli stessi valori del registro delle misurazioni senza fornire le stesse misurazioni nello stesso ordine. Sebbene questa proprietà aiuti a determinare l'integrità della VM, può rendere difficile basare i criteri su valori specifici del registro di misurazione. Questo perché piccole modifiche agli input di misurazione, come aggiornamenti software o firmware, o una modifica all'ordine di misurazione, comportano valori di registro diversi, rendendoli criteri potenzialmente instabili su cui basare le policy e aumentando il carico di manutenzione. Se devi basare la policy sui valori dei registri di misurazione, prova a selezionare valori di registro più stabili, ad esempio PCR 0 o PCR 7 sui vTPM.

Suggerimento :per basare le norme su misurazioni individuali stabili anziché su valori di registro di misurazione, puoi utilizzare un log eventi generato dal tuo TCB. Un verificatore deve prima eseguire una ripetizione del log eventi per verificare l'integrità del log rispetto ai registri di misurazione e, dopo la verifica riuscita, può analizzare gli eventi per estrarre misurazioni significative.

Log eventi

Man mano che le misurazioni vengono scritte o estese nei registri delle misurazioni, uno o più log vengono scritti nel file system del sistema operativo guest per registrare gli eventi di misurazione che si verificano.

Questi log eventi hanno i seguenti scopi:

• Un verificatore può riprodurre i log eventi per esaminare passo passo il processo di misurazione dell'istanza Confidential VM utilizzando registri di misurazione simulati. Se i digest finali calcolati dal verificatore corrispondono a quelli finali segnalati dal tester, la fiducia che sia il log eventi sia la procedura di avvio dell'istanza Confidential VM non siano stati manomessi può aumentare.

• Dopo la riproduzione, un verificatore può analizzare i log eventi per confrontare le prove con le norme di attestazione. Un verificatore potrebbe richiedere a un attestatore di superare determinati criteri, ad esempio l'attivazione dell'avvio protetto o l'utilizzo di una specifica tecnologia di Confidential Computing, prima che venga restituito un risultato di attestazione positivo.

I log eventi vengono archiviati nel file system del sistema operativo guest nelle seguenti posizioni:

Tecnologia di Confidential Computing	MR da verificare	Tipo di log	Percorso del sistema operativo guest per la riproduzione del log eventi
AMD SEV, AMD SEV-SNP, Intel TDX	Registri di configurazione della piattaforma (PCR) vTPM	Log eventi Trusted Computing Group (TCG)	/sys/kernel/security/tpm0/binary_bios_measurements
Intel TDX	RTMR[0], RTMR[1], RTMR[2]	Log eventi di Confidential Computing (CCEL)	/sys/firmware/acpi/tables/data/CCEL

Scopri di più sulla riproduzione e sull'analisi dei log eventi.

Preventivi e report di attestazione

La radice di attendibilità per la generazione di report fornisce protezione dell'integrità e dell'autenticità per i digest archiviati nel registro delle misurazioni firmando le misurazioni con una chiave di attestazione. Il blob binario risultante è noto come PCR quote per i vTPM, report di attestazione per AMD SEV-SNP e quote per Intel TDX.

Il contenuto del blob binario varia a seconda delle diverse tecnologie di Confidential Computing:

• AMD SEV: il vTPM di Shielded VM legge i valori da una delle sue banche PCR (SHA-1, SHA-256 o SHA-384), li concatena in ordine numerico e poi esegue l'hashing del risultato con lo stesso algoritmo di hashing utilizzato per la banca PCR per creare un digest di riepilogo. Questo digest di riepilogo, insieme a un nonce facoltativo fornito da un verificatore, viene inserito in una struttura TPMS_ATTEST e firmato dalla chiave di attestazione privata del vTPM per creare una citazione PCR.

  Per informazioni dettagliate sulla struttura di TPMS_ATTEST, consulta Trusted Platform Module Library, Part 2: Structures (PDF).

• AMD SEV-SNP: il processore AMD Secure genera un digest SHA-384, basato sulle misurazioni di avvio iniziali eseguite prima dell'esecuzione dell'UEFI dell'istanza Confidential VM.

  Questo digest, altri dati della VM e un nonce facoltativo fornito da un verificatore vengono inseriti in una struttura ATTESTATION_REPORT firmata dalla chiave di approvazione del chip (VCEK) del processore sicuro AMD per creare un report di attestazione.

  Per informazioni dettagliate sulla struttura di ATTESTATION_REPORT, vedi SEV Secure Nested Paging Firmware ABI Specification (PDF).

• Intel TDX: il modulo TDX inserisce i valori MRTD e RTMR, altri dati della VM e un nonce facoltativo fornito da un verificatore in una struttura TDREPORT_STRUCT.

  La creazione di un preventivo è un processo in più passaggi. Innanzitutto, l'enclave di certificazione del provisioning all'interno della CPU deriva una chiave di certificazione del provisioning (PCK) da secret crittografici integrati nella CPU. Successivamente, l'enclave Quoting all'interno della CPU genera una chiave di attestazione privata, che viene firmata con la chiave di certificazione di provisioning. Il TDREPORT_STRUCT viene quindi firmato con la chiave di attestazione privata per creare una citazione.

  Per i dettagli sulla struttura di TDREPORT_STRUCT, consulta Intel Trust Domain Extensions (Intel TDX) Module Base Architecture Specification (PDF).

Raccomandazioni

Diversi tipi di approvazioni vengono utilizzati come prova che un'istanza Confidential VM è in esecuzione sulle configurazioni hardware, vTPM e firmware previste.

Certificati

I certificati X.509 v3 vengono utilizzati come prova dell'utilizzo di hardware AMD o Intel originale nell'host oppure che l'istanza Confidential VM utilizza un vTPM Shielded VM.

Il nome del certificato è diverso per ciascuna delle tecnologie di Confidential Computing:

• AMD SEV: certificato della chiave di attestazione (AK)

• AMD SEV-SNP: certificato della chiave di approvazione del chip (VCEK) della versione

• Intel TDX: certificato della chiave di provisioning (PCK)

Per AMD SEV, il certificato verifica il vTPM della Shielded VM. L'host invia una richiesta al server dell'autorità di certificazione di Google e esegue il provisioning automatico del certificato direttamente nell'archivio non volatile vTPM di un'istanza di VM confidenziale. Un guest può recuperare questo certificato singolarmente richiedendolo dal vTPM con software come <x0A>go-tpm-tools.

Per AMD SEV-SNP e Intel TDX, l'host estrae le prove hardware dalla CPU e le presenta a una cache gestita da Google. Questa cache memorizza i certificati estratti in precedenza dal servizio di distribuzione delle chiavi AMD e dal servizio di provisioning dei certificati Intel. Dopo aver presentato correttamente le prove hardware, i certificati vengono memorizzati nella cache sul disco dell'host e condivisi con l'ospite. Un ospite può recuperare questi certificati singolarmente per convalidare l'hardware con software come go-sev-guest e go-tdx-guest.

I certificati contengono le seguenti informazioni:

• L'identità dell'emittente del certificato, ovvero AMD, Google o Intel.

• La chiave di attestazione pubblica, che verifica la firma delle citazioni PCR (vTPM), dei report di attestazione (SEV-SNP) e delle citazioni di attestazione (Intel TDX).

• Solo attestazione hardware: le versioni TCB del microcodice e del firmware dell'hardware su cui è in esecuzione il firmware dell'host.

• Solo attestazione hardware: prova che lega il certificato a un processore fisico specifico, firmato con una chiave privata nel processore e che non può essere esfiltrata. Per AMD SEV-SNP, questa prova è l'ID piattaforma. Per Intel TDX, la prova è il manifest della piattaforma.

Firmware

Per l'attestazione hardware, le approvazioni di avvio del firmware sono disponibili direttamente dalle istanze VM o possono essere scaricate online. Le approvazioni di avvio sono buffer di protocollo serializzati in formato binario firmati che vengono utilizzati per confermare che il firmware virtuale di un'istanza Confidential VM non è stato manomesso.

Quando una VM viene avviata, il modulo AMD Secure Processor o Intel TDX esegue l'hashing del binario del firmware prima dell'esecuzione. Questo digest SHA-384 è memorizzato nel campo MEASUREMENT per AMD SEV-SNP e nell'MRTD per Intel TDX.

Puoi utilizzare questo digest per scaricare un'approvazione del lancio da Google, verificare che la firma sia radicata in Google con uno strumento come gcetcbendorsement, e poi verificare che i digest SHA-384 corrispondano tra la misurazione del firmware e ciò che è registrato nell'approvazione.

Oltre alla verifica del firmware, puoi utilizzare determinate proprietà in un'approvazione di avvio per applicare un criterio di accesso, ad esempio il numero di versione di sicurezza minima (SVN), il conteggio delle vCPU, la configurazione della memoria o l'ID famiglia dell'UEFI.

Per saperne di più, consulta Verificare il firmware di un'istanza Confidential VM.

Riproduzione e analisi del log eventi del verificatore

Oltre a verificare direttamente le prove fornite da un attestatore, un verificatore può riprodurre un log eventi fornito dall'attestatore per verificarne l'integrità rispetto ai valori del registro di misurazione.

A questo scopo, il verificatore crea una versione simulata di ogni registro di misurazione che deve controllare nell'ambito delle norme di attestazione. Poi compila il registro simulato utilizzando gli eventi di un log eventi. Se il valore finale del registro simulato corrisponde al valore memorizzato nel registro di misurazione reale equivalente, aumenta la fiducia che sia il log eventi sia la procedura di avvio dell'istanza Confidential VM non siano stati manomessi.

Una volta verificato in questo modo, il log può essere analizzato per ricavare singole misurazioni su cui un verificatore o una parte terza può basare le norme.

Crea i tuoi strumenti di analisi e riproduzione dei log degli eventi

Anche se puoi creare il tuo software per riprodurre e analizzare i log eventi, ti consigliamo di utilizzare software consolidati come go-eventlog per evitare errori comuni come la vulnerabilità EventType per i formati dei log eventi di Trusted Computing Group e Confidential Computing.

Se vuoi comunque creare il tuo software di replay e analisi, i seguenti esempi basati su vTPM possono aiutarti a comprendere le basi, anche se devi basare l'implementazione sul log eventi generato dalla tua istanza Confidential VM.

L'esempio seguente contiene eventi selezionati da un log eventi vTPM di Ubuntu 24.04, che vengono misurati nel PCR 0. Il log eventi è stato convertito da binario ad ASCII con tpm2_eventlog utilizzando il seguente comando:

sudo tpm2_eventlog /sys/kernel/security/tpm0/binary_bios_measurements

Gli eventi PCR 0 del log sono i seguenti:

---
version: 1
events:
- EventNum: 0
  PCRIndex: 0
  EventType: EV_NO_ACTION
  Digest: "0000000000000000000000000000000000000000"
  EventSize: 41
  SpecID:
  - Signature: Spec ID Event03
    platformClass: 0
    specVersionMinor: 0
    specVersionMajor: 2
    specErrata: 0
    uintnSize: 2
    numberOfAlgorithms: 3
    Algorithms:
    - Algorithm[0]:
      algorithmId: sha1
      digestSize: 20
    - Algorithm[1]:
      algorithmId: sha256
      digestSize: 32
    - Algorithm[2]:
      algorithmId: sha384
      digestSize: 48
    vendorInfoSize: 0
- EventNum: 1
  PCRIndex: 0
  EventType: EV_NO_ACTION
  DigestCount: 3
  Digests:
  - AlgorithmId: sha1
    Digest: "0000000000000000000000000000000000000000"
  - AlgorithmId: sha256
    Digest: "0000000000000000000000000000000000000000000000000000000000000000"
  - AlgorithmId: sha384
    Digest: "000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000"
  EventSize: 160
  Event: "53503830302d313535204576656e7433792b000056aca511a145224ba54128607dac543b0d476f6f676c652c20496e632e0016476f6f676c6520436f6d7075746520456e67696e650001000d476f6f676c652c20496e632e00792b000004322e37000300000028000000468e85a27fa36a458c790c1fe48b65ff4600690072006d007700610072006500520049004d0000000000000000000000000000000000"
- EventNum: 2
  PCRIndex: 0
  EventType: EV_NO_ACTION
  DigestCount: 3
  Digests:
  - AlgorithmId: sha1
    Digest: "0000000000000000000000000000000000000000"
  - AlgorithmId: sha256
    Digest: "0000000000000000000000000000000000000000000000000000000000000000"
  - AlgorithmId: sha384
    Digest: "000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000"
  EventSize: 288
  Event: "53503830302d313535204576656e7433792b000056aca511a145224ba54128607dac543b0d476f6f676c652c20496e632e0016476f6f676c6520436f6d7075746520456e67696e650001000d476f6f676c652c20496e632e00792b000004322e370001000000a800000068747470733a2f2f73746f726167652e676f6f676c65617069732e636f6d2f6763655f7463625f696e746567726974792f6f766d665f7836345f63736d2f3834383939616564336339653837363735666638303966356665613365366638383733353533643166303130306464623961653333323639323832356163636537333866343562646563323738613430393864316332376534393533373134332e66642e7369676e65640000000000000000000000000000"
- EventNum: 3
  PCRIndex: 0
  EventType: EV_S_CRTM_VERSION
  DigestCount: 3
  Digests:
  - AlgorithmId: sha1
    Digest: "4031fe1129fb826f12dcad169992cca9f4f56aa3"
  - AlgorithmId: sha256
    Digest: "fa129a8f82b65bcbce8f9e8e5f6de509beff9b1df33714116bf918c5a3bba45d"
  - AlgorithmId: sha384
    Digest: "21d340a4a30bb8865486d150cd9ceb46100662b92f336d38b87d70b373ca15c4c60878336924baa818dc2aceaeb40ea6"
  EventSize: 48
  Event: "47004300450020005600690072007400750061006c0020004600690072006d0077006100720065002000760032000000"
- EventNum: 4
  PCRIndex: 0
  EventType: EV_NONHOST_INFO
  DigestCount: 3
  Digests:
  - AlgorithmId: sha1
    Digest: "2b106cedd1631981619790bbc1afaa80cc6ecd3e"
  - AlgorithmId: sha256
    Digest: "6ac9241348a80c5755a63bcd1865b9f6d5720f6e925dc869bb4694281c1510c5"
  - AlgorithmId: sha384
    Digest: "1167e32c3814259ea4809234cccfbd2785c32bde882833bb199d6df6bd989a49f45663e63ce11699fcd01250050f042c"
  EventSize: 32
  Event: "474345204e6f6e486f7374496e666f0001000000000000000000000000000000"
- EventNum: 19
  PCRIndex: 0
  EventType: EV_SEPARATOR
  DigestCount: 3
  Digests:
  - AlgorithmId: sha1
    Digest: "9069ca78e7450a285173431b3e52c5c25299e473"
  - AlgorithmId: sha256
    Digest: "df3f619804a92fdb4057192dc43dd748ea778adc52bc498ce80524c014b81119"
  - AlgorithmId: sha384
    Digest: "394341b7182cd227c5c6b07ef8000cdfd86136c4292b8e576573ad7ed9ae41019f5818b4b971c9effc60e1ad9f1289f0"
  EventSize: 4
  Event: "00000000"

Quando l'istanza Confidential VM viene reimpostata, i relativi PCR vengono inizializzati su zero. Man mano che si verificano gli eventi, il valore nel banco SHA-256 del PCR 0 (PCRIndex: 0) cambia come segue (gli eventi EV_NO_ACTION non estendono il registro):

1. Il valore del registro viene concatenato al digest SHA-256 dell'evento successivo assegnato al PCR 0, EV_S_CRTM_VERSION. Il risultato concatenato viene nuovamente sottoposto all'hashing SHA-256 e poi archiviato nel registro. L'hexdigest SHA-256 del PCR 0 ora è 0c3684a7571193d76a68e489ded7bf186fc2fb1efe0c6dd9ce147960bbc57365.

2. Lo stesso processo viene utilizzato per l'evento EV_NONHOST_INFO. L'hexdigest SHA-256 del PCR 0 ora è 509f590b71fb22c9a6eef647e3c23611d13e599a6e15fdbb4db56ea4c2cb878d.

3. Lo stesso processo viene utilizzato per un evento EV_SEPARATOR, che indica che le estensioni di misurazione in un registro specifico sono completate. EV_SEPARATOR è un valore zero a 32 bit (\x00*4). In questo modo, l'esadecimale SHA-256 finale di PCR 0 è a0b5ff3383a1116bd7dc6df177c0c2d433b9ee1813ea958fa5d166a202cb2a85.

Il seguente codice Python mostra la procedura precedente creando un PCR 0 di Compute Engine simulato. Il codice non è una riproduzione del log eventi, perché deriva i digest degli eventi da valori noti. Quando crei una riproduzione corretta del log eventi, devi leggere i digest dal log eventi dell'istanza VM.

import hashlib

def CalculatePCR0(version_num: int, mem_encrypt_enum: int):
  """Calculates the expected SHA-256 PCR 0 value given the
  Compute Engine firmware version and Confidential Computing technology
  that's in use.

  This code uses derived values for events instead of reading digests from an
  event log. It's intended to demonstrate how to simulate the extend function
  used in measurement registers.

  While the code should provide correct values for PCR 0 in
  Compute Engine VM instances, for other PCRs and true event log replay
  you should read in digests from an event log instead of using derived values.

  PCR 0 measurements include:
    * EV_S_CRTM_VERSION: The firmware version string, in UTF-16 little-endian
      form. This value remains stable as long as the firmware version stays the
      same.
    * EV_NONHOST_INFO: This value changes based on the Confidential Computing
      technology that's in use.
    * EV_SEPARATOR: A 32-bit zero value to split UEFI and bootloader
      measurements.

  Args:
    version_num (int): The Compute Engine firmware version number. The
      value is 2.

    mem_encrypt_enum (int): The type of Confidential Computing technology used
      on the VM:

      0: None
      1: AMD SEV
      2: AMD SEV-ES
      3: Intel TDX
      4: AMD SEV-SNP

  Returns:
    A hexstring representing the expected PCR 0 digest.
  """
  # Create a hash object to act as PCR 0, and initialize it with zeroes.
  h = hashlib.sha256()
  h.update(b'\x00' * h.digest_size)

  # Update the hash object with the EV_S_CRTM_VERSION event, with a hard-coded
  # firmware version `version_num`.
  #
  # This code uses derived values for events. To use the digest supplied in an
  # event log for event log replay, you need to read in the event digest, and
  # then convert it to bytes before updating the hash object, similar to the
  # following:
  #
  # h.update(bytes.fromhex('fa129a8f82b65bcbce8f9e8e5f6de509beff9b1df33714116bf918c5a3bba45d'))
  #
  h.update(
          hashlib.sha256(
              # The firmware uses UCS-2 encoding, so we match it by encoding to
              # the equivalent UTF-16 little-endian. An extra null byte is
              # needed to match the required byte length.
              f'GCE Virtual Firmware v{version_num}\x00'.encode('utf-16-le')).digest()
          )

  # Create a new hash object to act as PCR 0 and update it with the previous
  # hash object's digest. This simulates the first part of the register EXTEND
  # function.
  h2 = hashlib.sha256()

  h2.update(h.digest())

  # Update the hash object with the EV_NONHOST_INFO event, which includes
  # `mem_encrypt_enum`, the Confidential Computing technology in use. Performing
  # this update completes the simulated EXTEND function.

  h2.update(
          hashlib.sha256(
              b'GCE NonHostInfo\x00'
              + (mem_encrypt_enum).to_bytes(1, byteorder='little')
              + (b'\x00' * 15)
              ).digest()
          )

  # Create a new hash object to act as PCR 0 and update it with the previous
  # hash object's digest. This simulates the first part of the register EXTEND
  # function.
  h3 = hashlib.sha256()
  h3.update(h2.digest())

  # Update the hash object with the EV_SEPARATOR event. Performing this update
  # completes the simulated EXTEND function.
  h3.update(hashlib.sha256(b'\x00' * 4).digest())

  # There are more PCR 0 events, but they're all `EV_NO_ACTION` and don't
  # affect the register value. Return the final simulated register value.
  digest = h3.hexdigest()
  return digest

print('\nPCR 0 simulation')
print('\nConfidential Computing type\tDigest')
# Compute Engine firmware version 2, no Confidential Computing
# Expected hexdigest: d0c70a9310cd0b55767084333022ce53f42befbb69c059ee6c0a32766f160783
print(f'None\t\t\t\t{CalculatePCR0(2, 0)}')

# Compute Engine firmware version 2, AMD SEV
# Expected hexdigest: a0b5ff3383a1116bd7dc6df177c0c2d433b9ee1813ea958fa5d166a202cb2a85
print(f'AMD SEV\t\t\t\t{CalculatePCR0(2, 1)}')

# Compute Engine firmware version 2, AMD SEV-SNP
# Expected hexdigest: 50597a27846e91d025eef597abbc89f72bff9af849094db97b0684d8bc4c515e
print(f'AMD SEV-SNP\t\t\t{CalculatePCR0(2, 4)}')

# Compute Engine firmware version 2, Intel TDX
# Expected hexdigest: 0cca9ec161b09288802e5a112255d21340ed5b797f5fe29cecccfd8f67b9f802
print(f'Intel TDX\t\t\t{CalculatePCR0(2, 3)}')

print()

Configurazione del componente attendibile

A seconda che venga utilizzato il modello di passaporto o il modello di controllo dei precedenti, la parte che fa affidamento riceve i risultati dell'attestazione dall'attestatore o dal verificatore.

La relying party verifica quindi che le attestazioni ricevute nei risultati dell'attestazione corrispondano ai valori previsti. Se i valori corrispondono, la relying party consente all'attestatore di accedere alle risorse come identità locale.

Un pattern comune per configurare una relying party in Google Cloud è utilizzare la federazione delle identità per i carichi di lavoro e trattare l'attestatore come un'identità federata:

1. Aggiungi il tuo verificatore come provider OIDC a un pool di identità del workload. Dopodiché, il account di servizio collegato al workload dell'istanza Confidential VM può fungere da identità federata e accedere alle risorse richieste.

2. Definisci i valori che le attestazioni del verificatore devono corrispondere per concedere all'attestatore l'accesso alle risorse.

   In Google Cloud, ciò comporta il mapping delle attestazioni di attestazione agli attributi in modo che Identity and Access Management (IAM) possa elaborarle come condizioni che un'identità federata deve superare per autenticarsi come entità.

   Puoi quindi concedere all'attestatore l'accesso diretto alle risorse aggiungendo un'associazione di ruolo per la sua entità federata alle policy di autorizzazione delle risorse necessarie. Per i servizi che non supportano le identità federate, puoi fornire l'accesso alle risorse tramite la simulazione dell'identità del service account.

In alternativa alla federazione delle identità per i carichi di lavoro, puoi scrivere codice per analizzare direttamente le rivendicazioni di un token di attestazione. Per un esempio, vedi Attestazione remota vTPM su Confidential Virtual Machine.