遠端認證總覽

遠端驗證程序會驗證 Confidential VM 執行個體的 ID 是否合法,以及是否處於預期狀態。在授予系統受保護資源的存取權之前,您可以使用認證評估系統的可靠性。

認證方和模型

認證程序通常有三方參與:

  • 認證者。On Google Cloud:這是機密 VM 執行個體上的工作負載,需要存取受保護的資源。為提高信任度,確保機密 VM 執行個體未遭入侵,且並非冒名者,VM 及其主機會在啟動程序期間,測量 VM 的虛擬硬體和軟體狀態。

  • 驗證人員。驗證者是外部系統,可驗證機密 VM 執行個體提供的證據,並根據驗證政策進行檢查,確保 VM 設定符合預期。如果證據通過必要檢查,驗證者會傳回證據的簽署版本,也就是認證結果

    驗證者可以是預先存在的服務,例如 Google Cloud AttestationIntel Trust Authority,也可以是您自行建構的服務。

  • 依附方。信賴方會控管驗證者需要的受保護資源存取權。收到驗證結果後,信賴方會根據存取政策檢查證據中的值。如果值相符,驗證者就能存取資源。

    在 Google Cloud 依賴方通常是工作負載身分集區,驗證者會新增為 OpenID Connect (OIDC) 提供者。

各方互動方式取決於架構遵循的認證模型。遠端認證程序 (RATS) 架構 RFC 定義了兩種主要的認證模型:護照模型和背景檢查模型。兩者的主要差異在於哪一方擁有驗證者的已驗證身分:驗證者或信賴方。

護照型號

護照模型會透過下列程序確認認證者的身分,並授予所要求資源的存取權:

  1. 認證者會將身分證明傳送給驗證者。

  2. 如果驗證者認為證據可信,就會將驗證結果傳送給驗證對象,結果可能以驗證權杖的形式呈現。

  3. 驗證者會將驗證結果傳送給信任方。

  4. 驗證方會檢查認證結果是否符合特定條件。如果結果符合預期,信賴方會允許驗證者存取所要求的資源。

在護照模型中,驗證者和信賴方必須就驗證結果的呈現方式達成共識,也就是必須同意使用驗證器。

認證護照模型

背景調查模型

背景調查模型會透過下列程序確認認證者的身分,並授予所要求資源的存取權:

  1. 驗證者會將身分證明傳送給信賴憑證者。

  2. 依賴方會將證據轉寄給驗證者。

  3. 如果驗證者認為證據可信,就會將認證結果 (通常是認證權杖) 傳送給信賴方。

  4. 驗證方會檢查認證結果是否符合特定條件。如果結果符合預期,信賴方會允許驗證者存取所要求的資源。

認證背景調查模型

採用背景檢查模型時,信賴方會決定所需的認證證據,並選擇驗證者。

驗證者架構和證據

本節說明機密 VM 執行個體如何以驗證者的身分,提供身分防竄改證據。

信任根

在受信任的執行環境 (TEE) (例如 Confidential VM 執行個體) 中,信任根是基礎安全元件,其他信任關係都是從這裡建立。信任根可提供加密功能、防竄改,且無法由主機作業系統修改。

信任根位於 TEE 內的信任範圍,也就是可信任運算基礎 (TCB)。TCB 是指客體 VM 和主機上的一組硬體和軟體,負責環境隔離 (透過記憶體加密和管理程序隔離等機制) 和採取測量措施,以維護環境完整性等工作。

TEE 支援測量、儲存和回報函式的信任根:

  • 評估信任根:這段程式碼會啟動 TEE 啟動程序的評估作業。

  • 儲存空間的信任根會以測量暫存器的形式,提供受保護的記憶體來進行測量。

  • 「報表信任根」可為評估鏈提供完整性和真實性保護。這項服務會從儲存空間的信任根擷取測量結果,並將這些結果綁定至稱為「引號」或「驗證報告」的簽署證據套件。這個套件會使用 TEE 駐留的驗證金鑰簽署,並可包含加密 Nonce,確保證據是最新版本,且可抵禦重播攻擊。

