Question

我正在与使用以太坊标准（secp256k1）生成并签名的HSM接口。我使用称为Graphene的软件包与HSM进行接口。我使用其“ pointEC”属性拉出公钥： 0xc87c1d67c1909ebf8b54c9ce3d8e0f0cde41561c8115481321e45b364a8f3334b6e826363d8e895110fc9ca2d75e84cc7c56b8e9fbcd70c726cb44f5506848fa

我可以用来生成地址：0x21d20b04719f25d2ba0c68e851bb64fa570a9465

但是，当我尝试使用密钥对来自dApp的个人消息进行签名时，签名始终会评估为其他地址。例如，随机数/消息： wAMqcOCD2KKz2n0Dfbu1nRYbeLw_qbLxrW1gpTBwkq的签名：

0x2413f8d2ab4df2f3d87560493f21f0dfd570dc61136c53c236731bf56a9ce02cb23692e6a5cec96c62359f6eb4080d80328a567d14387f487f3c50d9ce61503b1c

但是它会恢复有效地址0xFC0561D848b0cDE5877068D94a4d803A0a933785

这大概都具有相同的私钥/公钥。当然，我仅附加了“ 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个键，它也会失败。

Answer 1

地址仅通过公钥计算，而签名使用ECDSA生成。 ECDSA由一个随机值r和一个特定于该随机值（当然还有私钥）的签名s组成。更多信息here (Wikipedia on ECDSA)。

您看不到它，因为它们只是被编码为静态大小（无符号，大整数）的值，然后串联在一起称为“签名”（因此，签名的大小是密钥大小的两倍），而不是32个字节，而是64个字节）。验证将解析签名并再次使用单独的值。使用以太坊和BitCoin，可以在签名之前添加一个额外的字节，以便可以取回公钥，然后重新计算地址。这也改变了签名生成，因此您不再使用普通的ECDSA。

还有X9.62签名格式，它仍然由两个单独的整数组成，使用ASN.1 / DER编码进行编码。由于分离/编码两个整数所需的开销，这些签名看起来只是部分随机。

Answer 2

结果证明我正在使用不推荐使用的Buffer.from函数，因为更新的版本要求您指定传入数据的格式。

E.g. Buffer.from("04021a","hex")

由于这是最终的“输入”和计算，因此我花了很长时间才意识到此时数据已被错误地转换。我以为我已经在每个步骤中多次检查并重新检查了数据，但错过了最亲密的部分。

此外，我了解到要创建适当的签名并防止交易延展性，您必须不断辞职，以使s的值最终小于： (0xfffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364141)/2

然后，当通过地址恢复功能放置“ r”和“ s”时，它应尝试恢复v = 27或v = 28（0x1a或0x1b）的地址，基本上，这是反复试验的结果。在大多数情况下，它将恢复v = 27的正确地址。

为什么相同的HSM密钥每次都会验证到不同的以太坊地址？

2 个答案: