Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Convalida un documento di attestazione NitroTPM

Questo argomento fornisce una panoramica dettagliata dell'intero flusso di attestazione NitroTPM. Descrive inoltre cosa viene generato dal sistema AWS Nitro quando viene richiesto un documento di attestazione e spiega come un servizio di gestione delle chiavi dovrebbe elaborare un documento di attestazione.

Lo scopo dell'attestazione è dimostrare che un'istanza è un'entità affidabile, in base al codice e alla configurazione che sta eseguendo. La radice della fiducia per l'istanza risiede nel sistema AWS Nitro, che fornisce documenti di attestazione.

I documenti di attestazione sono firmati dalla AWS Nitro Attestation Public Key Infrastructure (PKI), che include un'autorità di certificazione pubblicata che può essere incorporata in qualsiasi servizio.

Il documento di attestazione

I documenti di attestazione sono codificati in Concise Binary Object Representation (CBOR) e firmati utilizzando CBOR Object Signing and Encryption (COSE).

Per ulteriori informazioni su CBOR, vedere RFC 8949: Concise Binary Object Representation (CBOR).

Specificazione del documento di attestazione

Di seguito viene illustrata la struttura di un documento di attestazione.

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"

I parametri opzionali nel documento di attestazione (public_key,user_data, andnonce) possono essere utilizzati per stabilire un protocollo di convalida personalizzato tra un'istanza di attestazione e il servizio esterno.

Convalida del documento di attestazione

Quando richiedi un documento di attestazione dall'Hypervisor Nitro, ricevi un blob binario che contiene il documento di attestazione firmato. Il documento di attestazione firmato è un oggetto codificato in CBOR e firmato COSE (utilizzando la struttura di firma COSE_Sign1). Il processo di convalida complessivo include i seguenti passaggi:

I documenti di attestazione sono firmati da AWS Nitro Attestation PKI, che include un certificato root per le partizioni commerciali. AWS Il certificato principale può essere scaricato da https://aws-nitro-enclaves.amazonaws.com/AWS_NitroEnclaves_Root-G1.zip e può essere verificato utilizzando la seguente impronta digitale.

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

Il certificato radice si basa su una chiave AWS Certificate Manager privata della Private Certificate Authority (AWS Private CA) e ha una durata di 30 anni. L'oggetto del PCA ha il seguente formato.

CN=aws.nitro-enclaves, C=US, O=Amazon, OU=AWS

COSE e CBOR

Di solito, la struttura della firma COSE_sign1 viene utilizzata quando viene inserita una sola firma su un messaggio. I parametri relativi al contenuto e alla firma vengono inseriti nell'intestazione protetta anziché avere la separazione di COSE_sign. La struttura può essere codificata come etichettata o senza tag, a seconda del contesto in cui verrà utilizzata. Una struttura COSE_sign1 con tag è identificata dal tag CBOR 18.

L'oggetto CBOR che contiene il corpo, la firma e le informazioni sul corpo e sulla firma è chiamato struttura COSE_Sign1. La struttura COSE_sign1 è un array CBOR. L'array include i seguenti campi.

[
  protected:   Header,
  unprotected: Header,
  payload:     This field contains the serialized content to be signed,
  signature:   This field contains the computed signature value.
]

Nel contesto di un documento di attestazione, l'array include quanto segue.

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 */
)

Per ulteriori informazioni su CBOR, vedere RFC 8949: Concise Binary Object Representation (CBOR).

Validità semantica

Un documento di attestazione avrà sempre il relativo pacchetto CA nell'ordine seguente.

[ ROOT_CERT - INTERM_1 - INTERM_2 .... - INTERM_N]
      0          1          2             N - 1

Tieni presente questo ordine, poiché alcuni strumenti esistenti, come la Guida per programmatori dell'API Java CertPath di Java PKI, potrebbero richiedere che vengano ordinati in modo diverso.

Per convalidare i certificati, iniziate dal pacchetto Attestation Document CA e generate la catena richiesta, dove si TARGET_CERT trova il certificato nel documento di attestazione.

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

Validità del certificato

Per tutti i certificati della catena, è necessario assicurarsi che la data corrente rientri nel periodo di validità specificato nel certificato.

Validità della catena di certificati

In generale, potrebbe essere necessaria una catena di più certificati, comprendente un certificato del proprietario della chiave pubblica firmato da una CA e zero o più certificati aggiuntivi CAs firmati da un'altra. CAs Tali catene, chiamate percorsi di certificazione, sono necessarie perché un utente con chiave pubblica viene inizializzato solo con un numero limitato di chiavi pubbliche CA garantite. Le procedure di convalida dei percorsi di certificazione per la PKI Internet si basano sull'algoritmo fornito in X.509. L'elaborazione del percorso di certificazione verifica l'associazione tra il nome distinto del soggetto, il nome alternativo del soggetto e la chiave pubblica del and/or soggetto. L'associazione è limitata dai vincoli specificati nei certificati che comprendono il percorso e gli input specificati dalla parte affidante. I vincoli di base e le estensioni dei vincoli delle policy consentono alla logica di elaborazione del percorso di certificazione di automatizzare il processo decisionale.

Utilizzando Java, a partire dal percorso principale e dalla catena di certificati generata, la convalida della catena è la seguente.

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