以下資訊詳細說明不同機密運算技術的信任根方法。

AMD SEV

搭載 AMD SEV 的機密 VM 執行個體會使用Shielded VM vTPM 型測量值,驗證環境和設定。AMD 安全處理器和 AMD SEV 僅用於記憶體加密。

信任根如下:

  • 測量信任根:VM 執行個體韌體

  • 儲存空間的信任根:Shielded VM vTPM

  • 報表信任根:Shielded VM vTPM,使用私密認證金鑰簽署認證報表

SEV 信任根

如要瞭解 Shielded VM vTPM 中記錄了哪些測量值,請參閱 vTPM 平台設定暫存器

AMD SEV-SNP

搭載 AMD SEV-SNP 的機密 VM 執行個體主要會透過 AMD 安全處理器,驗證環境和設定,而 AMD 安全處理器會處理初始啟動測量作業。

針對系統啟動載入程式、核心和使用者空間測量,可以使用Shielded VM vTPM 型測量。

信任根如下:

  • 評估的信任根:AMD 安全處理器 + VM 執行個體韌體

  • 儲存空間的信任根:AMD 安全處理器 + Shielded VM vTPM

  • 回報的信任根

    • 初始啟動測量:AMD 安全處理器,使用晶片常駐版本晶片認可金鑰 (VCEK) 簽署認證報告

    • 系統啟動載入程式、核心和使用者空間測量:Shielded VM vTPM

SNP 信任根

如要瞭解 AMD 安全處理器記錄的測量值,請參閱 AMD SEV-SNP 測量值暫存器

如要瞭解 Shielded VM vTPM 中記錄了哪些測量值,請參閱 vTPM 平台設定暫存器

Intel TDX

搭載 Intel TDX 的機密 VM 執行個體會透過 Intel TDX 模組,驗證環境和設定。Intel TDX 模組會在獨立的信任網域中測量 VM 客戶端的韌體,並將這些測量結果儲存在信任網域測量 (MRTD) 中。開機鏈中的後續測量結果會測量到執行階段測量暫存器 (RTMR)。

信任根如下:

  • 評估的信任根:Intel TDX 模組

  • 儲存空間的信任根:信任網域的評估 (MRTD) 和執行階段評估暫存器 (RTMR)

  • 報告的信任根:Intel TDX 模組中的信任網域引用 Enclave (TDQE),可產生認證金鑰來簽署認證引用

TDX 信任根

如要瞭解 TDX 評估暫存器中記錄了哪些評估結果,請參閱「Intel TDX 評估暫存器」。

軟體和硬體驗證

Google Cloud 中的機密運算技術可視為軟體或硬體驗證,具體取決於信任根。

軟體認證是指信任根是以軟體為基礎:虛擬韌體是測量的信任根,而儲存空間的信任根則是 Shielded VM vTPM。vTPM 由主機的 Hypervisor 管理,韌體則由客體 VM 管理。在 Google Cloud上,這兩個元件都由 Google 控制。

硬體驗證是指測量作業由服務供應商控管範圍外的專屬硬體管理及保護。在 Google Cloud,這項硬體包括 AMD 安全處理器 (僅用於啟動測量) 和 Intel TDX 模組。

硬體驗證會從測量和儲存的信任根中移除服務供應商的管理程序,並在專用硬體中隔離測量結果。即使惡意行為人掌控主機的 Hypervisor,也無法偽造認證報告或引文,因為他們無權修改專用硬體的暫存器。

