this crypto is not a trivial piece of work, it requires very careful inspection of the gp spec. Everything is written in there. the only other document required is the way to compute the ISO9697 (IIRC) HMAC. single DES rounds plus final triple des is tricky. (maybe it's for SCP01? can't remember, I implemented both, because I also have old cards - that was 3 years ago)

Anyway it's normal to spend a large amount of time on it.

are you sure that you used the same challenges and sequence counter?
also check the IVParameterSpec is not passed by reference so the iv may be modified between the two uses.
and check the chaining mode, I remember ECB and CBC are used, I may be confused wit SCP01

and double check all constants, I don't have the spec under my nose right now but I remember there was a 0181 somewhere, maybe not 0182.

All of this from memory of course, that's just some ways to go forward. this needs to be fact checked with the proper documents.

I'm using the SCP02 conforming to the GPCardSpec_v2.2 , and for the generation of th EN key session the constant is 0182, 0181 is for KEK session key. For the ecryption mode it's the CBC one i cheked on the spec. But fir the IV i don't get it, you say 'is not passed by reference' , because first i initialize it and pass it in the method init directly.

In the spec the way we obtain the derivation data for SCP02 is constant+sequence counter+padding (0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00).

I think the problem is the way i encrypt or i don't khwo because i'm using DESedeKeySpec for the instantiation of the key and SecretKeyFactory . Do you think this implementation is the problem???

NB: i'm using the information of anathor test that was succesful in external authentificate , so i used the same keys and the same card response f0r init update just to obtain the correct session key.

the thing with the iv was: are you sure the iv is correctly initialized each time you use it in cipher.init()?

it could happen that the data inside the iv array is modified after being used in init/update/dofinal, to allow continuation of the crypto stream in next calls. displaying the value of "iv" just before use could help.

yes, there is no class for ECB, because Electronic Code*B*ook is the trivial mode.
On the contrary CBC is an additional "layer" (mode of operation) that can work with any block algorithm, so a helper class was made for it.

Just encode the input blocks with DESedeEngine with the same key without any chaining.

If you're implementing a spec that uses ECB that's ok, but for anything else (including large data blocks) it's not very secure. Just see the wikipedia article and compare the tux images!

http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation

I'm glad that I could help.

Regards

(PS: @Adriaan "a fishing pole is better that a fish", looking at someone else's code is not a good way to build expertise - you may loose time, copy hidden bugs, and loose freedom to implement it in a way that you control and understand - specifically such a crypto code. going back to the spec is the best way to learn here. If you want to check you work, generate test vectors with a known good implementation and compare. in that situation, the test vectors were already made by our "numbered" friend)

I have a strange problem that i can't understand.I'm testing the mutual authentification process,so i have already a test that succeded but not in my application.So when i take information for the response of the card to init update (i mean sequence counter , data diversification , card challenge and cart cryptogram) i get the good session keys , card cryptogram and MAC when i compare to the result of the other test .But!! when i use another test with another information , it failed !!! I can't understand