验证充气城堡上的 javacard 签名 ALG_ECDSA_SHA

Question

我的问题看起来像这样：我在 javaCard (jcdk 2.2.2) 上生成一个签名，当我想在终端上使用 BouncyCastle 验证它时，签名并不总是验证 - 3,66 中的 1 个（平均 100 次尝试) 签名被验证，其余的返回假。当我验证卡上的签名时，它总是返回 true，但在终端上它通常返回 false，但有时返回 true。因为终端有时会给出肯定的答案，所以我认为代码没问题，原因是其他地方，但我可能是错的。

在 javacard 上使用 Signature.ALG_ECDSA_SHA 和终端 Signature.getInstance("SHA1withECDSA", "BC") 我也尝试过 SHA1withDetECDSA 但我的行为相似。

请帮忙。

Answer 1

问题在于 JavaCard 和 BouncyCastle 使用不同格式的结果签名。例如，对于 Prime192v1 曲线，生成的 JavaCard 签名始终为 56 字节长，但 Bouncy Castle 签名有时更短，因为它省略了 EC 点坐标中的前导零。

JavaCard 签名（同样适用于 Prime192v1）的十六进制格式如下所示：

30 36 02 19 [25 bytes of the first coord] 02 19 [25 bytes of the second coord]

（是DER编码结构：两个INTEGER的序列）

但是，BouncyCastle 不希望在 EC 坐标中领先这些零。因此，您必须删除它们并修复 DER 结构，例如

30 36 02 19 **00 00** [the rest 23 bytes of the first coord] 02 19 **00** [24 bytes of the second coord]

从 JavaCard 必须为 Bouncy Castle 转换为：

30 **33** 02 **17** [23 bytes of the first coord] 02 **18** [24 bytes of the second coord]

您有时正确验证签名的原因很简单：有时您的 JavaCard 签名坐标中没有前导零。

编辑：受 TajnosAgentos 观察的启发：

BouncyCastle 将坐标编码为有符号整数，JavaCard 始终编码为无符号整数。这就是为什么当第一个字节的最高有效位为 1 时，BouncyCastle 会添加一个特殊的前导零（尽管它会修剪其他前导零），因为坐标始终是正数。

Answer 2

我有一个解决方案。我不知道为什么会这样，但确实如此... javacard 上的签名函数应该如下所示：

    byte[] buffer = apdu.getBuffer();

    signature.init(ecPrivateKey, Signature.MODE_SIGN);
    short sLen = signature.sign(helloWorld, (short) 0, (short)helloWorld.length, scratch, (short) 0);

    if((short)scratch[4] < 0 || (short)scratch[30] < 0)
    {
        sign(apdu);
    }
    else
    {
        Util.arrayCopyNonAtomic(scratch, (short)0, buffer, (short)0, (short) sLen);

        apdu.setOutgoingAndSend((short)0, (short)sLen);
    }

是一个“原型”函数。它有效，所以我先分享它，稍后也许我会改进它。 scratch 是在其他地方声明的字节数组。

就像 VOJTA 之前发布的那样，签名（在我的示例中）看起来像这样：

30 34 02 18 [24 字节 NO1] 02 18 [24 字节 NO2] [SW - 90 00]

不需要软件。所以[24 bytes NO1]的第一个字节的SHORT值和[24 bytes NO2]的第一个字节的SHORT值不能为负数。我不知道为什么会这样。我打印了已验证和未验证的签名，我正在寻找任何差异，我发现了这一点。我进行了 1000 多次尝试，验证始终返回 TRUE。这 2 个字节为负数的概率是 1/4（（-128,127），0 变为正数，半负数，半正数 -> 1/2 * 1/2 = 1/4）所以可能这就是为什么前面只有 1对 3,66 个签名进行了验证。如果有人知道它为什么起作用，我会很高兴阅读他的帖子

编辑

现在我知道它是如何工作的了。这个问题有解决办法。一种是上面的解决方案——生成签名直到数组的 2 个元素的 SHORT 值为正数，第二种解决方案：

签名看起来像这样：

30 34 02 18 [24 字节 NO1] 02 18 [24 字节 NO2]

现在是 VOJTA 所写的算法（如果需要，粗体值将被更改） lex x=34（符号的第二个字节——这可能会有所不同，在我的签名中是 34）。 如果 [24 byte NO1] 和 [24 byte NO2] 的第一个字节是肯定的，则对签名不做任何事情。 如果 [24 bytes NO1] 的第一个字节的 SHORT 值为负，那么我们必须将 ONE 添加到 X（现在 x=35），将 ONE 添加到 [24 bytes NO1] 的第一个字节旁边的 18 并插入一个签名的 18（现在是 19）旁边的值 00。如果 [24 bytes NO2] 的第一个字节的 SHORT 值为负，那么我们必须将 ONE 添加到 X（现在 x=36），将 ONE 添加到 [24 bytes NO2] 的第一个字节旁边的 18 并插入 00在 18 岁（现在是 19 岁）旁边。如果两个第一个字节都是负数，那么签名应该是这样的：

30 36 02 19 00 [24 字节 NO1] 02 19 00 [24 字节 NO2]

如果只有 [24 bytes NO1] 的第一个字节为负，而 [24 bytes NO2] 的第一个字节为正，则签名应该看起来像这样

30 35 02 19 00 [24 字节 NO1] 02 18 [24 字节 NO2]

最后一种情况： 如果只有 [24 bytes NO1] 的第一个字节为正，而 [24 bytes NO2] 的第一个字节为负，则签名应该看起来像这样

30 35 02 18 [24 字节 NO1] 02 19 00 [24 字节 NO2]

希望对你有用