Remote Attestation – Übersicht

Die Remote-Attestierung ist der Prozess, bei dem überprüft wird, ob die Identität einer Confidential VM-Instanz legitim ist und ob sie sich in einem erwarteten Zustand befindet. Mithilfe der Attestierung können Sie die Vertrauenswürdigkeit eines Systems bewerten, bevor Sie ihm Zugriff auf Ihre geschützten Ressourcen gewähren.

Attestierungsparteien und ‑modelle

In der Regel sind drei Parteien am Attestierungsprozess beteiligt:

• Ein Attestierer. Auf Google Cloudist dies eine Arbeitslast auf einer Confidential VM-Instanz, die Zugriff auf geschützte Ressourcen benötigt. Um das Vertrauen zu stärken, dass die Confidential VM-Instanz nicht manipuliert wurde und kein Betrüger ist, werden während des Bootvorgangs Messungen des virtuellen Hardware- und Softwarestatus der VM und ihres Hosts durchgeführt.

• Ein Prüfer Ein Prüfer ist ein externes System, das die Nachweise einer vertraulichen VM-Instanz validiert und anhand seiner Attestierungsrichtlinie prüft, um sicherzustellen, dass die VM-Konfiguration wie erwartet ist. Wenn der Nachweis die erforderlichen Prüfungen besteht, gibt der Zertifikatsprüfer eine signierte Version des Nachweises zurück, die als Bestätigungsergebnis bezeichnet wird.

  Ein Prüfer kann ein bereits vorhandener Dienst wie Google Cloud Attestation oder Intel Trust Authority oder ein selbst entwickelter Dienst sein.

• Eine vertrauende Partei. Die vertrauende Partei steuert den Zugriff auf geschützte Ressourcen, die der Attestierer benötigt. Nach Erhalt eines Attestierungsergebnisses prüft die vertrauende Partei die Werte im Beweis anhand ihrer Zugriffsrichtlinie. Wenn die Werte übereinstimmen, darf der Attestierer auf die Ressourcen zugreifen.

  Die Google Cloud vertrauende Partei ist häufig ein Workload Identity-Pool, wobei der Prüfer als OpenID Connect-Anbieter (OIDC) hinzugefügt wird.

Wie die Parteien interagieren, hängt vom Attestierungsmodell ab, dem Ihre Architektur folgt. Im RFC zur RATS-Architektur (Remote ATtestation procedureS) werden zwei Hauptmodelle für die Attestierung definiert: das Passport-Modell und das Background Check-Modell. Der Hauptunterschied zwischen den beiden besteht darin, welche Partei die bestätigte Identität des Attestierenden besitzt: der Attestierende oder die vertrauende Partei.

Reisepassmodell

Das Passport-Modell verwendet das folgende Verfahren, um die Identität eines Attesters zu bestätigen und Zugriff auf angeforderte Ressourcen zu gewähren:

1. Der Attestierer sendet einen Nachweis seiner Identität an einen Prüfer.

2. Wenn die Beweise als vertrauenswürdig eingestuft werden, sendet der Zertifikatsprüfer das Attestierungsergebnis an den Attestierer. Dieses kann in Form eines Attestierungstokens vorliegen.

3. Der Attestierer sendet das Attestierungsergebnis an eine vertrauende Partei.

4. Die vertrauende Partei prüft, ob das Attestierungsergebnis bestimmte Bedingungen erfüllt. Wenn das Ergebnis den Erwartungen entspricht, erlaubt die vertrauende Partei dem Attestierer den Zugriff auf die angeforderten Ressourcen.

Im Passport-Modell müssen sich Attestierer und vertrauende Partei darauf einigen, wie die Attestierungsergebnisse aussehen sollen. Das bedeutet, dass sie sich auf einen Prüfer einigen müssen.

Modell für die Zuverlässigkeitsüberprüfung

Das Modell für die Hintergrundüberprüfung verwendet den folgenden Prozess, um die Identität eines Attestierenden zu bestätigen und Zugriff auf angeforderte Ressourcen zu gewähren:

1. Der Attestierer sendet einen Nachweis seiner Identität an eine vertrauende Seite.

2. Die vertrauende Partei leitet die Nachweise an einen Prüfer weiter.

