本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
驗證 NitroTPM 證明文件
注意
本主題適用於使用第三方金鑰管理服務，且需要建置自己的證明文件驗證機制的使用者。
本主題提供整個 NitroTPM 認證流程的詳細概觀。它也會討論請求證明文件時 AWS Nitro 系統所產生的內容，並說明金鑰管理服務應如何處理證明文件。
證明的目的是根據執行個體正在執行的程式碼和組態，證明執行個體是值得信任的實體。執行個體的信任根位於 AWS Nitro 系統中，該系統提供證明文件。
證明文件由 AWS Nitro Attestation Public Key Infrastructure (PKI) 簽署，其中包含可併入任何服務的已發佈憑證授權機構。
證明文件
證明文件以簡潔二進位物件表示法 (CBOR) 編碼，並使用 CBOR 物件簽署和加密 (COSE) 簽署。
如需 CBOR 的詳細資訊，請參閱 RFC 8949：精簡二進位物件表示法 (CBOR)
證明文件規格
以下顯示證明文件的結構。
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"
證明文件 (public_key、 user_data和 nonce) 中的選用參數可用來在證明執行個體與外部服務之間建立自訂驗證通訊協定。
證明文件驗證
當您向 Nitro Hypervisor 請求證明文件時，您會收到包含已簽署證明文件的二進位 Blob。已簽署的證明文件是 CBOR 編碼的 COSE 簽署 （使用 COSE_Sign1 簽章結構） 物件。整體驗證程序包含下列步驟：
-
解碼 CBOR 物件並將其映射至 COSE_Sign1 結構。
-
從 COSE_Sign1 結構擷取證明文件。
-
驗證憑證的鏈結。
-
確定證明文件已正確簽署。
證明文件由 AWS Nitro Attestation PKI 簽署，其中包含商業 AWS 分割區的根憑證。根憑證可以從 https://aws-nitro-enclaves.amazonaws.com/AWS_NitroEnclaves_Root-G1.zip
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
根憑證是以 AWS Certificate Manager 私有憑證授權單位 (AWS Private CA) 私有金鑰為基礎，生命週期為 30 年。PCA 的主旨格式如下。
CN=aws.nitro-enclaves, C=US, O=Amazon, OU=AWS
COSE 和 CBOR
通常，當訊息上只會放置一個簽章時，會使用 COSE_Sign1 簽章結構。處理內容和簽章的參數會放置在受保護的標頭中，而不是分隔 COSE_Sign。結構可以編碼為已標記或未標記，取決於其將用於其中的內容。標記的 COSE_Sign1 結構由 CBOR 標籤 18 識別。
承載內文的 CBOR 物件、簽章，以及內文和簽章的相關資訊稱為 COSE_Sign1 結構。COSE_Sign1 結構是 CBOR 陣列。陣列包含下列欄位。
[ protected: Header, unprotected: Header, payload: This field contains the serialized content to be signed, signature: This field contains the computed signature value. ]
在證明文件的內容中，陣列包含下列項目。
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 */ )
如需 CBOR 的詳細資訊，請參閱 RFC 8949：精簡二進位物件表示法 (CBOR)
語意有效性
證明文件的 CA 套件順序如下。
[ ROOT_CERT - INTERM_1 - INTERM_2 .... - INTERM_N] 0 1 2 N - 1
請記住此順序，因為 Java PKI API 程式設計人員指南
若要驗證憑證，請從證明文件 CA 套件開始，並產生必要的鏈結，其中 TARGET_CERT是證明文件中的憑證。
[TARGET_CERT, INTERM_N, ..... , INTERM_2, INTERM_1, ROOT_CERT]
憑證有效性
對於鏈結中的所有憑證，您必須確保目前日期落在憑證中指定的有效期間內。
憑證鏈有效性
一般而言，可能需要多個憑證鏈，其中包含由一個 CA 簽署的公有金鑰擁有者憑證，以及由其他 CAs簽署的零個或多個額外 CAs憑證。這類鏈稱為認證路徑是必要的，因為公有金鑰使用者只會使用有限數量的保證 CA 公有金鑰進行初始化。網際網路 PKI 的認證路徑驗證程序是以 X.509 中提供的演算法為基礎。認證路徑處理會驗證主體辨別名稱和/或主體替代名稱與主體公有金鑰之間的繫結。繫結受限於憑證中指定的限制條件，這些限制條件是由依賴方指定的路徑和輸入組成。基本限制條件和政策限制延伸允許認證路徑處理邏輯自動化決策程序。
注意
執行驗證時，必須停用 CRL。
使用 Java，從根路徑和產生的憑證鏈開始，鏈驗證如下所示。
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); }
