基于TEE的智能合约及封闭陷阱

上周，我和 sgx.fail 团队的其他成员发布了一份研究预印本，内容包括对 Secret Network 的一个漏洞披露。Secret Network 是第一个基于可信执行环境 (TEEs) 线上生产的智能合约系统。然而，还有几个竞争项目拥有紧密相关的技术，并已推出公开测试网络，分别是 Oasis、Phala 和 Obscuro。我们的披露启动了更广泛的讨论，所有这些项目都与我们联系并/或发表了公开声明，分别说明了他们在多大程度上会受到影响以及他们正在开发的缓解措施。四个项目大多独立建设，但 TEE/SGX 的安全隐患对所有他们都构成了共同威胁，这表明有机会一起合作。

尽管他们面临挑战（包括可能未来出现新的 SGX 漏洞，以及对英特尔集中服务的固有依赖），但这个小众领域很可能会成长。一个前景广阔（但也具有挑战性）的未来方向是将 TEE 和多方计算 (MPC) 等加密技术结合在一起。稍后我会对此作进一步阐述。

但与此同时，我们需要讨论基于 TEE 的区块链中更基本的设计问题。最重要的是，我想解释 SGX 密封数据基于代码签名策略如何产生一个不必要的后门。具体来说，鉴于 Secret 目前的设计，开发者的代码签名密钥可能会被用来解密主密钥，即使不需要利用任何漏洞或侧信道。其他项目在他们的测试网上也在一定程度上表现出这个问题。我还会指出几个其他领域，基于 TEE 的智能合约可能会共同合作以增强整个小众领域的安全性。

基于 TEE 的智能合约快速回顾

TEEs 是为智能合约增加保密性的有希望的方式。TEE，或称为 enclave，是支持隔离和远程证明的安全处理器硬件。最常用的是 Intel SGX。这种方法非常灵活且高效，不需要与加密技术（如 zkSNARKs 和 MPC）相关的额外开销，支持现有的智能合约引擎，如 EVM 和 CosmWasm。这种方法在研究论文中有所描述，包括 Ekiden、PDOs 和 Kaptchuk, Green, Miers.。第一个上线投入生产的实例是 Secret Network。该网络自 2020 年以来一直在运行，已经托管了许多活跃的应用程序，包括 DeFi、高知名度的私有 NFT 等。Oasis、Phala 和 Obscuro 已推出公共测试网络，并准备即将开启主网。

所有这些项目的基本原理都是一样的：交易和合约状态都被加密，只有安全的 TEE enclave 才能访问它们。在 Secret 的情况下，所有解密密钥都是从主密钥“共识种子”派生的，该密钥复制到网络上的所有 enclave 中。为了获得共识种子的副本，一个 enclave 必须完成远程证明过程。这涉及从英特尔远程证明服务 (IAS) 获取签名报告，证明你在拥有最新微代码的处理器上运行了正确的程序。整体系统的隐私依赖于 TEE 的能力，以防止即使是物理拥有该节点的节点操作员在其运行期间读取内部状态。

接下来的讨论在某种程度上将批评 Secret Network。这并不是我的本意，因此在进入主题之前，我想先表明我非常钦佩 Secret 在利用其先发优势方面所做的许多工作。他们已经托管了几款真正引人注目的现实世界应用，这些都是 TEE 隐私功能的良好示例。它们的 私人 NFT 和市场 Stashh 是最好的例子。例如，你可以购买一个 NFT，其中包含一个未发布的电影的秘密访问信息，电影导演是凯文·史密斯。（在 Stashh 上的现行价格为 $50，二手市场）。原则上，任何所有者都可以在选择的情况下泄漏此访问信息，但据我所知，没有人这样做，因为它并未出现在任何在线搜索中。（参见 这个 reddit 讨论）。因此，如果你想观看电影，购买 NFT 并查看私有元数据是唯一的方式。这很好地展示了私人智能合约能做什么。

讨论 1. TCB 恢复计划的必要性