3. Wenn die Beweise als vertrauenswürdig eingestuft werden, sendet der Zertifikatsprüfer das Attestierungsergebnis an die vertrauende Partei, häufig als Attestierungstoken.

4. Die vertrauende Partei prüft, ob das Attestierungsergebnis bestimmte Bedingungen erfüllt. Wenn das Ergebnis den Erwartungen entspricht, erlaubt die vertrauende Partei dem Attestierer den Zugriff auf die angeforderten Ressourcen.

Mit dem Modell für die Zuverlässigkeitsüberprüfung bestimmt eine vertrauende Partei die erforderlichen Attestierungsnachweise und wählt den Prüfer aus.

Architektur und Beweise des Attesters

In diesem Abschnitt wird beschrieben, wie eine Confidential VM-Instanz als Attestierer manipulationssichere Nachweise ihrer Identität liefert.

Roots of Trust

In einer vertrauenswürdigen Ausführungsumgebung (Trusted Execution Environment, TEE) wie einer Confidential VM-Instanz ist ein Root of Trust eine grundlegende Sicherheitskomponente, aus der anderes Vertrauen abgeleitet wird. Ein Root of Trust bietet kryptografische Funktionen, ist manipulationssicher und kann nicht von einem Host-Betriebssystem geändert werden.

Roots of Trust gehören in eine Vertrauensgrenze innerhalb einer TEE, die als Trusted Computing Base (TCB) bezeichnet wird. Der TCB ist eine Sammlung von Hardware und Software in einer Gast-VM und ihrem Host, die für Aufgaben wie die Isolierung der Umgebung (durch Mechanismen wie Speicherverschlüsselung und Hypervisor-Isolierung) und das Ergreifen von Maßnahmen zur Aufrechterhaltung der Integrität der Umgebung verantwortlich sind.

Ein TEE unterstützt Roots of Trust für Mess-, Speicher- und Berichtsfunktionen:

• Der Root of Trust für die Messung ist der Code, der die Messungen des TEE-Boot-Vorgangs initiiert.

• Der Root of Trust für den Speicher bietet geschützten Speicher für Messungen in Form von Messregistern.

• Der Root of Trust für Berichte bietet Integritäts- und Authentizitätsschutz für die Messkette. Es werden Messungen vom Root of Trust für den Speicher abgerufen und in einem signierten Beweispaket, einem sogenannten Quote oder Attestierungsbericht, zusammengefasst. Dieses Paket ist mit einem im TEE gespeicherten Attestierungsschlüssel signiert und kann eine kryptografische Nonce enthalten, um sicherzustellen, dass die Beweise aktuell sind und vor Replay-Angriffen geschützt werden.

  Wichtiger Begriff :Bei einem Replay-Angriff kopiert ein böswilliger Akteur Beweise, die eine Identität bestätigen, und verwendet diese Beweise, um sich unrechtmäßig Zugriff auf Ressourcen zu verschaffen. Eine Möglichkeit, Replay-Angriffe zu verhindern, ist die Verwendung einer Nonce: einer einmaligen, kurzlebigen Zufallszahl, die von einer der Parteien bereitgestellt wird, die die Ressourcen schützt – im Fall von Confidential Computing vom Prüfer. Die Entität, die ihre Identität nachweist, muss die Nonce in den Nachweis einbeziehen, bevor dieser gesendet wird. Wenn ein böswilliger Akteur versucht, mit gestohlenen Beweisen auf Ressourcen zuzugreifen, schlägt dies wahrscheinlich fehl, da die in den Beweisen enthaltene Nonce bereits verwendet wurde oder abgelaufen ist.

Die folgenden Informationen beschreiben die verschiedenen Ansätze für Roots of Trust für unterschiedliche Technologien für Confidential Computing.

AMD SEV

Eine Confidential VM-Instanz mit AMD SEV bestätigt ihre Umgebung und Konfiguration mithilfe von Shielded VM vTPM-basierten Messungen. Der AMD Secure Processor und AMD SEV werden ausschließlich für die Arbeitsspeicherverschlüsselung verwendet.

Die Roots of Trust sind:

• Root of Trust für die Messung: VM-Instanz-Firmware

