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

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

在javacard im usign Signature.ALG_ECDSA_SHA,并在终端Signature.getInstance(“SHA1withECDSA”,“BC”)上我尝试了SHA1withDetECDSA,但我的行为相似.

请帮忙.

解决方法:

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

JavaCard签名(对于Prime192v1,再次)看起来像十六进制格式：

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

(它是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]

必须将来自JavaCard的Bouncy Castle转换为：

30 ** 33 ** 02 ** 17 ** [第一个coord的23个字节] 02 ** 18 ** [第二个coord的24个字节]

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

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

BouncyCastle将coords编码为有符号整数,JavaCard始终为无符号整数.这就是为什么只要第一个字节的最高位为1,BouncyCastle就会添加一个特殊的前导零(尽管它会修剪其他前导零),因为coord总是一个正数.

标签：java,cryptography,digital-signature,bouncycastle,javacard
来源： https://codeday.me/bug/20190824/1711366.html