Cheers Up AMA记录:聊聊钱包技术

22-11-05 11:51
阅读本文需 37 分钟
总结 AI 总结
看总结 收起

Kitty:大家好,我是 NextDAO 的 Lead Mod Kitty。很开心收到 Cheers Up 的邀请和信任,让我来主持今晚的活动,今天是我第一次主持这么强技术相关的主题,作为一个技术小白,专门提前做了一些功课。还好今天的嘉宾老师们都在 Mirror,Twitter 上有过内容产出,给我提供了一些学习资料。


本次活动嘉宾包括慢雾团队、Cobo、知名KOL 知县,以及 Cheers Up团队。


Kitty: OK,先跟大家介绍一下,为什么会有今天这个主题的活动。在隔壁都在聊香港新政,聊行情的时候,咱在这儿聊安全。


其实在 Web3 世界里钱包的安全性一直是个很大的问题和热点。我们几乎每天都能看到某项目方的钱包被盗了,价值多少多少万美元。


最近的一次大范围被盗可能是今年 8 月份  Solona 生态上的钱包,总共有 9000 多个钱包被清空。今天凌晨,Deribit 的热钱包被盗了 2800 万美金。所以说钱包安全,不仅对于 Web2 想进入 Web3 的人来说是个大门槛,对于已经在 Web3 的用户来说,也是一片黑暗森林。我们每天会收到无数个陌生链接,通过 Twitter,discord,甚至微信群发给你,可能你无意中点一下授权,钱包里的小图片就不见了。 


那 CheersUP 作为一个 NFT 项目方也很关心 holder 们的钱包安全,因为很多买 NFT 的朋友并不太知道钱包里潜在的风险,因为玩 NFT 的用户整体上都很年轻,他们踏入 Web3 的第一步,可能就是买 NFT。所以我们也希望通过今天的活动能让 holder 们网上冲浪的时候,能更多留意这个事情。


好,那咱们接下来就进入正式的 AMA 环节。首先,聊钱包的话,就不得不聊助记词,很多人说助记词是反人性的东西,因为现在的 MPC 技术其实理论上是可以达到不用用户自己去保管助记词,那第一个问题就是,


MPC 是什么样的技术,它能达到什么样的效果?MPC 和托管有关系吗?这个问题,先邀请 Cobo 的朋友回答吧。


Cobo:MPC 指的是多方安全计算,我这里先引用下学术上对 MPC 的一个定义:MPC 指的是在无可信第三方的情况下,多个参与方协同计算一个约定函数,除计算结果以外,各参与方无法通过计算过程中的交互数据推断出其他参与方的原始数据;这个定义比较拗口,简单来说,就是在保证各自数据隐私的前提下,基于大家的隐私数据完成一个协同计算;这里可以举个更具体的例子,假设 A 和 B 是两个百万富翁,他们想知道谁更有钱,但是又不想暴露自己的具体资产数额,这时他们就可以通过使用 MPC 的技术来计算,在满足隐私的前提下,得到谁更有钱这个结论。


刚刚说的这个例子是姚期智先生在 80 年代提出的著名的百万富翁问题,这个问题也是整个 MPC 学术领域的一个开创性的问题。


Kitty:我怎么听你说的这个意思,MPC 技术跟 ZK 零知识证明很像呢?都是在不暴露或者少暴露隐私的情况下,就能得到答案或者完成计算。


Cobo: 是的,MPC 的问题具体来说也可以在细分为一些不同的安全模型,一种比较简单的模型是,假设参与方都是诚实的,他们仅仅只是不想暴露各自的隐私,但是每个人都不会作恶,此时 MPC 运算会相对容易实现;另一种更通用的模型是,假设参与方相互之间是不信任的,是有作恶的可能性的,此时的 MPC 运算,一般都需要结合零知识证明才能得到正确的最终结果。


具体到我们的数字货币钱包,其实我们目前真正会用到的是 TSS(也就是门限签名算法),门限签名算法中会用到一些 MPC 的技术来解决核心的隐私计算问题,所以可以认为门限签名技术是 MPC 的一个具体应用。而且此时会假设参与方之间是不信任的,所以如果大家深入去看门限签名算法的实现,里面大量采用了零知识证明的方式去确保没有人作恶。我们目前大部分时候为了简单,就直接把门限签名钱包称作为 MPC 钱包了,不过这些基础概念还是希望给大家讲清楚的。


