Présentation de l'attestation à distance

L'attestation à distance est le processus de vérification de l'identité légitime d'une instance Confidential VM et de son fonctionnement dans un état attendu. L'attestation peut vous aider à évaluer la fiabilité d'un système avant de lui donner accès à vos ressources protégées.

Parties et modèles d'attestation

Le processus d'attestation implique généralement trois parties :

• Un certificateur. Sur Google Cloud, il s'agit d'une charge de travail sur une instance Confidential VM qui nécessite d'accéder à des ressources protégées. Pour renforcer la confiance dans le fait que l'instance de VM confidentielle n'a pas été compromise et n'est pas une imposture, la VM et son hôte mesurent l'état du matériel et des logiciels virtuels de la VM pendant le processus de démarrage.

• Un validateur Un vérificateur est un système externe qui valide les preuves d'une instance Confidential VM et les compare à sa stratégie d'attestation pour s'assurer que la configuration de la VM est conforme aux attentes. Si la preuve réussit les vérifications requises, l'outil de vérification renvoie une version signée de la preuve, appelée résultat d'attestation.

  Un vérificateur peut être un service préexistant tel que Google Cloud Attestation ou Intel Trust Authority, ou un service que vous avez créé vous-même.

• Une partie de confiance La partie de confiance contrôle l'accès aux ressources protégées dont l'attesteur a besoin. Lorsqu'elle reçoit un résultat d'attestation, la partie de confiance vérifie les valeurs dans les preuves par rapport à sa règle d'accès. Si les valeurs correspondent, l'attesteur est autorisé à accéder aux ressources.

  Dans Google Cloud la partie de confiance est souvent un pool d'identités de charge de travail, avec le vérificateur ajouté en tant que fournisseur OpenID Connect (OIDC).

La façon dont les parties interagissent dépend du modèle d'attestation suivi par votre architecture. La RFC sur l'architecture des procédures de test à distance (RATS) définit deux principaux modèles d'attestation : le modèle de passeport et le modèle de vérification des antécédents. La principale différence entre les deux réside dans la partie qui possède l'identité validée de l'attestateur : l'attestateur ou la partie de confiance.

Modèle de passeport

Le modèle Passport utilise le processus suivant pour confirmer l'identité d'un certificateur et accorder l'accès aux ressources demandées :

1. L'attestateur envoie une preuve de son identité à un vérificateur.

2. Si la preuve est jugée fiable, le vérificateur envoie à l'attestateur le résultat de l'attestation, qui peut prendre la forme d'un jeton d'attestation.

3. L'attestateur envoie le résultat de l'attestation à une partie de confiance.

4. La partie de confiance vérifie que le résultat de l'attestation répond à certaines conditions. Si le résultat répond aux attentes, la partie de confiance autorise l'attesteur à accéder aux ressources demandées.

Dans le modèle de passeport, l'attestateur et la partie de confiance doivent s'accorder sur l'apparence des résultats de l'attestation, ce qui signifie qu'ils doivent s'accorder sur un vérificateur.

Modèle de vérification des antécédents

Le modèle de vérification des antécédents suit le processus suivant pour confirmer l'identité d'un attestateur et lui accorder l'accès aux ressources demandées :

1. L'attestateur envoie une preuve de son identité à une partie de confiance.

2. La partie de confiance transmet les preuves à un vérificateur.

3. Si la preuve est jugée fiable, le vérificateur envoie le résultat de l'attestation à la partie de confiance, souvent sous la forme d'un jeton d'attestation.

4. La partie de confiance vérifie que le résultat de l'attestation répond à certaines conditions. Si le résultat répond aux attentes, la partie de confiance autorise l'attesteur à accéder aux ressources demandées.

Avec le modèle de vérification des antécédents, une partie de confiance détermine les preuves d'attestation dont elle a besoin et choisit le vérificateur.

Architecture et preuves de l'attestation

Cette section explique comment une instance Confidential VM en tant qu'attesteur fournit des preuves inviolables de son identité.

Racines de confiance

