盲签——以太坊社区的安全黑洞

Keystone
更新于 2022-07-28 13:30
阅读 2319

随著2020年以来 DeFi 赛道的蓬勃发展，以太坊已经成为区块链中最活跃的公链之一。当提及到 DeFi 的安全性，大多数人都是从智能合约的角度来讨论，却很少有人从另一个潜在的角度深入考虑DeFi 的安全性。

随著2020年以来 DeFi 赛道的蓬勃发展，以太坊已经成为区块链中最活跃的公链之一。当提及到 DeFi 的安全性，大多数人都是从智能合约的角度来讨论，却很少有人从另一个潜在的角度深入考虑DeFi 的安全性——

我们的交易签名过程是否安全？

事情发生在2020年12月，Nexus Mutual 的创始人 Hugh Karp 遭到了有针对性的远程攻击。据报道，攻击者获得了对 Hugh 计算机的远程访问权限然后针对他的 MetaMask 软件钱包进行一些修改，从而篡改他某一笔交易，并将资金转移到了攻击者自己的地址。最终导致了价值800万美元的数字货币被盗。
从 Hugh 的博客中还可以推断，攻击者不仅成功的攻击了 Hugh，还有证据表明同样成功的攻击了以太坊社区的其他 DeFi 大户

## 硬件錢包不是「银弹」

Hugh 当时使用了硬件钱包，很显然，仅仅知道如何使用硬件钱包并不是可以完全阻止攻击的灵丹妙药。

硬件钱包最基础的安全假设之一，就是原则上不应该相信配套的软件钱包，并且用户应该有能力手动检查硬件钱包上的交易，来确保没有任何东西被暗地里更换。
否则，我们就称它为盲签。

如果我们经过仔细研究就会发现，盲签意味著你不得不相信你的软件钱包在签名时提供的消息和命令都是真实的，无恶意的。那么我们现在反过来思考，如果我们被迫相信软件提供的所有东西都是没有问题的，那么我们选择使用硬件钱包去作为签名设备还有什麽意义呢？
实际上，Hugh 也承认在硬件钱包上去检查合约交互这件事情，说起来容易做起来难。

在 Keystone 硬件钱包上，我们已经提出了一个解决方案，它可能无法100%解决问题，但它绝对是目前市场上最好的解决方案。

在这里需要再次强调一下，并没有真正意义上的100%安全，我们所能做的就是尽可能的减少受到攻击能可能性。

## Keystone 的解決方案
### 4 寸大屏
下面这张图片是 Keystone 的屏幕截图，显示了在 Uniswap 上进行交易互换的交易细节。您可以清楚的感受大屏幕带来的视觉冲击。它使更多的信息具有可读性，这样用户就可以更加方便的去检查未签名的数据。