• Root of Trust für den Speicher: Shielded VM-vTPM

• Root of Trust für Berichte: Shielded VM-vTPM, das einen privaten Attestierungsschlüssel zum Signieren von Attestierungsberichten verwendet

Informationen dazu, welche Messungen wo im vTPM der Shielded VM aufgezeichnet werden, finden Sie unter vTPM-Plattformkonfigurationsregister.

AMD SEV-SNP

Eine Confidential VM-Instanz mit AMD SEV-SNP bezeugt ihr Umfeld und ihre Konfiguration hauptsächlich über den AMD Secure Processor, der die anfänglichen Startmessungen vornimmt.

Für Bootloader-, Kernel- und Userspace-Messungen können Shielded VM-vTPM-basierte Messungen verwendet werden.

Die Roots of Trust sind:

• Root of Trust für die Messung: AMD Secure Processor + Firmware der VM-Instanz

• Vertrauensbasis für den Speicher: AMD Secure Processor + Shielded VM-vTPM

• Root of Trust für die Berichterstellung:

  • Initial Launch Measurements: Der AMD Secure Processor, der den chipresidenten Version Chip Endorsement Key (VCEK) zum Signieren von Attestberichten verwendet

  • Bootloader-, Kernel- und Userspace-Messungen: Shielded VM-vTPM

Informationen dazu, welche Messungen im AMD Secure Processor aufgezeichnet werden, finden Sie unter AMD SEV-SNP measurement register.

Informationen dazu, welche Messungen wo im vTPM der Shielded VM aufgezeichnet werden, finden Sie unter vTPM-Plattformkonfigurationsregister.

Intel TDX

Eine Confidential VM-Instanz mit Intel TDX bestätigt ihre Umgebung und Konfiguration über das Intel TDX-Modul. Das Intel TDX-Modul misst die Firmware des VM-Gasts in einer isolierten Vertrauensdomäne und speichert diese Messungen im MRTD (Measurement of the Trust Domain). Nachfolgende Messungen in der Boot-Kette werden in den Run-Time Measurement Registers (RTMR) gemessen.

Die Roots of Trust sind:

• Root of Trust für die Messung: Intel TDX-Modul

• Root of Trust for Storage: Measurement of the Trust Domain (MRTD) und Run-Time Measurement Registers (RTMR)

• Root of Trust für die Berichterstellung: Die Trust Domain Quoting Enclave (TDQE) im Intel TDX-Modul, die einen Attestierungsschlüssel zum Signieren von Attestierungszitaten generiert.

Informationen dazu, welche Messungen wo in den TDX-Messregistern aufgezeichnet werden, finden Sie unter Intel TDX measurement registers.

Software- und Hardware-Attestierung

Confidential Computing-Technologien in Google Cloud können je nach Vertrauensanker entweder als Software oder Hardware eingestuft werden.

Software attested (Software-Attestierung) bedeutet, dass die Roots of Trust auf Software basieren: Die virtuelle Firmware ist der Root of Trust für die Messung und der Root of Trust für den Speicher ist das Shielded VM-vTPM. Das vTPM wird vom Hypervisor des Hosts verwaltet, während die Firmware von der Gast-VM verwaltet wird. Auf Google Cloudwerden beide Komponenten von Google gesteuert.

Hardware-Attestierung bedeutet, dass Messungen von dedizierter Hardware verwaltet und geschützt werden, die nicht der Kontrolle Ihres Dienstanbieters unterliegt. Auf Google Cloudenthält diese Hardware den AMD Secure Processor für AMD SEV-SNP (nur für Startmessungen) und das Intel TDX-Modul für Intel TDX.

Durch die Hardware-Attestierung wird der Hypervisor des Dienstanbieters aus dem Root of Trust für Messung und Speicherung entfernt und Messungen werden in dedizierter Hardware isoliert. Selbst wenn ein böswilliger Akteur die Kontrolle über den Hypervisor des Hosts erlangt, kann er keinen Attestierungsbericht oder kein Angebot fälschen, da er keinen Zugriff auf die Register der dedizierten Hardware hat.

Die von Google Cloud bereitgestellten Confidential Computing-Technologien sind in folgende Kategorien unterteilt:

