无密码身份验证的Web3Auth系统结构及部分原理

本篇文章内容来源于Web3Auth/Web3Auth：简单的基础设施，使Web3钱包和应用程序能够为主流和Web3.0用户提供无缝的用户登录。 (github.com)和官网Introduction | Documentation (web3auth.io)，还有部分内容来源于一些博客、视频和学术论文，由本人归纳整理而出，如有侵权请联系本人进行删除。

Web3Auth是无密码身份验证、Web3应用和钱包的非托管密钥基础设施组合而成的系统。Web3Auth通过聚合OAuth（Google，Twitter，Discord）登录，Web3Auth是Web3钱包和应用程序的可插拔身份验证基础设施。它通过提供他们最舒适的体验，在一分钟内简化了主流用户和加密原生用户的入门。由于支持所有社交登录、Web和移动原生平台、钱包和其他密钥管理方法，Web3Auth产生了一个特定于用户和应用程序的标准加密密钥提供商。

通过将Web3Auth集成到你的应用程序中，你的用户可以使用他们选择的流程注册：

• 主流社交账户登录和无密码登录：用户可以通过谷歌、Twitter、GitHub和他们选择的任何其他OAuth提供商进行注册。用户也可以通过无密码流程注册，他们可以在发送到他们电子邮件的链接中进行签名。这是由我们的密钥基础设施（tKey）启用的。在这里了解更多关于tkey和我们的基础设施的密钥管理和安全性。
• 全面的Web3钱包/密钥管理支持：授权用户使用他们选择的钱包或密钥管理。使用Web3Auth套件，用户可以使用他们现有的钱包或选择的密钥管理，并直接将其与您的应用程序挂钩。

它的特点

• 无缝登录：我们的社交登录流程与Web2.0登录流程没有什么区别，极大地改善了用户体验和登录。
• 非托管的公钥基础设施：用户始终控制所有权和访问他们的加密密钥对。登录服务只能访问一个共享，因此提供者不可能自己检索用户的私钥。
• Whitelabel：自定义Web3Auth的UI，使其直接融入您的应用程序中。
• Web和原生移动端：Web3Auth开箱即用，既可以在Web上运行，也可以在移动端运行，支持原生和混合应用程序。
• 使用现有的身份验证/用户基础：插入到现有的用户基础或身份验证。零迁移的必要。

Web3Auth在网络中的角色

Web3Auth SDK 仅依赖于用户/应用程序的前端客户端，并处理 OAuth 提供程序与身份验证网络之间的交互。
下图描述了Web3Auth SDK与集成应用程序之间的关系。

Web3Auth如何与您的钱包/应用程序进行流交互

用户启动该过程后：

1. 用户被重定向到Web3Auth的门户（app.openlogin.com)
2. 然后，Web3Auth的门户处理初始登录过程app.openlogin.com
3. 用户被重定向到 login/OAuth 提供程序，并对其身份验证提供程序执行身份验证过程
4. 用户被重定向回我们的门户，然后处理用户密钥的重建
5. 最后，一旦用户成功通过身份验证，他们就会被重定向回应用程序，并带有特定于应用程序/钱包的派生密钥。

下图展示了此过程：

Web3Auth在钱包领域的使用案例

Web3Auth不是钱包，而是插入应用程序或钱包的钱包基础设施。Web3Auth 生成特定于用户和应用程序的标准加密密钥提供程序。使用Web3Auth时，用户可以灵活地在应用程序中创建自己的钱包或使用我们预先存在的适配器之一，这可以处理将应用程序链接到钱包的复杂性。

下面是使用Web3Auth构建您的钱包的案例。

