深入了解zkLogin的Salt服务器架构

最新推荐文章于 2024-09-23 19:50:54 发布

Sui_Network

最新推荐文章于 2024-09-23 19:50:54 发布

阅读量877

点赞数 19

分类专栏： Sui 科普文章文章标签：服务器架构运维区块链算法智能合约去中心化

本文链接：https://blog.csdn.net/Sui_Network/article/details/141225878

版权

Sui 同时被 2 个专栏收录

431 篇文章 4 订阅

订阅专栏

科普文章

96 篇文章 0 订阅

订阅专栏

zkLogin是Sui的一种原生功能，是Web3中首创的真正无信任、可靠且用户友好的身份验证机制。通过zkLogin，开发者可以创建无缝的用户入驻体验，允许用户使用熟悉的Web2凭证（如Google或Facebook）轻松创建和管理Sui地址。

在使用zkLogin为某个地址签署交易时，必须提供一个独特的salt值来表示与该Sui地址相关的OAuth或Web2凭证。这个salt值对于确保链上地址无法追溯到用户的Web2凭证至关重要。Salt服务器负责在每次交易启动时生成、存储并提供此salt值。开发者有多种选择来生成和存储此salt值，无论是在客户端还是服务器端。

在Mysten Labs，我们运行的salt服务器使用主密钥助记词与用户的JSON Web Token (JWT) 相结合，为每个用户和每个应用程序派生一个可重复的salt值。此过程包括验证来自提供商的JWT。考虑到主密钥助记词的敏感性，在典型的计算环境中托管salt服务器存在较高风险。保护主密钥助记词对于维护Web2身份与Sui地址的分离至关重要。

为了保护我们的客户和合作伙伴的用户身份，我们的salt服务器在一个安全的计算环境中运行，确保防止意外或恶意泄露。我们将在此概述我们的方法，作为其他希望实现类似解决方案的参考。

zkLogin和Salt服务器

如上所述，Salt服务器在用户使用zkLogin时保持其Web2凭证的隐私和安全方面发挥着重要作用。通过使用秘密的主密钥助记词和用户的JWT，Salt服务器生成一个对该用户和该应用程序唯一的salt值，但用户身份与其Sui活动之间的联系被加密隐藏，从而确保隐私。在生成zkLogin证明之前（即在链上发起交易之前），必须使用这个salt值。

当某人使用由Mysten Labs Salt服务器支持的应用程序时，他们输入其Web2凭证，应用程序从身份验证提供者那里请求JWT。然后应用程序将JWT发送到Salt服务器以获取salt值。每次从用户身份派生Sui地址时，包括计算原始证明以获取用户的zkLogin签名，都会使用salt确保用户的地址可以从他们的token中确定性地计算出来，而不会泄露两者之间的关联。

深入探讨Salt服务器

在保护用于Salt服务器的主密钥助记词时，有三个主要目标：主密钥必须安全生成、免受Mysten Labs内部任何人的接触，并且免受通过服务或云提供商的侧信道攻击而导致的外部暴露。如果除了Salt服务器外，没有其他人或系统能够看到这个密钥，那么我们可以对其保密性以及从JWT到链上地址的哈希映射的有效性充满信心。

可信计算系统

托管可信计算基础设施有多种选择。在理想情况下，所有的哈希计算都应在像硬件安全模块 (Hardware Security Module，HSM) 或可信平台模块 (Trusted Platform Module ，TPM) 这样的可信硬件模块中进行。

然而，将主密钥绑定到单个硬件意味着该硬件成为系统中的单点故障 — — 如果失去了对HSM或TPM的访问，则意味着永久失去了主密钥。在这种情况下，助记词丢失的风险对于我们的Salt服务器来说太高了，因此我们需要在绝对的硬件安全性和灵活性之间进行权衡。最终，我们选择了使用可信计算环境，在其中我们可以在一个隔离的环境中运行服务器，通过容器认证，并且仅通过TCP直接访问服务的端点。

三大云提供商都提供了可信计算解决方案；Azure Confidential Computing、GCP Confidential VMs和AWS Nitro Enclaves都是支持隔离计算的环境。我们选择在EC2上使用Nitro Enclaves。通过Nitro Enclaves，我们可以使用自己的容器镜像和现有的构建工具，并在其上添加Enclave层。

助记词生成

由于主密钥助记词是永久性的且不可逆转，生成过程只会发生一次。助记词可以是任何字节序列，因为随机性才是关键。然而，如果由我本人生成主密钥助记词，那么它将会变得脆弱。即使我没有将主密钥助记词透露给任何其他人，但因为我知道这个助记词，它仍然是Mysten Labs zkLogin实现和基于其开发的任何应用程序中的一个基本漏洞。因此，我们更倾向于以自动化的方式生成密钥。

