本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
確認 NitroTPM 驗證文件
注意
本主題旨在面向使用第三方金鑰管理服務，以及需要建置其驗證文件確認機制的使用者。
本主題提供了整個 NitroTPM 驗證流程的詳細概觀。它也會討論請求證明文件時 AWS Nitro 系統所產生的內容，並說明金鑰管理服務應如何處理證明文件。
驗證旨在依據執行個體在執行的程式碼與組態，證明執行個體是一個值得信任的實體。執行個體的信任根位於 AWS Nitro 系統中，提供證明文件。
證明文件由 AWS Nitro Attestation Public Key Infrastructure (PKI) 簽署，其中包含可併入任何服務的已發佈憑證授權機構。
驗證文件
驗證文件以 Concise Binary Object Representation (CBOR) 編碼，以及使用 CBOR 物件簽署及加密 (COSE) 簽署。
若要了解 CBOR 的相關詳細資訊，請參閱 RFC 8949：Concise Binary Object Representation (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 私有 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：Concise Binary Object Representation (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 簽署的公有金鑰擁有者憑證，以及由其他 CA 簽署的零或多個額外的 CA 憑證。由於公有金鑰使用者僅使用有限數量的保證 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); }
