Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Validation d’un document d’attestation NitroTPM
Note
Cette rubrique est destinée aux utilisateurs qui utilisent un service de gestion de clés tiers et qui ont besoin de créer leurs propres mécanismes de validation des documents d’attestation.
Cette rubrique fournit un aperçu détaillé de l’ensemble du flux d’attestations NitroTPM. Il décrit également ce qui est généré par le système AWS Nitro lorsqu'un document d'attestation est demandé et explique comment un service de gestion des clés doit traiter un document d'attestation.
L’objectif de l’attestation est de prouver qu’une instance est une entité fiable, sur la base du code et de la configuration qu’elle exécute. La base de la confiance pour l'instance réside dans le système AWS Nitro, qui fournit les documents d'attestation.
Les documents d'attestation sont signés par l'infrastructure à clé publique (PKI) d'attestation AWS Nitro, qui inclut une autorité de certification publiée pouvant être intégrée à n'importe quel service.
Le document d’attestation
Les documents d’attestation sont codés au format CBOR (Concise Binary Object Representation) et signés à l’aide du protocole COSE (CBOR Object Signing and Encryption).
Pour plus d’informations sur le format CBOR, consultez la RFC 8949 : Concise Binary Object Representation (CBOR)
Spécification du document d’attestation
La structure d’un document d’attestation est présentée ci-dessous.
AttestationDocument = { module_id: text, ; issuing Nitro hypervisor module ID timestamp: uint .size 8, ; UTC time when document was created, in ; milliseconds since UNIX epoch digest: digest, ; the digest function used for calculating the ; register values nitrotpm_pcrs: { + index => pcr }, ; map of PCRs at the moment the Attestation Document was generated certificate: cert, ; the public key certificate for the public key ; that was used to sign the Attestation Document cabundle: [* cert], ; issuing CA bundle for infrastructure certificate ? public_key: user_data, ; an optional DER-encoded key the attestation ; consumer can use to encrypt data with ? user_data: user_data, ; additional signed user data, defined by protocol ? nonce: user_data, ; an optional cryptographic nonce provided by the ; attestation consumer as a proof of authenticity } cert = bytes .size (1..1024) ; DER encoded certificate user_data = bytes .size (0..1024) pcr = bytes .size (32/48/64) ; PCR content index = 0..31 digest = "SHA384"
Les paramètres facultatifs du document d’attestation (public_key, user_data, et nonce) peuvent être utilisés pour établir un protocole de validation personnalisé entre une instance d’attestation et le service externe.
Validation du document d’attestation
Lorsque vous demandez un document d’attestation à l’hyperviseur Nitro, vous recevez en retour un blob binaire contenant le document d’attestation signé. Le document d’attestation signé est un objet codé au format CBOR et signé selon COSE (en utilisant la structure de signature COSE_sign1). Le processus de validation global comprend les étapes suivantes :
-
Décodage de l’objet CBOR et mappage à une structure COSE_Sign1.
-
Extraction du document d’attestation de la structure COSE_Sign1.
-
Vérification de la chaîne du certificat.
-
Vérification de conformité de la signature du document d’attestation.
Les documents d'attestation sont signés par le AWS Nitro Attestation PKI, qui inclut un certificat racine pour les partitions commerciales AWS . Le certificat racine peut être téléchargé depuis https://aws-nitro-enclaves.amazonaws.com/AWS_NitroEnclaves_Root-G1.zip
64:1A:03:21:A3:E2:44:EF:E4:56:46:31:95:D6:06:31:7E:D7:CD:CC:3C:17:56:E0:98:93:F3:C6:8F:79:BB:5B
Le certificat racine est basé sur une clé AWS Certificate Manager privée de l'autorité de certification privée (AWS CA privée) et sa durée de vie est de 30 ans. Le sujet du PCA a le format suivant.
CN=aws.nitro-enclaves, C=US, O=Amazon, OU=AWS
Rubriques
COSE et CBOR
Habituellement, la structure de signature COSE_Sign1 est utilisée lorsqu’une signature unique doit être apposée sur un message. Les paramètres relatifs au contenu et à la signature sont placés dans l’en-tête protégé plutôt que d’être séparés de COSE_Sign. La structure peut être codée avec ou sans balise, selon le contexte dans lequel elle sera utilisée. Une structure COSE_Sign1 étiquetée est identifiée par la balise CBOR 18.
L’objet CBOR qui contient le corps, la signature et les informations relatives au corps et à la signature est appelé structure COSE_Sign1. La structure COSE_Sign1 est un tableau au format CBOR. Le tableau comprend les champs suivants.
[ protected: Header, unprotected: Header, payload: This field contains the serialized content to be signed, signature: This field contains the computed signature value. ]
Dans le contexte d’un document d’attestation, le tableau comprend les éléments suivants.
18(/* COSE_Sign1 CBOR tag is 18 */ {1: -35}, /* This is equivalent with {algorithm: ECDS 384} */ {}, /* We have nothing in unprotected */ $ATTESTATION_DOCUMENT_CONTENT /* Attestation Document */, signature /* This is the signature */ )
Pour plus d’informations sur le format CBOR, consultez la RFC 8949 : Concise Binary Object Representation (CBOR)
Validité sémantique
Un document d’attestation contiendra toujours son groupe d’autorité de certification (CA bundle) dans l’ordre suivant.
[ ROOT_CERT - INTERM_1 - INTERM_2 .... - INTERM_N] 0 1 2 N - 1
Gardez cet ordre à l'esprit, car certains outils existants, tels que le guide CertPath du programmeur d'API Java PKI de
Pour valider les certificats, commencez par le groupe d’autorité de certification du document d’attestation et générez la chaîne requise, où TARGET_CERT est le certificat dans le document d’attestation.
[TARGET_CERT, INTERM_N, ..... , INTERM_2, INTERM_1, ROOT_CERT]
Validité des certificats
Vous devez vous assurer que la date du jour se situe dans la période de validité spécifiée dans le certificat pour tous les certificats de la chaîne.
Validité de la chaîne de certificats
En général, une chaîne de plusieurs certificats peut être nécessaire, comprenant un certificat du propriétaire de la clé publique signé par une autorité de certification et zéro ou plusieurs certificats supplémentaires CAs signés par une autre autorité de certification CAs. Ces chaînes, appelées chemins de certification, sont nécessaires, car un utilisateur de clé publique n’est mis en service qu’avec un nombre limité de clés publiques d’autorité de certification garanties. Les procédures de validation du chemin de certification pour l’infrastructure à clé publique (PKI) Internet sont basées sur l’algorithme fourni dans X.509. Le traitement du chemin de certification vérifie le lien entre le nom distinctif du sujet, le nom alternatif du and/or sujet et la clé publique du sujet. Le lien est limité par des contraintes spécifiées dans les certificats qui comprennent le chemin et les entrées spécifiées par la partie utilisatrice. Les contraintes de base et les extensions des contraintes de politique permettent à la logique de traitement du chemin de certification d’automatiser le processus de prise de décision.
Note
La CRL doit être désactivée lors de la validation.
Sous Java, à partir du chemin racine et de la chaîne de certificats générée, la validation de la chaîne se déroule comme suit.
validateCertsPath(certChain, rootCertficate) { /* The trust anchor is the root CA to trust */ trustAnchors.add(rootCertificate); /* We need PKIX parameters to specify the trust anchors * and disable the CRL validation */ validationParameters = new PKIXParameters(trustAnchors); certPathValidator = CertPathValidator.getInstance(PKIX); validationParameters.setRevocationEnabled(false); /* We are ensuring that certificates are chained correctly */ certPathValidator.validate(certPath, validationParameters); }