在Web SDK中，我们有适配器，它们本质上是Web3Auth和底层钱包提供商之间的连接器。例如，用于连接环面钱包的适配器在web3auth下可用为。每个适配器在成功的用户登录时公开提供程序，可用于调用钱包和连接的区块链上的RPC调用。
此外，您可以让 Web3Auth 安全地将用户的私钥公开到应用程序的前端。使用私钥，您可以使用您选择的钱包在应用程序中进行进一步的交易。
下图描述了Web3Auth SDK与集成应用程序之间的关系。

Web3Auth的密钥管理

在本文档中，我们将进一步描述 Web3Auth 的体系结构，并详细介绍了用于载入、密钥恢复和设备管理的几个核心用户流。

基本 Web3Auth 关键基础架构保证

使用Web3Auth，用户处理类似于多因素帐户的密钥，他们使用OAuth登录，设备和其他因素来管理其密钥对。在此示例中，用户首先生成 3 个（2/3） Shamir秘密共享中的2个。这为用户提供了三个共享：ShareA、ShareB和ShareC。

1. ShareA 存储在用户的设备上：实现是特定于设备和系统的。例如，在移动设备上，共享可以存储在通过生物识别技术保护的设备存储中。
2. ShareB由通过节点运算符的登录服务管理：该共享在节点网络中进一步拆分，并通过传统的身份验证流进行检索。
3. ShareC是一个恢复共享：由用户保留的额外共享，可能保存在单独的设备上，下载或基于具有足够熵（例如密码，安全问题，硬件设备等）的用户输入。

与现有的2FA系统类似，用户需要证明至少拥有3份秘密中的2份，以便检索其私钥。此初始设置提供了几个优点。

非保管

使用Web3Auth，用户始终可以控制其加密密钥对的所有权和访问权限。登录服务只能访问一个共享，因此提供商无法自行检索用户的私钥。

感觉就像 Web 2.0 登录流程，在日常工作中，Web3Auth 允许通过与 Web2.0 登录无区别的流访问用户密钥对，从而大大改善用户体验和登录。

改进了密钥恢复和冗余

在设备/共享丢失的情况下，共享阈值中内置了冗余，以便用户仍可以恢复其密钥。还可以刷新共享，以便吊销丢失的共享。
这是对在一张纸上写下助记词的改进，因为丢失助记词可以完全访问私钥。但是，只要用户在不刷新其现有共享的情况下不丢失多个共享，丢失共享是可以接受的。

增量式安全

用户可以通过将2/3阈值增加到更高的阈值来提高其密钥的安全性。例如，用户可以将阈值从2/3增加到3/4，并添加另一个身份验证因素（如硬件设备）。如果用户的私钥上有大量的加密货币，这可能是必要的。

通过本机签名与区块链/平台无关

Web3Auth生成的接口是一个本机加密密钥对，使其与各种平台和椭圆曲线上的几乎所有加密构造兼容。秘密共享和共享刷新也是完全在链下完成的，这使得Web3Auth可用于智能合约功能有限的区块链。

抵抗审查

使用2/3阈值还可以防止Torus节点的审查。如果节点拒绝返回用户私钥的共享，即使用户已成功通过身份验证，用户仍可以使用 ShareA（设备共享）和 ShareC（恢复共享）重建其私钥。

密钥管理中的技术架构

Torus节点（或服务提供者）

Torus节点基于某种形式的用户认证提供特定于用户的密钥。这种认证可以是现有账户的OAuth登录，也可以是传统的电子邮件账户登录，甚至可以是生物识别。Torus节点不需要返回私钥，但需要完成接口：

1. retrievePubKey()
2. encrypt(msg, pubKey)
3. decrypt(msg)
4. sign(msg)

为了便于说明，本文的其余部分假设这是用secp256k1 keys和ECIES实现的。从Torus节点获取的密钥称为encryption key或encKey。

存储层

存储层是一个持久化的数据存储层，用于存储加密的元数据。此类系统的例子包括IPFS、Arweave、Sia，甚至是BFT层。数据可用性和成本是需要考虑的主要因素，但存储层的选择最终取决于实现者。
TKI利用来自torus节点的encKey作为检索私钥的入口点。encKey用于从存储层检索加密的用户特定数据，这些数据称为元数据。这些数据包括用户阈值、多项式承诺、关联设备等。