Dans un environnement d'exécution sécurisé (TEE), tel qu'une instance Confidential VM, une racine de confiance est un composant de sécurité fondamental à partir duquel d'autres éléments de confiance sont établis. Une racine de confiance fournit des fonctions cryptographiques, est inviolable et ne peut pas être modifiée par un système d'exploitation hôte.

Les racines de confiance appartiennent à une limite de confiance dans un TEE appelé Trusted Computing Base (TCB). La TCB est un ensemble de composants matériels et logiciels d'une VM invitée et de son hôte, qui sont responsables de tâches telles que l'isolation de l'environnement (par le biais de mécanismes tels que le chiffrement de la mémoire et l'isolation de l'hyperviseur) et la prise de mesures pour maintenir l'intégrité de l'environnement.

Un TEE est compatible avec les racines de confiance pour les fonctions de mesure, de stockage et de reporting :

• La racine de confiance pour la mesure est le code qui lance les mesures du processus de démarrage du TEE.

• La racine de confiance pour le stockage fournit une mémoire protégée pour les mesures sous la forme de registres de mesure.

• La racine de confiance pour les rapports assure l'intégrité et l'authenticité de la chaîne de mesure. Il récupère les mesures à partir de la racine de confiance pour le stockage et les regroupe dans un package de preuves signé appelé "devis" ou "rapport d'attestation". Ce package est signé avec une clé d'attestation résidant dans le TEE et peut inclure un nonce cryptographique pour garantir que la preuve est récente et protégée contre les attaques par relecture.

  Terme clé : Une attaque par relecture se produit lorsqu'un acteur malveillant copie des éléments prouvant une identité et les utilise pour accéder illégitimement à des ressources. Une façon de lutter contre les attaques par rejeu consiste à utiliser un nonce : un nombre aléatoire, éphémère et à usage unique fourni par l'une des parties protégeant les ressources (dans le cas du informatique confidentielle, le vérificateur). L'entité prouvant son identité doit intégrer le nonce à sa preuve avant que celle-ci ne soit envoyée. Si une personne malveillante tente d'utiliser des preuves volées pour accéder à des ressources, elle échouera probablement, car le nonce inclus dans les preuves a déjà été utilisé ou a expiré.

Les informations suivantes détaillent les différentes approches des racines de confiance pour les différentes technologies de informatique confidentielle.

AMD SEV

Une instance Confidential VM avec AMD SEV atteste de son environnement et de sa configuration à l'aide de mesures basées sur la vTPM de VM protégée. Le processeur AMD Secure Processor et AMD SEV sont utilisés uniquement pour le chiffrement de la mémoire.

Les racines de confiance sont les suivantes :

• Racine de confiance pour la mesure : micrologiciel de l'instance de VM

• Racine de confiance pour le stockage : vTPM de la VM protégée

• Racine de confiance pour les rapports : vTPM de VM protégée, qui utilise une clé d'attestation privée pour signer les rapports d'attestation

Pour savoir quelles mesures sont enregistrées et où dans le vTPM de la VM protégée, consultez Registres de configuration de la plate-forme vTPM.

AMD SEV-SNP

Une instance Confidential VM avec AMD SEV-SNP atteste principalement de son environnement et de sa configuration via le processeur AMD Secure, qui gère les mesures de lancement initiales.

Pour les mesures du bootloader, du noyau et de l'espace utilisateur, vous pouvez utiliser des mesures basées sur le vTPM des VM protégées.

Les racines de confiance sont les suivantes :

• Racine de confiance pour la mesure : processeur AMD sécurisé + micrologiciel de l'instance de VM

• Racine de confiance pour le stockage : processeur AMD sécurisé + vTPM de la Shielded VM

• Racine de confiance pour les rapports :

  • Mesures de lancement initial : le processeur AMD Secure, qui utilise la clé VCEK (Version Chip Endorsement Key) résidant dans le chip pour signer les rapports d'attestation

  • Mesures du bootloader, du noyau et de l'espace utilisateur : vTPM des VM protégées

Pour savoir quelles mesures sont enregistrées dans le processeur sécurisé AMD, consultez Registre de mesures AMD SEV-SNP.