TCB Recovery 大致是英特尔对发现可被利用漏洞后发生的所有事情的称谓。这可能是 SGX 生态系统中最不为人知的方面。我将介绍足够的关于最近的 AepicLeak 和 TCB 恢复的信息，以使大家理解这与区块链有什么关系，但要获取更多细节，你应阅读我们的论文和 SGX.fail 网站。AepicLeak 于八月公开披露（sgx.fail 团队与他们没有交集，我们第一次听到此事是在与其他人同时。我是在回程的路上听说的，参加了 IC3 区块链营,，在此，学生团队在 Oasis Sapphire 和 Secret Network 上开发应用）。像其他研究人员发现的漏洞一样，AepicLeak 的公开披露经过协调，以便英特尔和许多硬件供应商在声明发布时同时推出微代码和 BIOS 补丁。这可能让一些人（就像让我一站）产生了这样的印象：在公开发布时，IAS 中已经存在所有适当的缓解措施。

首先，我想解释一下在 AepicLeak 披露日期之前，我预计 IAS 将如何运作。每当一个 enclave 需要生成远程证书时，就必须与 IAS 进行交互，发送一些硬件和微代码状态的表示，并收到一个证明报告作为响应。签名的证明报告包括一个状态标志，并可选附详细的建议列表。因此，我期望 IAS 作为第一道防线，会对我能够找到的任何脆弱平台返回 SA-00657 的警告（这是有关 xAPIC 漏洞的通知）。当我进行硬件购买狂欢时，这似乎是一个遥不可及的目标。

Intel IAS 无法评估认可的 enclave 是否具备必要的软件补救措施，英特尔 PCS 不提供让人评估认可的 enclave 是否具备必要的软件补救措施的证明附件。

如果当时我对 TCB 恢复了解更多，我将会以不同的方式解读通知。通知上说，计划进行 TCB 恢复，预计将于 2023 年第一季度完成（后来改进为 2022 年第四季度）。这虽然是一个巨大的简化，但你可以将 TCB 恢复日期看作 IAS 需要在发布新证明之前应用微代码更新的时间。sgx.fail 论文的主要结论之一是 IAS 很难选择满足所有 SGX 应用的 TCB 恢复计划。例如，如果 IAS 在云服务提供商能够修补之前返回新的错误代码，SGX 应用可能会变得不可用。公开披露日期与 TCB 恢复日期之间的延迟是可用性风险与保密风险之间艰难折中的结果。

基于 TEE 的区块链必须做好执行其自身 TCB 恢复计划以应对下一个 SGX 漏洞的准备。最紧迫的行动必须是阻止新的脆弱节点加入。尽管该漏洞仅影响某些处理器，但公开披露作为寻找硬件以发动攻击的“提示”。Secret Network 开发者都知道 AepicLeak 的存在，但他们估计（就像我一样）并没有机器同时满足 a) 易受 AepicLeak 攻击，b) 能够通过 IAS 证明检查。因此，他们决定让注册保持开放。结果即使 AepicLeak 已经公布近两个月，我们依然能够找到合适的硬件并直接 breach 共识种子。针对我们的披露，Secret Network 开发者立即通过撤销他们与 IAS 的项目账户来停止新 enclave 节点的注册。

我们乐观地认为，机会窗口因此被关闭，并且这一潜在的数据泄露永远不会实现，尽管重要的是要提醒用户这种可能性。必须承认，无论是否更新微代码，已经在网络上的任何故意未打补丁的机器仍然今日构成威胁。Secret 开发者估计，注册在网络上的节点中有 4% 可能是脆弱的。

第一个经验教训是，所有基于 TEE 的区块链都需要为下一个 SGX 漏洞制定 TCB 恢复计划，特别应该计划在最早的通知下实施类似注册冻结的措施。这方面的规划是整个小众领域应形成的最佳实践。我想指出，根据我所理解，开发团队在公开宣布 AepicLeak 之前没有收到任何提前警告。该小众领域可能会联合起来，与英特尔更好地谈判/倡导提前通知。

Secret Network 的部分回应是开发密钥轮换机制。密钥轮换意味着停止使用旧主密钥，将每个合约的当前状态迁移到一个新密钥，然后继续处理在新密钥下加密的交易。一旦密钥被轮换，则新交易不再面临被解密的风险，即使旧密钥最终被攻破。密钥轮换是 Phala 已经实现的。 Oasis Sapphire 计划在完成密钥轮换机制之前推出他们的主网，尽管该机制仍在开发中。

讨论 2: 隔离。

