Authereum 密钥架构解析

Authereum 在提到智能合约账户时使用了不同的密钥概念：admin keys、dapp keys 和 recovery keys。为了更好地理解这些概念，我们先从一些背景信息开始。

背景

基于合约的账户由一组密钥管理，检查这些密钥的签名来确定发送者密钥是否被授权执行某些操作。如果我们考虑一个简单的基于合约的账户，比如一个多重签名合约，多重签名维护一个授权所有者的列表，这个所有者列表是允许发送多重签名交易或调用多重签名方法的地址列表。这些所有者对多重签名的功能拥有完全控制权。

多个所有者控制一个合约

这种单层次的所有者体系适用于大多数情况，但在尝试限制某些所有者可以做什么时，它就不再奏效。例如，可能在控制资金的合约中，你想要拥有根所有者和子所有者，其中子所有者在其可以调用的方法或在特定时间间隔内可以从合约中提取的以太数量上受到限制。对于这种额外的复杂性，智能合约需要像访问控制列表 (ACL) 那样运作，其中每个所有者的权限都包含在合约中。ACL 维护每个参与者可以在每个对象（在本例中为状态）上执行的权限级别。

合约中的 ACL 风格权限规则

向合约引入动态规则和权限的一种方法是使用借鉴自 Web 身份验证标准的概念，如 JSON Web Tokens (JWT)。我们可以让根所有者创建一个编码的令牌，列出子所有者被允许的权限。根所有者然后签署编码信息并创建一个签名。这个令牌现在可以被子所有者用来执行授权交易。在对账户合约的交易方法中，子所有者向合约展示编码的令牌，合约然后通过从签名中恢复签署者来验证这些编码的权限确实是由根所有者授予的。

合约验证子所有者权限的签名证明

本质上，根所有者通过创建签署的证明，证明子所有者有权执行那些功能，这在合约试图验证方法调用时充当证明。

附注：这种基于证明的交易概念最早是在 Authereum 创始文章 中提出的，被称为“auth keys”和“login keys”。自那以来，Authereum 将其重新命名为 admin keys 和 dapp keys，但你可以将它们视为根所有者和子所有者，其中子所有者密钥是为每个 dapp 生成的短暂密钥（dapp keys），权限则由根所有者（admin keys）授予。

Admin Keys

在 Authereum 中，每个基于合约的账户由 admin keys 管理。第一个 admin key 是在用户创建账户时在客户端生成的。

Admin key 创建

私钥是在浏览器中使用 Crypto.getRandomValues() 浏览器 API 假随机数生成器 (PRNG) 生成的，该生成器从 /dev/urandom 读取随机字节，这是在内核级别收集的设备驱动程序噪声的随机熵源，被认为是一种安全生成随机字节的方式。

Admin keys 允许添加其他 admin keys 来管理账户合约或作为恢复备份。例如，一个账户合约可以由两个独立的受信任设备管理，其中每个设备上都有一个唯一的 admin key。在这种情况下，每个设备对账户合约都有完全的保管权，因为它们都是 admin keys。用户可以将硬件冷存储密钥（如 Ledger Nano）添加为 admin key，但将硬件设备存放在一旁，仅在其他 admin keys 丢失或遗忘时使用，因为硬件 admin key 可以删除丢失的地址并将新的已知地址添加到账户合约。用户可以在 Authereum Web 应用程序中添加或移除 admin keys，或者通过发送交易直接到账户合约，只要发送者是另一个 admin key。

将其他 admin keys 添加到账户合约

最初的 admin key 会在用户的浏览器本地存储中生成并存储在域 accounts.authereum.org 下。这意味着其他网站无法直接访问原始密钥，因为只有在该域中加载的脚本可以读取该域的本地存储。Admin key 在客户端使用基于密码的密钥派生函数 (PBKDF2) 进行加密，以生成加密密钥。为了方便起见，Authereum 将加密的 admin key 作为密钥存储在服务器端。用户密码在客户端也被加盐和哈希，生成的摘要存储在服务器端。这使用户可以使用他们的密码对 Authereum 进行身份验证，验证之后 Authereum 然后提供用户加密的密钥存储，该密钥存储随后使用基于密码的加密密钥进行解密。Authereum 后端从不查看原始密码或原始私钥。所有的加密和哈希仅在客户端完成。

Authereum 在注册时要求提供电子邮件和密码，以提供基本级别的 Sybil 保护，因为 Authereum 为账户部署成本提供资金，但更重要的是可以通过电子邮件通知用户其账户中发生的活动。一旦用户注册，他们可以添加额外的 admin keys 并使用这些新密钥进行登录，而不是使用他们的用户名和密码。例如，用户可以选择使用他们的 Ledger 设备登录他们的 Authereum 账户。

