本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

# 確認 NitroTPM 驗證文件
<a name="nitrotpm-attestation-document-validate"></a>

**注意**  
本主題旨在面向使用第三方金鑰管理服務，以及需要建置其驗證文件確認機制的使用者。

本主題提供了整個 NitroTPM 驗證流程的詳細概觀。它也會討論請求證明文件時 AWS Nitro 系統所產生的內容，並說明金鑰管理服務應如何處理證明文件。

**Topics**
+ [驗證文件](#doc-def)
+ [驗證文件確認](#validation-process)

驗證旨在依據執行個體在執行的程式碼與組態，證明執行個體是一個值得信任的實體。執行個體的信任根位於 AWS Nitro 系統中，提供證明文件。

證明文件由 AWS Nitro Attestation Public Key Infrastructure (PKI) 簽署，其中包含可納入任何服務的已發佈憑證授權機構。

## 驗證文件
<a name="doc-def"></a>

驗證文件以 Concise Binary Object Representation (CBOR) 編碼，以及使用 CBOR 物件簽署及加密 (COSE) 簽署。

若要了解 CBOR 的相關詳細資訊，請參閱 [RFC 8949：Concise Binary Object Representation (CBOR)](https://www.rfc-editor.org/rfc/rfc8949.html)。

### 驗證文件規格
<a name="doc-spec"></a>

下面所示為驗證文件的結構。

```
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`) 中的選用參數，可在驗證執行個體與外部服務間建立自訂驗證通訊協定。

## 驗證文件確認
<a name="validation-process"></a>

若透過 Nitro Hypervisor 請求驗證文件，您會收到包含已簽署驗證文件的二進位 Blob。簽署的驗證文件為 CBOR 編碼、COSE 簽署 (使用 COSE\$1Sign1 簽章結構) 的物件。整個驗證程序包括以下步驟：

1. 解碼 CBOR 物件，以及將其映射至 COSE\$1Sign1 結構。

1. 透過 COSE\$1Sign1 結構擷取驗證文件。

1. 確認憑證的鏈結。

1. 確定驗證文件已適當簽署。

證明文件由 AWS Nitro Attestation PKI 簽署，其中包含商業 AWS 分割區的根憑證。根憑證可從 [https://aws-nitro-enclaves.amazonaws.com/AWS\$1NitroEnclaves\$1Root-G1.zip](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
```

**Topics**
+ [COSE 與 CBOR](#COSE-CBOR)
+ [語意有效性](#semantic-validation)
+ [憑證有效性](#cert-validity)
+ [憑證鏈有效性](#chain)

### COSE 與 CBOR
<a name="COSE-CBOR"></a>

通常，若訊息上僅置放一個簽章，則會使用 COSE\$1Sign1 簽章結構。處理內容與簽章的參數將會置放於受到保護的標頭中，而非分隔 COSE\$1Sign。視乎將在其中使用的內容，能夠以加標籤或不加標籤來對結構編碼。加標籤的 COSE\$1Sign1 結構可透過 CBOR 標籤 18 辨識。

承載內文的 CBOR 物件、簽章，以及內文及簽章的相關資訊稱為 COSE\$1Sign1 結構。COSE\$1Sign1 結構為 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)](https://www.rfc-editor.org/rfc/rfc8949.html)。

### 語意有效性
<a name="semantic-validation"></a>

驗證文件的 CA 套件始終按下面的順序排列。

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

請記住此排序，因為某些現有的工具可能需要以不同順序排列，例如，[Java PKI API 程式設計人員指南](https://docs.oracle.com/javase/8/docs/technotes/guides/security/certpath/CertPathProgGuide.html)中的 Java 的 CertPath。

如需驗證憑證，可從驗證文件 CA 套件開始，然後生成必要的憑證鏈，其中 `TARGET_CERT` 是驗證文件中的憑證。

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

### 憑證有效性
<a name="cert-validity"></a>

對於憑證鏈中的所有憑證，必須確保目前日期在憑證中指定的有效期間範圍內。

### 憑證鏈有效性
<a name="chain"></a>

一般來說，可能需要多個憑證鏈，且包含由一個 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);
}
```