技术分析丨Phala Network为何不受Intel SGX芯片漏洞影响？

最新推荐文章于 2024-11-08 21:24:28 发布

论道Web3云服务

最新推荐文章于 2024-11-08 21:24:28 发布

阅读量167

点赞数

文章标签：安全网络 web安全

原文链接：https://medium.com/phala-network/technical-analysis-of-why-phala-will-not-be-affected-by-the-intel-sgx-chip-vulnerabilities-e045b0189dc2

版权

文章介绍了SecretNetwork因IntelSGX漏洞面临的安全问题，而PhalaNetwork通过SecureEnclave和独特的云设计确保了网络安全性。Phala的访问控制、多层密钥管理和硬件认证机制降低了攻击风险。未来，Phala计划引入多方计算和定期RAQuotes刷新以增强安全机制。

摘要由CSDN通过智能技术生成

摘要

2022年11月30日，安全专家Andrew Miller曾指出，Intel SGX的漏洞给Secret Network等项目造成了极大的安全隐患，并引发了社区广泛讨论。

Intel SGX是最广泛采用的TEE解决方案，Phala Network的链下计算节点也使用它，但是Phala采用了一种新颖的系统设计，可以减少攻击面并减轻潜在攻击带来的影响与后果。因此，我们的开发团队认为此类漏洞对Phala Network的影响是可控的。

本文将向各位读者解释：

为什么ÆPIC泄漏和MMIO漏洞破坏了Secret Network的安全性
Phala使用Secure Enclave（TEE）的原因
Phala如何确保网络不受SGX漏洞的影响
未来可行的安全机制

Secret Network漏洞总结

1.Secret Network漏洞造成原因

未修补漏洞的硬件（英特尔于 2022 年 8 月 9 日宣布的 ÆPIC 泄漏和 MMIO 漏洞）被允许加入Secret Network并运行节点。白帽报告此问题后，Secret 团队冻结了注册；Secret Network中的唯一主解密密钥在所有节点之间共享。

结合这两个原因可以看出，Secret Network网络的保密性完全取决于网络中最不安全的节点。一旦其中任何一个遭到破坏，密钥就会泄露，用户数据也会泄露。

2.攻击者可以获得什么？

正如SGX.Fail网站中所阐述的那样：“这些漏洞可用于提取 Secret Network 上私人交易的主解密密钥，即共识种子（Consensus Seed）。一旦提取到共识种子，便可完全追溯披露自链开始运行之后的每一笔Secret-4隐私交易。”

3.Phala Network是否可能受到相同漏洞的影响？

答案是不会。

Phala采用了对Worker节点注册的访问控制和多层密钥管理［1］，这点我将在后面详细介绍。

[1]：多层密钥管理是指将密钥分为不同层级，并在这些层级之间进行管理和控制。这样做可以增加安全性和控制访问权限。多层密钥管理可以用于访问控制、数据加密和身份验证等多种安全应用场景。

Phala去信任化云设计

1.为什么Phala需要Secure Enclave（TEE）

Phala是一个无需许可的去中心化云计算平台，它允许任何计算机作为Worker计算节点加入，因此我们的威胁模型［2］设置为在默认情况下不信任任何节点。恶意的Worker节点可能会尝试以下几种行为：

查看用户数据；
提供错误的执行结果，或根本不进行任何计算；
提供低质量的服务，例如降低CPU性能或阻止网络访问。

[2]：威胁模型（系统）是寻找系统潜在威胁以建立对抗的策略，以建立安全的系统。

其中，服务质量（第三个问题）将由我们的供应端通证经济模型确保。此外，我们依靠Secure Enclave（又名TEE，如Intel SGX）的特性和我们的密钥管理机制来确保整个系统的去信任化。

Secure Enclave提供重要的基于硬件的安全承诺，包括：

保密性：所有的内部数据都是硬件加密的；
执行完整性：即使在物理上控制了操作系统和计算机，也没有人可以影响程序执行的正确性和结果；
远程认证：用户可以远程验证在Secure Enclave内运行的硬件和软件。

