Convalida un documento di attestazione NitroTPM

Questo argomento fornisce una panoramica dettagliata dell’intero flusso di attestazione NitroTPM. Inoltre descrive 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, consulta RFC 8949: Concise Binary Object Representation (CBOR).

Specifiche del documento di attestazione

Il seguente esempio illustra 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 facoltativi nel documento di attestazione (public_key,user_data, e nonce) 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 comprende le seguenti fasi:

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 privata della Private Certificate Authority AWS Certificate Manager (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 invece di 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, consulta RFC 8949: Concise Binary Object Representation (CBOR).

Validità semantica

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

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

Tieni presente questo ordine, poiché alcuni strumenti esistenti, come CertPath di Java dalla Guida per programmatori API PKI Java, potrebbero richiedere un ordine diverso.

Per convalidare i certificati, inizia dal pacchetto Attestation Document CA e genera la catena richiesta, dove TARGET_CERT è il certificato nel documento di attestazione.

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

Validità dei certificati

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

Validità della catena di certificati

In generale, potrebbe servire una catena di più certificati, comprendente un certificato del proprietario della chiave pubblica firmato da una CA e zero o più certificati aggiuntivi di CA firmati da altre CA. Queste 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 e/o il nome alternativo del soggetto e la chiave pubblica del 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 permettono 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);
}