RSA加密在JavaCard上间歇性地抛出异常 [英] RSA Encrytion throws an exception intermittently on JavaCard
问题描述
我编写了一个程序，使用我的Java Card上的RSA公钥加密 10 字节随机数。每次卡接收到该APDU命令时都会生成随机数，并且当我的applet中相关的密码对象块大小为2048位时，我追加242字节的 0x00 at这个 10 字节随机数的结尾使它 256 字节长度。
I've written a program to encrypt 10 bytes random number using an RSA public key on my Java Card. The random number is generated each time that the card receives that APDU command, and as the related cipher object block size is 2048 bit in my applet, I append 242 bytes of 0x00 at the end of this 10 byte random number to make it 256 bytes length.
问题是有时响应是带有 05 值的加密异常。如您所知和提到的JC API文档：
The problem is that sometimes the response is a Crypto Exception with 05 value. As you know and as JC API documents mentioned:
0x05= ILLEGAL_USE
0x05= ILLEGAL_USE
public static final short ILLEGAL_USE
public static final short ILLEGAL_USE
此原因代码用于
指示签名或密码算法不填充
传入消息，并且输入消息不是块对齐的。
This reason code is used to indicate that the signature or cipher algorithm does not pad the incoming message and the input message is not block aligned.
As输入长度在我的applet中修复，我无法解决我的问题！
As the input length is fixed in my applet, I can't resolve my problem!
这是我的applet的相关部分：
Here is the related part of my applet:
protected final void getEncChallenge(APDU apdu) {
random.generateData(generatedChall, (short) 0, (short) 10);
initAsymCipher(ENTITY_BOB, MODE_ENC);
Util.arrayCopy(generatedChall, (short) 0, transientData, (short) 0, (short) 10);
Util.arrayFillNonAtomic(transientData, (short) 10, (short) 246, (byte) 0x00);
rsaCrypto(transientData, persistentData);
apdu.setOutgoing();
apdu.setOutgoingLength((short) 256);
apdu.sendBytesLong(persistentData, (short) 0, (short) 256);
}
protected final void rsaCrypto(byte[] inData, byte[] outData) {
try{
asymCipher.doFinal(inData, (short) 0, (short) 256, outData, (short) 0);
}catch(CryptoException e){
short reason = e.getReason();
ISOException.throwIt((short)(0x6d00 | reason));
}
}
以下是回复：
transientData ---> APDU Response
---------------------------------
80 ..(Eight Random Bytes).. BD ..(246 bytes of "0x00").. ---> OK (i.e. 256 byte encrypted data)
EO ..(Eight Random Bytes).. 64 ..(246 bytes of "0x00").. ---> 6D05
02 ..(Eight Random Bytes).. B3 ..(246 bytes of "0x00").. ---> OK
CB ..(Eight Random Bytes).. 35 ..(246 bytes of "0x00").. ---> 6D05
17 ..(Eight Random Bytes).. 97 ..(246 bytes of "0x00").. ---> OK
0C ..(Eight Random Bytes).. 0C ..(246 bytes of "0x00").. ---> OK
D3 ..(Eight Random Bytes).. 91 ..(246 bytes of "0x00").. ---> 6D05
86 ..(Eight Random Bytes).. E2 ..(246 bytes of "0x00").. ---> OK
C2 ..(Eight Random Bytes).. 23 ..(246 bytes of "0x00").. ---> 6D05
有没有人知道我的小程序有什么问题？
Does anyone have any idea what's wrong with my applet?
推荐答案
你在错误的一边填充。 RSA适用于大端编码数字，最大模数大小。通常的填充机制（通常的RSA安全性所需）通过左填充来工作，其值严格小于模数。
You are padding at the wrong side. RSA works on big endian encoded numbers up to the modulus size. The usual padding mechanisms (which are required for the usual RSA security) work by left padding, to a value strictly smaller than the modulus.
因此，基本上您的填充挑战被视为编码数字，并且在转换时，它有时会大于模数。当发生这种情况时，RSA例程将不接受它。
So basically your padded challenge is seen as a encoded number, and when converted, it sometimes is larger than the modulus. When that happens the RSA routine won't accept it.
填充左边的零字节应该解决这个问题。或者，您可以确保挑战的最高位被掩盖为零（& 0x7F ）。
Padding the zero bytes to the left should fix this. Alternatively you could make sure that the highest order bit of the challenge is masked to zero (& 0x7F).
这篇关于RSA加密在JavaCard上间歇性地抛出异常的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
