Google Cloud 多方计算为机构数字资产运营提供加密信任基础设施。它采用多单租户架构：您创建的每个实例都是一个专用、隔离的环境，拥有自己的网络入站流量、自己的存储空间以及自己的硬件隔离计算，用于执行加密操作。
核心组件
每个多方计算实例都有三个主要组件。治理逻辑、请求路由和加密计算在不同的组件中运行。
MPC API
Multi-party Compute API 管理以下资源：
- 用户和团队：在实例中拥有角色的身份，以及密钥政策所引用的签名者群组。
- KeyRings 和 KeyPolicies：对密钥进行分组的 KeyRings，每个 KeyRing 都有一个密钥政策，用于决定哪些团队和用户持有密钥共享，以及其中有多少人必须批准签名。
- TransactionPolicies：允许或禁止交易的 Cedar 规则，以及启用或停用这些规则的政策作者审批。
- KeyLists：事务政策可以引用的已命名地址列表。
多方计算 API 会跟踪每笔交易的状态和记录的审批情况，并要求协调器编排密钥生成和签名。Spanner 会存储请求和已签名的批准。工作器 TEE 会先自行验证批准签名，然后再执行相应操作。
协调者
多方计算 API 用于将控制器连接到参与者 TEE：
- 密钥共享发现和请求路由：在密钥生成期间，它会分配运行状况良好的 TEE 来保存新的密钥共享，随后将请求路由到适当的 TEE。
- 健康状况：监控参与者 TEE 的健康状况，并充当签名请求的负载均衡器。
- 耐用性：当需要替换密钥共享时，它会管理重新共享。
协调器不会影响协议的安全性。它不持有任何密钥共享，也不验证审批或政策结果；这些验证在参与者 TEE 内部进行。
工作器 TEE
每个工作器都是一个在 Confidential Space 上运行的 TEE。工作器 TEE 运行两个部分：
- 加密引擎：保存密钥共享，并与其他工作器 TEE 一起运行安全阈值密钥生成和签名协议。
- 政策评估器：根据一组有效的交易政策评估交易。
交易签名流程
在多方计算中，您只需调用一个 API (CreateTransaction) 即可对载荷进行签名。交易政策评估、签名者审批和阈值签名都从该调用开始。以下是固定顺序的流程：
- 请求。签名者对密钥调用
CreateTransaction。该请求带有签名者自己的批准，并使用其授权密钥进行签名。IAM 会检查调用方是否可以调用该方法，并将请求记录在 Cloud Audit Logs 中。 - 政策评估。系统会根据一组有效的事务政策对事务进行评估。政策评估会为每个判定（
APPROVED或REJECTED）生成持久性审核日志。 - 发起方审批。如果仅发起者的批准就满足了密钥政策的阈值，
CreateTransaction会立即进入第 5 步。 - 签署者审批。如果仅凭发起者的批准无法达到密钥政策的阈值，交易将进入
PENDING_AUTHORIZATION状态。持有该密钥的密钥份额的其他签名者使用RecordSignerDecision调用批准或拒绝交易，每个签名者都使用其授权密钥进行签名。交易会一直处于PENDING_AUTHORIZATION状态，直到有足够多的签名者批准，达到密钥政策的阈值。如果有足够多的签名者拒绝，导致无法再满足阈值，则交易会进入REJECTED状态。如果该请求在到期时间之前未获得足够的批准，则会EXPIRED。 阈值签名。达到阈值后，持有密钥份额的可信执行环境 (TEE) 会运行阈值签名协议，并生成交易签名。
在参与者 TEE 使用其密钥共享之前，它会检查要求其签名的确切载荷是否已根据您的交易政策进行评估。任何客户端、操作员或其他服务组件都无法让参与者对未经评估的载荷进行签名。
如需了解所涉及的资源（例如用户、团队、密钥环和交易政策），请参阅多方计算概览。
安全模型
- 密钥共享固定到其 TEE。每个密钥共享只能由创建它的 TEE 读取。密钥共享绝不会以其他组件（包括协调器、控制器或 Google 操作员）可以读取的形式离开该 TEE。
- 客户密钥托管。客户通过在客户的 Google Cloud 组织中使用 Cloud Key Management Service，始终保留对其加密密钥的完全控制权。
- 硬件隔离。参与者 TEE 在 Confidential Space 上运行，后者使用硬件内存加密来保护使用中的数据，使其免受主机和 Google 基础设施的影响。证明会将每个 TEE 绑定到经过验证的容器映像。
- 端到端加密。工作器 TEE 通过端到端加密的 gRPC 直接通信。
- 已签名的审批。签名者、政策作者和管理员使用授权密钥签署审批，其私钥部分绝不会离开他们。参与者 TEE 会先验证这些签名，然后再签署交易、接受交易政策或接受管理员或政策作者角色变更。这使得交易具有防篡改性，并留下了持久的审核日志。
- 政策作者法定人数。只有在达到所需数量的政策作者批准后，新交易政策或停用政策的请求才会生效。
- 管理员法定人数。只有在所需数量的管理员批准后，授予或移除管理员或政策作者角色才会生效。如需了解详情，请参阅管理员批准角色变更。
路线图
我们计划在后续版本中提供以下功能：
- 外部 TEE：密钥共享存储在客户在 Google Cloud外部运行的 TEE 中，例如 AWS Nitro Enclaves。
- 移动密钥共享：用户移动设备上持有的密钥共享。
- 重新共享：更改现有密钥的共享持有者，或替换丢失的共享，而不更改密钥。
系统属性
多方计算信任基础设施会维护以下系统属性。
安全性（加密上下文中的健全性）
在任何情况下，系统都不得以任何不被允许的方式运行。例如，根据 DKLS23 协议，任何少于 k 个参与者的群组都无法伪造签名。文献中的通用可组合框架对确切的安全定义进行了形式化。
在实际实现中体现加密系统时，必须注意避免依赖会破坏安全属性的假设。例如，协议中的每一方都必须是独立的：他们遭受入侵的可能性应该相互独立。
为确保此属性，多方计算会在经过认证的 TEE 中运行每个参与者，并且每个密钥共享都会固定到创建它的 TEE。协议中一个参与者遭到入侵不会影响其他参与者。
关于多方计算的学术文献几乎完全侧重于健全性，并假设了一个简单的世界，其中参与方集合是不可变的，所有参与方始终可用，并且参与方使用理想且始终可用的点对点经过身份验证的渠道进行通信。对于实际产品，还必须解决其他几个问题。
活跃性
系统最终会取得进展。最常见的活跃性属性是无死锁，这在 DKLS23 协议中得到了保证。只要有足够多的持有其共享密钥的 TEE 可用，满足密钥政策的阈值，就可以使用阈值密钥进行签名。例如，对于 3 选 2 密钥，3 个共享密钥中的任意 2 个即可完成签名。
耐用性
必须替换永久失败的参与方，否则系统最终会永久丢失共享密钥。例如，当硬件发生故障时，在该硬件上运行的参与者的状态会丢失。由于密钥共享内容固定在其 TEE 中，因此协调器会跟踪哪些 TEE 包含每个密钥的共享内容。在 v1beta 中，只要有足够多的密钥份额满足密钥政策的阈值，密钥就仍可使用。如需替换丢失的共享，需要重新共享，此功能计划在后续版本中推出。
配置变更
硬件故障（TEE 丢失数据）和组织变更（新员工加入协议并获得密钥份额）都需要更改密钥份额的持有者。多方计算计划通过一种安全的重新共享协议来支持此功能，该协议可保留 DKLS23 的健全性属性：参与重新共享的恶意新方最多只会泄露一份秘密，与其他任何恶意方一样。