Pour savoir quelles mesures sont enregistrées et où dans le vTPM de la VM protégée, consultez Registres de configuration de la plate-forme vTPM.

Intel TDX

Une instance Confidential VM avec Intel TDX atteste de son environnement et de sa configuration via le module Intel TDX. Le module Intel TDX mesure le micrologiciel de l'invité de la VM dans un domaine de confiance isolé et stocke ces mesures dans le MRTD (Measurement of the Trust Domain). Les mesures suivantes de la chaîne de démarrage sont mesurées dans les registres de mesure d'exécution (RTMR).

Les racines de confiance sont les suivantes :

• Racine de confiance pour la mesure : module Intel TDX

• Racine de confiance pour le stockage : mesure du domaine de confiance (MRTD) et registres de mesure d'exécution (RTMR)

• Racine de confiance pour les rapports : enclave de citation du domaine de confiance (TDQE, Trust Domain Quoting Enclave) à l'intérieur du module Intel TDX, qui génère une clé d'attestation pour signer les citations d'attestation

Pour savoir quelles mesures sont enregistrées où dans les registres de mesure TDX, consultez Registres de mesure Intel TDX.

Attestation logicielle et matérielle

Les technologies d'informatique confidentielle dans Google Cloud peuvent être considérées comme des logiciels ou du matériel attestés, en fonction de leurs racines de confiance.

Logiciel attesté signifie que les racines de confiance sont basées sur un logiciel : le micrologiciel virtuel est la racine de confiance pour la mesure, et la racine de confiance pour le stockage est le vTPM de la VM protégée. Le vTPM est géré par l'hyperviseur de l'hôte, tandis que le micrologiciel est géré par la VM invitée. Sur Google Cloud, ces deux composants sont contrôlés par Google.

Attestation matérielle signifie que les mesures sont gérées et protégées par du matériel dédié qui ne dépend pas de votre fournisseur de services. Sur Google Cloud, ce matériel inclut le processeur AMD Secure pour AMD SEV-SNP (pour les mesures de lancement uniquement) et le module Intel TDX pour Intel TDX.

L'attestation matérielle supprime l'hyperviseur du fournisseur de services de la racine de confiance pour la mesure et le stockage, et isole les mesures dans du matériel dédié. Même si un acteur malveillant prend le contrôle de l'hyperviseur de l'hôte, il ne peut pas falsifier de rapport ni de citation d'attestation, car il n'a pas accès aux registres du matériel dédié pour les modifier.

Les technologies d'informatique confidentielle fournies par Google Cloud sont classées comme suit :

• AMD SEV : logiciel attesté. Le micrologiciel virtuel se mesure lui-même, et les mesures sont stockées dans le vTPM de la VM protégée.

• AMD SEV-SNP : attestation hybride matérielle et logicielle. Les mesures de lancement, y compris celles du micrologiciel virtuel, sont enregistrées et stockées dans le processeur AMD Secure Processor, ce qui les rend attestées par le matériel. Les mesures du bootloader, du noyau et de l'espace utilisateur sont stockées dans le vTPM de la VM protégée, ce qui les rend attestées par logiciel. Vous pouvez choisir d'utiliser uniquement les mesures attestées par le matériel, celles attestées par le logiciel ou les deux.

• Intel TDX : attestation matérielle. Le module TDX mesure le micrologiciel virtuel, et toutes les mesures sont stockées dans le module Intel TDX. Le vTPM de la VM protégée fait toujours partie du système, mais pas de la TCB, sauf si vous exécutez un logiciel qui nécessite une interface TPM.

Registres de mesure

Les racines de confiance pour les Confidential VM fournissent un stockage protégé et inviolable pour les mesures sous la forme de registres de mesures (MR). Le nom de ces registres de mesure varie en fonction de la technologie de informatique confidentielle utilisée :

• AMD SEV : registres de configuration de plate-forme (PCR). Elles se trouvent à l'intérieur du vTPM de la VM protégée.

  Les vTPM des VM protégées utilisent trois banques de PCR qui stockent les mêmes mesures, mais qui sont hachées avec des algorithmes différents : SHA-1, SHA-256 et SHA-384.

