在bouncy城​​堡验证javacard签名ALG_ECDSA_SHA [英] Verify javacard signature ALG_ECDSA_SHA on bouncy castle

问题描述

我的问题看起来像这样：im在javaCard（jcdk 2.2.2）上生成签名，当我想在终端上使用BouncyCastle验证签名isnt总是验证 - 1在3,66（平均在100尝试）签名被验证，其余的返回false。当我验证卡上的签名，它总是返回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 [第一个协调的25个字节] 02 19 [第二个协调程序的25个字节]

$ <$>

（它是一个DER编码结构：两个INTEGER的SEQUENCE）

但是，BouncyCastle不期望在EC坐标中引导这些零。所以你必须删除它们并修复DER结构，例如

  30 36 02 19 ** 00 00 ** [其余23个字节的第一个协调] 02 19 ** 00 ** [第二个协调的24个字节] 
  

from JavaCard必须将Bouncy Castle转换为：

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

：有时在您的JavaCard签名坐标中没有前导零。

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

BouncyCastle将coords编码为有符号整数，JavaCard总是作为无符号整数。这就是为什么BouncyCastle在第一个字节的最高有效位为1时添加一个特殊的前导零（虽然它修剪其他前导零），因为coord总是一个正数。

My problem looks like this: im generating a signature on javaCard (jcdk 2.2.2) and when when i want to verify it on the terminal using BouncyCastle the signature isnt always verified- 1 in 3,66 (average in 100 tries) signatures are verified, the rest in returning false. when i verify the signature on the card it always returns true, but on the terminal it usually returns false, but sometimes true. because the terminal sometimes gives a positive answer i think that the code is ok and the reason is some where else but i can be wrong.

on javacard im usign Signature.ALG_ECDSA_SHA, and on the terminal Signature.getInstance("SHA1withECDSA", "BC") i tried also SHA1withDetECDSA but i behaves similar.

please help.

解决方案

The problem is that JavaCard and BouncyCastle use different format of the resulting signature. For example for the Prime192v1 curve the resulting JavaCard signature is always 56 bytes long, but the Bouncy Castle signature is sometimes shorter, because it omits leading zeros in EC point coordinates.

The JavaCard signature (for Prime192v1, again) looks like this in the hexadecimal format:

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

(it is a DER encoded structure: SEQUENCE of two INTEGERs)

However, BouncyCastle does not expect leading these zeros in EC coords. So you have to remove them and fix the DER structure, for example

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

from JavaCard must be converted for Bouncy Castle to:

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

The reason why you sometimes verify the signature correctly is simple: sometimes there are no leading zeros in your JavaCard signature coordinates.

EDIT: inspired by TajnosAgentos' observation:

BouncyCastle encodes coords as signed integers, JavaCard always as unsigned integers. That is why BouncyCastle adds a special leading zero (although it trims other leading zeros) whenever the most significant bit of the first byte is 1, because the coord is always a positive number.

这篇关于在bouncy城​​堡验证javacard签名ALG_ECDSA_SHA的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！