我有使用SHA1withECDSA算法使用BouncyCastle签名的自签名证书.在不列颠哥伦比亚省,我可以很容易地验证它,但是当我在JavaCard上做它时,它每次都给我发假(来自NIST的曲线secp192r1 )。证书持有标志在普通(非X9.62指的只是r+s没有任何标签)。
这是我的代码来验证它(当然,值被作为常量-用于测试)。
byte[] certdata ={…}
    Signature signature = Signature.getInstance(Signature.ALG_ECDSA_SHA, false);
    ECPublicKey ecpk = (ECPublicKey) KeyBuilder.buildKey(KeyBuilder.TYPE_EC_FP_PUBLIC,      KeyBuilder.LENGTH_EC_FP_192, true);
    ecpk.setA(new byte[]{...}, (short)0, (short)0x0018); 
    ecpk.setB(new byte[]{...}, (short)0, (short)0x0018);
    ecpk.setG(new byte[]{...}, (short)0, (short)0x0031);
    //Point format: uncompressed tag(0x04), x, y
    ecpk.setK((short)0x0001);
    ecpk.setR(new byte[]{}, (short)0, (short)0x0018);
    ecpk.setW(new byte[]{}, (short)0, (short)0x31);
    ecpk.setFieldFP(new byte[]{}, (short)0, (short)0x0018);
    signature.init(ecpk, Signature.MODE_VERIFY);
    boolean result = signature.verify(certdata, (short)0, (short)certdata.length, signtab, (short)0, (short)signtab.length);
    if(result) ISOException.throwIt((short)0x0001);
    else ISOException.throwIt((short)0x0002);    
}“.”而不是用于清晰视图的字节(192位曲线可能造成很大的混乱)。
贴有标签的证书-对巴斯特箱的解释:
http://pastebin.com/gvqYzm2g
谢谢你的帮助
塞瓦尔
编辑:新测试:所有测试都是在相同的数据(PublicKey、PrivateKey、消息签名)上进行的,所以我将使用2个符号(由终端(BC)生成的signT-符号,由芯片生成的signC符号)。
signT不能在芯片上进行验证,但可以在终端上进行验证。signC在芯片和终端上得到验证
所以我检查了API之间的杂交
当我把BC生成的PrivateKey和PublicKey放到芯片上时,产生的签名就可以由芯片进行验证,所以密钥对生成得很好。
我不知道现在该查什么。问题可能是在ECDSA步骤e= SHA1(Message)中填充数组。散列后数组会发生什么(散列比曲线短,卡片在复制前需要声明数组的大小)
发布于 2014-12-17 09:12:56
签署和验证的ECDSAwithSHA-1与Prime192v1从弹跳城堡到JavaCard工作对我很好。
您的问题可能是签名本身的格式。
签名是一个DER编码结构,它是由两个整数(tag 0x02)组成的序列(tag 0x30)。在JavaCard中,通常需要56个字节:长度为25的两个坐标加上6个DER头。JavaCard总是期望每个坐标中都有前导零。然而,BC通常生成没有坐标中的前导零的签名,因此签名可以小于56个字节,这就是为什么JavaCard被混淆的原因。
相反的方向总是可以的,因为BC可以处理前导零,尽管它在创建签名时不添加它们。
您应该做的是:用自己的代码包装BC签名机制,并始终在BC签名中添加前导零以协调。如果这样做,您将能够在BC和JavaCard中验证签名。
我想张贴我的代码,但不幸的是,它是一个商业安全项目的一部分.
发布于 2015-03-05 21:12:43
我在使用JavaCard 192 r1生成的ECDSA信号(在BouncyCastle上生成)时遇到了问题,并找到了解决方案。我希望这是有用的
https://stackoverflow.com/questions/13721862
复制相似问题