站在区块链安全的最前线

日报

专栏

热点

国际

活动

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

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

如今，区块链相关业务正如火如荼地展开，但同时安全隐患依然存在，受害案例也层见叠出。在区块链的安全方面，如何保护密钥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端口已经可以通过公共网络进行访问，那么最好假定这个端口可能会受到攻击。此外，只要入侵服务器，将官方客户端软件替换为非法的客户端软件，把所有汇款地址都改为攻击者的地址，即使没有密钥，非法资金转移也一样能够实现。

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