在 Authereum 中验证用户需要用户使用 admin key 签名一个挑战字符串，以创建会话令牌。Authereum 在用户成功登录时，在用户加载他们的主要 admin key 时自动为用户执行此操作。用于签署挑战的密钥可以是任何 admin key，因此他们可以使用硬件设备甚至是作为 admin key 列出的注入 Web3 账户来创建会话令牌。

签署挑战字符串以创建会话令牌

有效的会话令牌在从 Web 应用程序向后端发起请求时是必需的，这以 Bearer Authentication 请求头的形式提供用户与其账户相关的附加信息，其中请求的账户信息来自于会话令牌的签名。会话令牌的形式为 JWT。

后端通过用户签名的会话令牌进行请求认证

一种类似 JWT 的以太坊标准 ethwebtoken 正在开发中。该令牌标准将允许在后端和智能合约中使用相同的令牌。

需要强调的是，额外的 admin keys 应该以安全的方式保存，因为任何被泄露的 admin key 都可能危及整个账户合约，因为它们对账户拥有完全权限。然而，可以要求 n of m 签名以添加额外的 admin keys，这样攻击者就需要多个 admin key 来添加额外的 admin keys，使账户更安全。

Dapp Keys

现在我们对 admin keys 在 Authereum 合约账户中的角色有了更好的理解，我们来深入探讨 dapp keys。如前所述，用于签署交易的 admin key 被加载到 Authereum 控制的域下的本地存储中。对 Authereum 来说，尽可能安全地保留这个 admin key 并限制未经授权的参与者访问它是非常重要的。这现在产生了一个小问题；不同域下的 dapp 如何使用这个密钥来签署交易，如果它们无法访问签署密钥？在每个 dapp 上复制 admin key 是不明智的，因为这样一来每个 dapp 以及 dapp 上的第三方脚本都会完全访问用户的账户合约。为每个 dapp 生成一个新的 admin key 并创建一个链上交易将新密钥作为 admin key 添加到账户合约，也是不经济的。

如果你还记得之前所说的，我们讨论了如何创建一个证明以声明子密钥应具有什么权限集。这完美契合，因为现在 admin key 可以证明其他密钥及其新角色的真实性。当用户需要与 dapp 交互时，Authereum 会生成一个新的短暂密钥，供特定 dapp 的交易签名使用。与 Authereum 的登录流程为 dapp 发起一个 Oauth2 风格的重定向或弹出窗口，将公共地址与 dapp 密钥一起发送到 accounts.authereum.org，用户现在可以确认日志请求，这涉及使用 admin key 创建签署的证明。创建 dapp key 证明签名后，弹出窗口将关闭或用户被重定向回 dapp，并可以开始与 dapp 进行交易。使用重定向或弹出窗口的好处在于，该网址易于验证，以防止点击劫持或伪造 UI 冒充 Authereum。

dapp 身份验证过程的高层概述

Authereum 作为一个 Web3 提供者被提供，这意味着 dapp 开发人员可以将 Authereum 用作 MetaMask 或其所依赖的注入 Web3 提供者的替代品。使用 Authereum SDK 或 Authereum web3 提供者将使用 dapp key 签署交易。

Authereum web3 提供者签署交易

为了从账户合约调用方法，交易调用必须来自于账户方法。账户合约只接受来自 admin keys 的交易签名者或通过 admin key 的签署证明被授予权利的签名者。这意味着该交易必须通过接受原始交易数据和 admin key 证明的智能合约方法进行中继。智能合约验证证明的签署者是账户合约的 admin key。然后，它验证该证明令牌没有过期，并且目标地址和目标方法 ID 是否被允许由 dapp key 调用。这是基于合约的账户的一个巨大优势，即它可以在链上限制不同密钥能够调用哪些合约和合约方法。一个比喻是对 dapp 的“家长控制”，其中 dapp keys 在可以执行的操作上受到限制。

来自 dapp key 的签署交易数据被发送至 Authereum 中继器。中继器提取 admin key 证明并调用账户密钥上的元交易方法。因为中继器是广播交易的那个，因此它负责支付 ETH 的交易手续费，但在元交易调用中，中继器会适当地通过 dapp key 账户所有者以 ETH 或 DAI 等令牌获得赔偿。

Authereum 中继 dapp key 签名的交易

账户合约从证明中派生签署地址，并验证其是否为有效的 admin key。签名负载中的一部分也是过期时间戳，这意味着 dapp keys 是短暂的，并在指定时间后到期。时间戳与当前区块时间进行对比，以确保其有效性。如果签名负载中有允许的方法 ID，则该 ID 也会与当前目标方法 ID 进行比较，以确保 dapp key 被允许进行与目标合约上指定方法的交易。之后，合约调用目标地址，传递 dapp key 签署的交易调用数据，并发出执行状态代码的事件。在调用过程中，元交易不能回滚，这一点很重要，否则中继器不会在执行过程结束时获得赔偿。