当然，从已发生的漏洞来看这点言之容易，但对我而言，共识种子与任何通过证明的节点共享的选择似乎风险过大。Secret 开发者解释说，这是 一种有意的设计权衡，因为这通常有利于活跃性（需要更多节点崩溃才能停止网络）并且使 API 端点和其他服务运行更容易。

其他 TEE 基于区块链有什么不同？我们可以从 Obscuro 的文档 推测，他们的主密钥复制方法与 Secret 类似，即任何“有效的 TEEs”，无论是聚合者（质押者）还是验证者（不需要质押），都可以获得主种子的副本。

一种替代方案是 2018 Ekiden 文件中提到的“隔离”设计。Ekiden 有两级 TEE 节点：密钥管理器和工作节点。工作节点根据需要了解特定合约的密钥，因此即使被攻破，他们也只会了解到最近区块链状态的一部分。密钥管理器节点仍存储一个主密钥，但数量较少，并且可能要求某种质押存款或从已知可信实体中选择。

Oasis 和 Phala 都具有类似 Ekiden 的多级方案。在 Oasis Sapphire 测试网中，密钥管理器当前由 6 个节点组成，尽管他们的主网推出可能会有更大的委员会。他们的帖子 提到，“将委员会成员限制在可信的运营合作伙伴中，以防止未知的坏演员试图利用像 Æpic 这样的漏洞。”

在 Phala，类似于 Oasis，能够访问主密钥的“门卫”由其“委员会”指定，这是一种 链上治理过程。虽然 Phala 目前仅对其“Phat Contracts”系统推出了测试网，但 委员会已经成立并有 8 名成员，并且 增加新门卫的提案在此 中有记录。

总而言之，目前 Oasis 和 Phala 实施隔离以将主密钥限制在一个小委员会中，而 Obscuro 和 Secret 更广泛地分发主密钥。这种做法到底有多好？我们该对这些委员会寄予多少信任？我们究竟是信任他们去做什么？这个问题与为 PoS 区块链建立验证器委员会是相关但不同的。委员会成员必须被信任而不去利用下一个可能发生的 SGX 漏洞——在普通的权益证明区块链中没有类似的比喻。明确哪些信息应该从有关密钥管理节点的透明报告中期待或许能够帮助，界定一些小众领域的最佳实践。

讨论 3. 软件升级及 MRSIGNER 的问题

接下来让我们谈谈本帖的主题。每个区块链项目都需要有软件升级流程。这需要将敏感数据（如主密钥）从旧 enclave 迁移到新 enclave。在 SGX 中以 MRSIGNER 密封数据是最简单的方法。不幸的是，这会创造一个开发者可以用来窥视主密钥的后门。我稍后会解释这意味着什么。

我对所有四个基于 TEE 的区块链代码库进行了快速调查（随后请求了评论），并确定 Secret 和 Obscuro 目前依赖 MRSIGNER 密封，因此开发者的代码签名密钥确实可以被用来在不留任何证据的情况下窃取主解密密钥，而 Oasis 和 Phala 则要求多个签署者在迁移发生之前提供链上发布的证明。

为了理解这个问题，我们需要从 TEEs 中的“密封数据”以及如何利用这些数据进行软件更新开始。密封是数据在 enclave 程序调用之间持久化的方式。例如，在 Secret Network 中，共识种子存储在一个密封文件中，“consensus_seed.sealed”，该文件在节点首次注册时创建，并在节点每次重新启动时加载。SGX 标准库提供了密封文件的抽象。由 enclave 创建的密封文件可以被该 enclave 后续读取，但不能被不受信的操作系统或其他 enclave 访问。

在问题变得清晰之前还有一个琐碎的 SGX 细节。SGX 提供了两种密封密钥策略：MRSIGNER 和 MRENCLAVE。MRENCLAVE 将密封数据绑定到创建它的程序二进制文件的哈希值。只有最初密封密钥的确切相同程序才可以解密以访问它。另一种策略 MRSIGNER 将密封数据绑定到 开发者的代码签名密钥。该策略规定，任何由这些开发者签名的程序二进制文件都可以访问密封文件。

你不需要了解硬件侧信道就可以看出这里的问题。如果开发者选择这样做，或者如果他们被强迫或密钥被盗，他们可以编写一个 enclave 程序，明文输出共识种子，签名后再在节点上运行。代码签名密钥可被直接用于检索主解密密钥，而无需利用任何 SGX 漏洞。这并不需要留下任何痕迹，开发者无法提供没有这样做的证据。

