Stefano Frassi wrote:
> 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
Great work.
But maybe there is another solution for this (An object of the
ObjectManager?), because these 1024 bytes are only used for this bug fix
and this memory is expensive on smart cards (without Garbage
Collection). But I know no good solution ... ObjectManager allocates
data from the end, so that beginning starting with offset > 304 is
always available ... but then this space must be reserved ... memory
with CLEAR_ON_RESET, but so much of this memory will not be available
(?) ... no idea.
Karsten
>
> ...
> 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
_______________________________________________
Muscle mailing list
[email protected]
http://lists.drizzle.com/mailman/listinfo/muscle