• AMD SEV: Software wird bestätigt. Die virtuelle Firmware misst sich selbst und die Messungen werden im vTPM der Shielded VM gespeichert.

• AMD SEV-SNP: Hybrid-Hardware und ‑Software werden bestätigt. Startmessungen, einschließlich Messungen der virtuellen Firmware, werden vom AMD Secure Processor aufgezeichnet und gespeichert, wodurch sie hardwarebestätigt sind. Bootloader-, Kernel- und Userspace-Messungen werden im vTPM der Shielded VM gespeichert, sodass sie softwareattestiert sind. Sie können entweder nur die hardwarebestätigten Messungen, nur die softwarebestätigten Messungen oder beides verwenden.

• Intel TDX: Hardware wird bestätigt. Das TDX-Modul misst die virtuelle Firmware und alle Messungen werden im Intel TDX-Modul gespeichert. Das vTPM der Shielded VM ist weiterhin Teil des Systems, aber nicht Teil des TCB, sofern Sie keine Software ausführen, die eine TPM-Schnittstelle benötigt.

Messregister

Die Roots of Trust für Confidential VM bieten geschützten, manipulationssicheren Speicher für Messungen in Form von Messregistern (Measurement Registers, MRs). Die Namen dieser Messregister hängen von der verwendeten Confidential Computing-Technologie ab:

• AMD SEV: Platform Configuration Registers (PCRs). Sie befinden sich im vTPM der Shielded VM.

  Shielded VM-vTPMs verwenden drei PCR-Banks, in denen dieselben Messungen gespeichert werden, die jedoch mit unterschiedlichen Algorithmen gehasht werden: SHA-1, SHA-256 und SHA-384.

• AMD SEV-SNP: Das MEASUREMENT-Register wird gestartet. Sie befindet sich im AMD Secure Processor.

  Die PCRs im vTPM der Shielded VM werden auch zum Speichern der Bootloader-, Kernel- und Userspace-Messungen verwendet.

• Intel TDX: Die Build-Time Measurement of the Trust Domain (MRTD) und die Run-Time Measurement Registers (RTMR).

  Messungen sind auch in den Shielded VM-vTPM-PCRs für Software verfügbar, die eine TPM-Schnittstelle erwartet.

Nur ein Root of Trust kann einen Registerwert ändern. In Messregistern wird in der Regel ein einzelner kryptografischer Digest gespeichert, der entweder ein einzelnes Ereignis oder eine Reihe von Ereignissen darstellt.

Bei einzelnen Ereignissen, z. B. der Startmessung oder der Build-Time-Messung einer VM, schreibt ein Root of Trust in der Regel direkt in das Register und macht das Register für die restliche Lebensdauer des TEE unveränderlich.

Komponenten, die später in der Bootkette geladen werden, z. B. der Bootloader, der Kernel und der Userspace, können Messungen für mehrere Ereignisse in einem einzigen Register aufzeichnen. Zum Speichern der Messungen für Gruppen von Ereignissen stellen Messregister einen extend-Befehl bereit, der den vorhandenen Registerwert mit einem neuen Ereignis-Digest verkettet, den verketteten Wert hasht und dann den resultierenden Digest speichert. Dieser Vorgang wird durch die folgende Formel dargestellt:

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

Da Hash-Funktionen unidirektional sind, ist es schwierig, dieselben Werte für das Messregister zu replizieren, ohne dieselben Messungen in derselben Reihenfolge bereitzustellen. Diese Eigenschaft hilft zwar bei der Bestimmung der VM-Integrität, kann es aber erschweren, Richtlinien auf bestimmten Messregisterwerten zu basieren. Das liegt daran, dass kleine Änderungen bei den Messungseingaben, z. B. Software- oder Firmware-Updates oder eine Änderung der Messreihenfolge, zu unterschiedlichen Registerwerten führen. Daher sind sie möglicherweise keine stabilen Kriterien für Richtlinien und erhöhen den Wartungsaufwand. Wenn Sie die Richtlinie auf Messregisterwerte stützen müssen, sollten Sie stabilere Registerwerte wie PCR 0 oder PCR 7 auf vTPMs auswählen.