Google Cloud 提供的機密運算技術可分為以下幾類:

  • AMD SEV:軟體經過認證。虛擬韌體會自行測量,測量結果會儲存在 Shielded VM vTPM 中。

  • AMD SEV-SNP:混合式硬體和軟體經過認證。啟動測量 (包括虛擬韌體的測量) 會由 AMD 安全處理器記錄及儲存,因此可進行硬體驗證。開機載入程式、核心和使用者空間的測量結果會儲存在 Shielded VM vTPM 中,因此這些結果會經過軟體認證。您可以選擇只使用硬體認證的測量結果、軟體認證的測量結果,或同時使用兩者。

  • Intel TDX:硬體認證。TDX 模組會測量虛擬韌體,所有測量結果都會儲存在 Intel TDX 模組中。受防護的 VM vTPM 仍是系統的一部分,但除非您執行需要 TPM 介面的軟體,否則 vTPM 不屬於 TCB。

評估登錄

Confidential VM 的信任根可提供受防護的防竄改儲存空間,以測量暫存器 (MR) 的形式儲存測量結果。這些測量暫存器的名稱會因使用的機密運算技術而異:

  • AMD SEV:平台設定暫存器 (PCR)。這些項目位於 Shielded VM vTPM 內。

    Shielded VM vTPM 使用三組 PCR,儲存相同的測量結果,但會以不同演算法進行雜湊處理:SHA-1、SHA-256 和 SHA-384。

  • AMD SEV-SNP:啟動 MEASUREMENT 註冊。這項技術位於 AMD 安全處理器內。

    Shielded VM vTPM 內的 PCR 也用於儲存開機載入程式、核心和使用者空間的測量值。

  • Intel TDX:信任網域的建構時間測量 (MRTD) 和執行階段測量暫存器 (RTMR)。

    對於需要 TPM 介面的軟體,Shielded VM vTPM PCR 也提供測量結果。

只有信任根才能變更暫存器值。評估記錄通常會保存單一加密摘要,代表單一事件或一組事件。

如果是單一事件,例如 VM 的啟動評估或建構時間評估,信任根通常會直接寫入暫存器,並在 TEE 的其餘生命週期內,讓暫存器保持不變。

開機鏈中稍後載入的元件 (例如系統啟動載入程式、核心和使用者空間) 可能會將多個事件的測量結果記錄到單一暫存器。如要儲存事件集的測量結果,測量暫存器會公開 extend 指令,將現有暫存器值與新的事件摘要串連、對串連值進行雜湊處理,然後儲存產生的摘要。這項程序可用下列公式表示:

\(MR_{new}=hash(MR_{old}\;∥\;hash(measured\;data))\)

由於雜湊函式是單向的,因此如果未以相同順序提供相同評估結果,就難以複製相同的評估結果登錄值。雖然這項屬性有助於判斷 VM 完整性,但根據特定測量暫存器值制定政策可能會有困難。這是因為測量輸入內容的微小變化 (例如軟體或韌體更新,或是測量順序變更) 會導致不同的暫存器值,因此根據這些值制定政策可能會不穩定,並增加維護負擔。如需根據測量暫存器值制定政策,請嘗試選取較穩定的暫存器值,例如 vTPM 上的 PCR 0 或 PCR 7

事件記錄

測量結果寫入或擴充至測量暫存器時,系統會將一或多個記錄寫入客層作業系統的檔案系統,記錄發生的測量事件。

這些事件記錄的用途如下:

  • 驗證者可以重播事件記錄,使用模擬的測量暫存器逐步執行 Confidential VM 執行個體的測量程序。如果驗證器計算出的最終摘要與驗證者回報的最終摘要相符,則可提高信任度,確保事件記錄和機密 VM 執行個體的啟動程序未遭竄改。

  • 重播後,驗證者可以剖析事件記錄,根據認證政策比較證據。驗證者可能會要求認證者通過特定條件,例如啟用安全啟動或使用特定機密運算技術,才會傳回成功的認證結果。

事件記錄會儲存在訪客作業系統的檔案系統中,位置如下:

機密運算技術 要驗證的 MR 記錄類型 用於事件記錄重播的客體 OS 路徑
AMD SEV、AMD SEV-SNP、Intel TDX vTPM 平台設定暫存器 (PCR) Trusted Computing Group (TCG) 事件記錄 /sys/kernel/security/tpm0/binary_bios_measurements
Intel TDX RTMR[0]RTMR[1]RTMR[2] 機密運算事件記錄 (CCEL) /sys/firmware/acpi/tables/data/CCEL

進一步瞭解事件記錄重播和剖析

報價和認證報告

報告的信任根會使用認證金鑰簽署測量值,為儲存在測量記錄中的摘要提供完整性和真實性保護。產生的二進位 BLOB 稱為 vTPM 的 PCR 引用、AMD SEV-SNP 的認證報告,以及 Intel TDX 的引用

不同機密運算技術的二進位 BLOB 內容有所不同:

  • AMD SEV:Shielded VM vTPM 會從其中一個 PCR 庫 (SHA-1、SHA-256 或 SHA-384) 讀取值,依數值順序串連這些值,然後使用與 PCR 庫相同的雜湊演算法雜湊處理結果,建立摘要摘要。這個摘要連同驗證器提供的選用 Nonce,會放入 TPMS_ATTEST 結構中,並由 vTPM 的私密驗證金鑰簽署,以建立 PCR 引用。

    如要瞭解 TPMS_ATTEST 結構,請參閱「Trusted Platform Module Library, Part 2: Structures (PDF)」。

  • AMD SEV-SNP:AMD 安全處理器會根據初始啟動測量結果產生 SHA-384 摘要,這些測量結果是在機密 VM 執行個體 UEFI 執行前取得。

    這項摘要、其他 VM 資料,以及驗證器提供的選用隨機值,都會放入 ATTESTATION_REPORT 結構中,並由 AMD 安全處理器的版本晶片認可金鑰 (VCEK) 簽署,以建立認證報告。

    如要瞭解 ATTESTATION_REPORT 結構的詳細資料,請參閱「SEV Secure Nested Paging Firmware ABI Specification」(PDF)

  • Intel TDX:TDX 模組會將 MRTD 和 RTMR 值、其他 VM 資料,以及驗證器提供的選用隨機數放入 TDREPORT_STRUCT 結構。

    建立報價的程序包含多個步驟。首先,CPU 內的佈建認證 Enclave 會從熔入 CPU 的密碼編譯密鑰衍生佈建認證金鑰 (PCK)。接著,CPU 內的 Quoting Enclave 會產生私密認證金鑰,並以佈建認證金鑰簽署。然後使用私密驗證金鑰簽署 TDREPORT_STRUCT,建立報價。

    如要瞭解 TDREPORT_STRUCT 結構,請參閱「Intel Trust Domain Extensions (Intel TDX) Module Base Architecture Specification (PDF)」。

代言

不同類型的認可會做為證據,證明 Confidential VM 執行個體是在預期硬體、vTPM 和韌體設定上執行。

憑證

X.509 v3 憑證可用來證明主機使用的是正版 AMD 或 Intel 硬體,或是 Confidential VM 執行個體使用的是 Shielded VM vTPM。

各項機密運算技術的憑證名稱如下:

  • AMD SEV:認證金鑰 (AK) 憑證

  • AMD SEV-SNP:版本晶片認可金鑰 (VCEK) 憑證

  • Intel TDX:佈建供應認證金鑰 (PCK) 憑證

如果是 AMD SEV,憑證會驗證 Shielded VM vTPM。主機會向 Google 的憑證授權單位伺服器提出要求,並直接將憑證自動佈建至 Confidential VM 執行個體的 vTPM 非揮發性儲存空間。訪客可使用 go-tpm-tools 等軟體向 vTPM 要求,個別擷取這項憑證。

如果是 AMD SEV-SNP 和 Intel TDX,主機會從 CPU 擷取硬體證據,並提供給 Google 管理的快取。這個快取會儲存先前從 AMD 金鑰發布服務和 Intel 佈建憑證服務提取的憑證。成功出示硬體證明後,憑證會快取至主機的磁碟,並與訪客共用。訪客可以個別擷取這些憑證,以便使用 go-sev-guestgo-tdx-guest 等軟體驗證硬體。