用户设备

TKI依赖于用户设备来存储共享。基本流容纳单个设备，但用户可以使用多个设备来增加阈值，一旦他们有了初始设置。访问用户设备上的设备存储是特定于实现的。例如，对于移动设备上的原生应用程序，它们可以使用设备keychain。

共享恢复

这通常不会在正常操作期间使用，而是在用户丢失设备或共享时用于密钥恢复/共享刷新。

密钥初始化与重构

在用户触发的操作(例如:登录到Torus节点)。然后，我们尝试为用户检索相关的元数据。如果不存在，则该用户是新用户，我们使用其各自的密钥和份额生成相应的SSS 2/3多项式。如果存在，我们使用Torus节点encKey解密元数据，并读取元数据来验证用户信息和相关的秘密共享参数。

初始化

我们选择在的多项式上，其中：

• 表示用户使用的私钥标量；
• 是的系数；
• ，和分别为ShareA, ShareB和ShareC

ShareA存储在用户设备上，ShareB使用encKey加密并存储在存储层以备将来检索，而ShareC则依赖于用户输入或作为恢复共享处理。

如果用户以前登录过，他/她通过解密ShareB（通过存储层检索）并使用拉格朗日插值将其与用户当前设备上的ShareA结合来重建他们的密钥。

具有确定份额的密钥生成

有了用户输入，我们可以在SSS多项式的生成中预先确定单个份额，其中我们将份额或与用户输入挂钩。设H是密码学上安全的散列函数。

给定在上选择σ并求解

在秘密共享的情况下，我们还可以在给定和输入的情况下，确定地生成多项式。只要，我们就可以将给定的值赋给密钥或份额，其中d是SSS多项式f(z)的次数。

重要的是，输入在生成时具有足够的熵。一种保证这一点的潜在方法是使用几个安全问题（例如其中三个），答案是A,B,C，以导出。这可以通过问题存储库来实现，问题的顺序和索引可以在元数据中定义。

候选合格的问题建议是具有确定性答案的问题（即：“你父母的生日”或“你出生的城市”），而不是“你最喜欢的歌手是谁?”以适应用户容易忘记答案的情况。还有一种通过SSS分割答案本身的可能性，这样用户可以回答3/5个问题，从而产生冗余。

在新设备的情况下，用户需要迁移一个共享到该设备以重建他们的密钥。这可以通过用户输入或登录到当前设备来完成。

在新设备上重建时，我们设置共享为。

利用存储层，我们能够为所有设备生成新的共享，无论它们是在线还是离线。这允许我们从共享中删除设备，允许用户更改他们的安全问题和/或调整他们的安全阈值。这里的关键概念是利用已发布的份额承诺作为加密密钥，在最新的SSS多项式上检索份额。

以2/4的SSS共享f(z)为例，共享保存在3个用户设备和Torus节点上。设g是一个乘子群的产生子群，其中假定离散对数问题难以求解。在密钥初始化时，我们创建共享承诺，，，并将其存储在存储层。这些份额承诺类似于从份额标量派生的公钥。

假设用户丢失了持有的设备D，并希望使该共享冗余。他/她首先在设备a上重构他们的密钥。我们利用基于公钥的加密方案。

用户在相同的上生成一个新的2/3 SSS多项式，该多项式包含份额，并对每个份额承诺加密新生成的份额，丢失的承诺除外。

对于和，，其中，加密后的密文将存储在存储层，以供其他设备检索。

在登录到设备B时，用户检索到的能够使用解密新的，并以类似的方式用从Torus节点派生的重建其密钥。使用允许也作为份额被弃用。