dapp keys 的存储也必须与 admin keys 一样安全。因此，不建议将原始 dapp keys 存放在每个 dapp 的本地存储中，因为这样一来，dapp 或 dapp 上的第三方脚本可以读取私钥，并在用户未意识到的情况下执行任意交易。为了解决这个问题，所有 dapp keys 被存放在一个特殊的子域；x.authereum.org。由于子域由 Authereum 管理，因此页面上加载的 JavaScript 被减少了，第三方脚本也都是经过验证的。这个子域页面没有用户界面，其唯一目的是存储 dapp keys。

如之前所述，另一个域无法直接访问另一个域的本地存储。那么，位于不同域的 dapp 如何使用 dapp keys 签署交易呢？答案是通过 iframe 进行沟通。Authereum SDK 和 web3 提供者在 dapp 页面上加载一个隐藏的 iframe，以向存储在浏览器本地存储中的 x.authereum.org 子域发送消息请求。在这种架构中，dapp 无法读取原始的 dapp keys，因为它们处于沙箱中。dapp 只能向 iframe 中隐藏的页面发出签署请求。

Authereum web3 提供者与 dapp key 提供者进行通信

由于 Authereum 管理着 iframe 页面，因此可以监控请求并提醒用户对未被发现的请求。这个模式的另一个优点是，当用户愿望或用户从 Authereum web 应用程序注销时，所有 dapp keys 都可以被清除，因为所有 dapp keys 都在一个安全的中心位置管理。难道这并不意味着 Authereum 可以审查 dapp keys 的交易？dapp key 的架构不是抗审查的，因为 Authereum 通过中继提供了额外的安全层，这意味着所有 dapp key 的交易必须经过 Authereum 中继。然而，用户可以使用他们的 admin key 与 dapp 进行交互，从而绕过所有 Authereum 服务，直接与他们的账户合约进行交互。在任何时候，用户都可以选择退出 Authereum 服务，但仍然保留他们基于合约的账户的完全保管权。Authereum 提供额外的服务，以便于用户的便利和安全，代价是它可以在怀疑交易恶意时扣留 dapp key 的交易。Authereum 将其称为 Authereum 交易防火墙 (ATF)，因为它可以防止来自于与创建dapp key不同的来源的 dapp key 交易的广播。例如，如果 dapp key 在 alicedapp.com 上创建，但中继器然后看到交易来自于 bobdapp.com，则中继器可以停止广播并通过电子邮件或短信通知用户有关此活动。用户可以选择将可疑交易的来源域列入黑名单，或者允许该交易通过。

如果来源不匹配，Authereum 中继器将不会广播交易

恢复密钥

Authereum 中使用的另一种密钥被称为 recovery keys。它们的作用非常简单；仅用于添加其他 admin keys。用户可以将任何地址添加为恢复密钥。当用户丢失或忘掉所有 admin keys 时，用户可以通过在账户合约上调用恢复方法并传递 admin key 地址来启动添加另一个 admin key 的过程。恢复过程不会立即添加另一个 admin key。相反，它会开始指定时间的时间锁，以便给其他 admin key 取消恢复请求留出充足的时间，以防恢复密钥本身已被泄露。在超时期之后，admin key 将被添加到账户中。

添加新 admin key 的恢复过程

为了加快恢复过程，用户可以选择要求 n 个 m ( n>1 ) 个恢复密钥才能添加新的 admin key。这意味着用户可以添加其他设备地址或他们最亲密的受信任的同龄人或家人的账户地址作为恢复密钥（社交恢复），因此在用户的设备被丢失或密钥存储解密密码被遗忘的情况下，用户可以提交来自恢复密钥的签名给基于合约的账户，一旦达到阈值，则将删除旧的 admin key 并添加新的 admin key。

使用多个恢复密钥时恢复过程是即时的

结论

本文介绍了 Authereum 密钥架构中 admin key 和 dapp key 概念的基础知识。Admin keys 是根账户合约密钥，拥有对合约的完全访问权限。任何 admin key 都可以添加其他 admin key。Dapp keys 是在每个 dapp 实例上生成的密钥。这些密钥是短期的，并且权限有限。Admin key 必须为每个 dapp key 创建签署的证明，声明它们在账户合约上有什么权限。Recovery keys 仅用于在丢失所有 admin keys 的情况下添加新的 admin keys。恢复密钥启动一个时间锁期，以便有足够的时间来取消请求。Authereum 提供一个中继服务，以便交易可以用不同的令牌支付，同时还提供用户额外的安全性和通知。

在撰写本文时，一些提到的功能尚在开发中，并将很快上线。请确保在 authereum.org 注册等待名单，以获取 Authereum 的早期访问权限。不要忘记在 @authereum 上关注我们。

感谢你的阅读！

更新 2020年1月30日

Authereum 从 authereum.org 迁移到 authereum.com，并使用 authereum.com 而不是 accounts.authereum.org 作为钱包。

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