千里之堤毁于蚁穴(慎用HD Wallets)

转自:http://blog.sina.com.cn/s/blog_12ce70a430102vbu9.html

-- 随机系列谈之四

现在我们都该明白,无论怎样强调随机对于比特币的重要性都不为过,随机的确称得上是比特币的“命根子”。
在过去的几篇文章中,小太已经介绍过了一些因随机问题可能导致私钥暴漏的情况,今天,我再跟大家聊聊分层确定性(Hierarchical Deterministic)钱包。

HD Wallets因其“只需要一个主(根)私钥,就能生成海量子私钥”这个特性广受欢迎,在过去的一年里,越来越多的钱包解决方案和比特币企业开始支持或采用HD模型来进行私钥管理,可是,大部分人并未意识到其中可能存在的潜在风险。(本文不讨论HD的原理,有兴趣的童鞋可参阅《分分钟搞懂HD钱包》 http://blog.sina.com.cn/s/blog_12ce70a430102v8c7.html 及 BIP32 规范中的相关说明)

HD模型的最大优点是不使用私钥就能生成大量的由您掌握的地址,其原理就在于直接通过主公钥就可以生成任意数量的子公钥,整个过程无需访问主私钥。这个特性有如下好处:
1、备份容易,只需备份主私钥,新增地址无需再次备份私钥;
2、保证主私钥的冷存储,无论新增多少个地址,仅需主公钥就能完成,无需主私钥介入;
3、方便的第三方审计,只需给第三方机构或会计提供主公钥,他就可以看到所有下级地址的交易,但又不能花费任何币(因为没有子私钥);
因为HD模型的这些好处,钱包解决方案和比特币企业就可以很方便的进行私钥管理。比如说,电子商务网站或交易所就可以在网站服务器上存放主公钥,然后按需新增子地址,对每个用户、每个商品甚至每笔交易都使用一个全新的比特币地址,而整个过程不会涉及冷存储的主私钥;再比如说,个人可以冷存储主私钥,在热设备上存放主公钥,就能方便的生成任意数量的地址,满足自己不断新增地址而又无需备份私钥的需求。

但这些好处其实是有代价的,因为HD模型有一个天生的“缺陷”(无论是Type1、Type2、还是遵循BIP32规范的确定性钱包),那就是只要暴漏任何一个子私钥,再加上主公钥,就能反推出主私钥,这是“致命”的。
也就是说,对于企业或个人,如果您使用HD模型管理私钥,出于方便的增加地址及第三方审计等目的,主公钥往往暴漏在外(主公钥的安全级别当然要远低于主私钥)。大家可能会认为,我们只要能安全的保管好私钥就足够了(比如说绝对冷存储主私钥,离线的使用子私钥签名交易等),但通过前几篇文章,您就该明白,如果使用了不够安全的随机数,签名交易也有可能会暴漏私钥。对于非HD解决方案来说,一个有问题的签名最多只会暴漏一个私钥,而在HD模型的情况下,任何一个子私钥的暴漏,都有可能导致主私钥的暴漏,最严重的情况下,整个树状的分层模型会整个崩塌,企业或个人的比特币资产也会全部丢失,这就是HD模型的最大风险。

HD模型的“安全”与“易用”其实是个悖论,为了易用,我们希望无论新增多少个地址都无需备份私钥,这就需要热的(泄露概率高)主公钥,而为了安全,又必须保护好主公钥,否则任何一个子私钥的泄露,都能反推出主私钥。这显然是个矛盾,而如果发生潜在的随机数问题,又会放大这种矛盾。因此,在这里,我特别提醒大家谨慎使用HD模型。

比特币的安全就在于随机,我们希望随机的生成一个个比特币私钥用来存币,希望使用随机的k值来签名交易。而HD Wallets的模型其实是基于一个唯一的(根)随机数来确定性的构建了整个分层级的、树状的私钥大厦(私钥和私钥间有着确定性的计算关系)。这座大厦,在没有遇到任何问题的时候,看起来也许是固若金汤,但任何一个小问题(如r值问题、内鬼盗窃等)的发生,都有可能导致整个大厦的崩塌。
这也许就是传说中的“千里之堤毁于蚁穴”吧!

最后,再说一句,尽量使用不相关(随机)的私钥解决方案吧,这才是比特币之本,比特币企业和个人应谨慎使用HD Wallets。

小太关于随机这个系列的文章就暂告一段落了,必须再次提醒大家,随着安全专家和黑客对k值更为深入的分析,因不安全随机数导致的丢币未来可能会越来越多,如果企业和个人采用了HD方案,甚至有可能会放大这种灾难,随机理应引起业内人士的足够重视。
看完这几篇文章,有人可能会担心“比特币到底安不安全?”。在这里,小太可以很负责的告诉您,直到今天(及可预计的未来),比特币很安全,比特币所依赖的椭圆曲线签名算法(ECDSA)也很安全,不安全的是一些有问题随机数生成器或技术解决方案,这些都与比特币无关。

本系列文章要特别感谢 Nicolas, Pinar, Filippo 这三位大牛,他们最近发表的论文(https://eprint.iacr.org/2014/848.pdf)让小太收益良多。在该论文中,几位作者深入的解释了不安全随机数的风险及其对HD Wallets可能造成的灾难,该篇论文干货十足,值得每位从业者学习。

----------------------------------------------------------------------------------------------

分分钟搞懂 HD 钱包

第一次看到 HD 这个词被用在比特币钱包中时,很容易就把它理解成硬件(Hardware)钱包,其实它是分层确定性(Hierarchical Deterministic)钱包的缩写 HD Wallets。
“分层确定性”这个词乍看起来很“高大上”,各类文档也把它描述的“云里雾里”的,其实原理本身很简单,两句话就能说清楚:
首先,要用一个随机数来生成主(根)私钥,这和任何一个比特币钱包生成任何一个私钥没任何区别;
然后,再用一个确定的、不可逆的算法,基于主私钥生成任意数量的子私钥;
看到了没?很简单吧?

那为什么要用“确定、不可逆”的算法呢?因为“确定”才能保证从一个主私钥可以生成出全部的子私钥,而“不可逆”则是为了确保不能通过子私钥反推出主私钥。
例如,SHA256 就可以看成是“确定、不可逆”的算法,我们可以很容易的使用 SHA256 设计出一个 HD 模型:SHA256(seed + n)
在这个模型里,seed 为主私钥,n=(1,2,3......)计算出来的结果对应于第(1,2,3......)个子私钥。
这其实就是类型1确定性钱包(Type1 HD Wallets),当然,我们还可以基于更多“确定、不可逆”的算法来设计其它 HD 模型,比如 BIP32,再比如类性2确定性钱包(Type2 HD Wallets)。算法可以复杂,但原理都一样,很简单,而且,只要 SHA256 是安全的,HD 模型就是安全的。

HD 模型在数学上有一个非常“好”的特性:只需要主公钥,就可以生成出任意数量的子公钥。也就是说,无需私钥介入(主私钥和子私钥),就能基于主公钥生成新(公钥)地址,而这些地址其实都能被主私钥所控制。
这个特性使得 HD 模型在过去一年里被越来越多的应用于企业和个人比特币钱包解决方案,可惜,优点往往伴随着代价,某些情况下,代价甚至是“致命的”。

下一篇文章中,小太将和您说说 HD 模型的潜在风险。

----------------------------------------------------------------------------------------------

本文不讨论HD的细节,仅谈其中潜在的风险。(有兴趣的童鞋可参考 http://www.8btc.com/hd-wallets 及 BIP32 的内容更深入的了解HD Wallets)

经常有用户建议我们支持分层确定性钱包(HD Wallets)功能,在过去的一年里,大家也能看到越来越多的钱包解决方案(如MultiBit等)开始HD化,也有越来越多的比特币企业开始利用HD来进行钱包管理,似乎只要是有了HD,人们就再也不用为私钥而头疼了,那真是这样的吗?

让我们先来了解一下到底什么是分层确定性(Hierarchical Deterministic)钱包,乍看起来,这个名词似乎很难理解,其实它的原理很简单,几句话就能讲清楚:
首先,用一个随机数来生成主(根)私钥;
然后,再用一个确定的、不可逆的算法,基于主私钥生成任意数量的子私钥;

为什么要用“确定、不可逆”的算法呢?因为“确定”才能保证从主私钥可以生成全部的子私钥,而“不可逆”则是为了确保不能通过子私钥反推出主私钥。
例如,SHA256就可以看成是“确定、不可逆”的算法,我们可以很容易的使用SHA256设计出一个HD模型(注:seed为主私钥):
SHA256(seed + n)
这其实就是(Type 1)确定性钱包。当然,我们还可以基于更多“确定、不可逆”的算法来设计其它HD模型,比如BIP32,再比如(Type 2)确定性钱包,算法可以复杂,但原理都一样,很简单。
选定了算法,我们还可以基于任何一个子私钥作为下一级的主私钥,继续使用相同算法来生成下一级的子私钥,也就是说,可以一层一层的树状结构向下生成,这就是为什么会称其为分层确定性的原因。

HD Wallets的特性和优点在某些情况下似乎特别适合企业和用户的一些需求(可参阅http://www.8btc.com/hd-wallets)

无论对于企业还是个人来说,比特币私钥管理总是件让人“头疼”的事,我们不仅需要多个地址、还需要区分冷热、并且考虑备份方式,这很麻烦。
考虑到这一点,有人“创新”的设计了一套分层确定性(Hierarchical Deterministic)模型来生成私钥,支持HD模型生成私钥的钱包被称为HD Wallets。
乍看起来“分层确定性”似乎很难理解,其实原理本身很简单,几句话就可以说清楚:
首先,用一个随机数生成主(根)私钥;
然后,用一个确定的、不可逆的算法,基于主私钥来生成任意数量的子私钥;
那么为什么要用确定的、不可逆的算法呢?这也很简单,因为“确定”才能保证从主私钥能生成全部的子私钥,而“不可逆”则是为了确保不能通过子私钥反推出主私钥。

最典型的“确定、不可逆”的算法就是SHA256,这样我们可以很容易的就设计出一个分层确定性模型(注:seed为主私钥):
SHA256(seed + n)
这其实就是类型1确定性钱包。
当然,基于相同的原理,我们可以设计出更多的“确定、不可逆”的算法来生成子私钥,比如说BIP32,再比如Armory所设计的类型2确定性钱包,算法可以复杂,但原理都一样,很简单。
确定了算法,我们还可以基于任何一个子私钥来作为下一级的主私钥,继续使用相同的算法来生成下一级子私钥,也就是说,可以是一层一层的树状结构向下生成,这就是为什么称其为分层确定性的原因。

好了,简单介绍完HD Wallets的原理,我在来说说这种模型的“优点”:
1、管理容易,只需保管好(备份)一个主私钥即可,通过主私钥可以生成全部的子私钥甚至是多级子私钥;
2、因为可以从父公钥生成全部子公钥,这意味着我们可以在不影响父私钥冷存储的情况下,生成任意数量的子地址用于比特币收款,这在电子商务场景下很有用,您可以为每个商品、每个用户、甚至是每笔交易都生成一个全新的比特币地址,而这个过程完全无需进行任何私钥管理;
3、多层树状结构很像是商业组织(如企业)的结构,比如说:总经理掌握主私钥,部门经理掌握1级子私钥,员工掌握2级子私钥(这能不能算成是优点,其实很值得商榷,因为如果真发生了比特币资产的丢失,到底该算到总经理、部门经理、还是员工的头上呢?);
4、更方便的审计,可以给会计或第三方审计任何一级上的公钥,他就可以看到该级下的所有交易,由于没有下一级私钥,只能审核(看),而不能花任何的币;
由于HD Wallets看起来优点多多,越来越多的钱包开始使用或支持这种解决方案,比如说:MultiBit HD、Electrum、Trezor等,甚至貔貅(云币)这个开源交易所平台据说也采用了这种模型来进行私钥管理。那么,HD Wallets到底好不好呢?

有不少用户在bitcointalk论坛上建议比太钱包支持HD Wallets,小太当时的回答是“我们未来可能会考虑哈”。现在,在这篇文章中,小太可以很认真的回答这个问题,那就是“我们不会考虑支持HD Wallets”,原因很简单,因为它不安全,如果在随机数不够安全的情况下,它甚至会放大风险,放大多少倍呢?也许是主私钥!

通过上面的原理性介绍,大家就应该能明白,整个HD Wallets的体系其实是构建在一个随机数(主私钥)之上的,虽然这种模型有着一些管理和审计上的优点,但如果暴露出任何一个小缺陷,就有可能导致整个体系的崩塌,千里之堤往往会毁于蚁穴,就是这个道理。
比如说,关于HD Wallets,有一个天生的、被大家讨论过多次的缺陷,即:主公钥+子私钥可以反推出主私钥。这在完美的情况下,不会有任何问题,企业和个人既不应该暴露主公钥,也不应该暴露子私钥。但即便比特币是完美的,并不代表使用比特币的企业或个人是完美的,也不代表第三方所开发的各种比特币钱包解决方案是完美的。
我们可能会因为各种原因暴露主公钥,比如为了第三方审计,再比如为了方便的新增地址而在网站服务器(企业)或热设备(个人)上存放主公钥,在这种情况下,主私钥可能的确做到了绝对的冷、绝对的安全,但主公钥显然存在暴漏风险。
在这种情况下,企业或个人如果能确保子私钥的安全,显然问题也不大,可是,通过小太之前两篇关于随机数的讨论,您就应该知道,如果基于不安全的随机数生成器进行签名,存在多种暴漏私钥的可能,对于一般的私钥来说,这可能导致单个私钥的暴漏,但对于HD Wallets来说,则可能由于暴漏单个子私钥而最终导致暴漏主私钥,这

时间: 2024-10-12 12:52:39

千里之堤毁于蚁穴(慎用HD Wallets)的相关文章

分成确定性钱包开发的代码实现(HD钱包服务)

HD Wallets的全称是Hierachical Deterministic Wallets, 对应中文是 分层确定性钱包. 这种钱包能够使用一组助记词来管理所有的账户的所有币种,在比特币的BIP32提案中提出,通过种子来生成主私钥,然后派生海量的子私钥和地址.种子很长,为了方便记录,转换为一组单词记录,这是BIP39提出的. 生成钱包地址的基本流程:1 生成一组助记词 2 助记词转化成种子(通过PBKDF2) 3 种子生成根私钥(通过HMAC-SHA512) 4 通过根私钥生成子私钥 本文的

周易卦象

作者:石中火链接:http://www.zhihu.com/question/28239173/answer/40146896来源:知乎著作权归作者所有,转载请联系作者获得授权. 题主,我推!给!你!看! 在推之前还有几句话要说..首先,我是按照周易六十四卦的顺序推的,不可能一次性推完,所以持续更新.其次,由于参考书目的不同和本人才疏学浅,请各路大神高抬贵手,不对的地方可以留言指正,我会改的.但是别喷!如果各路大神对周易的理解在我之上完全可以批评指正或者另开解答来打我的脸,秀优越秀智商的还是绕道

常见验证码的弱点与验证码识别

http://drops.wooyun.org/tips/141 常见验证码的弱点与验证码识别 insight-labs · 2013/06/08 11:36 0x00 简介 验证码作为一种辅助安全手段在Web安全中有着特殊的地位,验证码安全和web应用中的众多漏洞相比似乎微不足道,但是千里之堤毁于蚁穴,有些时候如果能绕过验证码,则可以把手动变为自动,对于Web安全检测有很大的帮助. 全自动区分计算机和人类的图灵测试(英语:Completely Automated Public Turing t

学习笔记之--高效程序员的45个习惯

有本关于敏捷开发方面的书非常不错<高效程序员的45个习惯-敏捷开发修炼之道>,Venkat Subramaniam和Andy Hunt著,该书简短.易读.精炼.深入,深刻且实用.对于想要采用敏捷方法的人很有价值.此书通过常理和经验,阐述了为什么应该在项目中实用敏捷方法.更难得的是,这些行之有效的实战经验,竟然从一本书中得到了.如果能拿这些习惯在项目中一以贯之,肯定会受益匪浅.下本罗列该书这45个习惯,一并列出其中的Key Point. -----------------------------

挨踢部落故事汇(16):技术人疲倦期的最佳实践

Coeus喜欢和朋友聊技术.怼产品.鄙销售.谈梦想.借着兴致与大家分享这几年遇到坑,经历的疲倦期和技术瓶颈,希望对大家有一定帮助. Coeus·新浪安徽站PHP主管 Coeus工作六年有余,一直从事PHP相关的Web开发工作.前端.服务器运维也做过,私活.技术顾问.个人规划的项目也接触做过.曾在小公司打过杂,也在外企熬过夜,目前在国内一家老牌互联网地方站做技术主管.这六年的工作期间Coeus踩过很多坑,做出了很多选择,很幸运的每一次都挺了过来.秘籍很简单:不能则学,不知则问,耻于问人,决无长进.

轻取帝国CMS管理员密码

“帝国”CMS是一套著名的PHP整站程序,是国内使用人数最多的PHPCMS程序之一.令人无奈的是,“帝国”虽然把势力壮大了,却忽略了自身防护的建设,结果在黑客攻击下,“帝国”沦陷了.“帝国”CMS曝出的漏洞能够让黑客在1分钟内拿到管理员的账户密码,之后更能轻松获取webshell.下面让我们一起来对“帝国”CMS进行一次入侵检测. 漏洞的成因: 都说安全是一个整体,千里之堤毁于蚁穴,往往一个看似坚不可摧的网站系统,在某个不被注意的角落出现了一个极小的疏忽,结果导致整个网站被黑客攻陷.“帝国”CM

管理学定律四:手表定律与破窗理论

1.手表定律 1.1 来源 手表定律是指一个人有一只表时,可以知道现在是几点钟,而当他同时拥有两只表时却无法确定.两只表并不能告诉一个人更准确的时间,反而会使看表的人失去对准确时间的信心.它的提出者是英国心理学家p.萨盖,因此手表定律也叫萨盖定律. 森林里生活着一群猴子,每天太阳升起的时候它们外出觅食,太阳落山的时候回去休息,日子过得平淡而幸福. 一名游客穿越森林,把手表落在了树下的岩石上,被猴子"猛可"拾到了.聪明的"猛可"很快就搞清了手表的用途,于是,"

【Java面向对象基础(一)】数据类型与运算符

[喵"的Android之路][基础篇(一)][Java面向对象基础]数据类型与运算符 1.数据类型介绍 在Java中,数据类型分为两种:基本数据类型和引用类型. 基本数据类型共8种,见下表: 基本数据类型 字节数 二进制位数 最小值 最大值 默认值 byte 1 8-bit -2^7 +2^7 - 1 0 short 2 16-bit -2^15 +2^15 - 1 0 int 4 32-bit -2^31 +2^31 - 1 0 long 8 64-bit -2^63 +2^63 - 1 0

《如何衡量你的人生》晨读笔记

<如何衡量你的人生>重点讨论的是三个方面的内容.分别是如何制定人生的战略,如何确保战略的执行,以及如何才能不偏离轨道. 首先要讨论的话题是人生的战略,说白了,就是怎样才能获得事业的成功. 我们都知道,实现梦想首先要制定一个目标,做自己喜欢的事情,持之以恒.今天要说的并不是这个,而是你既要有一个周全的计划,也要给偶然的机遇一点机会. 举个例子.在上个世纪,本田公司希望在美国的摩托车市场占有一席之地.因为美国人喜欢那种看起来超酷的大型摩托车,所以本田公司的战略也是主攻大型摩托车市场. 结果,因为摩