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

内容导读

互联网集市收集整理的这篇技术教程文章主要介绍了在充气城堡上验证javacard签名ALG_ECDSA_SHA，小编现在分享给大家，供广大互联网技能从业者学习和参考。文章包含1416字，纯文字阅读大概需要3分钟。

内容图文

我的问题看起来像这样：我在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总是一个正数.

内容总结

以上是互联网集市为您收集整理的在充气城堡上验证javacard签名ALG_ECDSA_SHA全部内容，希望文章能够帮你解决在充气城堡上验证javacard签名ALG_ECDSA_SHA所遇到的程序开发问题。 如果觉得互联网集市技术教程内容还不错，欢迎将互联网集市网站推荐给程序员好友。

内容备注

版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 gblab@vip.qq.com 举报，一经查实，本站将立刻删除。

内容手机端