• AMD SEV-SNP : le lancement MEASUREMENT est enregistré. Il se trouve à l'intérieur du processeur sécurisé AMD.

  Les PCR du module vTPM de la VM protégée sont également utilisées pour stocker les mesures du chargeur de démarrage, du noyau et de l'espace utilisateur.

• Intel TDX : mesure au moment de la compilation du domaine de confiance (MRTD) et registres de mesure au moment de l'exécution (RTMR).

  Des mesures sont également disponibles dans les PCR vTPM des VM protégées pour les logiciels qui attendent une interface TPM.

Seule une racine de confiance peut modifier une valeur de registre. Les registres de mesure contiennent généralement un seul condensé cryptographique, qui représente un seul événement ou un ensemble d'événements.

Pour les événements uniques, tels que la mesure du lancement ou du temps de compilation d'une VM, une racine de confiance écrit généralement directement dans le registre et le rend immuable pour le reste de la durée de vie de l'environnement d'exécution sécurisé.

Les composants chargés plus tard dans la chaîne de démarrage, tels que le bootloader, le noyau et l'espace utilisateur, peuvent enregistrer des mesures pour plusieurs événements dans un seul registre. Pour stocker les mesures pour des ensembles d'événements, les registres de mesure exposent une commande extend qui concatène la valeur de registre existante avec un nouveau résumé d'événement, hache la valeur concaténée, puis stocke le résumé obtenu. Ce processus est représenté par la formule suivante :

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

Comme les fonctions de hachage sont unidirectionnelles, il est difficile de reproduire les mêmes valeurs de registre de mesure sans fournir les mêmes mesures dans le même ordre. Bien que cette propriété permette de déterminer l'intégrité des VM, elle peut rendre difficile la création de stratégies basées sur des valeurs de registre de mesure spécifiques. En effet, de petites modifications des entrées de mesure (comme des mises à jour logicielles ou du micrologiciel, ou un changement dans l'ordre des mesures) entraînent des valeurs de registre différentes, ce qui en fait des critères potentiellement instables sur lesquels baser des règles et augmente la charge de maintenance. Si vous devez baser la règle sur les valeurs du registre de mesure, essayez de sélectionner des valeurs de registre plus stables, telles que PCR 0 ou PCR 7 sur les vTPM.

Conseil : Pour baser la règle sur des mesures individuelles stables au lieu de valeurs d'enregistrement de mesure, vous pouvez utiliser un journal des événements généré par votre TCB. Un vérificateur doit d'abord effectuer une relecture du journal des événements pour vérifier l'intégrité du journal par rapport aux registres de mesure. Une fois la vérification réussie, il peut analyser les événements pour extraire des mesures pertinentes.

Journaux des événements

À mesure que les mesures sont écrites ou étendues dans les registres de mesures, un ou plusieurs journaux sont écrits dans le système de fichiers du système d'exploitation invité, qui enregistrent les événements de mesure qui ont lieu.

Ces journaux d'événements servent aux fins suivantes :

• Un vérificateur peut rejouer les journaux d'événements pour parcourir le processus de mesure de l'instance de Confidential VM à l'aide de registres de mesure simulés. Si les résumés finaux calculés par le vérificateur correspondent à ceux signalés par l'attesteur, cela peut renforcer la confiance dans le fait que le journal des événements et le processus de démarrage de l'instance Confidential VM n'ont pas été falsifiés.

• Après la relecture, un vérificateur peut analyser les journaux d'événements pour comparer les preuves aux règles d'attestation. Un vérificateur peut exiger qu'un certificateur réponde à certains critères, comme l'activation du démarrage sécurisé ou l'utilisation d'une technologie de informatique confidentielle spécifique, avant qu'un résultat d'attestation positif ne soit renvoyé.

Les journaux d'événements sont stockés dans le système de fichiers du système d'exploitation invité aux emplacements suivants :

