在加密货币世界中,“Not your keys, not your coins”的观念深入人心。但权力越大,责任也越大。没有中心化的服务提供商,用户需要自己管理密钥的整个生命周期,包括密钥的生成、分发、存储、使用、更新、作废以及恢复。对小白来说可谓战战兢兢,时刻面临密钥丢失造成的资产或控制权丢失风险。这极大的损害了用户体验,影响区块链的推广和普及。

如何设计安全的密钥管理系统,实现足够的冗余,提供可靠的密钥恢复能力,是区块链行业面临的一大挑战。本文介绍一种基于智能合约的社交密钥恢复功能,它的核心思想来自social-recovery-using-address-book-merkle-proofs,并且在EIP2429中得以标准化。

社交密钥恢复

社交密钥恢复的思想由来已久。

在传统的web应用中,中心化的服务提供商会提供一系列的密钥恢复途径,比如:

  1. 用户可以预留经过验证的手机号,邮箱,密码丢失时通过它们重设密码;
  2. 在微信这类IM应用中,还可以提前设置几个亲密的联系人,用于在账户被冻结情况下的协助验证解封。

这些做法本质上都是提供了一个冗余的多因子身份认证。

在区块链上,用户的身份往往由公钥代表,他的所有数据都和这个身份绑定,这些数据可能包括:1. 账户余额;2. DAO里面的角色和权限,等等。私钥一旦丢失,可以认为在当下的计算能力下是无法再恢复的。但可以设置一个新公钥,绑定到丢失公钥的数据上,或者是代理丢失公钥的所有操作权限。这只能由智能合约来实现。

一个简单的方案可以是这样的:

Alice持有一对密钥 < secret_a, public_a> ,她的账户public_a里面转入了100个token。她为了防止密钥丢失,将Bob,Charlie, Dave作为恢复密钥的委托人,三者的公钥分别为{public_b, public_c, public_d}。Alice还设置了一个域值,任意两个人协助认证都可以重新设置公钥。这样就是一个最简单的2/3链上门限密钥恢复方案。

有天Alice真的丢失了自己的密钥,她重新生成了一对密钥< secret_a_1, public_a_1> ,找Bob和Charlie帮助,二者分别使用各自的密钥调用合约的恢复密钥接口,提交两笔交易tx1 = {(public_a, public_a_1, public_b), signature_of_bob}, tx2 = {(public_a, public_a_1, public_c), signature_of_charlie}。这样合约验证后通过了门限检查,就可以将public_a的账户所有人替换为public_a_1,Alice成功找回了这笔资产啦!

隐私保护?

上面的方案存在几个可能被攻击的方面:

  1. Bob, Charlie, Dave三人看到自己作为恢复功能的委托人,可能会共谋私自替换掉密钥,夺走这笔资产;
  2. 假设Bob, Charlie, Dave都是不作恶的好人,但由于他们的公钥在区块链是公开可查询的,攻击者可能选择攻击这三人中的薄弱环节,直到获取足够的私钥;
  3. 攻击者在直到Bob, Charlie, Dave身份的情况下,还可能模仿Alice的身份(使用AI模仿声音、视频已经很成熟!),向他们发起恢复密钥的请求;

为了避免这些攻击,不同的方法可以被采用,比如所有的密钥恢复过程存在一个锁定期(lock period),在锁定期内Alice发现有人恶意重置公钥,在她私钥没有丢失的情况下,可以主动终止密钥恢复过程。当然这需要一些通知机制的配合。也可以再增加一些经济上的惩罚措施,任何企图恢复密钥的人需要提前存一笔指定额度的资金,正常流程下在结束后会返还,但作恶情况下会被slash。

但如果仔细思考,很容易意识到,这里列举的攻击方法都由于Alice的协助恢复委托人账户在链上是公开可见的,缺乏隐私性。如果委托人的身份在链上是“加密”的,但同样能执行后续的验证过程,是否就能很好的降低风险呢?

协助验证的交易{(public_a, public_a_1, public_x), signature_of_x},本质上是需要证明该交易的签名者是委托人集合的一份子,也就是成员证明,membership proof。但由于保护隐私的要求,我们在链上又不能存储成员的明文。

默克尔证明

一种可行的方案是使用默克尔树,这个区块链里面频繁使用的数据结构,它不仅能够提供防篡改的功能,也能作为成员证明的工具。

比如,上图中的绿色叶节点是树的一部分,提供其中三个黄色的节点哈希,形成一条到根节点路径,即一个合法的默克尔证明(merkle proof)。

其他方案,甚至是具有零知识性质的成员证明工具也可以作为思考的一个方向。

概念实现(PoC)

基于上面的讨论,这里给出一个保护隐私的链上密钥恢复方案:

  1. Alice本地存储了Bob, Charlie, Dave等人的公钥薄,以这些公钥作为叶节点,生成一颗默克尔树,她将根哈希(root hash)提交到合约里,同时设置恢复阈值等参数;
  2. 在密钥恢复过程中,Alice寻求Bob, Charlie的帮助,Bob对Alice的新公钥进行签名,Alice也生成了一个Bob的默克尔证明,提交交易tx1 = {public_a, public_a_1, public_b, signature_b, proof_of_bob_membership},合约验证交易签名合法性和证明有效性,并且记录下bob的公钥,类似重复,直到满足阈值。

这个方案较好的解决了前面的攻击可能:

  1. Bob可能直到自己是委托人,但他并不知道其他委托人,则无法形成共谋;
  2. 链上只有一个root hash,不会泄漏委托人的身份,则不会被定向攻击;
  3. 攻击者在未获得Alice本地的地址薄时也就无法伪造身份发送恢复请求;

这是基于substrate的social-recovery组件,我开发的一个PoC,增加了隐私保护功能,代码参考:https://github.com/bitrocks/secret-social-recovery.