这些特征也将作为我们向人们“借用”计算机算力的信任基石。值得注意的是，作为去中心化云计算平台，Phala的核心价值在于为用户能够正确执行程序和保护用户数据的隐私提供可能，这也是Phala与其他仅关注TEE机密性的项目最大的区别。

Phala是否可以使用零知识证明（ZKP）、多方安全计算（MPC）或全同态加密（FHE）作为它的核心解决方案？

答案依次是不行，可以，可以。因为这些解决方案的运作形式不同。

在零知识证明案例中，由用户自己执行计算，并只将计算的工作证明提交上链以避免隐私泄露。这与云计算场景中，用户将自己的计算任务委托给服务提供方执行完全不同；
多方安全计算将计算任务分成不同的部分，因此任何一个执行者都无法知道完整的原始输入或最终输出；
全同态加密使执行者直接对密文进行计算，无法知道用户的数据。

然而事实上，当前的MPC和FHE解决方案在它们可以执行的计算和性能上都有限制，因此基于硬件的解决方案仍然是最实用的选择。

我们正在探索支持AMD和ARM等其他制造商的TEE解决方案的可能性。通过适当的接口抽象［3］，Phala最终可以实现基于MPC和FHE的worker。

[3]：在程序设计中，抽象是一种将复杂系统分解成独立的模块和接口的方法。这样可以使系统更加清晰和可维护，同时也更易于扩展和修改。在这里Phala能够实现基于MPC和FHE的worker，就是因为Phala抽象出了接口使得它能将复杂的计算分成若干个简单的模块，这样Phala就能更灵活的对接不同的计算方式，保证了其扩展性和可维护性。

2.Worker节点注册的访问控制

加入Phala有两个先决条件:

Worker必须基于Secure Enclave支持的硬件。目前我们只支持英特尔SGX，但我们对AMD-SEV的调查表明，它也兼容我们目前的系统；
运行未经修改的Phala构建的程序，包括Phala节点和链下执行环境pRuntime (Phala Runtime的简称)。

Phala遵循“不相信，要核实”原则，并在其注册过程中应用远程认证过程。也就是说，需要pRuntime来生成由受信任硬件直接提供并由硬件制造商（在本例中为Intel）认证的RA Quotes［4］。该报告包含有关硬件和软件的重要信息:

硬件信息：

pRuntime是否在SGX内部运行；
基于当前硬件和固件版本的已知漏洞。基于此，Phala区块链将拒绝有黑名单漏洞的硬件，并为每个Worker节点分配一个可信等级。

软件信息：

程序的哈希值，这有助于确保pRuntime未被修改;
程序的初始内存布局，因此它的初始状态是确定的。

有了所有这些信息，我们就可以验证受信任的硬件和在其中运行的程序。此外，RA Quotes和置信度度量使我们能够评估每个Worker的安全级别，并根据允许加入网络的硬件定制我们的安全策略。

[4]：Intel硬件中SGX的RA Quotes是在确保应用程序和数据安全性时使用的一种机制。其中RA是指“可信度验证”，Quotes是指“引用证明”。所以RA Quotes就是在确定应用程序和数据是可信的时使用的证明。

SGX提供了一个称为“受保护的区域”的特殊环境，应用程序和数据可以在这个环境中运行和存储。

然后，SGX通过硬件证明机制来验证受保护区域中运行的应用程序和存储的数据是否符合可信度要求，而RA Quotes则是将这种可信度度量结合起来确认应用程序和数据的可信度。

通过这种机制，可以确保应用程序和数据在受保护的区域中运行和存储是安全可信的。

此外，Phala的供应端通证经济学旨在为Worker提供高质量的服务，如果想要了解更多信息，可以访问Phala WiKi进行了解。

3.多层密钥管理

Ekiden在2019年的论文中提出了世界上第一个“区块链-TEE”混合架构的密钥层次结构，并作为Oasis项目的基础。作为去中心化云计算平台，Phala改进了这一设计，使其适用于超100k节点的大规模网络。并且，我们还引入了新的机制，如密钥轮换，以进一步提高云计算网络的稳固性。

