mt logoMyToken
Market cap:$0
0%
FGI:0
0%
Cryptocurrencies:--
Exchanges --
ETH Gas:--
English
USD
APP
Ap Store QR Code

Scan Download

“好的多重签名”和“坏的多重签名”
Collect

概要:这篇文章的要点在于定义一下“好的多重签名”和“坏的多重签名”。好的多重签名免除了人们必须相信个体的麻烦,促进对消费者的保护,而坏的多重签名仅仅是对加密经济安全性的威胁。本文试图厘清两者的区别。

482

经过数年基础设施与技术的发展,看起来多重签名钱包技术终于在比特币世界里有了长足进展。 Greenaddress.it BitGo 是最初的两个竞争者,后者最近拿到1200万美元的风投并自称囤有价值超过1亿美元的比特币。

从比特币系统的角度看,多重签名越来越多的出现,是非常受欢迎的,比如 已知的好处 ,比特币协议的这一组成部分面世接近两年,现在主流的消费者终于可以享受它的果实了。

多重签名的好处尤其包括消费者—商家第三方担保应用,在有必要进行保护的地方,允许开放自由的市场作为仲裁员,保证比特币交易的相对安全和无欺诈。其好处还包括作为个人存储钱包的应用,保护用户免受任何因为单一秘钥带来的损失和妥协。

当消费者保护成为被关注的焦点 ,数字货币许可证(BitLicense)的浮现带来的对数字货币生意的高度限制,在保护消费者权益方面,多重签名提供了不同于中心化监管的一种选择——不要完全确认每一个生意中的个体是可信的。我们可以建立一个系统,最大化地去除单点故障,优先信赖数字上的安全。

然而,像多重签名这样的潜在的技术革命,依然存在被误传和过誉的风险。就像一些企业会宣传自己的地址由“3”开头的品牌效益,却没有实际的取信于人的努力。这篇文章的要点在于定义一下“好的多重签名”和“坏的多重签名”。好的多重签名免除了人们必须相信个体的麻烦,促进对消费者的保护,而坏的多重签名仅仅是对加密经济安全性的威胁。本文试图厘清两者的区别。

客户端的革命

真正涉及多重签名以前,我们必须首先仔细分析一项被一些公司采用的特殊技术,这项技术看起来是出于增强安全性和降低对信任的需求:客户端网页应用。

在客户端网页应用之前,比特币客户端有两种主要方式。

第一, 桌面客户端( the desktop clients) ,你直接下载程序到你的电脑上。桌面客户端的好处是,用户在自己的机器上掌握自己的私钥,所以不必依赖任何第三方就能保存自己的资金。但是它的易用性有一定的缺陷:至少用户需要去下载。

第二, 服务器端在线钱包(the server-side web wallets) ,有一个第三方替你保存你的比特币,给你一个账号可以方便的转入和转出,就像是用谷歌和脸书账号一样,不需要下载任何软件。它有很高的易用性,但是他要求你对第三方的信任。

客户端网页应用( Client-side web apps ) 是一个简洁的第三种解决方案:尽管依然是通过网页应用登陆网站,但是不需要下载必需的软件,私钥的存储和变更使用网络浏览器内置的用Javascript编写的客户端完成。因此,尽管这种应用,与受信任的服务器钱包提供的网页交互相比,有同样的便捷性,但是服务器并不获取你的个人私钥。看起来兼有两方的长处。现在最流行的客户端钱包可能是blockchain.info.

现在,让我们评价一下这种形式的优点。现在,Javascript客户端当然不乏批评者;甚至Matasano专门有一篇名为“ Javascript Cryptography Considered Harmful ”的文章。尽管他的观点,完全否认基于浏览器加密的客户端的任何优点,相当极端,但他确实有合理的地方——尤其是,当你下载一个浏览器Javascript时,你依然要信赖它的来源。这就是说,如果blockchain.info或某个blockchain.info的流氓员工想要,或者政府强迫他们,他们可以寄出包含你私钥的代码,或者签署一个将你的全部资金发送到他们地址的交易。而你永远不能及时知道。

现在,如果有人将这个论点推到极致,他可能会声称,即便是下载的客户端,也可能会发布会偷你私钥的版本。但是显然这种可能性会小得多——尤其是当你只下载过一次这个软件的时候。

你有多信任各种情形下的软件呢?让我们看一看,想要成功, 对每种情况的攻击需要什么条件