重新共享允许我们在具有不同次数/阈值的新多项式上共享密钥，也允许我们增加用户的安全/因素设备或输入，以根据他们的需要重构他们的密钥。这可以根据需要逐步完成。

与传统的密钥管理相比，TKI在可恢复性、可用性和灵活性等方面有了很大的提高。它还允许撤销共享和编辑用户密钥的访问结构。今天，我们确实有multi-sig和智能合约钱包（SCW），它们持有提供类似属性的资产。它们工作得很好，TKI可以用作这些结构的外部密钥。相对于这些工具，因为TKI是围绕着管理本地私钥进行的，所以它的可组合性要高得多。

虽然链上multi-sig/SCW可以实现大多数功能，但在实现方面有一些细微差别需要考虑。例如，在链上，它们被限制在它们实现的第1层链上，限制了与其他第2层可伸缩性解决方案或其他区块链的互操作性。智能合约钱包的部署费用也可能昂贵且缓慢，这增加了用户摩擦。

该模型还具有一定的灵活性，可以根据用户的需求，对SSS阈值进行不同的配置，以平衡方便性、安全性和冗余性。

未来的发展方向

基于门限签名的主动秘密共享方案

TKI可以与门限签名方案相结合，在对交易进行签名时，不需要在已有的前端构造密钥，从而提高了安全性。还可以通过分布式密钥生成的方式生成初始私钥，确保私钥完全不需要重构。在这种情况下，可以通过参与者动态的主动秘密共享方案实现对一个新多项式的份额的再共享。

各节点的作用

Torus节点之间运行一个分布式密钥生成协议来分配、存储和返回密钥给用户。一般来说，在Torus密钥基础设施中，节点管理通过传统OAuth流检索的份额。

该架构由四个部分组成：

• 分布式密钥生成（DKG）节点
• 一个负责管理节点的智能合约
• 节点间的私有BFT网络
• 与节点交互的前端客户端/SDK

智能合约用于节点发现。选择节点，运行一段固定的时间，并通过DKG生成一组密钥。‌
当用户到达DApp时，客户端将被加载。从那里，用户登录，他们提供他们登录的证明，并由每个节点单独验证。这个证明与现代OAuth 2.0令牌身份验证流程集成在一起。对于新用户，节点将从预先生成的密钥份额集合中分配一个新的密钥份额，并将此分配存储在内部映射中。对于返回的用户，节点将查找其内部映射并返回该用户对应的密钥份额。‌
然后，客户端在前端组装这些共享并重构用户密钥。

生命周期

本文档描述Torus节点在运行Torus网络中的作用。

时期

Torus节点在一定的时间段内运行，称为epoch。同一epoch内的节点属于同一个BFT网络，并且节点所持有的密钥份额与其他节点的密钥份额相匹配。不同时代的节点则不然。epochs的主要目的是确保节点操作符可以被删除和添加，并将随着时间的推移密钥份额丢失或节点故障的影响降到最低。

初始化

当一个Torus节点启动时，该节点尝试在以太坊智能合约上注册它的连接细节。一旦所有节点都注册了该epoch，它们就会尝试相互连接以建立BFT网络，并开始生成分布式密钥。它们还监听来自前一阶段节点的信息。

操作

在操作期间，Torus节点运行三个独立的并行进程：一个将用户id映射到密钥，一个生成分布式密钥份额，一个允许用户检索其份额。
映射过程主要与BFT层交互，该层允许节点共享属于哪个用户的键的状态。当新用户请求密钥时，节点提交一个修改此状态的BFT事务。将已登录的现有用户与此共享状态进行比较，以确保他们检索正确的密钥共享。
分布式密钥生成过程主要使用libp2p进行节点间通信，并生成共享密钥缓冲区，以减少新用户分配密钥的平均响应时间。
当用户希望检索他们的密钥时，共享检索过程开始。他们通过提交-揭示方案分别向节点提交他们的OAuth令牌，一旦这个OAuth令牌被检查唯一性和有效性，每个节点返回用户的(加密的)密钥份额。这并不需要节点之间的通信。
假设缓冲区中至少有一个未分配的键，那么向新用户分配键只需要与映射过程交互。因此，我们能够在账户的所有者决定登录并重建密钥之前，提前将密钥分配给账户。这构成了我们的账户解析器api的基础。