Kitty:那目前支持 MPC 的产品有哪些呢?


Cobo: 目前支持 MPC 的产品已经有很多了,我这里可能无法一一列举,就说几个我印象比较深的吧;ToC 的产品中,ZenGo 是我觉得目前在产品层面和在开源贡献方面都做的很不错的一家公司,他们应该也是这个方向最早期的创业公司之一;ToB 方面,目前市场份额最大的应该还是 Fireblocks,此外安全鹭是一个我们华人的创业项目,他们在产品层面以及开源贡献方面也都是做的非常不错的,Cobo 也参与了安全鹭这个项目的投资;同时,我们 Cobo 的 Custody 服务目前也在增加 MPC 的支持,在很近的将来(应该就是最近一两个月),也会对外提供 MPC 协管钱包的服务,感兴趣的小伙伴可以关注下。


Kitty:不错不错,支持。看看慢雾的朋友有没有补充。


慢雾:MPC 的英文全称为:Multi-Party Computation,也就是多方计算,它是一种密码学技术,通过该技术,所有参与方为了完成一项任务而执行复杂的联合计算,而他们的数据保持私有和安全,不与其他参与方共享。


具体到 MPC 钱包,或者更加专门化的门限签名钱包,通过对私钥进行多方计算在链下实现安全的多方共同管理账户等复杂的验证方式。

简单来说,就是将一个私钥安全打碎成多片,由多方共同管理;或者干脆就是多方共同生成一个虚拟的密钥,可能后者的情形更为普遍,因为这时候没有人曾经见过完整的私钥。这也是虚拟的意思。


MPC 的核心思路为分散控制权以达到分散风险或提高备灾的目的,有效避免了单点故障等安全问题。

 

Cobo 已经将 MPC 是什么讲得比较清楚了,所以这边不多介绍关于 MPC 的概念了。我们知道一项新技术的产生必然是为了解决某些痛点。就像主持人刚刚讲到助记词是反人性的东西,用户必须要小心翼翼的去保管它。那么从安全角度来讲,私钥或者助记词其实是一个单点故障问题,一旦被盗或者丢失就很难挽回。那么 MPC 钱包出现也是为了能够解决单点故障的问题。


我们经过大量钱包钓鱼案例总结,发现 web3 钱包在钓鱼手法方面一般可以分为三大类别,盗助记词或私钥 (如:假钱包 APP 钱包插件钱包)、恶意修改转账的目标地址 (如:假交易平台 APP,假社交软件 TG),另外一种是发生在真的钱包,但是攻击者通过欺骗批准签名恶意的交易来盗取用户的资产。


那么 MPC 由于 seedless 的机制所以天然防御盗取私钥的手法,不过在应对其他钓鱼手法时仍需要钱包额外的加强防御和安全提醒。


另外,我们近期也审计了几个 MPC 钱包,我们也会发现在创建或者备份过程存在一个生物识别认证过程,然后才开始进入备份或者恢复备份,这里就可以通过验证 APP 的签名的方式来识别 APP 是否为官网的钱包,防止用户使用来恶意的钱包还能够恢复备份。


另外,即使钱包采用了 MPC 架构,我们从审计的角度来看,也要去看 MPC 的实现上是否安全。大致就补充这些。


Cheers Up:关于 MPC 我补充一下。在签名场景,MPC 可能有两种主要的技术,一种是门限签名技术,英文叫做 TSS,一种是秘密分割技术,也就是 Shamir’s Secret Sharing 或者简称 SSS。两者的区别在于,门限签名技术 TSS 直接就签名了,而秘密分割技术 SSS 则主要是加解密信息。


当需要私钥签名时,如果使用门限签名技术的话,一般并不需要将碎片再拼接起来形成一个完整的私钥。而是各方按照既定的安全协议要求,使用各自掌握的碎片执行计算,并将各自的计算结果合成为一个完整的签名。需要注意的是,在这个过程中,不需要恢复完整的私钥。这是门限签名技术的一个核心安全性。