为什么要使用 MRSIGNER？没有 MRSIGNER，部署软件更新将变得极为困难。所有基于 TEE 的区块链项目都在积极开发与维护该项目。没有 MRSIGNER 密封数据时，升级流程会复杂得多，因为运行新软件的节点需要重新注册。在 Phala 的代码库中的开发者讨论中，Shelven Zhou 很清楚地解释了 “MRSIGNER的问题”：

MRSIGNER 基于密封更易于实现，但它使得任何拥有签署程序的证书的人都可以解密其密封数据。

让我们先关注 SecretNetwork。他们的文档明确指出 “共识种子是以 MRSIGNER 密封到本地文件中的。” 查看进行此操作的代码 (storage.rs)，共识种子是使用 Teaclave 库（确实是 MRSIGNER）的默认选项进行密封的。这是

接下来，Obscuro 使用了 EGo 库。它提供了两个选项，“seal_ex”（MRENCLAVE）和“seal”（MRSIGNER）。Obscuro 目前使用的是“seal”。 Obscuro 的开发者确认这是一个疏漏而非有意的设计选择。Obscuro 的文档提到“一个独立、声誉良好且胜任的安全审计小组必须分析此代码并通过小心签署批准它。”开发者计划在他们的主网发布前，在 enclave 内强制执行这一点。

Phala 目前的实现 使用 MRSIGNER 密钥策略给主密钥密封。 但是，他们对 MRSIGNER 问题的详细讨论还包括一个更复杂的升级流程，即需要委员会和/或门卫的多数签署，并要求在链上发布程序。他们的计划是在线以上还要在主网之前去掉 MRSIGNER。

而 Oasis 只使用了 MRENCLAVE 进行密封。 (代码) 在软件更新方面，他们实施了 一种多密钥代码签名机制，该机制要求 2-of-3 代码签署者在主密钥可以从现有节点转移到升级软件的节点之前批准更新。此外，与 Phala 一样，该程序二进制文件 必须在链上发布。

我将把到目前为止讨论的内容总结在一个表格中（但请注意这并不详尽，我们可以讨论许多其他设计细节）：

对基于 TEE 的智能合约中选择性关键泄露缓解措施的非详尽总结。主网络中缺失的缓解措施标记为红色，而测试网上的标记为黄色，因为这些措施仍可在任何敏感用户数据受到影响之前应用。

Secret 开发者解释说，MRSIGNER 是一种有意的设计权衡。除了便于升级外，更安全的论点是，更复杂的升级机制可能会引入更多潜在的漏洞，从而破坏网络或泄漏共识种子。然而，我怀疑 Secret 的用户和旁观开发者普遍不知道这一选择或没有充分理解这一困境。一旦讨论结束，我认为会有明确的共识认为这是一个不必要的后门。我的希望是，在这篇帖子之后，Secret 社区会要求改变这一政策，并进行另一次密钥轮换，以便开发者无法单方面窥视密钥。这将要求实施一种依赖于开发者代码签名、链上发布的证明，以及要求多个独立代码签署者的组合的升级机制，而不仅仅是一个人。

需要证明的是，要求一个可信的委员会对代码更新签名是有意义的，前提是他们的声誉真的处于风险中。若不要求软件更新发布，委员会可能会联手窃取主密钥而不被发现。即使有公开证明，代码签名委员会到底承诺要做什么仍然不明确。由于我尚未看到有关委员会成员的声誉何在以及在批准代码更新时遵循何种过程的文档，因此这些项目没有在其代码签名政策中获得“绿灯”。

致谢与披露： 我是 (Andrew Miller) Zcash 基金会的董事会成员，同时也是 Oasis 基金会 TAC 的成员，但与此处讨论的其他三个项目没有关系。这篇帖子完全是我个人的观点，我的意图是尽量保持中立。

感谢 Phala 的 Shelven Zhou、Oasis 的 Jernej Kos、Obscuro 的 Tudor Malene 和 Secret 的 Guy Zyskind 对这篇帖子的评论。我开始时基于代码审查及所引用的代码片段编写了对这些代码库功能的描述，但尽力结合基于开发者评论的修正。任何剩下的错误都是我自己的，而我得到的正确内容则得益于他们的帮助。

• 原文链接： medium.com/initc3org/tee...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～