迁移

当一个epoch结束时，当前节点操作符就下一个epoch达成一致，并将有关当前映射状态和现有键的信息发送给下一个epoch的下一组节点。这是通过典型的可靠的广播映射方法和PSS （proactive secret sharing，主动秘密共享）密钥份额实现的。

信任的假设

Torus网络基于两个主要的阈值假设:密钥生成阈值（>1/4）和密钥检索阈值（>1/2）。为新用户生成密钥需要3/4以上的节点诚实操作，为已有用户重构密钥需要1/2以上的节点诚实操作。有关更多信息，请参阅AVSS中的双阈值构造。
当大多数秘密共享方案采用2/3诚实多数和1/3重构门限时，我们更倾向于系统完全失败而不是密钥被窃取‌。

密钥生成和重新共享

密钥生成

由于密钥生成是一个需要几轮通信的活动，所以当用户需要新的密钥时就这样做是不明智的。相反，我们提前生成未分配密钥的缓冲区，这样我们只需要在用户请求新密钥时将它们分配给用户。‌
我们通过Cachin等人2002年提出的一个称为异步可验证秘密共享(AVSS)的加密方案来运行分布式密钥生成（DKG）。DKG与其他著名的DKG（如Pedersen DKG, Feldman的VSS及其变体）相比的主要优势是，它是完全异步的，因此当我们考虑到小的零知识证明时，不需要投诉阶段。这导致了更简单的实现(即使在恶意场景中，通信轮数也不变)，但以牺牲消息大小为代价。
简而言之，该方案生成一个随机二元多项式（即二维曲面），并在适当的索引处创建水平(X)和垂直(Y)切片作为共享。然后，我们在适当的索引上得到水平和垂直共享上的子共享（点），并将它们返回给其他节点。作为节点，从其他节点接收到的共享子重构出的多项式应该与该节点从分发者那里得到的初始共享子匹配，即使不匹配，该节点也可以通过这些重复共享子插值出正确的共享子。这消除了经销商投诉阶段。然后，我们将自己限制在水平(X)域中，这样我们的最终共享仍然在单变量多项式上，这是典型的DKG所做的‌。
在分布式密钥生成过程结束时，节点会得到一个（多项式）共享给主多项式。主多项式是每个参与节点生成的所有初始多项式的和。由于该主多项式的随机性与节点的阈值数量有关，因此任何非阈值节点子集都不可能恢复其系数。
主多项式的常系数就是用户的私钥。

主动秘密共享

Torus网络在多个时期都有作用。每个epoch都有一组节点负责节点操作，当节点操作完成时，它们将必要的状态迁移到下一个epoch的节点上。由于我们的整个系统除了TorusIDs到用户id和私钥的映射之外不存储任何状态，因此唯一需要的系统是跨时代迁移映射和私钥的系统‌
密钥的迁移使用了主动秘密共享（PSS），同样来自AVSS论文。简单地跨epoch复制共享是一个坏主意，因为在两个单独的epoch操作的单个节点操作符将访问两个共享，而且这也导致无法在每个epoch增加或减少操作符的数量。
简而言之，关键思想是我们创建现有密钥份额的多项式共享，并以特定的方式添加这些多项式，使主多项式的系数是现有密钥份额的拉格朗日插值。就像dkg是多个秘密共享的总和，其中主秘密是n个并行秘密共享协议中每个秘密的总和一样，我们可以将n个并行秘密共享协议设置为由原始集合运行，它们的“秘密”作为它们的份额。如果将得到的秘密份额适当相加(先乘以拉格朗日系数)，就会导致对原始秘密的重新共享。