Tipp :Wenn Sie die Richtlinie auf stabilen Einzelmessungen anstelle von Messregisterwerten basieren möchten, können Sie ein Ereignisprotokoll verwenden, das von Ihrer TCB generiert wird. Ein Prüfer muss zuerst ein Event-Log-Replay durchführen, um die Log-Integrität anhand von Messregistern zu überprüfen. Nach erfolgreicher Überprüfung kann er die Ereignisse parsen, um aussagekräftige Messungen zu extrahieren.

Ereignisprotokolle

Wenn Messungen in Messregistern geschrieben oder erweitert werden, werden ein oder mehrere Logs in das Dateisystem des Gastbetriebssystems geschrieben, in denen die stattfindenden Messereignisse aufgezeichnet werden.

Diese Ereignisprotokolle dienen folgenden Zwecken:

• Ein Prüfer kann Ereignisprotokolle wiedergeben, um den Messvorgang der Confidential VM-Instanz mithilfe von simulierten Messregistern durchzugehen. Wenn die vom Prüfer berechneten endgültigen Digests mit den vom Attestierer gemeldeten endgültigen Digests übereinstimmen, kann dies das Vertrauen stärken, dass sowohl das Ereignisprotokoll als auch der Bootvorgang der Confidential VM-Instanz nicht manipuliert wurden.

• Nach der Wiedergabe kann ein Prüfer Ereignisprotokolle parsen, um Beweise mit Attestrichtlinien zu vergleichen. Ein Prüfer kann von einem Attestierer verlangen, dass er bestimmte Kriterien erfüllt, z. B. dass Secure Boot aktiviert ist oder dass eine bestimmte Confidential Computing-Technologie verwendet wird, bevor ein erfolgreiches Attestierungsergebnis zurückgegeben wird.

Ereignisprotokolle werden im Dateisystem des Gastbetriebssystems an den folgenden Speicherorten gespeichert:

Confidential Computing-Technologie	Zu überprüfende Merge-Anfragen	Logtyp	Gastbetriebssystempfad für die Wiedergabe des Ereignisprotokolls
AMD SEV, AMD SEV-SNP, Intel TDX	vTPM-Plattformkonfigurationsregister (PCRs)	TCG-Ereignisprotokoll (Trusted Computing Group)	/sys/kernel/security/tpm0/binary_bios_measurements
Intel TDX	RTMR[0], RTMR[1], RTMR[2]	Confidential Computing Event Log (CCEL)	/sys/firmware/acpi/tables/data/CCEL

Weitere Informationen zum Wiedergeben und Parsen von Ereignisprotokollen

Angebote und Attestberichte

Der Root of Trust für Berichte bietet Integritäts- und Authentizitätsschutz für die im Messregister gespeicherten Digests, indem die zugehörigen Messungen mit einem Attestierungsschlüssel signiert werden. Der resultierende binäre Blob wird als PCR-Quote für vTPMs, als Attestierungsbericht für AMD SEV-SNP und als Quote für Intel TDX bezeichnet.

Der Inhalt des binären Blobs variiert je nach Confidential Computing-Technologie:

• AMD SEV: Das vTPM der Shielded VM liest die Werte aus einem seiner PCR-Speicher (entweder SHA-1, SHA-256 oder SHA-384), verkettet diese Werte in numerischer Reihenfolge und hasht das Ergebnis dann mit demselben Hashing-Algorithmus wie für den PCR-Speicher, um einen Zusammenfassungs-Digest zu erstellen. Dieser Zusammenfassungs-Digest wird zusammen mit einer optionalen Nonce, die von einem Prüfer bereitgestellt wird, in eine TPMS_ATTEST-Struktur eingefügt und mit dem privaten Attestierungsschlüssel des vTPM signiert, um ein PCR-Zitat zu erstellen.

  Details zur TPMS_ATTEST-Struktur finden Sie unter Trusted Platform Module Library, Part 2: Structures (PDF).

