# Validación de un documento de atestación de NitroTPM **nota** Este tema está dirigido a los usuarios que utilizan un servicio de administración de claves de terceros y necesitan crear sus propios mecanismos de validación de documentos de atestación. Este tema ofrece una descripción detallada de todo el flujo de atestación de NitroTPM. También aborda lo que genera el sistema AWS Nitro cuando se solicita un documento de atestación y explica cómo un servicio de administración de claves debe procesar dicho documento. **Topics** + [El documento de atestación](#doc-def) + [Validación del documento de atestación](#validation-process) El propósito de la atestación es demostrar que una instancia es una entidad confiable, con base en el código y la configuración que ejecuta. La raíz de confianza de la instancia reside dentro del sistema AWS Nitro, que proporciona documentos de atestación. Los documentos de atestación están firmados por la infraestructura de clave pública (PKI) de atestación de AWS Nitro, que incluye una autoridad certificadora publicada que se puede incorporar a cualquier servicio. ## El documento de atestación Los documentos de atestación se codifican en la representación concisa de objetos binarios (CBOR) y se firman mediante el esquema de firma y cifrado de objetos CBOR (COSE). Para obtener más información sobre CBOR, consulte [RFC 8949: Representación concisa de objetos binarios (CBOR)](https://www.rfc-editor.org/rfc/rfc8949.html). ### Especificación del documento de atestación A continuación se muestra la estructura de un documento de atestación. ``` 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" ``` Los parámetros opcionales del documento de atestación (`public_key`, `user_data` y `nonce`) se pueden utilizar para establecer un protocolo de validación personalizado entre una instancia que realiza la atestación y el servicio externo. ## Validación del documento de atestación Cuando se solicita un documento de atestación al hipervisor Nitro, se recibe un blob binario que contiene el documento de atestación firmado. El documento de atestación firmado es un objeto codificado en CBOR y firmado en COSE (mediante la estructura de firma COSE\$1Sign1). El proceso general de validación incluye los siguientes pasos: 1. Decodificar el objeto CBOR y asignarlo a una estructura COSE\$1Sign1. 1. Extraer el documento de atestación de la estructura COSE\$1Sign1. 1. Verificar la cadena de certificados. 1. Asegurarse de que el documento de atestación esté firmado correctamente. Los documentos de atestación se firman mediante la infraestructura de clave pública de atestación (PKI) de AWS Nitro, que incluye un certificado raíz para las particiones comerciales de AWS. El certificado raíz se puede descargar desde [https://aws-nitro-enclaves.amazonaws.com/AWS\$1NitroEnclaves\$1Root-G1.zip](https://aws-nitro-enclaves.amazonaws.com/AWS_NitroEnclaves_Root-G1.zip) y se puede verificar con la siguiente huella digital. ``` 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 ``` El certificado raíz se basa en una clave privada de una entidad de certificación privada de AWS Certificate Manager (AWS Private CA) y tiene una vigencia de 30 años. El asunto de la PCA tiene el siguiente formato. ``` CN=aws.nitro-enclaves, C=US, O=Amazon, OU=AWS ``` **Topics** + [COSE y CBOR](#COSE-CBOR) + [Validez semántica](#semantic-validation) + [Validez del certificado](#cert-validity) + [Validez de la cadena de certificados](#chain) ### COSE y CBOR Por lo general, la estructura de firma COSE\$1Sign1 se utiliza cuando solo se aplica una firma a un mensaje. Los parámetros relacionados con el contenido y la firma se ubican en el encabezado protegido, en lugar de utilizar la separación propia de COSE\$1Sign. La estructura se puede codificar como etiquetada o sin etiquetar, según el contexto en el que se use. Una estructura COSE\$1Sign1 etiquetada se identifica mediante la etiqueta CBOR 18. El objeto CBOR que contiene el cuerpo, la firma y la información sobre ambos se denomina estructura COSE\$1Sign1. La estructura COSE\$1Sign1 es un arreglo CBOR. El arreglo incluye los siguientes campos. ``` [ protected: Header, unprotected: Header, payload: This field contains the serialized content to be signed, signature: This field contains the computed signature value. ] ``` En el contexto de un documento de atestación, el arreglo incluye lo siguiente. ``` 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 obtener más información sobre CBOR, consulte [RFC 8949: Representación concisa de objetos binarios (CBOR)](https://www.rfc-editor.org/rfc/rfc8949.html). ### Validez semántica Un documento de atestación siempre contiene su paquete de entidades de certificación (CA) en el siguiente orden. ``` [ ROOT_CERT - INTERM_1 - INTERM_2 .... - INTERM_N] 0 1 2 N - 1 ``` Se debe tener en cuenta este orden, ya que algunas herramientas existentes, como CertPath de Java ([de la guía del programador de la API de PKI de Java](https://docs.oracle.com/javase/8/docs/technotes/guides/security/certpath/CertPathProgGuide.html)), pueden requerir que se ordenen de manera diferente. Para validar los certificados, inicie desde el paquete de entidades de certificación (CA) del documento de atestación y genere la cadena necesaria, donde `TARGET_CERT` corresponde al certificado dentro del documento de atestación. ``` [TARGET_CERT, INTERM_N, ..... , INTERM_2, INTERM_1, ROOT_CERT] ``` ### Validez del certificado Para todos los certificados de la cadena, se debe asegurar de que la fecha actual se encuentre dentro del período de validez especificado en el certificado. ### Validez de la cadena de certificados En general, puede ser necesaria una cadena compuesta por varios certificados, que incluya un certificado del propietario de la clave pública firmado por una entidad de certificación, y cero o más certificados adicionales de entidades de certificación firmados por otras entidades de certificación. Dichas cadenas, denominadas rutas de certificación, son necesarias porque un usuario de clave pública solo se inicializa con un número limitado de claves públicas de entidades de certificación de confianza. Los procedimientos de validación de rutas de certificación para la infraestructura de clave pública (PKI) de Internet se basan en el algoritmo definido en X.509. El procesamiento de rutas de certificación verifica la vinculación entre el nombre distinguido del sujeto o el nombre alternativo del sujeto, y la clave pública del sujeto. La vinculación está limitada por las restricciones especificadas en los certificados que componen la ruta y por las entradas definidas por la parte que confía. Las extensiones de restricciones básicas y de políticas permiten que la lógica de procesamiento de rutas de certificación automatice el proceso de toma de decisiones. **nota** CRL debe estar desactivado al realizar la validación. En Java, al partir de la ruta raíz y de la cadena de certificados generada, la validación de la cadena se realiza de la siguiente manera. ``` 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); } ```