桌面客户端,原始的——攻击系统的代码提供者,或者攻击者,需要在Gigub的客户端仓库里面提交一个包含后门的补丁,你需要在组织内部或外部的某人扫描代码并发现这个后门之前,下载这个客户端(才能中招)。

桌面客户端,二进制的( binary,普通人的选择)——攻击系统的代码提供者或者攻击者,需要编制并发布一个包含后门的客户端,你要在组织内的某人删除这个版本之前下载它。(在大多数情况下,通过反编译二进制客户端发现后门是不可能的,所以漏洞必须是内在的,尽管长期看来一旦入侵被发现,这个漏洞也就永远被堵住了。)

客户端浏览器网页应用( Client-side browser webapp) ——攻击者需要在内容发布网络,快速插入一个包含后门的客户端版本,只有在这一时间段内(恶意版本发布和下线之间的时间段)登陆的用户是易受攻击的。

服务器端浏览器网页应用( Server-side browser webapp )——攻击者需要仅需进入网站的冷钱包,如果这一点成功的话,显然每一个用户的账户都会受到连累。

因此,我们能够看到一个安全性的等级,越往下,安全性越低,你需要投入的信任越多。短期和长期的攻击者之间有一个独有的区别:公司是邪恶的?还是仅仅是在被发现之前,一些人通过一些漏洞进入服务器的几分钟或几个小时?对付长期的攻击者,只有通过从开源社区下载一些稳定版本能够帮到你,而对付短期的攻击者,二进制的桌面应用就做的很好,甚至客户端浏览器网页应用也能限制一小部分用户的伎俩。

一般来说,尽管,在桌面端和浏览器端存在着基本的区别:前两个,如果攻击者短期侵入,在安全设置正确的前提下,根本不足为害,因为问题会被很快解决。而在后两种情况下,短期侵入也是有害的。客户端浏览器基础的App比服务器基础的钱包仅仅增加了一部分的安全性。

问题怎么解决呢?最简单的办法是将客户端的网页应用改成浏览器扩展,这几乎彻底解决了这个问题;从安全角度看,浏览器扩展等同于,在比如Java或者Python交互环境中运行的桌面应用。然而,这是以增加了一个额外的步骤来实现的——用户必须下载一个浏览器扩展,而不是仅仅相信服务器。因为这个原因,尽管像blockchain.info提供了他们自己的浏览器扩展,但是大多数人却没有使用。

注意,以上所说的当然不是对客户端浏览器Javascript的指控;我的意思不过是说,客户端浏览器Javascript并不比服务器掌握你所有钱的方式有特别高的安全性,或者不需要支付那么高的信任成本。

除了安全和信任,还有其他的理由去写一个客户端浏览器Javascript加密货币应用,最大的理由就是便捷。因为越多的事情在浏览器那里完成,你作为一个应用开发者,就可以省略越多的基础工作。

以太坊正是由于这个原因使用客户端Javascript(开发的方便和对拒绝服务攻击的稳健性)。当然你在使用这个App的时候你是相信以太坊的,但是无论如何,这不是一个问题,因为你相信以太坊能够开发一个平台。因此,如果我们承认,我们相信像blockchain.info这样的提供者,我们可以说使用客户端加密是合理的。然而对于多重签名,故事是完全不同的……

熔合的多重签名钱包

前面关于客户端安全性的讨论是重要的,因为,它带来了对一个重要的,有时候被忽略的,加密货币协议中关于安全性的组分:源代码自身的安全性。尽管比特币这样的加密协议理论上讲是无须怀疑的,但事实上几乎没有人有能力自己检验所有的代码。在 黑暗C竞争 中,聪明的开发者展现了一个软件免于攻击是多么的困难。因此,除了程序协议的原始开发者,几乎每一个人都是要支付一定的信任成本的。

在多重签名中,我们试图做的是,明确消除信任任何一个实体的必要。一般来说,有两种多重签名实现的途径。

第一种我们称作 延伸版的2-of-2 。基本的2-of-2的概念是简单的,一个秘钥由用户掌握,可能是通过密码推断的脑钱包,可能是浏览器或客户端随机生成的加密秘钥。另一个秘钥则由服务器掌握。当用户想要交易的时候,他们在电脑上登陆钱包,然后使用他们的私钥签署一个从自己的地址发送资金的交易。这时交易送达服务器,服务器做一些反欺诈检验,比如向用户的手机上发送一个验证码,要求用户输入这个验证码。如果成功,服务器签署这个交易并发送。