• AMD SEV-SNP: Der AMD Secure Processor generiert einen SHA-384-Digest basierend auf den anfänglichen Startmessungen, die vor der Ausführung des UEFI der Confidential VM-Instanz durchgeführt werden.

  Dieser Digest, andere VM-Daten und eine optionale Nonce, die von einem Prüfer bereitgestellt wird, werden in eine ATTESTATION_REPORT-Struktur eingefügt, die mit dem Version Chip Endorsement Key (VCEK) des AMD Secure Processor signiert wird, um einen Attestierungsbericht zu erstellen.

  Details zur ATTESTATION_REPORT-Struktur finden Sie in der SEV Secure Nested Paging Firmware ABI Specification (PDF).

• Intel TDX: Das TDX-Modul platziert die MRTD- und RTMR-Werte, andere VM-Daten und eine optionale Nonce, die von einem Prüfer bereitgestellt wird, in einer TDREPORT_STRUCT-Struktur.

  Das Erstellen eines Angebots ist ein mehrstufiger Prozess. Zuerst leitet die Provisioning Certification Enclave in der CPU einen Provisioning Certification Key (PCK) aus kryptografischen Secrets ab, die in die CPU eingebettet sind. Anschließend generiert die Quoting Enclave in der CPU einen privaten Attestierungsschlüssel, der mit dem Bereitstellungszertifikatschlüssel signiert wird. Die TDREPORT_STRUCT wird dann mit dem privaten Attestierungsschlüssel signiert, um ein Angebot zu erstellen.

  Details zur TDREPORT_STRUCT-Struktur finden Sie in der Intel Trust Domain Extensions (Intel TDX) Module Base Architecture Specification (PDF).

Empfehlungen

Verschiedene Arten von Bestätigungen dienen als Beweis dafür, dass eine Confidential VM-Instanz auf der erwarteten Hardware, dem vTPM und der Firmwarekonfiguration ausgeführt wird.

Zertifikate

X.509 v3-Zertifikate werden als Nachweis dafür verwendet, dass auf dem Host echte AMD- oder Intel-Hardware verwendet wird oder dass die Confidential VM-Instanz ein Shielded VM-vTPM verwendet.

Der Name des Zertifikats ist für jede der Confidential Computing-Technologien unterschiedlich:

• AMD SEV: Zertifikat für den Attestierungsschlüssel (AK)

• AMD SEV-SNP: VCEK-Zertifikat (Version Chip Endorsement Key)

• Intel TDX: Bereitstellung des PCK-Zertifikats (Provisioning Certification Key)

Bei AMD SEV wird mit dem Zertifikat das vTPM der Shielded VM bestätigt. Der Host sendet eine Anfrage an den Zertifizierungsstellenserver von Google und stellt das Zertifikat automatisch im nichtflüchtigen Speicher des vTPM einer Confidential VM-Instanz bereit. Ein Gast kann dieses Zertifikat einzeln abrufen, indem er es mit Software wie go-tpm-tools vom vTPM anfordert.

Bei AMD SEV-SNP und Intel TDX extrahiert der Host Hardware-Nachweise von der CPU und präsentiert sie einem von Google verwalteten Cache. In diesem Cache werden Zertifikate gespeichert, die zuvor vom AMD-Schlüsselverteilungsdienst und vom Intel-Bereitstellungszertifikatsdienst abgerufen wurden. Nachdem die Hardware-Beweise erfolgreich präsentiert wurden, werden die Zertifikate auf der Festplatte des Hosts zwischengespeichert und für den Gast freigegeben. Ein Gast kann diese Zertifikate einzeln abrufen, um Hardware mit Software wie go-sev-guest und go-tdx-guest zu validieren.

Die Zertifikate enthalten die folgenden Informationen:

• Die Identität des Zertifikatausstellers, entweder AMD, Google oder Intel.

• Der öffentliche Attestierungsschlüssel, mit dem die Signatur für PCR-Zitate (vTPM), Attestierungsberichte (SEV-SNP) und Attestierungszitate (Intel TDX) überprüft wird.

• Nur Hardware-Attestierung: die TCB-Versionen des Hardware-Mikrocodes und der Firmware, auf denen die Firmware des Hosts ausgeführt wird.

• Nur Hardware-Attestierung: Nachweis, der das Zertifikat an einen bestimmten physischen Prozessor bindet, der mit einem privaten Schlüssel im Prozessor signiert wurde und nicht exfiltriert werden kann. Bei AMD SEV-SNP ist dieser Beweis die Plattform-ID. Für Intel TDX ist der Beweis das Plattformmanifest.

