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

我的问题如下所示：我在 javaCard (jcdk 2.2.2) 上生成签名，当我想使用 BouncyCastle 在终端上验证它时，签名并不总是经过验证 - 3,66 中的 1（100 次尝试的平均值）签名是验证完毕，其余返回 false。当我验证卡上的签名时，它总是返回 true，但在终端上它通常返回 false，但有时返回 true。因为终端有时会给出肯定的答案，我认为代码没问题，原因是在其他地方，但我可能是错的。

在javacard上我使用Signature.ALG_ECDSA_SHA，并在终端Signature.getInstance（“SHA1withECDSA”，“BC”）上我也尝试了SHA1withDetECDSA，但我的行为类似。

请帮忙。

问题在于 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 的 SEQUENCE）

然而，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]

Bouncy Castle 必须将 JavaCard 转换为：

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

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

编辑：受到 TajnosAgentos 观察的启发：

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