tg-me.com/yachme/42
Last Update:
上一篇文章中，我提到了比特币的使用和存储让我颇费脑筋，当想把百万以上的资金放入一个纯粹依靠算法与数字技术保护的钱包时，你会觉得所有看似稳妥的方案都暗藏危机。
1. 硬件钱包
通常能想到的最安全的方案是硬件钱包（如 Ledger），因为其私钥仅存在与独立的硬件上（除了备份用的助记词），所以非常安全。但是我不禁脑补了这样一个故事：
Ledger 的一名员工，悄悄修改了用于灌入 firmware 的写入程序，让出厂的硬件被装上了一个修改版的固件。这个固件的随机数生成器被动了手脚，攻击者可以轻易的推测出随机数的序列。
当生产了一万个硬件钱包后，攻击者恢复了正常的固件写入程序，所以这件事完全不被任何其他人所察觉。
五年之后，攻击者利用随机数生成的缺陷，轻易地破解了这一万个硬件钱包的私钥，将他们的数字货币全部转走，价值数亿美金。
而这个员工早在三年前就消声灭迹了。
2. iOS 软钱包
另一个比较安全的方案，是在 iOS 设备上安装一个钱包程序，然后使用该钱包程序保管私钥，得益于 iOS 系统的封闭性和优秀的安全设计，比起在 Windows/macOS/Android/Linux 等开放系统上要安全不少。同时几乎所有钱包 app 都是开源的，代码可被审查。
但有一个问题是，我怎么样确保从 App Store 下载的 binary 确实是由公开的源代码所编译而成的？要进行这个验证很麻烦，而且由于 app 可以被更新，App Store 的开发者账号所有者，是可以在某次更新时悄悄塞入恶意代码上传用户钱包私钥的，这样的攻击可能要数天或者数月后才能被发现，为时已晚。
另外，即使 app 开发者绝不会这样做，也不能排除他人使用这种方式攻击的可能。不知各位读者是否还记得 2015 年 XcodeGhost 的攻击事件，如果攻击者获得了开发者的编译机器的访问权限，是可以在连开发者自己都不知情的情况下，通过 App Store 分发带有恶意代码的更新的。
另外由于现代操作系统的复杂性，攻击者完全可以将上传的网络连接隐藏在各种正常请求中，如 iCloud 的 CloudKit Public Database，连防火墙都无能为力。
当然还有一种更脑洞大开的可能性，Apple 的员工（或者获得了 Apple 权限的黑客）通过直接修改 App Store 的 binary 插入恶意代码完成攻击。
一个解决方案是，自己通过源代码编译安装，但是每次更新时都得自己重新编译安装。
你会发现，这两个虚构的攻击案例，潜在收益都极高，至少是亿元以上，而且手段高明的话，被发现概率很低。难点是有合适的「位置」，比如 Ledger 的员工，钱包 app 开发团队人员等。但在这么高的利益和相对较低的风险面前，我相信未来一定会出现类似的惊天巨盗事件。
最终在朋友的建议下，我采用了冷存储的方案：
1. 使用一台完全离线的设备，编译和安装钱包软件 Electrum。
2. 在该设备上完成私钥生成，导出公钥。
3. 用 U 盘将公钥复制到日常使用的电脑和手机上，将钱包配置为 watch-only 模式，用来查看转账记录和接受转账。
4. 当需要向外转账时，用日常电脑的 Electrum 生成 unsigned transaction，用 U 盘复制到离线电脑上进行签名，再复制回来在链上进行广播。
（具体步骤参见：https://electrum.readthedocs.io/en/latest/coldstorage.html）
我几乎想不出能够对这套方案进行攻击的可能，对于现代操作系统，操作正确的情况下，几乎不可能透过U盘进行攻击。而最重要的是这种方案下黑客只能 case by case 的进行定点攻击（那就需要考虑自己值不值得被这样针对性作案），而不可能被范围攻击伤害（如上述两个虚构攻击）。
BY Yachen's Channel
Warning: Undefined variable $i in /var/www/tg-me/post.php on line 280
Share with your friend now:
tg-me.com/yachme/42