Validar um atestado do NitroTPM

Este tópico fornece uma visão geral detalhada de todo o fluxo de atestação do NitroTPM. Também discute o que é gerado pelo sistema AWS Nitro quando um atestado é solicitado e explica como um serviço de gerenciamento de chaves deve processar um atestado.

O objetivo do atestado é provar que uma instância é uma entidade confiável, com base no código e na configuração que está sendo executada. A raiz de confiança da instância reside no sistema AWS Nitro, que fornece os atestados.

Os atestados são assinados pela Public Key Infrastructure (PKI) da atestação do AWS Nitro, que inclui uma autoridade de certificação publicada que pode ser incorporada a qualquer serviço.

O atestado

Os atestados são codificados em Concise Binary Object Representation (CBOR) e assinados usando CBOR Object Signing and Encryption (COSE).

Para obter mais informações sobre CBOR, consulte RFC 8949: Concise Binary Object Representation (CBOR).

Especificação do atestado

O exemplo a seguir mostra a estrutura de um atestado.

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"

Os parâmetros opcionais do atestado (public_key, user_data e nonce) podem ser usados para estabelecer um protocolo de validação personalizado entre uma instância de atestado e o serviço externo.

Validação do atestado

Ao solicitar um atestado do Hipervisor Nitro, você recebe um blob binário que contém o atestado assinado. O atestado assinado é um objeto codificado em CBOR e assinado com COSE (usando o objeto de estrutura de assinatura COSE_Sign1). O processo de validação inclui as seguintes etapas:

Os atestados são assinados pela PKI da atestação do AWS Nitro, que inclui um certificado raiz para as partições comerciais AWS. O certificado-raiz pode ser baixado de https://aws-nitro-enclaves.amazonaws.com/AWS_NitroEnclaves_Root-G1.zip e pode ser verificado usando a impressão digital a seguir.

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

O certificado raiz é baseado em uma chave privada da autoridade privada de certificação (AWS Private CA) do AWS Certificate Manager e tem vida útil de 30 anos. O assunto da PCA tem o seguinte formato:

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

COSE e CBOR

Normalmente, a estrutura de assinatura COSE_Sign1 é usada quando apenas uma assinatura vai ser colocada em uma mensagem. Os parâmetros que lidam com o conteúdo e a assinatura são colocados no cabeçalho protegido em vez de ter a separação da COSE_Sign. A estrutura pode ser codificada como marcada ou não marcada, dependendo do contexto em que será usada. Uma estrutura marcada COSE_Sign1 é identificada pela tag CBOR 18.

O objeto CBOR que traz o corpo, a assinatura e as informações sobre o corpo e a assinatura é chamado de estrutura COSE_Sign1. A estrutura COSE_Sign1 é uma matriz CBOR. A matriz inclui os campos a seguir.

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

No contexto de um atestado, a matriz inclui o que se 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 */
)

Para obter mais informações sobre CBOR, consulte RFC 8949: Concise Binary Object Representation (CBOR).

Validação semântica

Um atestado sempre tem o pacote da CA na ordem a seguir.

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

Lembre-se dessa ordem, pois algumas ferramentas existentes, como o CertPath do Java do Java PKI API Programmer's Guide, podem exigir uma ordem diferente.

Para validar os certificados, comece com o pacote da CA do atestado e gere a cadeia necessária, na qual TARGET_CERT é o certificado no atestado.

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

Validade de certificado

Para todos os certificados da cadeia, você deve garantir que a data atual esteja dentro do período de validade especificado no certificado.

Validade da cadeia de certificados

Em geral, uma cadeia de vários certificados pode ser necessária, incluindo um certificado do proprietário da chave pública assinado por uma CA e zero ou mais certificados adicionais de CAs assinados por outras CAs. Essas cadeias, chamadas de caminhos de certificação, são necessárias porque um usuário de chave pública é inicializado apenas com um número limitado de chaves públicas garantidas da CA. Os procedimentos de validação do caminho de certificação para a PKI da Internet são baseados no algoritmo fornecido no X.509. O processamento do caminho de certificação verifica a associação entre o nome distinto do sujeito e/ou o nome alternativo do sujeito e a chave pública do sujeito. A vinculação é limitada pelas restrições especificadas nos certificados que compõem o caminho e as entradas que são especificadas pela parte que vai confiar. As restrições básicas e as extensões das restrições das políticas permitem que a lógica de processamento do caminho de certificação automatize o processo de tomada de decisão.

Usando Java, partindo do caminho raiz e da cadeia de certificados gerada, a validação da cadeia se dá como se segue.

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