Attestation et provenance des CVM TDX

1. Présentation

Les Confidential Virtual Machines (CVM) sont un type de machines virtuelles Compute Engine qui utilisent le chiffrement de la mémoire et la protection de l'intégrité basés sur le matériel. Cela permet de s'assurer que vos données et applications ne peuvent pas être lues ni modifiées en mémoire pendant leur utilisation. Dans cet atelier de programmation, vous apprendrez à générer un devis d'attestation Intel TDX sur la CVM et à le vérifier localement à des fins de démonstration. Vous validerez également l'hôte Google Cloud et la provenance de l'instance de la CVM.

Cet atelier de programmation comprend les étapes suivantes :

  • Configurer une Confidential VM Intel TDX
  • Récupérer un devis d'attestation TDX
  • Valider le devis d'attestation TDX et le nonce
  • Valider l'intégrité du micrologiciel GCE (OVMF)
  • Valider l'hôte GCE TDX et la provenance de l'instance

Points abordés

  • Récupérer un devis d'attestation TDX sur une CVM à l'aide des outils go-tdx-guest
  • Valider l'authenticité, la fraîcheur (nonce) et l'intégrité du micrologiciel GCE (OVMF) du devis
  • Valider l'hôte Google Cloud et la provenance de l'instance (recherche dans le registre PPID et liaison de l'instance PZID)

Ce dont vous avez besoin

2. Préparation

Pour activer les API nécessaires, exécutez la commande suivante dans la console Google Cloud ou dans votre environnement de développement local :

gcloud auth login

gcloud services enable \
    cloudapis.googleapis.com \
    cloudshell.googleapis.com \
    confidentialcomputing.googleapis.com \
    compute.googleapis.com

3. Configurer une CVM et récupérer un devis TDX

Dans cette étape, vous allez créer une CVM TDX et récupérer un devis d'attestation TDX à partir du matériel.

  1. Accédez à la console Google Cloud ou à votre environnement de développement local. Créez une CVM comme suit :
gcloud config set project <project-id>

gcloud compute instances create tdx-cvm-attestation-codelab \
    --machine-type=c3-standard-4 \
    --zone=us-central1-c \
    --confidential-compute-type=TDX \
    --maintenance-policy=TERMINATE \
    --image-family=ubuntu-2204-lts \
    --image-project=ubuntu-os-cloud \
    --scopes https://www.googleapis.com/auth/cloud-platform

Remplacez <project-id> par l'identifiant unique de votre projet.

  1. Connectez-vous à la CVM.
gcloud compute ssh --zone us-central1-c tdx-cvm-attestation-codelab
  1. Configurez un environnement Go sur la CVM :
wget https://go.dev/dl/go1.24.0.linux-amd64.tar.gz
sudo tar -C /usr/local -xzf go1.24.0.linux-amd64.tar.gz
export PATH=$PATH:/usr/local/go/bin
  1. Installez les outils go-tdx-guest.

Clonez le dépôt et créez l'outil attest, qui génère un devis TDX.

git clone https://github.com/google/go-tdx-guest.git
cd go-tdx-guest/tools/attest
go build
  1. Récupérez le devis d'attestation TDX :

Utilisez l'outil attest pour générer un devis. Nous allons transmettre un nonce (64 octets de REPORT_DATA) et enregistrer le résultat dans quote.bin.

nonce=$(head -c 64 /dev/urandom | xxd -p | tr -d '\n' | head -c 128)
sudo ./attest -in $nonce -inform hex -outform bin -out quote.bin

Le devis TDX est maintenant enregistré dans quote.bin.

4. Valider le devis d'attestation TDX

Maintenant que nous avons généré un devis Intel TDX (quote.bin), nous pouvons le valider à l'aide de l'outil check fourni dans le dépôt go-tdx-guest. Cet outil compare le devis aux spécifications d'Intel, le valide par rapport aux garanties téléchargées à partir du service de certification de provisionnement (PCS) d'Intel et valide les contraintes de la règle, comme le nonce, pour éviter les attaques par relecture.

  1. Accédez au répertoire de l'outil check et créez-le :
cd ~/go-tdx-guest/tools/check
go build
  1. Exécutez l'outil pour valider à la fois les signatures cryptographiques et le nonce. Nous allons utiliser l'option -get_collateral=true pour télécharger les certificats TEE nécessaires à partir du PCS d'Intel, l'option -check_crl=true pour vérifier les révocations de certificats et l'option -report_data pour valider la fraîcheur du nonce :
./check -in ~/go-tdx-guest/tools/attest/quote.bin -inform bin \
    -get_collateral=true -check_crl=true \
    -report_data $nonce

Si le devis est cryptographiquement valide et que le nonce correspond, l'outil enregistre un message de réussite semblable à l'exemple suivant et se ferme avec le code 0 :

INFO : TDX Quote verified successfully

5. Valider l'intégrité du micrologiciel GCE (OVMF)

Bien que la garantie d'Intel valide le matériel, elle ne vérifie pas que la machine virtuelle exécute un micrologiciel Google Compute Engine (GCE) authentique et non modifié.

Google publie des approbations de lancement signées (contenant des mesures d'intégrité de référence (RIM) de référence) pour toutes les versions officielles du micrologiciel GCE UEFI (OVMF) dans un bucket Google Cloud Storage (GCS) public.

Dans cette étape, nous allons utiliser l'outil public gce-tcb-verifier de Google pour récupérer automatiquement l'approbation du micrologiciel à partir de GCS, vérifier la signature de Google et valider la mesure du micrologiciel de notre CVM (MRTD) par rapport à celle-ci.

1. Créer l'outil de validation TCB GCE

  1. Clonez le dépôt public gce-tcb-verifier depuis GitHub :
cd ~
git clone https://github.com/google/gce-tcb-verifier.git
  1. Accédez au répertoire de l'outil CLI et créez-le :
cd gce-tcb-verifier/gcetcbendorsement/cli
go build -o gcetcbendorsement
  1. Ajoutez l'outil créé à votre PATH pour plus de commodité :
export PATH=$PATH:$(pwd)

2. Valider le devis par rapport à l'approbation du micrologiciel GCE

Exécutez maintenant l'outil gcetcbendorsement pour valider votre devis d'attestation. Comme l'outil réussit en mode silencieux lors d'une validation réussie, nous pouvons enchaîner la commande avec && echo "Validation Succeeded!" pour obtenir une confirmation explicite et conviviale de la réussite :

gcetcbendorsement tdx validate ~/go-tdx-guest/tools/attest/quote.bin && echo "Validation Succeeded!"

Résultat :

Validation Succeeded!

Que se passe-t-il en arrière-plan ?

  1. Extraction : l'outil analyse quote.bin et extrait la mesure du micrologiciel (MRTD) du corps du devis TD.
  2. Récupération : il crée une URL GCS à l'aide de MRTD et télécharge le VMLaunchEndorsement correspondant à partir du bucket public de Google (gs://gce_tcb_integrity).
  3. Validation de la signature : il récupère le certificat CA racine public de Google (https://pki.goog/cloud_integrity/GCE-cc-tcb-root_1.crt) et valide cryptographiquement la signature de Google sur l'approbation téléchargée.
  4. Validation de la mesure : il compare le MRTD signé par le matériel TDX dans votre devis aux mesures de référence de référence dans l'approbation signée de Google.

Si toutes les vérifications sont réussies, la commande se ferme avec le code 0 en mode silencieux (ou affiche Validation Succeeded! avec l'écho enchaîné), ce qui prouve que votre VM exécute un micrologiciel authentique approuvé par Google.

6. Valider l'hôte GCE TDX et la provenance de l'instance

Bien que l'attestation et la validation du micrologiciel confirment que votre VM s'exécute sur du matériel Intel TDX authentique avec un micrologiciel UEFI approuvé par Google, la validation de la provenance GCE TDX connecte directement votre devis d'attestation à l'infrastructure de Google Cloud de deux manières essentielles :

  1. Provenance de l'hôte : identifie la machine hôte Google Cloud physique qui exécute votre VM en extrayant le PPID (ID de provisionnement de la plate-forme) unique de la plate-forme à partir du certificat PCK du devis. Il récupère ensuite l'enregistrement du registre de la plate-forme hôte à partir de Google Cloud Storage (confidential-host-registry), qui enregistre la zone physique et la dernière fois que Google Cloud a provisionné les certificats d'attestation de l'hôte.
  2. Provenance de l'instance (liaison PZID) : Google Cloud lie cryptographiquement l'identité de votre VM spécifique (ProjectNumber, Zone, et InstanceID) au registre MR_OWNER du devis TDX. La validation de cette liaison garantit que le devis appartient exclusivement à votre instance et empêche les attaques par relecture ou par substitution de devis sur différentes VM ou différents projets.

L'outil CLI gceprovenance (également situé dans le dépôt go-tdx-guest) automatise la validation complète de la provenance : vérification de l'authenticité du devis, du défi de fraîcheur, de l'enregistrement du registre de l'hôte et de la liaison PZID de l'instance en une seule commande.

  1. Accédez au répertoire gceprovenance et créez l'outil :
cd ~/go-tdx-guest/tools/gceprovenance
go build
  1. Exécutez la validation complète de la provenance à l'aide de la commande verify. Nous allons transmettre le fichier de devis (quote.bin) et le défi nonce ($nonce) que nous avons générés précédemment :
./gceprovenance verify -quote ~/go-tdx-guest/tools/attest/quote.bin -challenge $nonce
  1. Lorsque toutes les vérifications sont réussies, l'outil génère un rapport de validation semblable à celui-ci :
GCE TDX provenance verification: OK

Instance: projects/123456789012/zones/us-central1-c/instances/987654321098765

Checks
  Quote verification: OK
  REPORT_DATA challenge: OK
  Host registry document: found
  PZID binding: OK

PPID: 0123456789abcdef0123456789abcdef
Quote: tdx_quote.bin
Host registry: host_registry.json

Que se passe-t-il en arrière-plan ?

  • Devis et défi : l'outil valide la chaîne de signature du devis par rapport au certificat racine d'Intel et confirme que le REPORT_DATA du devis correspond à votre défi $nonce.
  • Provenance de l'hôte (PPID) : il extrait le PPID hexadécimal de 32 caractères du certificat PCK de feuille et télécharge le document JSON du registre de l'hôte à partir de GCS (https://storage.googleapis.com/confidential-host-registry/).
  • Provenance de l'instance (PZID) : il interroge le serveur de métadonnées GCE local pour obtenir l'ID du projet numérique, la zone et l'ID d'instance de votre instance, crée la charge utile JSON PZID canonique ({"instanceId":...,"numericalProjectId":...,"zone":...}), calcule son condensé SHA-384 et vérifie qu'il correspond à MR_OWNER dans le devis.
  1. Inspectez le document du registre de l'hôte récupéré :

Par défaut, la commande verify enregistre le document JSON du registre de l'hôte récupéré dans host_registry.json. Vous pouvez l'inspecter pour afficher les métadonnées de la plate-forme hôte :

cat host_registry.json

Exemple de résultat :

{
  "zone": "us-central1",
  "timestamp": "2026-02-17T11:25:12Z"
}

Ces métadonnées décrivent les propriétés de la machine hôte :

  • zone: région/zone Google Cloud physique où réside la machine hôte.
  • timestamp: date et heure UTC auxquelles les certificats d'attestation matérielle de cette machine hôte ont été provisionnés et validés pour la dernière fois par Google Cloud.

7. Nettoyage

Exécutez les commandes suivantes dans la console Cloud ou dans votre environnement de développement local :

# Delete the CVM instance
gcloud compute instances delete tdx-cvm-attestation-codelab --zone=us-central1-c

8. Étape suivante

En savoir plus sur les Confidential VM et Compute Engine.