Le micrologiciel de toutes les instances de Confidential VM est UEFI et basé sur le projet Open Virtual Machine Firmware. Le micrologiciel est géré par Google pour assurer la sécurité, les performances et la stabilité.
Le micrologiciel géré par Google assure également la cohérence des valeurs stockées dans les registres de mesure sur la racine de confiance d'une instance de Confidential VM. Cela permet d'éviter que les charges de travail d'informatique confidentielle ne soient bloquées par la validation de l'attestation lorsque le micrologiciel d'une instance Confidential VM est mis à jour.
Pour vous assurer que votre instance de Confidential VM s'exécute sur un micrologiciel authentique géré par Google, vous pouvez effectuer les tâches suivantes :
Récupérez une attestation de lancement signée par Google sur les instances Confidential VM avec AMD SEV-SNP ou Intel TDX activé. Une approbation de lancement contient des mesures précalculées et signées liées au micrologiciel.
Vérifiez l'approbation du lancement en la comparant aux mesures spécifiques à l'architecture.
Vérifiez que le binaire UEFI est approuvé par Google et n'a pas été modifié.
En plus de l'attestation à distance, vous pouvez inclure la validation du micrologiciel dans votre stratégie de sécurité, qui détermine si une instance de Confidential VM doit avoir accès aux ressources protégées.
Récupérer les approbations de lancement
Vous pouvez récupérer les recommandations de lancement à l'aide des outils Google ou des vôtres.
Récupérer les approbations de lancement avec les outils Google
Pour récupérer une approbation de lancement à partir d'une instance Confidential VM AMD SEV-SNP ou Intel TDX à l'aide des outils Google :
Utilisez SSH pour vous connecter à votre instance de VM confidentielle.
Utilisez Go-TPM-Tools (AMD SEV-SNP ou Intel TDX) ou SEV Guest (AMD SEV-SNP) pour récupérer un rapport d'attestation et les certificats associés.
Utilisez
gcetcbendorsement
pour extraire l'approbation UEFI de l'attestation et la stocker dans un fichier. Vous pouvez ensuite vérifier que l'approbation est ancrée dans Google et que la mesure du rapport d'attestation figure parmi les mesures signées.
Récupérer les approbations de lancement avec vos propres outils
Pour récupérer une approbation de lancement à l'aide de vos propres outils, suivez les instructions ci-dessous.
AMD SEV-SNP
Envoyez une demande d'invité étendu au processeur sécurisé AMD pour récupérer un rapport d'attestation.
Extrayez la mesure de 384 bits du rapport stockée au décalage
90h
. Pour en savoir plus, consultez la section 7.3, tableau 22 de la spécification ABI du micrologiciel SEV Secure Nested Paging.Utilisez la mesure de 384 bits pour télécharger une approbation de lancement de référence sérialisée à partir du bucket Cloud Storage suivant :
gs://gce_tcb_integrity/ovmf_x64_csm/sevsnp/384_BIT_MEASUREMENT.binarypb
Décodez le fichier BINARYPB avec un outil tel que protoc, en utilisant la définition du message
VMLaunchEndorsement
:message VMLaunchEndorsement { bytes serialized_uefi_golden = 1; bytes signature = 2; }
Autres emplacements de l'approbation du lancement
L'approbation du lancement peut également être disponible dans un tableau GUID dans le mécanisme de distribution des certificats AMD SEV-SNP. Il possède le GUID suivant :
9f4116cd-c503-4f5a-8f6f-fb68882f4ce2
La table GUID est documentée dans la spécification du bloc de communication hyperviseur invité AMD, dans la section "SNP Extended Guest Request" (Requête invitée étendue SNP).
Il peut également y avoir des références aux emplacements locaux et distants de l'approbation de lancement dans le journal des événements du client PC Trusted Computing Group, qui se trouve dans l'événement SP800-155, comme indiqué dans la spécification du profil du micrologiciel de la plate-forme client PC TCG version 1.06 révision 52.
Intel TDX
Créez une entrée configfs-tsm report :
name=/sys/kernel/config/tsm/report/report0 mkdir "${name}" cat "${your_nonce_file}" > "${name}/inblob" cat "${name}/outblob" > "${your_quote_destination}"
Extrayez la mesure MRTD (Measured Root of Trust Domain) de 384 bits de la citation stockée au décalage
b8h
(pour le module TDX 1.5). Pour en savoir plus, consultez la bibliothèque de devis TDX DCAP.Utilisez la mesure de 384 bits pour télécharger une approbation de lancement de référence sérialisée à partir du bucket Cloud Storage suivant :
gs://gce_tcb_integrity/ovmf_x64_csm/tdx/384_BIT_MEASUREMENT.binarypb
Décodez l'approbation du lancement avec un outil tel que protoc, en utilisant la définition du message
VMLaunchEndorsement
:message VMLaunchEndorsement { bytes serialized_uefi_golden = 1; bytes signature = 2; }
Exemple de recommandation de lancement
Voici un exemple de mention de lancement :
VMLaunchEndorsement:
serialized_uefi_golden: "SERIALIZED_BYTES"
signature: "LAUNCH_ENDORSEMENT_SIGNATURE_BYTES"
Mesures de référence UEFI
Le champ serialized_uefi_golden
contient une version sérialisée de plusieurs valeurs, comme défini par le tampon de protocole suivant :
message VMGoldenMeasurement {
google.protobuf.Timestamp timestamp = 1;
// The changelist number this UEFI was built from.
uint64 cl_spec = 2;
// DER format certificate of the key that signed this document.
bytes cert = 4;
// SHA-384 digest of the UEFI binary without TEE-specifics about launch.
bytes digest = 5;
// A sequence of PEM-encoded certificates of keys used in cert in Root ...
// final intermediate order. The last certificate will have a signed cert.
bytes ca_bundle = 6;
VMSevSnp sev_snp = 7;
VMTdx tdx = 8;
}
Le champ VMSevSnp
du message VMGoldenMeasurement
est défini par le tampon de protocole suivant :
message VMSevSnp {
// The Google-reported security version number of this UEFI on SEV-SNP.
uint32 svn = 1;
// Expected MEASUREMENT report field values given [key]-many VMSAs at launch.
map<uint32, bytes> measurements = 2; // bytes size 48
// A UUID that Google uses for its CVM UEFIs
bytes family_id = 3; // size 16
// A UUID to name this specific release of the UEFI image. This is randomly
// generated with each build.
bytes image_id = 4; // size 16
// The launch policy that verifiers should expect with this UEFI.
uint64 policy = 5;
// Optional. PEM-encoded certs for Identity..Author..Root. If a singleton,
// only an Id-key is used.
bytes ca_bundle = 6;
}
Le champ VMTdx
du message VMGoldenMeasurement
est défini par le tampon de protocole suivant :
message VMTdx {
message Measurement {
// The amount of RAM in GiB provided to the VM. This is relevant to the
// construction of the measured TDHOB page that includes memory region
// resource attributes.
uint32 ram_gib = 1;
// If true, EFI_UNACCEPTED_MEMORY not presented to guest.
// All memory is accepted by the firmware. Relevant to the TDHOB page
// since the resource attribute will include
// EFI_RESOURCE_ATTRIBUTE_NEEDS_EARLY_ACCEPT.
bool early_accept = 2;
// The SHA-384 digest of the measurement operations for the VM at launch.
bytes mrtd = 3;
}
// The Google-reported security version number of this UEFI on TDX.
uint32 svn = 1;
// Expected MRTD report field values given legal configurations.
repeated Measurement measurements = 2;
}
Pour décompresser et décoder ces valeurs à partir de serialized_uefi_golden field
avec vos propres outils, procédez comme suit :
Allouez un nouveau message
VMGoldenMeasurement
.Désérialisez
serialized_uefi_golden
dans le message.
Vous pouvez également utiliser la commande
gcetcbendorsement inspect
.
Vérifier les recommandations de lancement
Après avoir récupéré une approbation de lancement, vérifiez sa signature, puis intégrez ses mesures à votre stratégie de sécurité, le cas échéant.
Valider la signature d'une approbation de lancement
Vous pouvez valider la signature d'une approbation de lancement en incluant le certificat de clé racine de la base de calcul sécurisée Compute Engine Confidential Computing dans vos ancres de confiance.
Le champ cert
de VMGoldenMeasurement
dans l'approbation de lancement contient un certificat X.509v3 encodé au format DER de la clé publique de la clé de signature de l'approbation.
Le certificat est signé par la clé racine.
Vous pouvez utiliser gcetcbendorsement pour afficher les commandes openssl
à exécuter afin de valider la signature. Par exemple, si vous exécutez la commande suivante :
gcetcbendorsement verify --show LAUNCH_ENDORSEMENT_FILENAME.binarypb
Vous devriez recevoir une réponse de ce type :
openssl verify -CAfile <(openssl x509 -outform pem -in <(curl https://pki.goog/cloud_integrity/GCE-cc-tcb-root_1.crt)) \
<(gcetcbendorsement inspect mask "LAUNCH_ENDORSEMENT_FILENAME.binarypb" --path=cert) \
&& \
openssl pkeyutl -verify -pkeyopt rsa_padding_mode:pss \
-pkeyopt rsa_pss_saltlen:32 -pkeyopt digest:sha256 -pkeyopt rsa_mgf1_md:sha256 -pubin \
-inkey <(openssl x509 -pubkey -nocert -outform pem -in <(gcetcbendorsement inspect mask "LAUNCH_ENDORSEMENT_FILENAME.binarypb" --path=cert)) \
-sigfile <(gcetcbendorsement inspect signature "LAUNCH_ENDORSEMENT_FILENAME.binarypb") -keyform PEM \
-in <(openssl dgst -sha256 -binary <(gcetcbendorsement inspect payload "LAUNCH_ENDORSEMENT_FILENAME.binarypb")
Si vous préférez utiliser vos propres outils, vous pouvez remplacer les commandes gcetcbendorsement inspect
utilisées dans la réponse par votre propre logique d'extraction de tampon de protocole pour les champs nommés du message VMGoldenMeasurement
désérialisé.
Vérifier les mesures d'approbation du lancement
L'exemple de code expliquant comment créer une approbation de lancement est disponible dans le dépôt GitHub gce-tcb-verifier
.
Vous pouvez l'utiliser pour comprendre comment Google a obtenu les mesures à partir de l'UEFI et pour intégrer les mesures pertinentes à votre stratégie de sécurité.
Par exemple, vous pouvez vérifier que le micrologiciel est signé par le fournisseur du micrologiciel et comparer les mesures spécifiques à l'architecture aux valeurs précalculées et signées fournies dans le message VMLaunchEndorsement
.
Bien que le micrologiciel virtuel Compute Engine soit mis à niveau lors de la réinitialisation, la valeur PCR0 ne change pas. Par conséquent, la valeur svn
du micrologiciel dans la mesure signée peut différer de la valeur EV_S_CRTM_VERSION
mesurée pour PCR0, et l'événement EV_POST_CODE
dans le résumé du blob du micrologiciel est ignoré.
Vérifier le binaire UEFI d'une instance Confidential VM
À partir d'une approbation de lancement, décompressez la valeur
serialized_uefi_golden
dans unVMGoldenMeasurement
. Pour obtenir des exemples, consultez l'implémentation en Go ou la compilation protoc deendorsement.proto
pour une autre langue compatible avec les tampons de protocole.Récupérez la valeur du condensé à partir de
VMGoldenMeasurement
. Il s'agit du condensé SHA-384 du binaire UEFI sur lequel l'instance de Confidential VM s'exécute.Utilisez le résumé SHA-384 pour télécharger le binaire du micrologiciel à partir du bucket Cloud Storage suivant :
gs://gce_tcb_integrity/ovmf_x64_csm/UEFI_BINARY_DIGEST.fd
Si l'URL est valide et que le micrologiciel est téléchargé, effectuez un hachage SHA-384 sur le binaire du micrologiciel. S'il correspond au résumé de la mesure de référence, le micrologiciel exécuté sur votre instance de VM confidentielle n'a pas été modifié.