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.

Valider un document d'attestation NitroTPM

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 selon une représentation concise des objets binaires (CBOR) et signés à l'aide de la signature et du chiffrement d'objets CBOR (COSE).

Pour plus d'informations sur le CBOR, consultez la RFC 8949 : Représentation concise des objets binaires (CBOR).

Spécification du document d'attestation

Ce qui suit montre la structure d'un document d'attestation.

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, etnonce) 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 un blob binaire contenant le document d'attestation signé. Le document d'attestation signé est un objet codé en CBOR et signé COSE (en utilisant la structure de signature COSE_sign1). Le processus de validation global comprend les étapes suivantes :

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, et il peut être vérifié à l'aide de l'empreinte digitale suivante.

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 Private CA) 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

COSE et CBOR

Habituellement, la structure de signature COSE_sign1 est utilisée lorsqu'une seule signature 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é au lieu d'être séparés par COSE_sign. La structure peut être codée avec ou sans étiquette, 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 CBOR. Le tableau inclut 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 inclut 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 CBOR, consultez la RFC 8949 : Représentation concise des objets binaires (CBOR).

Validité sémantique

Un document d'attestation contiendra toujours son bundle CA 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 Java, peuvent nécessiter un ordre différent.

Pour valider les certificats, commencez par le bundle du document d'attestation CA et générez la chaîne requise. Où se TARGET_CERT trouve le certificat dans le document d'attestation ?

[TARGET_CERT, INTERM_N, ..... , INTERM_2, INTERM_1, ROOT_CERT]

Validité du certificat

Pour tous les certificats de la chaîne, vous devez vous assurer que la date actuelle correspond à la période de validité spécifiée dans le certificat.

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 initialisé qu'avec un nombre limité de clés publiques CA garanties. Les procédures de validation du chemin de certification pour l'Internet PKI sont basées sur l'algorithme fourni dans le 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. La liaison est limitée 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.

En utilisant Java, en partant du chemin racine et de la chaîne de certificats générée, la validation de la chaîne est la suivante.

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);
}