Technologie d'informatique confidentielle	Demandes de fusion à vérifier	Type de journal	Chemin d'accès de l'OS invité pour la relecture du journal des événements
AMD SEV, AMD SEV-SNP, Intel TDX	Registres de configuration de plate-forme (PCR) vTPM	Journal des événements Trusted Computing Group (TCG)	/sys/kernel/security/tpm0/binary_bios_measurements
Intel TDX	RTMR[0], RTMR[1], RTMR[2]	Journal des événements d'informatique confidentielle (CCEL, Confidential Computing Event Log)	/sys/firmware/acpi/tables/data/CCEL

En savoir plus sur la relecture et l'analyse des journaux d'événements

Rapports de citation et d'attestation

La racine de confiance pour les rapports assure l'intégrité et l'authenticité des digests stockés dans le registre des mesures en signant leurs mesures avec une clé d'attestation. Le blob binaire obtenu est appelé citation PCR pour les vTPM, rapport d'attestation pour AMD SEV-SNP et citation pour Intel TDX.

Le contenu du blob binaire diffère selon les technologies d'informatique confidentielle :

• AMD SEV : le vTPM de la VM blindée lit les valeurs de l'une de ses banques PCR (SHA-1, SHA-256 ou SHA-384), les concatène dans l'ordre numérique, puis hache le résultat avec le même algorithme de hachage que celui utilisé pour la banque PCR afin de créer un condensé récapitulatif. Ce condensé récapitulatif, ainsi qu'un nonce facultatif fourni par un vérificateur, sont placés dans une structure TPMS_ATTEST et signés par la clé d'attestation privée du vTPM pour créer une citation PCR.

  Pour en savoir plus sur la structure TPMS_ATTEST, consultez Trusted Platform Module Library, Part 2: Structures (PDF).

• AMD SEV-SNP : le processeur AMD Secure génère un résumé SHA-384 basé sur ses mesures de lancement initiales prises avant l'exécution de l'UEFI de l'instance Confidential VM.

  Ce résumé, d'autres données de VM et un nonce facultatif fourni par un vérificateur sont placés dans une structure ATTESTATION_REPORT signée par la clé d'approbation de la puce de version (VCEK) du processeur sécurisé AMD pour créer un rapport d'attestation.

  Pour en savoir plus sur la structure ATTESTATION_REPORT, consultez SEV Secure Nested Paging Firmware ABI Specification (PDF).

• Intel TDX : le module TDX place les valeurs MRTD et RTMR, d'autres données de VM et un nonce facultatif fourni par un vérificateur dans une structure TDREPORT_STRUCT.

  La création d'un devis est un processus en plusieurs étapes. Tout d'abord, l'enclave de certification de provisionnement à l'intérieur du processeur dérive une clé de certification de provisionnement (PCK) à partir de secrets cryptographiques fusionnés dans le processeur. L'enclave de citation à l'intérieur du processeur génère ensuite une clé d'attestation privée, qui est signée avec la clé de certification de provisionnement. Le TDREPORT_STRUCT est ensuite signé avec la clé d'attestation privée pour créer un devis.

  Pour en savoir plus sur la structure TDREPORT_STRUCT, consultez la spécification de l'architecture de base du module Intel Trust Domain Extensions (Intel TDX) (PDF).

Recommandations

Différents types d'approbations sont utilisés comme preuve qu'une instance Confidential VM s'exécute sur les configurations matérielles, vTPM et de micrologiciel attendues.

Certificats

Les certificats X.509 v3 sont utilisés comme preuve de l'utilisation de matériel AMD ou Intel authentique dans l'hôte, ou que l'instance Confidential VM utilise un module vTPM de VM protégée.

Le nom du certificat est différent pour chacune des technologies de informatique confidentielle :

• AMD SEV : certificat de clé d'attestation (AK)

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

• Intel TDX : certificat PCK (Provisioning Certification Key)

Pour AMD SEV, le certificat valide le vTPM de la VM protégée. L'hôte envoie une requête au serveur de l'autorité de certification de Google et provisionne automatiquement le certificat directement dans le stockage non volatile du vTPM d'une instance de VM confidentielle. Un invité peut récupérer ce certificat individuellement en le demandant au vTPM avec un logiciel tel que go-tpm-tools.

