Google Cloud 多方運算可為機構數位資產作業提供加密信任基礎架構。這項服務採用多單一租戶架構：您建立的每個執行個體都是專屬的隔離環境，有自己的網路輸入、儲存空間，以及硬體隔離運算，可用於加密編譯作業。
核心元件
每個 Multi-party Compute 運算執行個體都有三個主要元件。管理邏輯、要求轉送和密碼編譯運算會在不同的元件中執行。
MPC API
Multi-party Compute API 可管理下列資源：
- 使用者和團隊：在執行個體中擔任角色的身分，以及金鑰政策參照的簽署者群組。
- 金鑰環和金鑰政策：金鑰環會將金鑰分組，每個金鑰環都有金鑰政策，決定哪些團隊和使用者持有金鑰共用，以及必須有多少人核准簽章。
- TransactionPolicies：允許或禁止交易的 Cedar 規則，以及啟用或停用這些規則的政策作者核准。
- KeyLists：交易政策可參照的具名位址清單。
多方運算 API 會追蹤每筆交易的狀態和記錄的核准，並要求協調者安排金鑰產生和簽署作業。Spanner 會儲存要求和已簽署的核准。工作站 TEE 會先驗證核准簽章，再執行相關動作。
協調員
Multi-party Compute API 會將控制器連結至參與者 TEE：
- 金鑰共用探索和要求轉送：在金鑰產生期間，指派健康狀態良好的 TEE 保留新的金鑰共用，並在之後將要求轉送至適當的 TEE。
- Health：監控參與者 TEE 的健康狀態，並做為簽署要求的負載平衡器。
- 耐用性：需要更換金鑰共用時，管理重新共用。
協調者不會影響通訊協定的安全性。不含任何金鑰共用，也不會驗證核准或政策結果，這類驗證會在參與者 TEE 內進行。
Worker TEE
每個 Worker 都是在機密空間中執行的 TEE。Worker TEE 執行兩個部分：
- 加密引擎：保存金鑰共用，並與其他工作站 TEE 執行安全門檻金鑰產生和簽署通訊協定。
- 政策評估工具：根據一組有效的交易政策評估交易。
交易簽署流程
在多方運算中，您可以使用單一 API 呼叫 CreateTransaction 簽署酬載。交易政策評估、簽署者核准和門檻簽署，都從這項呼叫開始。以下是固定順序的流程：
- 要求。簽署者會對金鑰呼叫
CreateTransaction。要求會附上簽署者自己的核准，並以授權金鑰簽署。IAM 會檢查呼叫端是否能呼叫方法，並將要求記錄在 Cloud 稽核記錄中。 - 政策評估：系統會依據現行的一組交易政策評估交易。政策評估會為每項判定結果 (
APPROVED或REJECTED) 產生永久稽核記錄。 - 發起人核准。如果發起人的核准本身就符合金鑰政策的門檻，
CreateTransaction會立即前往步驟 5。 - 簽署者核准。如果只有發起人核准，未達金鑰政策門檻，交易就會進入
PENDING_AUTHORIZATION狀態。其他持有金鑰共用金鑰的簽署者，會使用RecordSignerDecision呼叫核准或拒絕交易，並各自使用授權金鑰簽署。交易會維持在PENDING_AUTHORIZATION狀態，直到有足夠的簽署者核准，達到金鑰政策的門檻為止。如果拒絕的簽署者人數過多，導致無法達到門檻，交易就會進入REJECTED狀態。如果未在到期前獲得足夠的核准，就會EXPIRED。 門檻簽章。達到門檻後，持有金鑰共用項目的受信任的執行環境 (TEE) 會執行門檻簽署通訊協定，並產生交易簽章。
參與者 TEE 使用金鑰共用前，會先檢查要求簽署的確切酬載是否已根據交易政策進行評估。任何用戶端、運算子或其他服務元件，都無法讓參與者簽署未經評估的酬載。
如要瞭解涉及的資源 (例如使用者、團隊、KeyRing 和交易政策)，請參閱「多方運算總覽」。
安全性模型
- 金鑰共用項目固定在 TEE。每個金鑰共用只能由建立它的 TEE 讀取。金鑰共用項絕不會以其他元件 (包括協調者、控制器或 Google 營運商) 可讀取的形式離開 TEE。
- 客戶金鑰保管。客戶在 Google Cloud 組織中使用 Cloud Key Management Service，隨時保有加密金鑰的完整保管權。
- 硬體隔離。參與者 TEE 會在 Confidential Space 上執行，並使用硬體記憶體加密功能，保護使用中的資料，避免主機和 Google 基礎架構存取。認證會將每個 TEE 繫結至經過驗證的容器映像檔。
- 端對端加密。Worker TEE 會直接透過端對端加密 gRPC 進行通訊。
- 簽署核准。簽署者、政策作者和管理員會使用授權金鑰簽署核准，而授權金鑰的私密部分絕不會離開他們。參與者 TEE 會先驗證這些簽章，再簽署交易、接受交易政策，或接受管理員/政策作者角色變更。這可防止交易遭到竄改，並留下永久的稽核記錄。
- 政策作者法定人數。新的交易政策或停用政策的要求，必須經過指定數量的政策作者核准，才會生效。
- 管理員仲裁。授予或移除管理員或政策作者角色時，必須獲得指定數量的管理員核准，才會生效。詳情請參閱「管理員核准角色變更」。
道路圖
我們預計在日後推出的版本中提供下列功能：
- 外部 TEE：金鑰共用項目保存在客戶於 Google Cloud外部執行的 TEE 中，例如 AWS Nitro Enclaves。
- 行動金鑰共用：使用者行動裝置上的金鑰共用。
- 重新分享：變更現有金鑰的持有人，或更換遺失的持有人，但不變更金鑰。
系統屬性
多方運算信任基礎架構會維護下列系統屬性。
安全性 (密碼編譯環境中的健全性)
在任何情況下，系統都不得以任何不允許的方式運作。舉例來說，根據 DKLS23 協定，任何少於 k 個參與者的群組都無法偽造簽章。確切的安全性定義已在文獻中的通用可組合架構中正式化。
在實際實作密碼編譯系統時，請務必避免依賴會破壞安全性屬性的假設。舉例來說，通訊協定中的各方必須獨立：他們遭受入侵的可能性應獨立。
為確保這項屬性，多方運算會在經過認證的 TEE 中執行每位參與者，且每個金鑰共用都會固定在建立該金鑰的 TEE。如果通訊協定中的某個參與者遭到入侵，其他參與者不會受到影響。
多方運算的學術文獻幾乎完全著重於健全性，並假設一個簡單的世界，其中參與者集合不可變、所有參與者一律可用，且參與者使用理想且一律可用的點對點驗證通道進行通訊。如果是實際產品，則必須解決其他幾項問題。
Liveness
系統最終會取得進展。最常見的活躍性屬性是沒有死結，這在 DKLS23 通訊協定中成立。只要持有門檻金鑰片段的 TEE 數量足以達到金鑰政策的門檻，就能使用門檻金鑰簽署。舉例來說，如果使用 2-of-3 金鑰，3 個金鑰片段中只要有 2 個就能完成簽署。
耐用性
如果參與者永久失敗，就必須更換，否則系統最終會永久遺失共用密鑰。舉例來說，如果硬體故障，在該硬體上執行的參與者狀態就會遺失。由於金鑰共用項目會固定在 TEE，協調者會追蹤哪些 TEE 含有各個金鑰的共用項目。在 v1beta 中，只要金鑰的共用數量足以達到金鑰政策的門檻，金鑰就能繼續使用。如要取代遺失的共用項目，必須重新共用，這項功能預計在日後版本推出。
設定變更
無論是硬體故障 (TEE 遺失資料) 或組織異動 (新員工加入通訊協定並取得密鑰的一部分)，都必須變更金鑰持有者。多方運算計畫透過安全重新分享通訊協定支援這項功能，該通訊協定可保留 DKLS23 的健全性屬性：參與重新分享的惡意新方最多會洩漏一個秘密共用，與任何其他惡意方相同。