Javacard KeyAgreement 与 BouncyCastle KeyAgreement 不同答案

【问题标题】：Javacard KeyAgreement differs from BouncyCastle KeyAgreementJavacard KeyAgreement 与 BouncyCastle KeyAgreement 不同
【发布时间】：2015-03-09 23:02:55
【问题描述】：

我的问题看起来像这样。我已经在卡和终端侧生成了密钥。我在终端端有卡公钥和私钥以及终端公钥和私钥，在卡端也是如此（我正在做测试，这就是为什么我在终端和卡上都有它们）。当我为私有卡和私有终端生成 KeyAgreement（终端端）时，扇区是相同的，所以生成是好的，我得到一个 24 字节（192 位）的秘密。当我在卡上生成秘密时（2 种情况，如在终端上），秘密也是相同的，但它们更短 - 20 字节（160 位）。这是生成代码。终端：

ECPublicKey publicKey;
ECPrivateKey privateKey;

...

KeyAgreement aKeyAgree = KeyAgreement.getInstance("ECDH", "BC");
aKeyAgree.init(privateKey);
aKeyAgree.doPhase(publicKey, true);
byte[] aSecret = aKeyAgree.generateSecret();

和卡方：

eyAgreement = KeyAgreement.getInstance(KeyAgreement.ALG_EC_SVDP_DH, false);
short length = terminalEcPublicKey.getW(array, (short) 0);

keyAgreement.init(cardEcPrivateKey);
short secretlength = keyAgreement.generateSecret(array, (short)0, length, buffer, (short)0);

【问题讨论】：

标签： bouncycastle javacard elliptic-curve diffie-hellman

【解决方案1】：

您在终端端执行KeyAgreement.ALG_EC_SVDP_DH 时出现问题。由于对派生的输出执行 SHA-1，因此这种密钥协商方法的正确输出长度应始终为 20 字节。

所以在你的终端端，你应该在生成秘密数据后执行 SHA-1。

【讨论】：

为什么会这样？卡不必那样做，那终端为什么要那样做呢？
实际上，该卡确实执行 SHA-1。 generateSecret() 对 ALG_EC_SVDP_DH 算法执行此操作。
但是为什么终端不这样做呢？
在 JavaCard 中，有 ALG_EC_SVDP_DH、ALG_EC_SVDP_DH_KDF、ALG_EC_SVDP_PLAIN、ALG_EC_SVDP_DHC 等等）。 ECDH 在所有这些算法中执行，它们只是在计算后（在您的情况下执行 SHA-1）有所不同，这与 ECDH 算法不再相关。在您的终端端，您创建了一个带有参数“ECDH”的 KeyAgreement 实例，这表明它只执行 ECDH。我认为在 ECDH 计算之后进行任何后期计算都取决于终端。