站在区块链安全的最前线

日报

专栏

热点

国际

活动

以虚拟货币交易所为代表的区块链相关业务正如火如荼地展开,但同时存在着安全隐患,受害案例也层见叠出。在开发使用区块链的系统时,需要从攻击者的视角出发,基于风险对采用多重防御的架构和操作设计进行评估。

译/未央网 原作/野村综合研究所 · 田笼照博

如今,区块链相关业务正如火如荼地展开,但同时安全隐患依然存在,受害案例也层见叠出。在区块链的安全方面,如何保护密钥1)至关重要,因此,最近常见的说法是,应当采用多重签名(Multisig)和冷钱包(Cold wallet),但如果认为单靠这两种技术就可以高枕无忧,那就大错特错了。而且,区块链安全也并非仅限于此。下面就来谈谈区块链安全的题中应有之义。

采用多重签名时的注意事项

多重签名是一种需要用多个密钥来实现所有权转移的方式,一般来说安全级别较高。多重签名的表现形式为“M-of-N”,“N”表示所有存在的密钥,“M”则表示完成某一个交易授权所需的密钥数量。如果M个密钥被同时存储在同一台服务器上,那么当服务器被入侵时,所有内容就会被盗。即便将M个密钥分散存储的服务器属于同一网段,那么当一台服务器被入侵时,就会以之为起点,致使其他服务器也遭到入侵,最终有很大可能性会导致M个密钥全部失窃。因此最好以服务器会遭受入侵为前提,从网段层面采取分散密钥等措施。

此外,还必须谨防内部作案。即使适当进行了分散存储,负责人也能访问全部M个密钥,这就是问题所在。因此操作设计也愈发重要。由于区块链保持了一定的匿名性,所以即使是内部作案,败露的可能性也没有那么高。

所以说,在密钥备份网站和“应急恢复”网站中都必要要落实密钥分散存储和负责人访问权控制这两点。

采用冷钱包时的注意事项

钱包可以理解为存储密钥的盒子。冷钱包是指离线环境中的钱包。而热钱包(Hot wallet)则处于在线环境中。使用冷钱包时,虽然外部作案的难度会增大,但内部作案并不是非常困难。无论是纸钱包(Paper wallet)2)还是硬件钱包(以下简称H/W),能够访问冷钱包的负责人都可以轻松地进行非法资金转移。因此,即使在采用了冷钱包的情况下,也最好通过配合使用多重签名的方式来分散存储。

热钱包需要注意的问题也是一样的,但令人头疼的是不采用多重签名的区块链平台。比如,平台之一的以太坊(Ethereum)就没有采用多重签名。以太坊采用的是一种能够在区块链上执行的方案--智能合约(Smart contract)3),实际上可以跟多重签名一样安装,在此概念的指导下创建名为Parity的多重签名钱包,但因其智能合约中存在漏洞,导致2017年有巨额的虚拟货币被盗。以太坊中的智能合约任何人都可以访问,时常处在遭受攻击的风险之中。在这种情况下,攻击点只是智能合约,即变成了一个单点,因此笔者认为,其风险等于甚至大于不采用多重签名的情况。

密钥管理还存在其他需要担忧的问题。例如,钱包中有一种名为确定性钱包(Deterministic Wallet)的方式,可以从一个种子(Seed)4)中生成多个密钥。如果使用H/W,可以将种子相应的备份--助记词(Mnemonic code)记录下来,以便密钥丢失或故障时用来恢复。因此,对于助记词,也需要采取与冷钱包同等的安全措施。

使用H/W时,密钥存储在专用硬件中,不会外流,因此密钥的泄露风险极低,但如果连接H/W的PC端处于在线环境,就存在剪贴板中的地址被恶意软件改写为攻击者的地址等风险,建议在离线环境下使用。

重要的不止密钥管理

确实,笔者也认为,区块链中最应该在乎的就是密钥管理。但是,这并不是说只要密钥管理方面做到无懈可击,就万无一失了。我们必须纵览全局,确保每一个环节都坚实可靠,包括为成功提供服务而使用的Web应用程序、服务器、网络等等。因为即使密钥不曾失窃,也有可能出现非法资金转移等情况。

例如,系统会通过一个基于HTTP的服务JSON-RPC(JavaScript Object Notation Remote Procedure Call)向区块链公共用户软件界面发送命令,确保命令能够从HTTP端传送出去。不过,JSON-RPC一般不用于向外部公开,仅限于本地主机或虚拟IP访问。但即便如此,如果是从面向用户的Web服务直接调用JSON-RPC的架构,或者公共网络“碰巧”可以访问该架构的话,黑客就可以通过JSON-RPC传送的命令进行非法资金转移。目前,我们已经发现了不少搜索搜索区块链中JSON-RPC端口的行为。所以如果一个JSON-RPC端口已经可以通过公共网络进行访问,那么最好假定这个端口可能会受到攻击。此外,只要入侵服务器,将官方客户端软件替换为非法的客户端软件,把所有汇款地址都改为攻击者的地址,即使没有密钥,非法资金转移也一样能够实现。

对安全进行评估时,只看"采用多重签名"、"采用冷钱包"等单一侧面是极其危险的。虽然应制定与密钥管理相关的实践方案,并切实贯彻落实这些方案,但如果未理解其中的目的背景和本质,安全级别就不会得到提升。此外,虽然架构和操作会根据提供服务的系统/业务条件而改变,但我们还是必须纵览全局,从攻击者的视角出发,基于风险进行评估。除了密钥管理,还需要与传统应用程序一样的风险分析和安全措施。

  • 发表于:
  • 原文链接https://kuaibao.qq.com/s/20180612G199C200?refer=cp_1026
  • 腾讯「腾讯云开发者社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 cloudcommunity@tencent.com 删除。

扫码关注云+社区

领取腾讯云代金券