java - 在 bouncy caSTLe 上验证 javacard 签名 ALG_ECDSA_SHA

Question

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

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

请帮忙。

Answer 1

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

JavaCard 签名(同样适用于 Prime192v1)采用十六进制格式如下所示:

30 36 02 19 [第一个坐标的 25 个字节] 02 19 [第二个坐标的 25 个字节]

(它是一个 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 个字节] 02 **18** [第二个坐标的 24 个字节]

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

编辑:灵感来自 TajnosAgentos 的观察:

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