憑證包含下列資訊:

  • 憑證頒發機構身分,可以是 AMD、Google 或 Intel。

  • 公開驗證金鑰,用於驗證 PCR 引號 (vTPM)、驗證報告 (SEV-SNP) 和驗證引號 (Intel TDX) 的簽章。

  • 僅限硬體驗證:主機韌體執行的硬體微碼和韌體 TCB 版本。

  • 僅限硬體證明:證明憑證與特定實體處理器繫結的證據,已使用處理器中的私密金鑰簽署,且無法外洩。如果是 AMD SEV-SNP,這項證據就是平台 ID。 如果是 Intel TDX,證據就是平台資訊清單

韌體

如要進行硬體驗證,韌體啟動認可可直接從 VM 執行個體取得,或從線上下載。啟動認可為經過簽署的二進位序列化通訊協定緩衝區,用於確認機密 VM 執行個體的虛擬韌體未遭竄改。

VM 啟動時,AMD 安全處理器或 Intel TDX 模組會先雜湊處理韌體二進位檔,再執行該檔案。這個 SHA-384 摘要會儲存在 AMD SEV-SNP 的 MEASUREMENT 欄位中,以及 Intel TDX 的 MRTD 中。

您可以使用該摘要從 Google 下載啟動認可,並使用 gcetcbendorsement 等工具驗證簽章是否源自 Google,然後驗證韌體測量值和認可中記錄的 SHA-384 摘要是否相符。

除了韌體驗證之外,您也可以在啟動認可中使用特定屬性來強制執行存取政策,例如最低安全版本號碼 (SVN)、vCPU 數量、記憶體設定或 UEFI 的系列 ID。

詳情請參閱驗證機密 VM 執行個體的韌體

重新播放及剖析驗證器事件記錄

除了直接驗證認證者提供的證據,驗證者也可以重播認證者提供的事件記錄,根據測量暫存器值驗證完整性。

為此,驗證者會建立每個測量暫存器的模擬版本,以做為認證政策的一部分進行檢查。然後使用事件記錄檔中的事件,填入模擬的暫存器。如果模擬暫存器的最終值與對等實際測量暫存器中儲存的值相符,則可提高信任度,確保事件記錄和 Confidential VM 執行個體的啟動程序都未遭到竄改。

以這種方式驗證記錄後,即可剖析個別測量結果,供驗證者或信賴方做為政策依據。

建構專屬的事件記錄重播和剖析工具

雖然您可以自行建構軟體來重播及剖析事件記錄檔,但我們建議您使用 go-eventlog 等成熟的軟體,避免常見的陷阱,例如 Trusted Computing Group 和 機密運算 Event Log 格式的 EventType 安全漏洞

如果您仍想自行建構重播和剖析軟體,下列以 vTPM 為基礎的範例有助於初步瞭解,但您應根據自己的 Confidential VM 執行個體產生的事件記錄檔,實作相關功能。

以下範例選取了 Ubuntu 24.04 vTPM 事件記錄中的事件,這些事件會計入 PCR 0。事件記錄檔已使用下列指令,透過 tpm2_eventlog 從二進位轉換為 ASCII:

sudo tpm2_eventlog /sys/kernel/security/tpm0/binary_bios_measurements

記錄中的 PCR 0 事件如下:

---
version: 1
events:
- EventNum: 0
  PCRIndex: 0
  EventType: EV_NO_ACTION
  Digest: "0000000000000000000000000000000000000000"
  EventSize: 41
  SpecID:
  - Signature: Spec ID Event03
    platformClass: 0
    specVersionMinor: 0
    specVersionMajor: 2
    specErrata: 0
    uintnSize: 2
    numberOfAlgorithms: 3
    Algorithms:
    - Algorithm[0]:
      algorithmId: sha1
      digestSize: 20
    - Algorithm[1]:
      algorithmId: sha256
      digestSize: 32
    - Algorithm[2]:
      algorithmId: sha384
      digestSize: 48
    vendorInfoSize: 0