![1.jpg](https://img.learnblockchain.cn/attachments/2022/07/TKzGF1K662e21d8770877.jpg!/scale/50)
 
### 智能合约地址验证
第一件事情我们需要做的是确认您调用了正确的智能合约。

如果攻击者创建了一个和 Uniswap 一样的钓鱼网站，那么它就可以复制 Uniswap 当前的 UI，并且调用恶意的智能合约，将用户的资金转移到黑客的地址上。

所以我们会在钱包里内置一些著名的智能合约地址，比如 Uniswap 的智能合约地址，我们将 Uniswap 进行标记，这样用户就更容易识别它。如果地址并未提前内置，则有可能此合约是新合约或者是恶意合约，我们同样会用红色的字样突出显示为未知地址来提醒用户。
 
![2.png](https://img.learnblockchain.cn/attachments/2022/07/h5a5NayB62e21ee7e5b3f.png!/scale/50)

### 智能合约功能验证
如果软件钱包（例如：MetaMask）被入侵，就算用户正在与原生 Dapp 进行交互，也仍然有可能被黑客成功攻击。

如果用户的软件钱包被盗取资金，那么有几种方法可以实现（以 Uniswap 为例）。
 
第一个风险就暴露在授权智能合约使用用户的代币时，恶意软件钱包可以将原始的合约地址替换为黑客的地址，那么它就可以直接访问用户的资金且不受限制。

![3.png](https://img.learnblockchain.cn/attachments/2022/07/hw26PLBM62e21e8100253.png!/scale/50)
为了防止这种情况发生，我们特别标注了您授权的智能合约地址，并在解析为未知地址时突出显示来提示用户。

第二种攻击更值得注意。

再深入研究 Uniswap 的代码库后，我们发现了以下代码可能存在风险：

`function swapExactTokensForTokens(
        uint amountIn,
        uint amountOutMin,
        address[] calldata path,
        address to,
        uint deadline
    ) external override ensure(deadline) returns (uint[] memory amounts) {
        amounts = UniswapV2Library.getAmountsOut(factory, amountIn, path);
        require(amounts[amounts.length - 1] >= amountOutMin, 'UniswapV2Router: INSUFFICIENT_OUTPUT_AMOUNT');
        TransferHelper.safeTransferFrom(path[0], msg.sender, UniswapV2Library.pairFor(factory, path[0], path[1]), amounts[0]);
        _swap(amounts, path, to);
    }`

函数定义中有一个地址参数叫做 “to”。通常它应该与用户自己的 “From” 地址一致，以便交换的代币可以转到用户的原始地址。但是 Uniswap 是允许更改这个参数的，以便用户可以将代币交换到另外一个地址（我们不认为这个是一个缺陷，而是 Uniswap 本来就这么设计的）。

但是如果这种设计被黑客利用，它就可以通过攻破软件钱包来将这个值修改为黑客自己的地址，然后用户在交换代币的过程中，将代币交换到了黑客的地址上。

因此为了应对这种攻击策略，我们会用 “From” 的地址验证这个地址，若发现两个地址不一致，则我们会将它清晰的标注到 Keystone 上（详见下图）。

![4.jpg](https://img.learnblockchain.cn/attachments/2022/07/uZZpV3aR62e21ed9dca51.jpg!/scale/70)

从截图中可以看出，我们同样也标注了路径，以便用户验证它是否与 Uniswap 的 UI 保持一致。

下面是另一款钱包在签署 Uniswap 交易的实例（将0.1 ETH 交换为 DAI）。在下面的截图中可以看到，整个签署过程都没有显示 “to” 的地址。如果黑客通过攻破 MetaMask 钱包将你的收款地址改成黑客的地址并且发送了一笔交易，无论你多么仔细检查，也无法发现这笔交易存在问题。

![5.png](https://img.learnblockchain.cn/attachments/2022/07/ykk3WWBL62e21e9c51af9.png!/scale/50)

一笔 Uniswap 交易在 Ledger 上面的签名全过程

### 当前进展

目前 Keystone 硬件钱包已经可以和 MetaMask Extension（浏览器插件） 和 MetaMask Mobile（手机 APP 端） 实现交互。
以下是相关链接：
consensys.net
support.keyst.one
support.keyst.one

## 写在最后
在 Keystone，我们认为用户体验在数字货币安全领域是及其重要的，因为往往人为因素才是导致数字货币资产丢失的最大原因。这也是Keystone最重要的设计原则之一。

对于所有的硬件钱包产品来说，不仅要保护好私钥，同样也要儘可能避免人为因素导致的失误。

总结来讲，如何保证数字货币资产安全绝对不是一件容易的事。

如果我们以智能合约验证功能为例，硬件钱包厂商需要对 Dapp 的逻辑非常熟悉，并且还要找出潜在的威胁。如果 Dapp 项目方可以与硬件钱包团队共同合作，一起解决掉这些潜在的安全层面的问题，那么对于每个人来讲都是有好处的。

保护用户资产的安全是整个社区共同的责任，我们 Keystone 团队欢迎任何形式的合作。
特别感谢Philipp 和 Ryan 對本文的审阅。

Keystone国内的销售渠道目前在有赞上：j.youzan.com/V7Xx3e

我们的交易签名过程是否安全？

事情发生在2020年12月，Nexus Mutual 的创始人 Hugh Karp 遭到了有针对性的远程攻击。据报道，攻击者获得了对 Hugh 计算机的远程访问权限然后针对他的 MetaMask 软件钱包进行一些修改，从而篡改他某一笔交易，并将资金转移到了攻击者自己的地址。最终导致了价值800万美元的数字货币被盗。从 Hugh 的博客中还可以推断，攻击者不仅成功的攻击了 Hugh，还有证据表明同样成功的攻击了以太坊社区的其他 DeFi 大户

硬件錢包不是「银弹」

Hugh 当时使用了硬件钱包，很显然，仅仅知道如何使用硬件钱包并不是可以完全阻止攻击的灵丹妙药。

如果我们经过仔细研究就会发现，盲签意味著你不得不相信你的软件钱包在签名时提供的消息和命令都是真实的，无恶意的。那么我们现在反过来思考，如果我们被迫相信软件提供的所有东西都是没有问题的，那么我们选择使用硬件钱包去作为签名设备还有什麽意义呢？实际上，Hugh 也承认在硬件钱包上去检查合约交互这件事情，说起来容易做起来难。

在 Keystone 硬件钱包上，我们已经提出了一个解决方案，它可能无法100%解决问题，但它绝对是目前市场上最好的解决方案。

在这里需要再次强调一下，并没有真正意义上的100%安全，我们所能做的就是尽可能的减少受到攻击能可能性。

Keystone 的解決方案

4 寸大屏

下面这张图片是 Keystone 的屏幕截图，显示了在 Uniswap 上进行交易互换的交易细节。您可以清楚的感受大屏幕带来的视觉冲击。它使更多的信息具有可读性，这样用户就可以更加方便的去检查未签名的数据。

智能合约地址验证

第一件事情我们需要做的是确认您调用了正确的智能合约。

如果攻击者创建了一个和 Uniswap 一样的钓鱼网站，那么它就可以复制 Uniswap 当前的 UI，并且调用恶意的智能合约，将用户的资金转移到黑客的地址上。

所以我们会在钱包里内置一些著名的智能合约地址，比如 Uniswap 的智能合约地址，我们将 Uniswap 进行标记，这样用户就更容易识别它。如果地址并未提前内置，则有可能此合约是新合约或者是恶意合约，我们同样会用红色的字样突出显示为未知地址来提醒用户。

智能合约功能验证

如果软件钱包（例如：MetaMask）被入侵，就算用户正在与原生 Dapp 进行交互，也仍然有可能被黑客成功攻击。

如果用户的软件钱包被盗取资金，那么有几种方法可以实现（以 Uniswap 为例）。

第一个风险就暴露在授权智能合约使用用户的代币时，恶意软件钱包可以将原始的合约地址替换为黑客的地址，那么它就可以直接访问用户的资金且不受限制。

为了防止这种情况发生，我们特别标注了您授权的智能合约地址，并在解析为未知地址时突出显示来提示用户。

第二种攻击更值得注意。

再深入研究 Uniswap 的代码库后，我们发现了以下代码可能存在风险：

function swapExactTokensForTokens( uint amountIn, uint amountOutMin, address[] calldata path, address to, uint deadline ) external override ensure(deadline) returns (uint[] memory amounts) { amounts = UniswapV2Library.getAmountsOut(factory, amountIn, path); require(amounts[amounts.length - 1] >= amountOutMin, 'UniswapV2Router: INSUFFICIENT_OUTPUT_AMOUNT'); TransferHelper.safeTransferFrom(path[0], msg.sender, UniswapV2Library.pairFor(factory, path[0], path[1]), amounts[0]); _swap(amounts, path, to); }

因此为了应对这种攻击策略，我们会用 “From” 的地址验证这个地址，若发现两个地址不一致，则我们会将它清晰的标注到 Keystone 上（详见下图）。

从截图中可以看出，我们同样也标注了路径，以便用户验证它是否与 Uniswap 的 UI 保持一致。

                  一笔 Uniswap 交易在 Ledger 上面的签名全过程

当前进展

目前 Keystone 硬件钱包已经可以和 MetaMask Extension（浏览器插件）和 MetaMask Mobile（手机 APP 端）实现交互。以下是相关链接： consensys.net support.keyst.one support.keyst.one

写在最后

在 Keystone，我们认为用户体验在数字货币安全领域是及其重要的，因为往往人为因素才是导致数字货币资产丢失的最大原因。这也是Keystone最重要的设计原则之一。

对于所有的硬件钱包产品来说，不仅要保护好私钥，同样也要儘可能避免人为因素导致的失误。

总结来讲，如何保证数字货币资产安全绝对不是一件容易的事。

保护用户资产的安全是整个社区共同的责任，我们 Keystone 团队欢迎任何形式的合作。特别感谢Philipp 和 Ryan 對本文的审阅。

Keystone国内的销售渠道目前在有赞上：j.youzan.com/V7Xx3e

学分: 0
分类: 智能合约
标签: 钱包安全