而所谓的 Shamir’s Secret Sharing 算法,使用 SSS 这种技术的话往往需要首先恢复密钥。这看起来不如门限签名技术安全,但在特定的场合,可能更加适用。例如,如果被分享的秘密并非种子或者私钥,而是对称加密算法的密码,用来加密进一步的信息,那么这个场合可能更加适用 SSS 技术。当然,用来重建秘密的设备或者计算机,需要专门的安全加固,甚至可以使用一些机密计算技术来加以进一步的安全保证。


Kitty: 这里我想补充问一句,为什么我们现在用的钱包是助记词外显呢?不管是 onekey,keystone,这种硬件钱包,还是我们更常用的小狐狸或者 imtoken,都需要记下一大串助记词。是因为 MPC 技术还不成熟吗?


Cheers Up:没错,门限签名技术看上去非常安全,那么为什么到最近才开始讨论比较多呢?这是因为以太坊使用的签名算法 ECDSA,它对私钥的使用不像 RSA 签名算法那样,不能很直接就能使用门限签名方案的。这里面其实有一个新技术的研发、成熟、采用的这么一个过程。包括一开始先有一个两方签名的一个算法,可能是 17 年,Lindell 提出来的。


后来到 18 年,才有 m 选 n 的这么算法出现,其中包括 GG18。所谓 m 选 n,就是比如五个人里面出三个人,或者三个人里面出两个人。然后密码学家把算法研究出来,还有一个安全分析的过程,之后才是库的开发和应用的开发。GG18 其实后来到了 21 年的时候被发现有一点点安全上的隐患,修复起来并不难,只是说安全两个字真的不容易。而这还只是说算法方面的安全隐患,具体实现的时候,是否存在实现方面的问题,还是要另外请专家团队来审计的。这就是为什么好几个 TSS 的库都带上了一个安全审计。这也需要一定的时间,包括审计和问题修复、确认等等,可能要几个月的时间。


拉回来说的话,这个门限签名算法其实已经是采纳得非常快的了。前面几位嘉宾介绍的几个产品,背后的团队其实已经是走得比较快的了。


seedless 具体什么意思,是完全没有助记词吗?有哪些技术和产品?


Cobo:seedless 或者说 keyless 指的是在用户的使用过程中,不会显式的出现完整的助记词或者私钥。在门限签名的算法中,包含两个核心的过程,即 KeyGen 私钥生成过程和 Signing 签名过程。在 KeyGen 的过程中,所有参与方通过 MPC 的技术进行运算,最终每个人都会获得一个私钥分片;随后在 Signing 的过程中,每个参与方基于各自的私钥分片进行 MPC 运算来得到合法的签名结果。


在整个流程中,完整的私钥不会显式的出现在任何一台设备上,因此能很好的抵御单点风险。但是在逻辑层面,这个群组的私钥是确实存在的。进一步的,如果参与方遇到一些系统故障,导致门限签名的系统无法运转了,理论上是可以约定一个流程,在某地集合他们各自手中的私钥分片,恢复出一个真实私钥的。当然,这个是一个灾备方案了,只在极端情况下使用。


慢雾:这里的 seed 指的是 seed phrase,就是我们创建钱包的时候经常被要求备份的助记词。那么 seedless 的意思就是「无助记词的」,或者也可以说成「无私钥的」。


注意这个「无」并不是实际意义上的没有密钥,而是指不需要用户备份助记词/私钥或者感知到它们的存在。那么对于钱包而言,也就是钱包不会在任何时候生成或保存完整的私钥和种子短语。在创建无钥匙钱包的整个过程中,私钥不会在任何时间、任何地点被创建或存储。在签署事务时,不涉及私钥,而且私钥在任何时候都不会被重构。


从我们安全审计的角度来看的话,我们会这样说,我们会关注密钥的安全生命周期,生成、存储、使用、备份、销毁这些过程中,都不应该出现完整的私钥或者种子短语。与传统钱包使用私钥签署交易 (这产生了被盗窃的风险) 不同,无密钥钱包能够以分布式的方式与来自不同方的多个密钥股份共同签署交易,而不会将密钥股份相互暴露或暴露给任何其他方。


Kitty :听了前面几位嘉宾的发言,我理解大家说的,之后使用 MPC 技术以后可能不存在一个助记词了,但是每个端上管理的分片或者说碎片,需要如何管理,是不是还要有一些技术上的设计?否则还是需要用户去管理或者备份这个碎片,好像也没有减轻负担呀?


