驗證機密 VM 執行個體的韌體

所有機密 VM 執行個體的韌體都是 UEFI，且以開放虛擬機器韌體專案為基礎。韌體由 Google 管理，可確保安全性、效能和穩定性。

Google 管理的韌體也能確保儲存在機密 VM 執行個體信任根的測量暫存器中的值保持一致。這樣一來，機密 VM 執行個體的韌體更新時，就不會因為認證驗證而導致機密運算工作負載遭到封鎖。

如要確認機密 VM 執行個體是否在真正的 Google 管理韌體上執行，請執行下列工作：

  • 在啟用 AMD SEV-SNP 或 Intel TDX 的機密 VM 執行個體上擷取 Google 簽署的啟動認可。啟動認可包含與韌體相關的預先計算和簽署測量結果。

  • 驗證發布認可，方法是與特定架構的測量結果進行比較。

  • 確認 UEFI 二進位檔是由 Google 背書且未經修改。

除了遠端驗證外，您也可以將韌體驗證納入安全政策，判斷機密 VM 執行個體是否應有權存取受保護的資源。

擷取發布認可

您可以使用 Google 工具或自己的工具，擷取發布認可。

使用 Google 工具擷取發布簽署

如要使用 Google 工具，從 AMD SEV-SNP 或 Intel TDX Confidential VM 執行個體擷取啟動認可：

  1. 使用 SSH 連線至機密 VM 執行個體。

  2. 使用 Go-TPM-Tools (AMD SEV-SNP 或 Intel TDX) 或 SEV Guest (AMD SEV-SNP) 擷取認證報告和相關聯的憑證。

  3. 使用 gcetcbendorsement 從認證中擷取 UEFI 認可，並儲存在檔案中。 接著，您可以確認認可是否源自 Google，以及認證報告的評估結果是否屬於已簽署的評估結果。

使用自有工具擷取發布認可

如要使用自己的工具擷取發布認可，請完成下列操作說明。

AMD SEV-SNP

  1. 提出擴充的訪客要求，向 AMD 安全處理器擷取認證報告。

  2. 擷取儲存在偏移 90h 的 384 位元報表評估值。詳情請參閱「SEV Secure Nested Paging Firmware ABI Specification」第 7.3 章表 22。

  3. 使用 384 位元測量結果，從下列 Cloud Storage bucket 下載序列化參照發布認可：

    gs://gce_tcb_integrity/ovmf_x64_csm/sevsnp/384_BIT_MEASUREMENT.binarypb

  4. 使用 protoc 等工具，透過 VMLaunchEndorsement 訊息定義解碼 BINARYPB 檔案：

    message VMLaunchEndorsement {
  bytes serialized_uefi_golden = 1;
  bytes signature = 2;
}

其他發布認可地點

啟動認可也可能透過 AMD SEV-SNP 憑證傳送機制，在 GUID 表格中提供。其 GUID 如下：

9f4116cd-c503-4f5a-8f6f-fb68882f4ce2

如需 GUID 表格的相關文件，請參閱 AMD Guest-Hypervisor Communication Block 規格的 SNP Extended Guest Request 一節。

在 Trusted Computing Group PC 用戶端事件記錄中，可能也會有啟動認可的本機和遠端位置參照，這類記錄位於 SP800-155 事件中，如 TCG PC Client Platform Firmware Profile Specification Version 1.06 Revision 52 所述。

Intel TDX

  1. 建立 configfs-tsm 報表項目：

    name=/sys/kernel/config/tsm/report/report0
mkdir "${name}"
cat "${your_nonce_file}" > "${name}/inblob"
cat "${name}/outblob" > "${your_quote_destination}"

  2. 擷取儲存在偏移 b8h 的報價 384 位元信任網域測量值 MRTD (適用於 TDX 模組 1.5)。詳情請參閱 TDX DCAP 引用程式庫。

  3. 使用 384 位元測量結果，從下列 Cloud Storage bucket 下載序列化參照發布認可：

    gs://gce_tcb_integrity/ovmf_x64_csm/tdx/384_BIT_MEASUREMENT.binarypb

  4. 使用 protoc 等工具，透過 VMLaunchEndorsement 訊息定義解碼啟動認可：

    message VMLaunchEndorsement {
  bytes serialized_uefi_golden = 1;
  bytes signature = 2;
}

推出推薦範例

以下是啟動認可的參考範例：

VMLaunchEndorsement:
serialized_uefi_golden: "SERIALIZED_BYTES"
signature: "LAUNCH_ENDORSEMENT_SIGNATURE_BYTES"

UEFI 黃金測量

serialized_uefi_golden 欄位包含多個值的序列化版本，定義方式如下列通訊協定緩衝區所示：

message VMGoldenMeasurement {
  google.protobuf.Timestamp timestamp = 1;

  // The changelist number this UEFI was built from.
  uint64 cl_spec = 2;

  // DER format certificate of the key that signed this document.
  bytes cert = 4;

  // SHA-384 digest of the UEFI binary without TEE-specifics about launch.
  bytes digest = 5;

  // A sequence of PEM-encoded certificates of keys used in cert in Root ...
  // final intermediate order. The last certificate will have a signed cert.
  bytes ca_bundle = 6;

  VMSevSnp sev_snp = 7;

  VMTdx tdx = 8;
}

VMGoldenMeasurement 訊息中的 VMSevSnp 欄位是由下列通訊協定緩衝區定義：