- EventNum: 1
  PCRIndex: 0
  EventType: EV_NO_ACTION
  DigestCount: 3
  Digests:
  - AlgorithmId: sha1
    Digest: "0000000000000000000000000000000000000000"
  - AlgorithmId: sha256
    Digest: "0000000000000000000000000000000000000000000000000000000000000000"
  - AlgorithmId: sha384
    Digest: "000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000"
  EventSize: 160
  Event: "53503830302d313535204576656e7433792b000056aca511a145224ba54128607dac543b0d476f6f676c652c20496e632e0016476f6f676c6520436f6d7075746520456e67696e650001000d476f6f676c652c20496e632e00792b000004322e37000300000028000000468e85a27fa36a458c790c1fe48b65ff4600690072006d007700610072006500520049004d0000000000000000000000000000000000"
- EventNum: 2
  PCRIndex: 0
  EventType: EV_NO_ACTION
  DigestCount: 3
  Digests:
  - AlgorithmId: sha1
    Digest: "0000000000000000000000000000000000000000"
  - AlgorithmId: sha256
    Digest: "0000000000000000000000000000000000000000000000000000000000000000"
  - AlgorithmId: sha384
    Digest: "000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000"
  EventSize: 288
  Event: "53503830302d313535204576656e7433792b000056aca511a145224ba54128607dac543b0d476f6f676c652c20496e632e0016476f6f676c6520436f6d7075746520456e67696e650001000d476f6f676c652c20496e632e00792b000004322e370001000000a800000068747470733a2f2f73746f726167652e676f6f676c65617069732e636f6d2f6763655f7463625f696e746567726974792f6f766d665f7836345f63736d2f3834383939616564336339653837363735666638303966356665613365366638383733353533643166303130306464623961653333323639323832356163636537333866343562646563323738613430393864316332376534393533373134332e66642e7369676e65640000000000000000000000000000"
- EventNum: 3
  PCRIndex: 0
  EventType: EV_S_CRTM_VERSION
  DigestCount: 3
  Digests:
  - AlgorithmId: sha1
    Digest: "4031fe1129fb826f12dcad169992cca9f4f56aa3"
  - AlgorithmId: sha256
    Digest: "fa129a8f82b65bcbce8f9e8e5f6de509beff9b1df33714116bf918c5a3bba45d"
  - AlgorithmId: sha384
    Digest: "21d340a4a30bb8865486d150cd9ceb46100662b92f336d38b87d70b373ca15c4c60878336924baa818dc2aceaeb40ea6"
  EventSize: 48
  Event: "47004300450020005600690072007400750061006c0020004600690072006d0077006100720065002000760032000000"
- EventNum: 4
  PCRIndex: 0
  EventType: EV_NONHOST_INFO
  DigestCount: 3
  Digests:
  - AlgorithmId: sha1
    Digest: "2b106cedd1631981619790bbc1afaa80cc6ecd3e"
  - AlgorithmId: sha256
    Digest: "6ac9241348a80c5755a63bcd1865b9f6d5720f6e925dc869bb4694281c1510c5"
  - AlgorithmId: sha384
    Digest: "1167e32c3814259ea4809234cccfbd2785c32bde882833bb199d6df6bd989a49f45663e63ce11699fcd01250050f042c"
  EventSize: 32
  Event: "474345204e6f6e486f7374496e666f0001000000000000000000000000000000"
- EventNum: 19
  PCRIndex: 0
  EventType: EV_SEPARATOR
  DigestCount: 3
  Digests:
  - AlgorithmId: sha1
    Digest: "9069ca78e7450a285173431b3e52c5c25299e473"
  - AlgorithmId: sha256
    Digest: "df3f619804a92fdb4057192dc43dd748ea778adc52bc498ce80524c014b81119"
  - AlgorithmId: sha384
    Digest: "394341b7182cd227c5c6b07ef8000cdfd86136c4292b8e576573ad7ed9ae41019f5818b4b971c9effc60e1ad9f1289f0"
  EventSize: 4
  Event: "00000000"

