为什么同一个 HSM 密钥每次都会验证到不同的以太坊地址?
Why does the same HSM key verify to a different ethereum address every time?
我正在连接一个 HSM,它正在生成并使用以太坊标准 (secp256k1) 进行签名。我正在使用一个名为 Graphene 的包与 HSM 连接。我使用 "pointEC" 属性拉出 public 键:
0xc87c1d67c1909ebf8b54c9ce3d8e0f0cde41561c8115481321e45b364a8f3334b6e826363d8e895110fc9ca2d75e84cc7c56b8e9fbcd70c726cb44f5506848fa
我可以用它来生成地址:0x21d20b04719f25d2ba0c68e851bb64fa570a9465
但是当我尝试使用密钥对来自 dApp 的个人消息进行签名时,签名总是评估为不同的地址。例如,nonce/message:
wAMqcOCD2KKz2n0Dfbu1nRYbeLw_qbLxrW1gpTBwkq
有签名:
0x2413f8d2ab4df2f3d87560493f21f0dfd570dc61136c53c236731bf56a9ce02cb23692e6a5cec96c62359f6eb4080d80328a567d14387f487f3c50d9ce61503b1c
但它恢复了0xFC0561D848b0cDE5877068D94a4d803A0a933785
的有效地址
这大概都是用同一个 private/public 键。当然,我只是附加了“1c”恢复值,但即使我尝试使用其他值,我也没有运气。这里还有几个例子:
Nonce: WRH_ApTkfN7yFAEpbGwU9BiE2M6eKTZMklPYK50djnx
Sig: 0x70242adabfe27c12e54abced8de87b45f511a194609eb27b215b153594b5697b7fb5e7279285663f80c82c2a2f2920916f76fd845cdecb45ace19f76b0622ac41c
Address: 0x1A086eD40FF90E75764260E2Eb42fab4Db519E53
Nonce: TZV6qhplddJgcKaN7qtpcIhudFhiQ
Sig: 0x3607beb3d58ff35ca1059f3ea44f41e79e76d8ffe35a4f716e78030f0fe2ca1da51f138c31d4ec4b9fc3546c4de1185736a4c4c7030a8b1965e30cb0af6ba2ee1c
Address: 0xa61A518cf73163Fd92461942c26C67c203bda379
我的消息签名代码:
let alg: graphene.MechanismType;
alg = graphene.MechanismEnum.ECDSA;
const session = get_session();
let key: graphene.Key | null = null;
//#region Find signing key
const objects = session.find({label: GEN_KEY_LABEL});
for (let i = 0; i < objects.length; i++) {
const obj = objects.items(i);
if ((obj.class === graphene.ObjectClass.PRIVATE_KEY ||
obj.class === graphene.ObjectClass.SECRET_KEY) &&
obj.handle.toString('hex') == params.handle
) {
key = obj.toType<graphene.Key>();
break;
}
}
if (!key) {
throw new Error("Cannot find signing key");
}
var sign = session.createSign(alg,key);
if (!params.data) {
console.log("No data found. Signing 'test' string");
params.data = 'test';
}
sign.update(Buffer.from(params.data.toString().trim()));
var signature = sign.final();
console.log(signature.toString('hex'));
请记住,即使只有 1 个密钥,它也会失败。
地址只是通过 public 密钥计算出来的,而签名是使用 ECDSA 生成的。 ECDSA 由随机值 r 和特定于该随机值(当然还有私钥)的签名 s 组成。更多信息 here (Wikipedia on ECDSA).
你看不到这一点,因为它们只是被编码为静态大小(无符号,大整数)值,然后连接在一起称为 "the signature"(因此签名的大小是密钥大小,64 字节而不是 32 字节)。验证将解析签名并再次使用单独的值。对于以太坊和比特币,可以在签名前加上一个额外的字节作为前缀,这样就可以取回 public 密钥,然后重新计算地址。这也改变了签名生成,所以你不再谈论普通的 ECDSA。
还有 X9.62 签名格式,它仍然由两个单独的整数组成,使用 ASN.1 / DER 编码进行编码。由于分离/编码两个整数所需的开销,这些签名看起来只是部分随机。
原来我使用的是已弃用的 Buffer.from 函数,因为更新版本要求您指定传入数据的格式。
E.g. Buffer.from("04021a","hex")
因为这是最后的 'input' 和计算,我花了很长时间才意识到数据在那个时候被错误地转换了。我以为我已经多次检查并重新检查了每个步骤的数据,但是错过了最直接的部分。
此外,我了解到要创建适当的签名并防止交易延展性,您必须不断辞职,以便 's' 的值最终小于:
(0xfffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364141)/2
那么当'r'和's'通过地址恢复函数时,应该尝试恢复v=27或v=28(0x1a或0x1b)的地址,基本上是这样点它的试验和错误。大多数时候,它会恢复 正确的 地址 v=27.
我正在连接一个 HSM,它正在生成并使用以太坊标准 (secp256k1) 进行签名。我正在使用一个名为 Graphene 的包与 HSM 连接。我使用 "pointEC" 属性拉出 public 键:
0xc87c1d67c1909ebf8b54c9ce3d8e0f0cde41561c8115481321e45b364a8f3334b6e826363d8e895110fc9ca2d75e84cc7c56b8e9fbcd70c726cb44f5506848fa
我可以用它来生成地址:0x21d20b04719f25d2ba0c68e851bb64fa570a9465
但是当我尝试使用密钥对来自 dApp 的个人消息进行签名时,签名总是评估为不同的地址。例如,nonce/message:
wAMqcOCD2KKz2n0Dfbu1nRYbeLw_qbLxrW1gpTBwkq
有签名:
0x2413f8d2ab4df2f3d87560493f21f0dfd570dc61136c53c236731bf56a9ce02cb23692e6a5cec96c62359f6eb4080d80328a567d14387f487f3c50d9ce61503b1c
但它恢复了0xFC0561D848b0cDE5877068D94a4d803A0a933785
这大概都是用同一个 private/public 键。当然,我只是附加了“1c”恢复值,但即使我尝试使用其他值,我也没有运气。这里还有几个例子:
Nonce: WRH_ApTkfN7yFAEpbGwU9BiE2M6eKTZMklPYK50djnx
Sig: 0x70242adabfe27c12e54abced8de87b45f511a194609eb27b215b153594b5697b7fb5e7279285663f80c82c2a2f2920916f76fd845cdecb45ace19f76b0622ac41c
Address: 0x1A086eD40FF90E75764260E2Eb42fab4Db519E53
Nonce: TZV6qhplddJgcKaN7qtpcIhudFhiQ
Sig: 0x3607beb3d58ff35ca1059f3ea44f41e79e76d8ffe35a4f716e78030f0fe2ca1da51f138c31d4ec4b9fc3546c4de1185736a4c4c7030a8b1965e30cb0af6ba2ee1c
Address: 0xa61A518cf73163Fd92461942c26C67c203bda379
我的消息签名代码:
let alg: graphene.MechanismType;
alg = graphene.MechanismEnum.ECDSA;
const session = get_session();
let key: graphene.Key | null = null;
//#region Find signing key
const objects = session.find({label: GEN_KEY_LABEL});
for (let i = 0; i < objects.length; i++) {
const obj = objects.items(i);
if ((obj.class === graphene.ObjectClass.PRIVATE_KEY ||
obj.class === graphene.ObjectClass.SECRET_KEY) &&
obj.handle.toString('hex') == params.handle
) {
key = obj.toType<graphene.Key>();
break;
}
}
if (!key) {
throw new Error("Cannot find signing key");
}
var sign = session.createSign(alg,key);
if (!params.data) {
console.log("No data found. Signing 'test' string");
params.data = 'test';
}
sign.update(Buffer.from(params.data.toString().trim()));
var signature = sign.final();
console.log(signature.toString('hex'));
请记住,即使只有 1 个密钥,它也会失败。
地址只是通过 public 密钥计算出来的,而签名是使用 ECDSA 生成的。 ECDSA 由随机值 r 和特定于该随机值(当然还有私钥)的签名 s 组成。更多信息 here (Wikipedia on ECDSA).
你看不到这一点,因为它们只是被编码为静态大小(无符号,大整数)值,然后连接在一起称为 "the signature"(因此签名的大小是密钥大小,64 字节而不是 32 字节)。验证将解析签名并再次使用单独的值。对于以太坊和比特币,可以在签名前加上一个额外的字节作为前缀,这样就可以取回 public 密钥,然后重新计算地址。这也改变了签名生成,所以你不再谈论普通的 ECDSA。
还有 X9.62 签名格式,它仍然由两个单独的整数组成,使用 ASN.1 / DER 编码进行编码。由于分离/编码两个整数所需的开销,这些签名看起来只是部分随机。
原来我使用的是已弃用的 Buffer.from 函数,因为更新版本要求您指定传入数据的格式。
E.g. Buffer.from("04021a","hex")
因为这是最后的 'input' 和计算,我花了很长时间才意识到数据在那个时候被错误地转换了。我以为我已经多次检查并重新检查了每个步骤的数据,但是错过了最直接的部分。
此外,我了解到要创建适当的签名并防止交易延展性,您必须不断辞职,以便 's' 的值最终小于:
(0xfffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364141)/2
那么当'r'和's'通过地址恢复函数时,应该尝试恢复v=27或v=28(0x1a或0x1b)的地址,基本上是这样点它的试验和错误。大多数时候,它会恢复 正确的 地址 v=27.