然而,这个策略天生就是脆弱的。如果你的电脑被攻击,或者你忘记了自己的密码,那么你就不能登录自己的钱包,而服务器对此则无能为力。类似的,如果运行服务器的公司出了什么意外,或灾祸,或跑路了。你也不能使用了。

延伸版的2-of-2解决了这个问题。本质上,每一次你的客户端发起一个新的交易,它实际上产生两个交易:一个是你希望的资金转移,第二个是在第一个交易完成后,将你其余的资金转移到另一个由你控制的地址。但是只有第一个是公开的,----第二个交易返还给你,这样即便服务器消失你依然有办法恢复你的资金。注意这是2-of-2地址,服务器无法在不经你同意的情况下撤销你的交易。应该注意的特殊的一点是,服务器应该是第一个签署交易的,而不是第二个,否则服务器就可以恶意的只签署第一个交易而不签署第二个,然后跑路,将用户留风中哭泣。

第二种策略是简单的 2-of-3 .有三条秘钥:你的秘钥,服务器秘钥,还有一个由你以安全的离线方式保存的秘钥。就像上面一样,你签署交易,服务器向你的手机发送一个验证码,你在电脑上输入验证码,服务器签署交易;这就是全部了。如果你丢失了密码,你可以使用备用秘钥和服务器秘钥发送交易到一个新钱包;如果你或者服务期被攻击了,那攻击者也仅仅是获得了三分之一秘钥,如果服务器有意作恶或者跑路,它仅仅掌握三分之一秘钥,而你掌握三分之二。与2-of-2的逻辑类似,你丢失你的秘钥或服务器消失的情况下,你可以申请一个紧急交易。因此,我们有两个稍有不同但是在很多方面类似的协议来创建一个多重签名,以防单点故障……

……直到我们开始考虑软件代码。一个流行的多重签名钱包是BitGo,当前多数情况下作为一个客户端Javascript网页应用出现;因此我们可以使用分析blockchain.info一样的方法来分析BitGo(注意,我并没有特意针对BitGo,它仅仅是最突出和资金充足的一个,其他类似的选择,通常工作原理与之一样。)如果攻击者控制了BitGo的服务器,他们就有能力向用户输送错误的网页应用。

现在,人们可以合理的认为,(1)BitGo是一个值得信任的公司,因此他们不太可能监守自盗,(2)多重签名的存在意味着攻击者必须从两方面而不是一方面攻击BitGo。

但是,这并没有绕开最开始的软肋。中心化的服务器端钱包可以达到相同的安全效果,不需要用户存储秘钥那么复杂,只要额外增加一个多重签名步骤或者秘密分享到他们的冷钱包就可以了。因此,这种客户端浏览器多重签名钱包可以被认为,完全是对加密经济安全性的威胁。这并不是说BitGo不安全,相比于大多数的选择,它还是不错的。这只是说,这种“多重签名”并没有提供一些人想象它具有的,精确的安全保证。

为什么浏览器Javascript与多重签名组合在一起是有问题的?其哲学原因是,浏览器Javascript多重签名钱包的提供者,与很多桌面应用的提供者一样,在试图从一开始就建立一个不受单点故障影响的协议,但是他们在协议中同时扮演两个角色:客户端和服务器,这使他们在现实中牺牲了原定的优势。问题看起来是基础性的,在任何交互中,考虑到客户端的重要性,这个问题可能是无解的。就像我们上面看到的,无论你如何下载一个软件,除非你有时间检查每一行代码,我们不得不预设你是相信软件的提供者的。乍看起来,这个问题是无解的,但是就像我们即将看到的,有解决办法。解决办法又一次来源于多重签名——这一次是正确的方向。

未熔合的多重签名

我相信现实生活中我见到的多重签名的正确实现是基于 CryptoCorp . CryptoCorp实现多重签名的方法有根本不同:不是试图采用Paypal的模式(事实上,几乎所有前加密时代商业的模式),将接口和安全提供者打包处理。CryptoCorp归纳和提炼了接口的角色,将安全提供者作为他们唯一的核心产品。这就是说,CryptoCorp将他的大多数资源用来专门发展和改进它的签名数据库服务器的算法和高级功能。而让其他的钱包提供者与之结合,来提供有相兼容的接合点。在3月份在德克萨斯举行的比特币会议上,CryptoCorp展示了改进的Electum钱包原型;现在他们在与超过十个钱包提供商合作,整合支持他们的分服务器。

