使用 AWS Nitro Enclaves 构建 Cubist CubeSigner，一个安全且高度

• 2026-01-27 12:56:30

使用 AWS Nitro Enclaves 构建 Cubist CubeSigner：为以太坊验证者及其它应用提供安全且高可靠的密钥管理平台

by Fraser Brown Deian Stefan 和 DavidPaul Dornseifer，发表于 2024 年 3 月 15 日于 AWS 密钥管理服务区块链 中级(200) 安全、身份与合规 思想领导永久链接评论 分享

关键要点

以太坊的验证者是类似于以太坊的权益证明 (PoS) 区块链协议的基础构建块，负责维护链的历史记录并运行共识协议，使复杂的去中心化应用成为可能。但验证者在与协议的互动中面临着许多挑战，包括潜在的安全风险和经济损失。本文描述了一种新型的安全密钥管理平台Cubist CubeSigner，旨在帮助以太坊验证者应对这些挑战。

验证者是类似于以太坊的权益证明 (PoS) 区块链协议的基础构建块。它们维护链的历史记录并运行共识协议，使得复杂的去中心化应用得以实现，从去中心化金融应用到 NFT 收藏品。为了加入该协议，验证者需要提供资产作为抵押物，以确保其在推动共识时的正确行为。然而，由于该协议无法区分恶意验证者和诚实的错误，操作失误和验证者客户端软件中的漏洞可能导致资产的风险。这在最好情况下可能导致小的经济罚款，而在最坏的情况下可能导致资金的完全损失。

在本文中，我们描述了一种旨在保护以太坊验证者运营者免受内部威胁、验证者妥协、操作失误和客户端软件漏洞的安全密钥管理平台的高层架构。我们将涵盖以下主题：

运行以太坊验证者所面临的挑战及相关的安全和处罚风险。使用远程密钥管理解决方案来应对这些挑战的构想，以及密钥管理器必须围绕的基本目标，以有效降低风险。Cubist 的 CubeSigner 的高层设计，这是一种基于 AWS Nitro Enclaves 构建的安全密钥管理平台，支持质押和其他应用，从最终用户钱包到交易团队和操作的密钥管理。

运行以太坊验证者的操作陷阱和陷阱

以太坊 PoS 协议是一个在数十万验证者之间运行的共识协议。每隔几秒，验证者会运行以太坊交易，如果运行这些交易的结果与随机选择的验证者所提出的状态变化一致，它们就会将这些交易添加到区块链中，并通过签署验证消息来证明这一点。为了激励验证者诚实地报告链的状态，协议要求他们抵押 32 ETH。如果验证者按预期行为例如，不操纵交易或谎报链的状态，他们会在抵押资产上获得奖励。如果不这样做，他们的抵押金将会减少。

如果验证者被发现操纵链的状态，他们将因将网络安全置于风险中而受到惩罚，这被称为罚金slashing。被罚款意味着失去大量的抵押金并被驱逐出协议。较小程度上，如果验证者离线或签名速度过慢，也会受到惩罚，因为这会影响协议的可用性。

不幸的是，验证者的错误无法与恶意行为区分开来。如果验证者对区块链状态提供了两个相互冲突的报告，无法判断冲突是出于故意的不当行为还是验证者软件中的漏洞。因此，出现安全、正确性或性能错误的运营者可能会因被罚款而遭受直接的经济损失。预防每种错误面临严重挑战：

远程签名降低由于Bug和操作失误带来的风险

为了参与以太坊 PoS 信标链，节点运营者使用类似于 Lighthouse 或 Prysm 的 验证者客户端。验证者客户端包含任意数量的验证者密钥对。每对密钥对应一个验证者：公钥是验证者的身份，私钥是验证者客户端用于代表验证者签署消息的密钥。随后，验证者客户端将这些签署的消息广播到信标链网络，基本上声称验证者的链状态。

验证者客户端可以将验证者密钥存储在他们的机器上并进行本地签名，或者他们可以使用 远程签名器。远程签名器在远程存储密钥，并向验证者客户端暴露签名API。在每个纪元，验证者客户端向远程签名器发出签名请求，签名器则返回一个签署的验证消息。尽管网络延迟使得远程签名比本地签名慢，操作员使用远程签名器的原因有很多，包括：