Cobo: MPC 解决的是单点风险的问题,但并不是说用了 MPC 技术之后,就一定高枕无忧了。每一个私钥分片的持有方,其实都应该采用不低于原先单签私钥的安全保管逻辑去管理这个 MPC 私钥分片。


以 Cobo Custody 的业务举例,在原先全托管模式下,我们会采用 SGX 或者 HSM 来保管用户的私钥;在未来基于 MPC 的协管钱包下,我们内部对于我们所持有的 MPC 私钥分片的风控管理逻辑和原先单签私钥的风控管理逻辑是一致的,这部分的安全能力不会有任何的降低。MPC 协管钱包下,对于客户来说,带来的好处是解决了 Cobo 单点故障的风险,但是客户作为 MPC 私钥分片的持有方,承担的安全责任其实是增加了的,我们也会协助客户去搭建一套他们内部的系统去维护这个 MPC 私钥分片的管理和日常使用。


此外,前面提到的例如 ZenGo 之类的 ToC 的 MPC 钱包,他们会为用户设计复杂的 MPC 私钥分片访问、备份恢复等逻辑,一方面要确保客户手里的 MPC 私钥分片不会泄漏,另一方面也要确保 MPC 私钥分片不会由于客户的误操作导致丢失。顺便说一下,有的时候,私钥丢失其实比私钥泄漏更危险,私钥泄漏导致资产被盗了,也许还有一些途径可以让黑客还钱,但是如果私钥丢失了,那就彻底没法找回了。

Kitty 接:所以说 Cobo 的托管服务是,Cobo 和用户双方一起管理一个多签钱包。你们会在用户发生交易的时候,协助用户做风险判断和核对?我之前还以为托管是直接把钱存到你们那里。


Kitty : 你们聊的 MPC 让我想到账户抽象,可以解释下账户抽象是什么意思吗?有哪些便利性?


慢雾:以太坊一共有两种账户:外部账户(externally-owned account)和合约账户(contract account)。


外部账户就是我们平常用来发起交易的钱包账户,它是由私钥控制的,这种账户本身是没有代码的,因此独立于以太坊虚拟机之外。


合约账户就是智能合约,其代码由以太坊虚拟机来运行,由存储在智能合约账户内的以太坊虚拟机代码控制的。


账户抽象化,就是试图将两类账户并为一类,即,让外部账户像合约账户一样运作。参考:https://legacy.ethgasstation.info/blog/ethereum-account-abstraction-explained/


作为钱包用户,需要考虑很多因素,比如 gas price、gas limit、事务阻塞等等复杂的费用逻辑,这些问题如果直接让用户来处理并非特别适合的。使外部账户更贴近合约账户,这样就可以通过智能合约的方式来赋予钱包处理这些复杂的逻辑。


Kitty:明白了。外部账户是不具备代码逻辑的。如果想要引入更复杂的逻辑来实现其他的功能,比如多签,就需要使用到 MPC 和账户抽象。我们看看知县老师有没有补充。


知县:从 EVM(以太坊虚拟机)的角度来说,账户抽象让未来更换密码学工具变成了可能;从用户的角度来说,账户抽象可以用来提升用户体验,比如 seedless / gasless 这些特定就可以让用户用起来非常顺滑;随着用户经验和资产的增长,账户抽象还能允许用户在不换地址的前提下升级自己的账户逻辑,加入更多安全或者便利的能力。


从生态的角度来说,账户抽象让用户端能力获得了解放,可以提供批量交易、离线授权等新的底层能力,类比于智能手机提供的 GPS 能力让 LBS 相关的产品可以大放异彩一样,基于账户抽象能力来构建上层应用更有可能出现可以大量获取用户的产品,进一步可能出现最早的 web3 原生应用。


Kitty: 那接着上一个问题,智能合约钱包跟 MPC 可以一起使用吗?这个问题本来是账户抽象和 MPC 能不能一起使用,但之前的说法似乎有点不准确,正好,知县老师是专家。您可以先给我们解释一下,「账户抽象」和「智能合约钱包」这两个词的差异和关系。因为我们买 NFT 的小伙伴包括我本身对这些词其实还是比较陌生的。