重設機密 VM 執行個體時,PCR 會初始化為零。事件發生時,PCR 0 (PCRIndex: 0) 的 SHA-256 儲存區值會依下列方式變更 (EV_NO_ACTION 事件不會擴充暫存器):

  1. 暫存器的值會與指派給 PCR 0 的下一個事件 (EV_S_CRTM_VERSION) 的 SHA-256 摘要串連。串連結果會再次經過 SHA-256 雜湊處理,然後儲存在暫存器中。PCR 0 的 SHA-256 十六進位摘要現在為 0c3684a7571193d76a68e489ded7bf186fc2fb1efe0c6dd9ce147960bbc57365

  2. EV_NONHOST_INFO 事件也採用相同的程序。PCR 0 的 SHA-256 十六進位摘要現在為 509f590b71fb22c9a6eef647e3c23611d13e599a6e15fdbb4db56ea4c2cb878d

  3. EV_SEPARATOR 事件也採用相同程序,表示特定登錄的評估擴充功能已完成。EV_SEPARATOR 是 32 位元的零值 (\x00*4)。這會產生 PCR 0 的最終 SHA-256 十六進位摘要 a0b5ff3383a1116bd7dc6df177c0c2d433b9ee1813ea958fa5d166a202cb2a85

下列 Python 程式碼會建立模擬的 Compute Engine PCR 0,示範上述程序。由於程式碼是從已知值衍生事件摘要,因此並非事件記錄重播。建立適當的事件記錄重播時,您必須改為從 VM 執行個體的事件記錄讀取摘要。

import hashlib

def CalculatePCR0(version_num: int, mem_encrypt_enum: int):
  """Calculates the expected SHA-256 PCR 0 value given the
  Compute Engine firmware version and Confidential Computing technology
  that's in use.

  This code uses derived values for events instead of reading digests from an
  event log. It's intended to demonstrate how to simulate the extend function
  used in measurement registers.

  While the code should provide correct values for PCR 0 in
  Compute Engine VM instances, for other PCRs and true event log replay
  you should read in digests from an event log instead of using derived values.

  PCR 0 measurements include:
    * EV_S_CRTM_VERSION: The firmware version string, in UTF-16 little-endian
      form. This value remains stable as long as the firmware version stays the
      same.
    * EV_NONHOST_INFO: This value changes based on the Confidential Computing
      technology that's in use.
    * EV_SEPARATOR: A 32-bit zero value to split UEFI and bootloader
      measurements.

  Args:
    version_num (int): The Compute Engine firmware version number. The
      value is 2.

    mem_encrypt_enum (int): The type of Confidential Computing technology used
      on the VM:

      0: None
      1: AMD SEV
      2: AMD SEV-ES
      3: Intel TDX
      4: AMD SEV-SNP

  Returns:
    A hexstring representing the expected PCR 0 digest.
  """
  # Create a hash object to act as PCR 0, and initialize it with zeroes.
  h = hashlib.sha256()
  h.update(b'\x00' * h.digest_size)

  # Update the hash object with the EV_S_CRTM_VERSION event, with a hard-coded
  # firmware version `version_num`.
  #
  # This code uses derived values for events. To use the digest supplied in an
  # event log for event log replay, you need to read in the event digest, and
  # then convert it to bytes before updating the hash object, similar to the
  # following:
  #
  # h.update(bytes.fromhex('fa129a8f82b65bcbce8f9e8e5f6de509beff9b1df33714116bf918c5a3bba45d'))
  #
  h.update(
          hashlib.sha256(
              # The firmware uses UCS-2 encoding, so we match it by encoding to
              # the equivalent UTF-16 little-endian. An extra null byte is
              # needed to match the required byte length.
              f'GCE Virtual Firmware v{version_num}\x00'.encode('utf-16-le')).digest()
          )

  # Create a new hash object to act as PCR 0 and update it with the previous
  # hash object's digest. This simulates the first part of the register EXTEND
  # function.
  h2 = hashlib.sha256()

  h2.update(h.digest())

  # Update the hash object with the EV_NONHOST_INFO event, which includes
  # `mem_encrypt_enum`, the Confidential Computing technology in use. Performing
  # this update completes the simulated EXTEND function.

  h2.update(
          hashlib.sha256(
              b'GCE NonHostInfo\x00'
              + (mem_encrypt_enum).to_bytes(1, byteorder='little')
              + (b'\x00' * 15)
              ).digest()
          )

  # Create a new hash object to act as PCR 0 and update it with the previous
  # hash object's digest. This simulates the first part of the register EXTEND
  # function.
  h3 = hashlib.sha256()
  h3.update(h2.digest())

  # Update the hash object with the EV_SEPARATOR event. Performing this update
  # completes the simulated EXTEND function.
  h3.update(hashlib.sha256(b'\x00' * 4).digest())

  # There are more PCR 0 events, but they're all `EV_NO_ACTION` and don't
  # affect the register value. Return the final simulated register value.
  digest = h3.hexdigest()
  return digest