在非隔离网络的机器上生成助记词会引入额外的漏洞，因为它可能暴露给系统的其他部分，甚至可能暴露在互联网上。我们使用Nitro Enclaves来创建一个隔离的环境，以安全地为zkLogin的主密钥进行密钥生成。

在Enclave内部，我们通过随机性生成主密钥助记词。然后我们使用加密密钥对助记词进行加密，并将密钥存储在一个秘密存储中。该秘密存储被配置为只有Enclave可以获取该秘密，甚至管理员都无法访问该明文秘密。我们还将密钥分割并按照“助记词恢复”部分中描述的方法存储碎片。

在Nitro Enclave内运行的Shell脚本相对简单。

./generate-random-seed > seed.json
secrets-store put - name SEED - file seed.json

助记词用例

主密钥助记词密钥的策略仅允许Enclave身份访问它，这意味着即使是管理员也无法意外读取它。我们还为Salt服务器的密钥维护了一个独立的云提供商账户，以将管理员访问权限与其他Mysten Labs项目隔离开，并限制有访问权限的人员数量。

当密钥被Nitro Enclave中的Salt服务器读取时，它会以明文形式保存在内存中。我们依赖隔离环境的保护来防止在同一主机上的访问，因此将助记词加密保存然后为每个请求解密并没有什么好处。由于助记词在每个请求中都会被使用，因此常规流量会削弱静态加密所能提供的保护。

为了让服务能够接收流量，我们必须允许一小部分网络访问通过到Salt服务器的Enclave环境。我们使用vsock代理来限制通过单个应用程序端口的入站流量，并限制出站流量至OAuth提供商用于JWT验证的地址以及用于可观察性发布的网关地址。这使得Salt服务器能够执行验证和生成Salt值的任务，并允许我们监控服务，同时拒绝所有其他网络访问。

以下是一些示例代码，展示了我们如何使用Pulumi配置Enclave并初始化它。

🔎代码见文章：Dive into zkLogin’s Salt Server Architecture

这段Python Pulumi代码为我们服务的每个副本创建一个EC2实例，将其连接到我们设置的网络，并为其启用Nitro Enclaves。我们插入的 `user_data` 会构建Enclave，设置vsock代理，并启动Enclave。

虽然我们尽力成功地保护主密钥的使用，但将我们的秘密保存在单一服务的云提供商中仍然存在风险。一项助记词恢复计划确保我们在灾难情况下有多种方式恢复主密钥。

助记词恢复

在我们最初的助记词生成过程中，我们将助记词分成多个加密碎片，以便由参与设计Salt服务器系统的团队成员进行恢复。我们使用了Unit 410的Horcrux工具来实现这一目标。

Horcrux使用Shamir的秘密共享方案生成助记词的多个加密部分，并允许通过指定的碎片子集进行解密。每个碎片都由团队中每个人拥有的硬件密钥加密，从而增加了地理上分布的安全性。

这些加密碎片被冗余存储在多个远程服务器中。由于它们是加密的，我们将它们存储在一起，并添加冗余以避免单点故障。在密钥从服务器丢失的情况下，通过Horcrux的恢复过程既迅速又能保持秘密性。

权衡

我们的Salt服务器生产系统与我们运行的许多其他服务看起来非常不同。我们通过在Nitro Enclaves中运行服务所施加的安全约束使得Salt服务器的操作化成为一个挑战。

我们对Enclave添加的每个网络代理都是对主密钥助记词潜在的外流攻击面。只要我们在每个新的OAuth提供商上继续遵循相同的做法，我们预计攻击面将保持不变。我们预计不需要在Enclave本身内外添加更多的网络流量。

Salt服务器必须保持简单；随着时间的推移，与Mysten Labs的其他服务的通信以及与新工具的集成可能需要对涉及的安全权衡进行单独的具体考虑。我们将在严格限制的环境中维护系统，以保护基于我们zkLogin实现的应用程序所依赖的这一关键部分。

安全第一

在Mysten Labs，我们专注于解决基础性问题，而zkLogin就是这种专注的实际体现。随着我们继续构建类似于zkLogin及其上的其他新构造，我们将以加密可验证的方式保持系统的最高安全标准。我们的实现结合了Nitro Enclaves和Horcrux的强大功能，展示了我们对这些标准的承诺，并将Web3的优势带给每个人。