在我们真正深入研究合约密钥管理的细节之前，读者有必要了解Phala系统中的每个实体都有自己的身份密钥。

每个用户都有自己的账户，每个Worker和守门人（Gatekeeper，由Worker选出）都有自己的sr25519 WorkerKey对，这是在pRuntime内生成的（在SGX中也是如此），私钥永远不会离开SGX。

身份密钥用于：

进行数字签名以标识来自不同实体的消息;
使用ECDH密钥协议，在用户、Worker和守门人之间建立加密通信通道。默认情况下，Phala中的任何通信都加密。

MasterKey是整个网络信任的根源。所有与智能合约相关的密钥，包括ClusterKey和ContractKey，都是由MasterKey派生而来。MasterKey由所有的守门人生成并共享（通过上面提到的加密通信通道），使得MasterKey的安全性完全依赖于守门人的安全性。这就是为什么守门人不同于其他Worker节点的原因：

守门人节点的硬件具有最高的可信等级：他们对所有已知的SGX漏洞都免疫；
与普通Worker节点不同，守门人的端点并不公开，你不能向它们部署合约。这避免了对守门人的远程访问；
要求守门人增加质押数量，以阻止其的不良行为。

在Phala中，Worker被分组成集群，以提供无服务器的计算服务。使用主密钥（通过密钥派生）为每个集群生成一个唯一的ClusterKey，但是任何人都无法反推过程来断定ClusterKey的主密钥。并且，ClusterKey被该集群中的所有Worker共享。

最后，当一个合约被部署到一个集群时，它也被部署到该集群中的所有Worker。这些Worker将遵循确定性过程并派生ClusterKey以获得相同的ContractKey。Contractkey对于不同的合约都是独立且唯一的。

如果某些密钥泄露，有哪些漏洞?

如果WorkerKey泄露，攻击者可以解密发送给对应Worker的所有消息，例如其集群的ClusterKey，可以用来访问该集群的ContractKey。攻击者甚至可以冒充Worker向用户提供虚假的结果。通过比较多个Worker的结果，可以检测到这种恶意活动，然后链将切断受损Worker并没收该Worker质押的PHA；
如果合约密钥泄露，攻击者可以解密该合约的状态和所有历史输入；
如果一个ClusterKey被泄露，攻击者就可以知道该集群中所有合约的上述信息；如果主密钥泄露，则所有历史数据都将被泄露。

如果最坏的情况发生了，Phala如何应对？

Phala选择为守门人提供密钥轮换，这意味着在议会的许可下，守门人可以更新主密钥，然后相应地更新ClusterKey和ContractKey。
因此，当最坏的情况发生时，Phala将首先用最新的硬件注册新的守门人，注销所有旧的并切换到一个新的主密钥。

未来的安全机制

1.使用多方计算管理万能钥匙

目前，相同的主密钥在所有守门人之间共享，因此如果其中任何一个守门人泄露，主密钥就会泄露。如果转化成多方安全计算，攻击者将不得不妥协需要大多数守门人来共同达成共识以获取主密钥。

2.启用RA Quotes刷新

由于Phat Contract目前不支持主网，Worker只需要在注册期间提交一次RA Quotes。当Phat Contract发布时，我们将启用定期的RA Quotes刷新，这样一旦报告了新的漏洞，而那些不会应用补丁，易受攻击的Worker节点将被大幅削减（Slash）。

最后，感谢Andrew Miller和包括Christina Garman、Daniel Genkin、Stephan van Schaik等人在内的安全研究团队为安全领域做出的贡献。正如Andrew所说，他的团队的目标是帮助提高安全性并减少安全事故的发生。我真诚期待与安全研究人员进行更深入的讨论，以巩固Web3世界的去信任基础设施。

关于作者

Dr. Shunfan（Shelven）Zhou，Phala Network首席研究员，Phala白皮书的作者之一，从事安全研究超7年。曾作为《USENIX Security Symposium 2020》《An Ever-evolving Game: Evaluation of Real-world Attacks and Defenses in Ethereum Ecosystem》以及其他关于程序分析的论文的第一作者。