Pour AMD SEV-SNP et Intel TDX, l'hôte extrait les preuves matérielles du processeur et les présente à un cache géré par Google. Ce cache stocke les certificats précédemment extraits du service de distribution de clés AMD et du service de provisionnement de certificats Intel. Une fois les preuves matérielles présentées, les certificats sont mis en cache sur le disque de l'hôte et partagés avec l'invité. Un invité peut récupérer ces certificats individuellement pour valider le matériel avec des logiciels tels que go-sev-guest et go-tdx-guest.

Les certificats contiennent les informations suivantes :

• Identité de l'émetteur du certificat (AMD, Google ou Intel).

• Clé d'attestation publique, qui valide la signature des citations PCR (vTPM), des rapports d'attestation (SEV-SNP) et des citations d'attestation (Intel TDX).

• Attestation matérielle uniquement : versions TCB du microcode et du micrologiciel matériels sur lesquels le micrologiciel de l'hôte s'exécute.

• Attestation matérielle uniquement : preuve qui lie le certificat à un processeur physique spécifique, qui a été signé avec une clé privée dans le processeur et ne peut pas être exfiltré. Pour AMD SEV-SNP, cette preuve est l'ID de la plate-forme. Pour Intel TDX, la preuve est le manifeste de la plate-forme.

Micrologiciel

Pour l'attestation matérielle, les approbations de lancement du micrologiciel sont disponibles directement à partir des instances de VM ou peuvent être téléchargées en ligne. Les approbations de lancement sont des protocol buffers sérialisés au format binaire et signés. Elles permettent de confirmer que le micrologiciel virtuel d'une instance de VM confidentielle n'a pas été altéré.

Lorsqu'une VM démarre, le module AMD Secure Processor ou Intel TDX hache le binaire du micrologiciel avant son exécution. Ce condensé SHA-384 est stocké dans le champ MEASUREMENT pour AMD SEV-SNP et dans le MRTD pour Intel TDX.

Vous pouvez utiliser ce résumé pour télécharger une attestation de lancement de Google, vérifier que la signature est ancrée à Google avec un outil tel que gcetcbendorsement, puis vérifier que les résumés SHA-384 correspondent entre la mesure du micrologiciel et ce qui est enregistré dans l'attestation.

Au-delà de la validation du micrologiciel, vous pouvez utiliser certaines propriétés d'une approbation de lancement pour appliquer une règle d'accès, comme le numéro de version de sécurité (SVN) minimal, le nombre de processeurs virtuels, la configuration de la mémoire ou l'ID de famille de l'UEFI.

Pour en savoir plus, consultez Vérifier le micrologiciel d'une instance Confidential VM.

Relecture et analyse des journaux d'événements du vérificateur

En plus de vérifier directement les preuves fournies par un attestateur, un vérificateur peut rejouer un journal d'événements fourni par l'attestateur pour vérifier son intégrité par rapport à ses valeurs de registre de mesure.

Pour ce faire, le vérificateur crée une version simulée de chaque registre de mesures qu'il doit vérifier dans le cadre de sa règle d'attestation. Il remplit ensuite ce registre simulé à l'aide des événements d'un journal d'événements. Si la valeur finale du registre simulé correspond à la valeur stockée dans le registre de mesure réel équivalent, cela renforce la confiance dans le fait que le journal des événements et le processus de démarrage de l'instance Confidential VM n'ont pas été falsifiés.

Une fois qu'un journal a été validé de cette manière, il peut être analysé pour obtenir des mesures individuelles sur lesquelles un validateur ou une partie de confiance peut baser une règle.

Créer vos propres outils d'analyse et de relecture des journaux d'événements

Bien que vous puissiez créer votre propre logiciel pour relire et analyser les journaux d'événements, nous vous recommandons d'utiliser un logiciel établi tel que go-eventlog pour éviter les pièges courants tels que la faille EventType pour les formats Trusted Computing Group et Confidential Computing Event Log.

Si vous souhaitez toujours créer votre propre logiciel de relecture et d'analyse, les exemples suivants basés sur le vTPM peuvent vous aider à comprendre les bases. Toutefois, vous devez baser votre implémentation sur le journal des événements généré par votre propre instance Confidential VM.

