作为区块链安全领域从业者,我对密码学和安全一直都有着强烈的兴趣,上周看了一篇非常不错的文章,在和作者联系取得同意后,翻译成了中文,与感兴趣的朋友一起分享一下。下边就是原文:
上周,以太坊黑暗森林里的一只怪兽终于向我露出了他的獠牙。在与tux交流后,我得知了这只怪兽的存在,于是投下了“我的诱饵”,16个小时之后它如期上钩。在Etherscan上看到我消失的ETH,仍旧心有余悸。
这只怪兽一直在注视着以太坊网络,试图寻找以太坊交易中那个不为人注意的错误:签名中的k值复用。为了找到这只怪兽,我引诱它出现。为了理解我是怎么做到的,一些关于椭圆加密曲线签名算法(ECDSA)和数字签名的知识需要先介绍一下。
ECDSA
椭圆曲线的数字签名算法(ECDSA)是支撑当今最大的两个区块链,Bitcoin 和 Ethereum的密码学基础。就如同在现实中,人们用自己的签名来证明自己的权益,基于ECDSA的数字签名可以证明这些区块链上的数字资产的所有权。数字签名可以提供下边两个方面的证明:
- 对于私钥的所有权。每把私钥都有与之绑定的一把公钥,这把公钥同时也用来生成在区块链上的一个“地址”。
- 使用私钥对于一个消息的签名。在区块链的上下文中,这个消息就是交易。
ECDSA之所以有效是因为,我们可以使用私钥非常容易的得到公钥,但是无法(或者说很难)从公钥去推到出私钥。但是如果得到了数字签名,在一些条件下是可以推导出私钥的。下边让我们聊一点技术细节。
如果要完成对某个消息的签名,我们需要使用私钥d,一个随机值k,以及这个消息的哈希h。同时加上椭圆曲线中的G和n, 经过下边的公式计算,我们可以得到这个消息的数字签名r和s。
\[r = k * G\ mod\ n \\ s = \frac{h+d*r}{k}\ mod\ n\\\]r和s一起就是这消息数字签名。
nonce是什么?
在椭圆加密算法中,计算数字签名的随机k值是非常关键的。k值永远不能暴露,并且一个k值永远只能使用一次。这就是随机k值被称为nonce的原因。下文中也会用nonce来指代k值。如果黑客知道了某个签名对应的k值,那么它就可以通过以下的公式推算出这个签名的私钥。
\[d = (s*k - h) * r^{-1}\ mod\ n \\\]同样,如果nonce被在两个不同的签名中重复使用,这个nonce(k值)同样也可以通过以下公式被推算出来
\[k = (h_1 - h_2) * (s_1 - s_2)^{-1}\ mod\ n \\\]有了nonce就可以通过上边的公式来推算出私钥。
那在实际中我们如何判断有没有nonce重复使用呢?
我们回忆一下,在ECDSA 数字签名中r的计算过程 r = k * G mod n. 这个公式中G和n都是确定的,唯一变量就是k,所以如果用同一个私钥签两个不同消息,在得到的签名中r是一样的,那么就可以判断出有nonce重复使用的问题。
在了解了这些后,我们来看看以太坊上的交易,如果一个地址下的两笔交易的签名有相同的r值但是s值不同,那么可以判断这个地址下有nonce重复使用的情况。这就是“那只怪兽”一直的关注点。也是我下边所用的实验方法。
Note:对于普通的用户来说,只要选择靠谱的钱包,你不要关心nonce泄露和重复使用的问题。但是对于区块链开发者来说,这些是需要了解和注意的。
下饵,引蛇出洞
为了引蛇出洞,找到这只怪兽,我构造了两笔交易,这两笔交易的签名使用了相同的nonce,所以他们签名会有相同的r值。我在这个地址上留了点ETH,所以如果有任何人盯着这个地址,那么它就可以通过签名推算出私钥来转走这个地址上的ETH。
为了制作这些诱饵,我必须构造出两笔nonce重复使用的交易,当然你没法使用Metamask来达到这个目的。于是我使用ether.js来达到这个目的。来看下边的示例代码。
1
2
3
4
5
6
7
var drbg = new HmacDRBG({
hash: this.hash,
entropy: bkey,
nonce: 1, // changed from "nonce"
pers: options.pers,
persEnc: options.persEnc || 'utf8',
});
(代码仅供参考示例,别在自己的钱包上试)
在这里我把nonce设为了1!然后我重新生成了一把私钥,并在地址上充了0.04ETH,然后我使用下边的脚本,生成了两笔交易
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
const ethers = require("ethers")
async function main(){
const privateKey = "not-leaking-it-this-way"
let wallet = new ethers.Wallet(privateKey)
console.log("Using wallet:", wallet.address)
const provider = new ethers.providers.JsonRpcProvider("rpc-endpoint")
let signer = wallet.connect(provider)
const tx = await signer.sendTransaction({
to: wallet.address,
value: ethers.utils.parseEther("0").toString(),
gasLimit: 45000,
})
console.log(tx)
}
main()
由于我把nonce设为了1, 所以这两个交易的签名是有相同的r,和不同的s值。写了一个简单的脚本验证了一下:
1
2
3
4
5
6
7
8
robert@mbp nonce-reuse-bait % node get_r_s.js
Transaction 1
r: 0x340709f674d030dda4aa8794bffb578030870bdfe583e7f41aea136a7ca1ed94
s: 0x3e5b92d8c5a2a033c9e5eb53ff2946681b28ab82fa5b17d0a9c48d139e78fe2c
Transaction 2
r: 0x340709f674d030dda4aa8794bffb578030870bdfe583e7f41aea136a7ca1ed94
s: 0x2c17cf960d1af7602f875afc56d01eddcc67bb03e962877444ed8d4c1287ab7a
随着这两笔交易的上链,签名私钥其实已经暴露了。我已经把饵下好,现在就静静地等待那只怪兽的上钩。
惊鸿一瞥,怪兽出没
当发送完这两笔交易后,我就不断的刷新区块浏览器来观察地址上的ETH是否还依旧存在。但是奇怪的事,一切如常。又过了几个小时,依旧一切如常。我都开始怀疑是不是自己搞错了什么,但是天色已晚,我就先去休息了。
第二天早上一早,我就查看我的账户,它出现了!我地址上的ETH被取的干干净净,我故意留在地址上的0.04个ETH被取走了!
那只怪兽终于露出了獠牙,他注视着以太坊上的交易, 看是不是有交易的签名有相同的r值。当他发现以后就去推算他们的私钥,取空他们账户上的所有资产。我有点疑惑的是,为什么过了这么久它才出动?有一种可能性是它一直在默默等待,看这个账户上会不会有更多的资产转进来,它好一次性的都转走。
让我们近距离的看看这只怪兽,我不仅仅是唯一的受害者,它同样也取干了别人的资产!
这个地址一直有从不同地址下转入的ETH,截止目前这个账户上有价值$3,700的资产。为了验证这些被盗地址是否也有nonce重复使用的问题,我写了一个脚本来检查他们历史上交易检查是否也有相同的r值。我检查这只怪兽(黑客)盗取的第二地址,发现它之前发送的交易也存在r值重复使用的问题。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
robert@mbp nonce-reuse-bait % node get-tx-history.js
Same r found!
r: 0xf0d7b10f398357f7d140ff2be1bea9165d32238360ad0f82911235868be7c6e1
hash: 0xb5d2454d7380bfa7ac75ec76f15eecb56e60941429153081fe799fb53a7ff901
r: 0xf0d7b10f398357f7d140ff2be1bea9165d32238360ad0f82911235868be7c6e1
hash: 0x9e459be7fa9950835a3c2594d3440c684fed05fa8e12e8088cc7776c4afb364c
Same r found!
r: 0x41d43fd626c24e449ac54257eeff271edb438bbabbc9bee3d60a5bd78dc39d6d
hash: 0x670f66ff71882ae35436cd399adf57805745177b465fdb44a60b31b7c32e4d16
r: 0x41d43fd626c24e449ac54257eeff271edb438bbabbc9bee3d60a5bd78dc39d6d
hash: 0x374180005946ef3b1906ee1677f85fa62eb5a834aa0241b4c9c74174bca26a07
这进一步证明了我的猜测,这只怪兽紧紧盯着以太坊上的交易,时刻关注着是否有nonce复用的情况。一旦发现了nonce复用,它会慢慢的,悄悄地把这些地址上的资产都取光。
在我分析了这只怪兽攻击的其他地址后,我惊奇的发现有些地址并没有nonce重复使用的问题,事实上在它攻击的20个地址里,有9个存在nonce重复使用的问题,而其他并没有。
那么其他11个地址是什么因为什么遭到了攻击呢?老实来说我并不清楚,一种可能性是这只怪兽同时还有其他策略去尝试推算私钥,例如用常见的一些单词,数字来推算私钥。同时还有一些其他的方法来利用nonce生成中的漏洞。但是我并没有从这只怪兽的行为中找到证明。
以太坊黑暗森林里的这只怪兽终于被我找到,但是会不会有或者谁是它的下一个受害者?这依旧是个谜题。
Aaron简评:
私钥生成不随机,nonce生成不随机,nonce重复使用这些问题都会有泄漏的可能性。
对于用户来说,选择靠谱的钱包是避免这个问题的最好的方法,尤其推荐使用有真随机数生成器的硬件钱包。
对于开发者来说,重视随机数的产生,选择靠谱的cryptographic library。同时使用确定性ECDSA签名算法也是避免这个问题的另一种方式。
Comments powered by Disqus.