print('\nPCR 0 simulation')
print('\nConfidential Computing type\tDigest')
# Compute Engine firmware version 2, no Confidential Computing
# Expected hexdigest: d0c70a9310cd0b55767084333022ce53f42befbb69c059ee6c0a32766f160783
print(f'None\t\t\t\t{CalculatePCR0(2, 0)}')

# Compute Engine firmware version 2, AMD SEV
# Expected hexdigest: a0b5ff3383a1116bd7dc6df177c0c2d433b9ee1813ea958fa5d166a202cb2a85
print(f'AMD SEV\t\t\t\t{CalculatePCR0(2, 1)}')

# Compute Engine firmware version 2, AMD SEV-SNP
# Expected hexdigest: 50597a27846e91d025eef597abbc89f72bff9af849094db97b0684d8bc4c515e
print(f'AMD SEV-SNP\t\t\t{CalculatePCR0(2, 4)}')

# Compute Engine firmware version 2, Intel TDX
# Expected hexdigest: 0cca9ec161b09288802e5a112255d21340ed5b797f5fe29cecccfd8f67b9f802
print(f'Intel TDX\t\t\t{CalculatePCR0(2, 3)}')

print()

信賴方設定

視使用護照模型背景檢查模型而定,信賴方會收到來自認證者或驗證者的認證結果。

然後,信賴方會驗證認證結果中收到的聲明是否與預期值相符。如果值相符,信賴方會允許驗證者以本機身分存取資源。

在 Google Cloud 中設定信賴方的常見模式是使用工作負載身分聯盟,並將驗證者視為聯合身分:

  1. 將驗證者新增為工作負載身分集區的 OIDC 提供者。完成這項操作後,附加至機密 VM 執行個體工作負載的服務帳戶,就能做為聯合身分存取所需資源。

  2. 定義驗證者認證聲明必須相符的值,驗證者才能取得資源存取權。

    在 Google Cloud中,這項作業涉及將認證權杖附加資訊對應至屬性,以便身分與存取權管理 (IAM) 將這些屬性視為條件,而聯合身分必須通過這些條件,才能以主體身分進行驗證。

    然後,在所需資源的允許政策中,為驗證者的同盟主體新增角色繫結,即可授予驗證者直接存取資源的權限。對於不支援聯合身分的服務,您可以透過服務帳戶模擬功能授予資源存取權。

除了 Workload Identity Federation,您也可以編寫程式碼,直接剖析驗證權杖的權杖附加資訊。如需範例,請參閱機密虛擬機器的 vTPM 遠端認證