L'exemple suivant présente une sélection d'événements d'un journal d'événements vTPM Ubuntu 24.04, qui sont mesurés dans le PCR 0. Le journal des événements a été converti du format binaire au format ASCII avec tpm2_eventlog à l'aide de la commande suivante :

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

Les événements PCR 0 du journal sont les suivants :

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

Lorsque l'instance Confidential VM est réinitialisée, ses PCR sont initialisés à zéro. Lorsque des événements se produisent, la valeur dans la banque SHA-256 du PCR 0 (PCRIndex: 0) change comme suit (les événements EV_NO_ACTION n'étendent pas le registre) :

1. La valeur du registre est concaténée avec le condensé SHA-256 de l'événement suivant attribué au PCR 0, EV_S_CRTM_VERSION. Le résultat concaténé est à nouveau haché avec SHA-256, puis stocké dans le registre. Le hexdigest SHA-256 du PCR 0 est désormais 0c3684a7571193d76a68e489ded7bf186fc2fb1efe0c6dd9ce147960bbc57365.

2. Le même processus est utilisé pour l'événement EV_NONHOST_INFO. Le hexdigest SHA-256 du PCR 0 est désormais 509f590b71fb22c9a6eef647e3c23611d13e599a6e15fdbb4db56ea4c2cb878d.

3. Le même processus est utilisé pour un événement EV_SEPARATOR, qui indique que les extensions de mesure dans un registre spécifique sont terminées. EV_SEPARATOR est une valeur zéro de 32 bits (\x00*4). Cela donne le hexdigest SHA-256 final de PCR 0 : a0b5ff3383a1116bd7dc6df177c0c2d433b9ee1813ea958fa5d166a202cb2a85.

Le code Python suivant illustre la procédure précédente en créant un PCR 0 Compute Engine simulé. Le code n'est pas une rediffusion du journal des événements, car il dérive ses résumés d'événements de valeurs connues. Lorsque vous créez une relecture de journal d'événements appropriée, vous devez lire les résumés à partir du journal d'événements de votre instance de 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()

Configuration du tiers de confiance

Selon que le modèle de passeport ou le modèle de vérification des antécédents est utilisé, la partie de confiance reçoit les résultats de l'attestation de l'attestateur ou du vérificateur.

La partie de confiance vérifie ensuite que les revendications qu'elle a reçues dans les résultats de l'attestation correspondent aux valeurs attendues. Si les valeurs correspondent, la partie de confiance autorise l'attesteur à accéder aux ressources en tant qu'identité locale.

Une méthode courante pour configurer une partie de confiance dans Google Cloud consiste à utiliser la fédération d'identité de charge de travail et à traiter l'attesteur comme une identité fédérée :

1. Ajoutez votre vérificateur en tant que fournisseur OIDC à un pool d'identités de charge de travail. Après cela, le compte de service associé à la charge de travail de votre instance de VM confidentielle peut agir en tant qu'identité fédérée et accéder aux ressources requises.

2. Définissez les valeurs auxquelles les revendications de l'attestation du validateur doivent correspondre pour que l'attestateur puisse accéder aux ressources.

   Dans Google Cloud, cela implique de mapper les revendications d'attestation aux attributs afin que Identity and Access Management (IAM) puisse les traiter comme des conditions qu'une identité fédérée doit remplir pour s'authentifier en tant que compte principal.

   Vous pouvez ensuite accorder à l'attesteur un accès direct aux ressources en ajoutant une liaison de rôle pour son compte principal fédéré aux stratégies d'autorisation des ressources nécessaires. Pour les services qui ne sont pas compatibles avec les identités fédérées, vous pouvez fournir un accès aux ressources via l'usurpation d'identité d'un compte de service.

Au lieu d'utiliser la fédération d'identité de charge de travail, vous pouvez écrire du code pour analyser directement les revendications d'un jeton d'attestation. Pour obtenir un exemple, consultez Attestation à distance vTPM sur une machine virtuelle confidentielle.