Finally, I solved the problem:
as previously said, the method
ciph.doFinal(src_buff, (short)(src_base + 2), size, mem.getBuffer(),
(short)(dst_base + 2))
throws an Exception. The problem is the destOffset (in this case dst_base + 2)
if destOffset is > 304 then the JCOP41v2.2 always throws an
ArrayIndexOutOfBoundsException...
So, to use the MUSCLE Applet with a JCOP41v2.2, I fixed in this way:
---------------------------------------
byte result[] = new byte[1024]; //declared in cardedge.java
...
else {
ciph.doFinal(src_buff, (short)(src_base + 2), size, result,
(short)0); //now destOffset is 0
Util.arrayCopyNonAtomic(result,(short)0,mem.getBuffer(),(short)(dst_base
+ 2),size);
}
....
------------------------------------------
About the strange behaviour of the ciph.doFinal in JCOP41v2.2, I asked to
IBM Zurich.
Bye
Stefano
>>
>> I will try to figure it out if it is a bug of the card or of the applet.
>
>
> I've tried to reproduce the bug with the JCOP simulator...
>
> 1- Muscle Applet installed
> 2- Framework initialized with the INS_WRITE_FRAMEWORK
> 3- Imported 1 cert x509, 1 priv key and 1 pub key correctly
>
> until this point the APDU sent and the relative responses of a
> JCOP41v2.2, an E-gate and the JCOP simulator are the same.
>
> Now, after the PIN has been verified,
> I send the cipher init with
> [INS_COMPUTE_CRYPT] b0 36 00 01 05 0003010000
> <-:9000
>
> this it's OK on all the cards and the simulator
>
> but when I send the cipher final with
> [INS_COMPUTE_CRYPT] b0 36 00 03 83 0100801122334455667788000000.........00
>
> the Schlumberger E-gate and the JCOP SIMULATOR return the correctly
> encripted 128 bytes
> while the JCOP41v2.2 returns 6F00...
>
> I catched the point where the exception is thrown, it's the ciph.doFinal
> method: it doesn't throw a
> CryptoException but a general Exception
>
---------------------------------------------------------------------------------------------------------------------------------
>
> private void ComputeCrypt(APDU apdu, byte buffer[])
> ....
> case OP_FINALIZE:
> ...
> case CD_ENCRYPT:
> case CD_DECRYPT:
> ....
> ciph.doFinal(src_buff, (short)(src_base + 2), size,
> mem.getBuffer(), (short)(dst_base + 2));
>
---------------------------------------------------------------------------------------------------------------------------------
>
>
> The different behaviour between the JCOP Simulator and the JCOP41v2.2,
> makes me think that
> maybe the Java Virtual Machine is not well implemented as regard the
> javacardx.crypto.Cipher class...
>
> What do you think about?
_______________________________________________
Muscle mailing list
[email protected]
http://lists.drizzle.com/mailman/listinfo/muscle