登录，键分配和检索

请务必参考这篇高级文章：Key Assignments, Resolution and Retrieval | by Web3Auth | Web3Auth | Medium

关键任务

密钥被分配给验证者（例如谷歌、Reddit、Discord）和verifier_id（例如email、username）的组合，这是验证者提供的唯一标识符。‌这种分配可以由任何节点触发，并通过节点共识层决定。

验证器和密钥检索

Torus登录的基本流程如下：

1. 你的应用程序通过用户首选的方式（OAuth/电子邮件密码/无密码/验证码）让用户登录。
2. 在用户同意/验证他/她的电子邮件后，Torus SDK将收到一个ID令牌，并根据ID令牌中的用户验证者ID分配一个密钥给用户。
3. 从Torus网络中检索密钥并公开给Web3 provider（DApp）以完成用户登录请求。
4. Torus使用这个ID令牌来检查DApp中是否存在用户的配置文件信息。
   1. 如果是这样，用户将用他们首选的登录登录到DApp。
   2. 如果没有，用户可以用他们首选的登录在DApp上创建一个新帐户。

为了允许使用通用验证器，而不仅仅允许使用OAuth，我们通常需要至少两个api由外部验证器实现：

1. 当用户登录时发出唯一令牌的API。
2. 使用这些令牌并返回用户信息以及令牌何时发出的API。

第一个API必须可以从浏览器访问（例如启用CORS，受限的首部），以确保Torus服务器无法拦截用户的令牌（超前）。
通常，任何满足这两个api并提供唯一ID字符串和时间戳签名的实体都可以成为验证者。这可以扩展到几种身份验证方案，包括现有的身份验证标准，如OAuth令牌流和OpenID Connect.‌

最后保护

为了防止流氓节点，或Torus服务器，通过获取您的令牌，冒充您的登录，从而窃取您的密钥，我们在令牌上使用类似于Bracha的可靠广播的承诺方案，以确保所有节点可以确定阈值数量的其他节点知道承诺，在它最终被披露之前‌。
一般的方法如下:我们确保前端首先获得令牌的访问权，创建一个对令牌的承诺和一个临时公私密钥对，只有当接受该承诺的节点达到阈值时，才显示令牌。然后，节点将使用这个密钥对对共享进行加密，然后再将其发送给用户。
这是通过在前端生成一个临时的公私密钥对来实现的。前端调用第一个API并接收身份验证令牌。对令牌进行哈希处理，前端将令牌哈希和临时公钥发送给每个节点，每个节点如果是第一次看到此令牌承诺，则返回此消息的签名。这些签名的一束就是证明，将证明和未加密的令牌一起提交给每个节点，该节点将以一个用临时公钥加密的密钥份额响应。
攻击1：领先者拦截原始的承诺请求并发送修改后的公钥
在这种情况下，用户将不会收到阈值数量的签名，因此不会暴露他们的令牌。然后他们将被要求再次登录并请求新令牌。由于向节点发出的请求是随机顺序的，最终可以在领跑者收到承诺请求之前达到诚实阈值集。
攻击2：Front-runner拦截泄露请求并重新发送给其他节点
由于公钥已经在承诺请求中与令牌相关联，因此节点将只使用加密的共享进行响应。即使领跑者拦截了加密的股份，他们也无法解密。

代理验证

代理验证器不同于标准验证器或第三方OAuth2登录，因为它们依赖于Torus网络和第三方（谷歌）之间的代理。
这通常是一个登录服务提供商，如Auth0、AWS Cognito或Okta，登录流程的区别如下：

这导致在原始流之上，这些登录对代理也有额外的信任假设。对于涉及代理的集成，我们强烈建议DApps通过包含“注意：以下登录涉及第三方验证：（列出登录 Linkedin, Twitter. etc）”这行来通知用户存在第三方验证。