message VMSevSnp {
  // The Google-reported security version number of this UEFI on SEV-SNP.
  uint32 svn = 1;

  // Expected MEASUREMENT report field values given [key]-many VMSAs at launch.
  map<uint32, bytes> measurements = 2; // bytes size 48

  // A UUID that Google uses for its CVM UEFIs
  bytes family_id = 3; // size 16

  // A UUID to name this specific release of the UEFI image. This is randomly
  // generated with each build.
  bytes image_id = 4; // size 16

  // The launch policy that verifiers should expect with this UEFI.
  uint64 policy = 5;

  // Optional. PEM-encoded certs for Identity..Author..Root. If a singleton,
  // only an Id-key is used.
  bytes ca_bundle = 6;
}

VMGoldenMeasurement 訊息中的 VMTdx 欄位是由下列通訊協定緩衝區定義：

message VMTdx {
  message Measurement {
    // The amount of RAM in GiB provided to the VM. This is relevant to the
    // construction of the measured TDHOB page that includes memory region
    // resource attributes.
    uint32 ram_gib = 1;
    // If true, EFI_UNACCEPTED_MEMORY not presented to guest.
    // All memory is accepted by the firmware. Relevant to the TDHOB page
    // since the resource attribute will include
    // EFI_RESOURCE_ATTRIBUTE_NEEDS_EARLY_ACCEPT.
    bool early_accept = 2;
    // The SHA-384 digest of the measurement operations for the VM at launch.
    bytes mrtd = 3;
  }
  // The Google-reported security version number of this UEFI on TDX.
  uint32 svn = 1;

  // Expected MRTD report field values given legal configurations.
  repeated Measurement measurements = 2;
}

如要使用自己的工具從 serialized_uefi_golden field 解壓縮及解碼這些值，請完成下列步驟：

  1. 分配新的 VMGoldenMeasurement 訊息。

  2. 將 serialized_uefi_golden 解除封送至訊息中。

或者，您也可以使用 gcetcbendorsement inspect 指令。

驗證發布認可

擷取啟動認可後，請驗證其簽章，然後視需要將其測量結果整合至安全政策。

驗證啟動認可簽章

您可以在信任錨點中加入 Compute Engine 機密運算信任運算基礎根金鑰憑證，驗證啟動認可的簽章。

啟動認可中的 VMGoldenMeasurement cert 欄位包含認可簽署金鑰公開金鑰的 DER 編碼 X.509v3 憑證。憑證是由根金鑰簽署。

您可以使用 gcetcbendorsement 顯示要執行哪些 openssl 指令來驗證簽章。舉例來說，如果您執行下列指令：

gcetcbendorsement verify --show LAUNCH_ENDORSEMENT_FILENAME.binarypb

您應該會收到類似以下範例的回覆：

openssl verify -CAfile <(openssl x509 -outform pem -in <(curl https://pki.goog/cloud_integrity/GCE-cc-tcb-root_1.crt)) \
    <(gcetcbendorsement inspect mask "LAUNCH_ENDORSEMENT_FILENAME.binarypb" --path=cert) \
    && \
    openssl pkeyutl -verify -pkeyopt rsa_padding_mode:pss \
        -pkeyopt rsa_pss_saltlen:32 -pkeyopt digest:sha256 -pkeyopt rsa_mgf1_md:sha256 -pubin \
        -inkey <(openssl x509 -pubkey -nocert -outform pem -in <(gcetcbendorsement inspect mask "LAUNCH_ENDORSEMENT_FILENAME.binarypb" --path=cert)) \
        -sigfile <(gcetcbendorsement inspect signature "LAUNCH_ENDORSEMENT_FILENAME.binarypb") -keyform PEM \
        -in <(openssl dgst -sha256 -binary <(gcetcbendorsement inspect payload "LAUNCH_ENDORSEMENT_FILENAME.binarypb")

如果您偏好使用自己的工具，可以將回覆中使用的 gcetcbendorsement inspect 指令，替換為您自己的通訊協定緩衝區擷取邏輯，用於已還原序列化 VMGoldenMeasurement 訊息的具名欄位。

驗證發布認可度評估結果

如要瞭解如何建立發布認可，請參閱 gce-tcb-verifier GitHub 存放區中的範例程式碼。您可以藉此瞭解 Google 如何從 UEFI 衍生出測量結果，並將相關測量結果納入安全政策。

舉例來說，您可以檢查韌體是否由韌體供應商簽署，並將架構專屬的測量結果與 VMLaunchEndorsement 訊息中提供的預先計算和簽署值進行比較。

雖然 Compute Engine 虛擬韌體會在重設時升級，但 PCR0 值不會變更。因此，簽署的評估結果中韌體的 svn 值，可能與測量至 PCR0 的 EV_S_CRTM_VERSION 不同，且韌體 Blob 摘要中的 EV_POST_CODE 事件會遭到略過。

驗證機密 VM 執行個體的 UEFI 二進位檔

  1. 從啟動認可中，將 serialized_uefi_golden 值解壓縮至 VMGoldenMeasurement。如需範例，請參閱以 Go 語言實作的範例，或endorsement.proto的 protoc 編譯，適用於支援通訊協定緩衝區的其他語言。

  2. 從 VMGoldenMeasurement 擷取摘要值。這是機密 VM 執行個體執行的 UEFI 二進位檔的 SHA-384 摘要。

  3. 使用 SHA-384 摘要，從下列 Cloud Storage 值區下載韌體二進位檔：

    gs://gce_tcb_integrity/ovmf_x64_csm/UEFI_BINARY_DIGEST.fd

  4. 如果網址有效且韌體已下載，請對韌體二進位檔執行 SHA-384 雜湊。如果與黃金測量結果的摘要相符，表示機密 VM 執行個體上執行的韌體未經修改。