当然,一个问题是,CryptoCorp的服务器有什么特别呢?如果是一个使用谷歌认证做手机二次验证的App,签署几天内可被写入NodeJS的交易;这个我自己都能做。CryptoCorp的出色之处在于用来甄别不正当交易的先进算法。花三刀买杯咖啡?CryptoCorp甚至不耐烦去等待确认;花500刀买个笔记本电脑?也需要稍微严格的检查一下;花50000刀买个汽车?准备好接受接近KYC认证那样的检验吧。除非收款地址被认为属于老牌的BitPremier,在那种情况下可以经过较少的麻烦发送交易,因为一旦你发生错误,你总是可以要求退款——而如果接收地址与黑客有所关联,那么即使是3刀的交易也会请求检验。

那么为什么CryptoCorp的方式更好呢?从以上我对多重签名常见方式的批评来看,答案是显而易见的: 整个数据库的建立和整个软件的维持是完全分开的 。事实上,即使你的软件完全被攻击者控制,使用CryptoCorp,你依然是相当安全的。你可以使用独立的工具验证你看到的地址是不是合法的(而不是所有的秘钥实际上控制在攻击者手中的虚假的多重签名)。客户端不能单方面发送交易,如果客户端试图发起更加狡猾的攻击,比如改变交易的输出或者数额,数据库会发现它。因此,实际上,不会有单点故障的失败,加密货币零信任的许诺最终得以实现。

值得注意的是,CryptoCorp并不是以广义和高模块化的方式做事的唯一的公司, Codius,其数据库基础来自Ripple的智能合约平台,再以几乎相同的方式解决这个问题。还有基于消费者保护的立场的Bitrated,和他的买家、卖家、公证人的开放市场。尽管Bitrated有所下降,因为它是一个浏览器基础的网页应用,而不是一个客户端应用或浏览器扩展。或者实现与协议多样的兼容会更好。

去中心化友好的商业文化

要让加密商业更像CryptoCorp, Codius 或者Bitrated,而不是更像PayPal,我们有很长的路要走。在技术商业社区,很大的力量总是倾向于创造一个一站式解决的生态系统。而不是一个单一的组件,修建一个“护城河”,这样你的用户无法离开你的产品。前者恰恰是走向了去中心化生态系统的反面。商品化,普遍化,关注点分离的原则对一个去中心化生态系统的健全是如此的重要。尽管目前如果你有一个安全和垄断的位置,公司利润会有巨大的增长。但是加密货币应用变得模块化和可替换是这个游戏的未来。

我们必须注意到,CryptoCorp已经试图超越这个障碍,通过实现真正真正好的签名数据库,超越“只是签名数据库”的烙印——与CryptoCorp合作的钱包也做了同样的事情。甚至交易所,或许在全世界有许许多多的的交易所,依然试图将他们自身与加密货币区分开来。但目前,在服务中的仲裁服务比如Bitrated,仲裁者可以选择专门从事不同的行业,不同的商业模式(比如,产品质量的接受标准,消费者希望读到的购买协议的程度,等等),并有允许他们支付最少费用的最佳的风险模式。

此外,也许运行一个多重签名数据库不一定非得是在买卖中。像DNS服务器,任务可以简单地商品化,并由大公司,非盈利的研究团队和爱好者共同完成。这样的情形会更好,因为各自完成自己的部分,会有一个稳定独立的收入来源,和更多的维护声誉的需要,所以我们能够预期数据库跑路和欺诈更少。但是最终,如果社区需要真正的去中心化,市场会以某种方式配置自身来实现它,唯一留下的事情是完成这个转变的有组织的努力。

更新:BitGo的Ben Davenport已经回复,说他们已经有了一个API支出使用他们的服务,就像一个纯CryptoCorp那样,很快他们还将推出浏览器扩展。我赞赏他们的快速反应和对稳固安全性实践的付出。


Disclaimer: The copyright of this article belongs to the original author and does not represent MyToken(www.mytokencap.com)Opinions and positions; please contact us if you have questions about content
Related Reading

Bitcoin Price Consolidates Below Resistance, Are Dips Still Supported?

Bitcoin Price Consolidates Below Resistance, Are Dips Still Supported?

XRP, Solana, Cardano, Shiba Inu Making Up for Lost Time as Big Whale Transaction Spikes Pop Up

XRP, Solana, Cardano, Shiba Inu Making Up for Lost Time as Big Whale Transaction Spikes Pop Up

Justin Sun suspected to have purchased $160m in Ethereum

Justin Sun suspected to have purchased $160m in Ethereum