知县:可以,MPC 提供的是密钥层的管理方案,智能钱包在密钥层的上层(账户抽象「抽」出来的),可以根据场景需求选择不同的密钥层。比如 UniPass SDK 钱包就是内置了 Zengo 的 2-2 MPC 方案,为了应对嵌入式 SDK 的需求;UniPass 跟 MetaMask 做的 Seedless Snap 就用了 MetaMask Flask 提供的密钥管理作为密钥层,这就没有 MPC 了。现在我们也在选择 MPC 方案 / EOA 钱包方案的合作伙伴,在未来更加多样化的场景下提供更适合用户的密钥层方案。


Cobo:目前大部分的账户抽象钱包还是和 MPC 钱包独立开的。


我可以先简单介绍下两者的优劣:账户抽象钱包的优势是可以实现很多复杂的业务逻辑,但是他的劣势或者说限制,就是需要底层公链或者智能合约体系的支持,因此跨平台性较弱,一般现在只在 EVM 生态内会提到这个概念;MPC 钱包的优势在于非常容易跨平台,只要实现了少数几种签名曲线的支持,基本可以服务现在市面上所有的公链,但是 MPC 钱包的缺点就是他只能实现多签的能力,或者进一步的是一些分层多签的能力,但是无法实现特别复杂的业务逻辑在里面。


总的来说,账户抽象钱包是基于一些复杂的智能合约逻辑或者链逻辑,来实现一些例如权限分配、风控、社交恢复等能力;MPC 钱包,则是基于密码学原理,来实现任意公链的多签能力。其实他们两者是在不同层面的技术手段,一个是在底层密码学上,一个是在智能合约或者链的应用层,所以理论上两者肯定是可以一起使用的。


慢雾:这里做一些补充,比如在多签合约的场景下,给每一个私钥定义不同的权限:50U 以下的交易需要私钥 A 签名,50U 以上的交易需要私钥 B 签名,超过 2000U 的交易需要私钥 ABC 共同签名等。


但是 其实 ABC 这几方本身的钱包也可以通过 MPC 的方案来实现和管理。


当然也可以使用 MPC 的方案来进行业务流程的审批 (比如安全鹭的做法),这种方式在感知上是和多签合约类似的,只不过多签合约的方式是需要有多个钱包地址通过智能合约在链上来实现,而 MPC 方案可以通过密钥分片/门限来在链下达到这类的效果。


Kitty: 目前有哪些技术趋势有利于小白用户提升安全性?


知县:老板们肯定会说很多跟密钥管理相关的安全性方案,我就不班门弄斧了,我讲几个 Web2 甚至是生活中的设施能够带来的安全性提升,很多属于交互安全层面的:


· WebAuthn 标准,可以让 2FA 更安全方便,还能防钓鱼;如果巨头们实现的算法再多一些,或者在一些密码学灵活的链上,还能直接用这个标准生成和管理密钥,安全便利打满。


· HRM(Human Readable Message)相关标准推进顺利,如 EIP-712 和越来越多的 transaction insight 服务,让大家签名的时候能知道自己在做什么。


智能钱包可以允许用户用不同的密钥做不同的事情,比如资产相关的密钥和登录相关的密钥可以不同,但是都对应同一个地址(账户)

智能钱包还可以让用户用护照 / 银行卡 / 电子邮件等日常非常熟悉的基础设施来提升账户安全。


Kitty:据我所知,有的链的钱包已经部分支持 2FA 和知县老师提的其中的几个方案了。


慢雾:助记词和私钥是一个单点故障问题,能够解决单点故障问题的技术。MPC 钱包,由用户控制的私钥分片(存储在不同设备上)是可以恢复出完整私钥权限的的技术。


(假设一个场景,钱包项目方被恶意 ddos,用户仍可以正常行使密钥权限而不受影响。)


能够识别恶意签名/黑地址,并且能够进行有效安全提醒的技术。


Kitty:很有意思,刚刚知县老师提到的使用护照、银行卡等提升账户安全性,可能比较接近普通人日常使用银行账户的体验,特别是账户恢复方面。可否具体展开一下?项目方应该怎样管理国库资产,有没有最佳实践推荐,社区如何判断项目方采用的技术是否靠谱?


知县:这个我就不专业了哈哈,有用智能钱包的(gnosis safe)也有用 mpc 的(fireblocks),我觉得从一个韭菜的角度来看,主要还是看透明度,比如到底谁有权限动钱,动多少钱这些。