Firmware

Für die Hardware-Attestierung sind Startbestätigungen für die Firmware direkt von VM-Instanzen verfügbar oder können online heruntergeladen werden. Startbestätigungen sind signierte binär serialisierte Protokollpuffer, mit denen bestätigt wird, dass die virtuelle Firmware einer Confidential VM-Instanz nicht manipuliert wurde.

Wenn eine VM gestartet wird, wird das Firmware-Binärprogramm vom AMD Secure Processor oder Intel TDX-Modul gehasht, bevor es ausgeführt wird. Dieser SHA-384-Digest wird für AMD SEV-SNP im Feld MEASUREMENT und für Intel TDX im MRTD gespeichert.

Mit diesem Digest können Sie eine Startbestätigung von Google herunterladen, mit einem Tool wie gcetcbendorsement überprüfen, ob die Signatur auf Google zurückzuführen ist, und dann prüfen, ob die SHA‑384-Digests zwischen der Firmware-Messung und den in der Bestätigung aufgezeichneten Daten übereinstimmen.

Neben der Firmware-Überprüfung können Sie bestimmte Eigenschaften in einer Launch-Bestätigung verwenden, um eine Zugriffsrichtlinie zu erzwingen, z. B. die minimale Sicherheitsversionsnummer (Security Version Number, SVN), die Anzahl der virtuellen CPUs, die Arbeitsspeicherkonfiguration oder die Familien-ID des UEFI.

Weitere Informationen finden Sie unter Firmware einer Confidential VM-Instanz prüfen.

Wiedergabe und Parsing des Ereignisprotokolls des Prüfers

Zusätzlich zur direkten Überprüfung der vom Attestierer bereitgestellten Beweise kann ein Prüfer ein vom Attestierer bereitgestelltes Ereignisprotokoll wiedergeben, um seine Integrität anhand der Werte des Messregisters zu überprüfen.

Dazu erstellt der Prüfer eine simulierte Version jedes Messregisters, das er im Rahmen seiner Attestrichtlinie prüfen muss. Anschließend wird das simulierte Register mit Ereignissen aus einem Ereignisprotokoll gefüllt. Wenn der endgültige Wert des simulierten Registers mit dem Wert übereinstimmt, der im entsprechenden realen Messregister gespeichert ist, erhöht dies das Vertrauen, dass sowohl das Ereignisprotokoll als auch der Bootvorgang der Confidential VM-Instanz nicht manipuliert wurden.

Nachdem ein Log auf diese Weise überprüft wurde, kann es nach einzelnen Messungen durchsucht werden, auf denen ein Prüfer oder eine vertrauende Partei eine Richtlinie basieren kann.

Eigene Tools zum Wiedergeben und Parsen von Ereignisprotokollen erstellen

Sie können zwar Ihre eigene Software zum Wiedergeben und Parsen von Ereignisprotokollen erstellen, wir empfehlen jedoch, etablierte Software wie go-eventlog zu verwenden, um häufige Fehler wie die EventType-Sicherheitslücke für die Ereignisprotokollformate von Trusted Computing Group und Confidential Computing zu vermeiden.

Wenn Sie Ihre eigene Software zum Wiedergeben und Parsen erstellen möchten, können Ihnen die folgenden vTPM-basierten Beispiele helfen, die Grundlagen zu verstehen. Sie sollten Ihre Implementierung jedoch auf dem Ereignisprotokoll Ihrer eigenen Confidential VM-Instanz basieren.

Das folgende Beispiel enthält ausgewählte Ereignisse aus einem vTPM-Ereignislog von Ubuntu 24.04, die in PCR 0 gemessen werden. Das Ereignisprotokoll wurde mit tpm2_eventlog mit dem folgenden Befehl von binär in ASCII konvertiert:

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

Die PCR 0-Ereignisse aus dem Log sind die folgenden:

---
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"