远程签名器的设计必须考虑到这些特性仅仅使用类似 Web3Signer 的商业化签名器并无法确保这些特性。例如，远程签名器必须限制谁能访问密钥这意味着仅限于授权用户和验证者客户端访问，并将密钥封闭在签名器内部这样可以避免由于遭受攻击或内部威胁而导致的密钥盗窃。远程签名器本身必须具有高可用性和容错性，并使用全球可用的反罚款数据库；否则，签名器或操作系统更新、机器故障或网络中断可能导致罚款事件。最后，尽管远程签名器的速度不需要像本地不安全签名那么快，但远程签名器的延迟确实很重要：如果其速度过慢通常以超过一秒为标准，验证者将无法及时签名消息而导致运营者蒙受损失。

在接下来的部分中，我们将详细解释如何通过实施基于 Nitro Enclaves 的 CubeSigner 远程签名解决方案来实现安全性、正确性和可用性的目标。

Cubist CubeSigner 架构概述

为了解决前一部分提到的正确性、安全性、性能和可靠性挑战，我们构建了 CubeSigner，这是一种新的远程签名服务，基于 AWS 密钥管理服务 (AWS KMS)、亚马逊 DynamoDB 和 Nitro Enclaves 构建。

在高层次上，为了处理来自验证者客户端的验证消息，签名器完成以下步骤：

以下图表说明了解决方案的架构。

在接下来的部分中，我们将详细介绍这三个步骤。

经过身份验证的高级签名API

签名器需要公开一个 API，以便像 Lighthouse 和 Prysm 这样的验证者客户端可以直接使用。与 AWS KMS API 提供的简单但低级的签名端点不同，该 API 必须处理特定于以太坊信标链的高级验证者消息。这个高级 API 非常重要，因为它可以根据内容执行防止罚款的策略。如果该 API 发入并签署原始消息哈希，它将无法确定给定消息是否可罚。

除了防止罚款外，这个高级 API 也需要确保验证请求来自经过身份验证的验证者客户端否则，单一客户端的泄漏将意味着所有验证者客户端和所有密钥都将不安全。CubeSigner 更进一步，使用细粒度的 作用域 进行身份验证。作用域限制身份验证会话的操作例如，验证。通过仅授予验证者客户端验证作用域，节点运营商可以防止这些验证者，比如签署退出消息并退出验证协议。这可以避免运营者不小心将其验证者退出，并保护他们免受攻击者试图代为退出以损失奖励的风险。

CubeSigner 使用 API Gateway 与 AWS Lambda 授权者 实现自定义授权方案，以确定调用者的身份。每个经过授权的签名请求随后发送到 CubeSigner 的 亚马逊弹性计算云 (Amazon EC2) 实例，这些实例首先检查授权作用域是否允许该请求。然后，签名器计算消息的签名根哈希，应用防止罚款的策略，以确保签署消息哈希不会导致可罚违规，签署后返回签名给验证者客户端。接下来，我们讨论防止罚款和签署本身。

防止罚款

CubeSigner 在第二层，即政策引擎中实现防止罚款。在授权签名请求后，CubeSigner 应用若干政策，包括针对以太坊内置的防止罚款政策。防止罚款政策遵循 EIP3076，确保验证者永远不会签署与验证者已承诺的链历史不一致的消息，因此该政策要求保留状态。CubeSigner 通过使用 DynamoDB 作为其数据库来实施此政策。它原子性和条件地记录每个验证者密钥签署的消息。例如，确保签名器对此特定插槽号仅生成一次签名。

DynamoDB 是一个全托管的无服务器键值 NoSQL 数据库，旨在高性能应用程序的高可用性运行。DynamoDB 提供内置安全性、持续备份、自动多区域复制、内存缓存和数据导入/导出工具。可用性和一致性性能在运行区块链验证者时尤为关键，因为停机、延迟或数据不一致可能直接导致经济损失。鉴于这些要求，DynamoDB 极其适合，因为其性能稳定，单次延迟在毫秒级，并且可达 99999 的可用性。有关 DynamoDB 性能、成本和可扩展性特性的更多信息，请参见 亚马逊 DynamoDB 特性。

安全签署

第三层是低级签名器CubeSigner 虚拟硬件安全模块 (vHSM)。这一层建立在 AWS KMS 之上，用于在 HSM 中签署验证消息，确保密钥远离攻击者。

HSM和AWS KMS

在银行或域名证书管理等对安全敏感的业务领域，通常外包与密钥管理相关的任务例如，密钥存储或签名给 HSM。HSM 是专门设计的硬件，将加密秘密与物理硬件绑定，从而使其非常难以盗取。对标准 HSM 的