智能钱包在这方面的优势是,权限控制可以做得更灵活和复杂,比如分资产设权限,引入链上治理等等。


Cheers Up:这里我可以简单介绍一下 Cheers UP 项目上的一些安全实践,跟社区交个底,同时也请在座的嘉宾不吝赐教。


目前,项目方资产也就是 baselabs.eth 上的资产,这里主要放的是销售收入以及归属项目方的盲盒,有几百个以太和两百多个盲盒,以及国库资产,也是有两百多个盲盒。那这里面的安全性当然很重要,我们也不希望发生资产的损失,这样不管对我们项目方还是对整个社区,都是很糟糕的事情。肯定没有人希望这种事情发生。


那么我们项目方其实从一开始就把这个资产的安全放在很重要的位置。我们从技术和管理流程两方面入手去保证资产的安全性。首先从技术上,我们采用了 MPC 技术,我们从技术上保证了团队里没有一个人是掌握了我们这些资产的私钥的。都是集体掌握,而且即便是集体掌握的那几个同事,他们并不能直接就把私钥恢复出来,这里面还会有一些技术上的门槛。具体的技术我可能不会在这里讲很细,但技术上的确我们不仅是没有哪个人是掌握私钥的,也没有哪个小组是直接掌握私钥的。


其次就是从管理和流程上再去加以保证。因为再好的技术也是人来使用的嘛,我们需要尽量减少和控制人为失误、人为因素带来的风险。刚刚说了我们所有的私钥都是集体掌握的,其实这里还需要再加上一个集体管理。这里我可能不会很完整地去描述我们的具体技术和管理方案,我想分享的是,所有使用私钥签名的场景,不管是交易的签署还是合约的调用,除了需要多人共同参与、共同确认,也会有相应的记录,以便后面能够审计。如果其中一个参与者对交易有疑问,他不推进他那部分,那么这个交易在排除疑问之前就不能继续。


通过这样双管齐下,我们是从技术和人两个方面共同去保障项目资产和国库资产的安全。当然我们不是这样就一劳永逸了,我们会持续关注,持续研究,持续改进。


我这边可以回过头去接一下主持人前面的问题。这个问题是说,MPC 技术跟 ZK 零知识证明是不是很像呢?都是在不暴露或者少暴露隐私的情况下,就能得到答案或者完成计算。


这么说吧,主持人这个问题本身体现了一个非常敏锐的观察。虽然实际上这两个技术有很大的不同,它们确实共享了一定的相似之处。


零知识证明顾名思义,它是一种证明技术;而 MPC 呢,这里面的 C 是 Computing,计算的意思。侧重点或者说目的性不一样。


但是零知识证明里面也是有计算的,它证明的是某个计算的结果,比如说,我有一个秘密数据,我不告诉你是什么,但是它的哈希是某某某,这里是证明数据,你可以去验证。然后对方验证了一下,真的是哦。所以,它对隐私的保护体现在不需要披露这个秘密数据而证明根据这个数据计算的一个结果。


而 MPC 更重要的在于 MP,也就是 Multi-Party,多方参与。它是多方共同参与的一个计算。如果在钱包中应用的 TSS 门限签名技术的话,它是可以做到不重构私钥而完成签名的,起到了保护私钥的作用。然后 MPC 技术里面可能也会应用一定的零知识证明技术,比如说如果 MP 中的某个 P 是一个第三方服务器,那这个服务器会不会对我发起协议攻击,试图盗取我掌握的私钥碎片呢?这是完全有可能的,那就可以通过零知识证明技术来证明,大家都是严格遵循 MPC 协议来参与计算的。


所以回到主持人的问题的话,确实是的,就它们起到的保护作用而言是有一定的相似之处的,只是具体应用的场景不一样而已。然后根据具体的场景,需要选择相应的技术。


本文来自投稿,不代表BlockBeats观点


欢迎加入律动 BlockBeats 官方社群:

Telegram 订阅群:https://t.me/theblockbeats

Telegram 交流群:https://t.me/BlockBeats_App

Twitter 官方账号:https://twitter.com/BlockBeatsAsia

选择文库
新增文库
取消
完成
新增文库
仅自己可见
公开
保存
纠错/举报
提交