Wenn die Confidential VM-Instanz zurückgesetzt wird, werden ihre PCRs auf null initialisiert. Bei Ereignissen ändert sich der Wert in der SHA-256-Bank von PCR 0 (PCRIndex: 0) wie folgt (EV_NO_ACTION-Ereignisse erweitern das Register nicht):

1. Der Wert des Registers wird mit dem SHA-256-Digest des nächsten Ereignisses verkettet, das PCR 0 zugewiesen ist, EV_S_CRTM_VERSION. Das verkettete Ergebnis wird noch einmal mit SHA-256 gehasht und dann im Register gespeichert. Der SHA-256-Hexdigest von PCR 0 ist jetzt 0c3684a7571193d76a68e489ded7bf186fc2fb1efe0c6dd9ce147960bbc57365.

2. Für das Ereignis EV_NONHOST_INFO wird derselbe Prozess verwendet. Der SHA-256-Hexdigest von PCR 0 ist jetzt 509f590b71fb22c9a6eef647e3c23611d13e599a6e15fdbb4db56ea4c2cb878d.

3. Derselbe Prozess wird für ein EV_SEPARATOR-Ereignis verwendet, das angibt, dass die Erweiterungen für die Messung in einem bestimmten Register abgeschlossen sind. Der EV_SEPARATOR ist ein 32-Bit-Nullwert (\x00*4). Dadurch ergibt sich für den endgültigen SHA-256-Hexdigest von PCR 0 der Wert a0b5ff3383a1116bd7dc6df177c0c2d433b9ee1813ea958fa5d166a202cb2a85.

Der folgende Python-Code demonstriert das vorherige Verfahren, indem ein simulierter Compute Engine-PCR 0 erstellt wird. Der Code ist keine Wiedergabe des Ereignisprotokolls, da die Ereigniszusammenfassungen aus bekannten Werten abgeleitet werden. Wenn Sie eine korrekte Wiedergabe des Ereignislogs erstellen, müssen Sie die Digests stattdessen aus dem Ereignislog Ihrer VM-Instanz lesen.

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()

Konfiguration der vertrauenden Partei

Je nachdem, ob das Passport-Modell oder das Modell für die Hintergrundüberprüfung verwendet wird, erhält die vertrauende Partei die Attestierungsergebnisse entweder vom Attestierer oder vom Prüfer.

Die vertrauende Partei prüft dann, ob die Ansprüche, die sie in den Attestierungsergebnissen erhalten hat, mit den erwarteten Werten übereinstimmen. Wenn die Werte übereinstimmen, erlaubt die vertrauende Partei dem Attestierenden, als lokale Identität auf Ressourcen zuzugreifen.

Ein gängiges Muster zum Konfigurieren einer vertrauenden Seite in Google Cloud ist die Verwendung der Workload Identity-Föderation, wobei der Attester als föderierte Identität behandelt wird:

1. Fügen Sie Ihren Prüfer als OIDC-Anbieter zu einem Workload Identity-Pool hinzu. Danach kann das Dienstkonto, das an Ihre Confidential VM-Instanz-Arbeitslast angehängt ist, als föderierte Identität fungieren und auf die erforderlichen Ressourcen zugreifen.

2. Definieren Sie die Werte, die die Behauptungen der Attestierung des Prüfers erfüllen müssen, damit dem Attestierer Zugriff auf Ressourcen gewährt wird.

   In Google Cloudmüssen Sie dazu Bestätigungsansprüche Attributen zuordnen, damit IAM sie als Bedingungen verarbeiten kann, die eine föderierte Identität erfüllen muss, um sich als Prinzipal zu authentifizieren.

   Anschließend können Sie dem Attestierer direkten Zugriff auf Ressourcen gewähren, indem Sie eine Rollenbindung für sein föderiertes Hauptkonto zu den Zulassungsrichtlinien der erforderlichen Ressourcen hinzufügen. Für Dienste, die keine föderierten Identitäten unterstützen, können Sie den Zugriff auf Ressourcen über die Identitätsübernahme des Dienstkontos gewähren.

Als Alternative zur Workload Identity-Föderation können Sie Code schreiben, um die Ansprüche eines Attestierungstokens direkt zu parsen. Ein Beispiel finden Sie unter vTPM-Remote-Attestierung auf einer vertraulichen virtuellen Maschine.