Open max-lb opened 1 year ago
Not really, other than GP explicitly declaring that all commands being not extended and SCP02 being obsolete as well. As this is supposedly not going to a card manager (which, as said, explicitly requires short apdu-s as per 11.1.5 APDU Message and Data Length) it would require support from on-card SecureChannel.unwrap().
Which card are you using, to be able to test it?
You are right - it's not with the card manager. We are communicating with one particular applet, which requires using extended APDUs.
The cards are NXP P71 with JCOP4. Do you need some specific details?
That's a card that does SCP03 just fine - why on earth are you using SCP02 these days? :)
Most of them do work with SCP03 just fine... Unfortunately we've got some cards that come pre-personalized and "locked" to SCP02 (and we can't change this :( ).
With SCP02, trying to send an extended length APDU (> 255 bytes) with GPSession.transmit() always results in IllegalArgumentException:
With SCP03 everything works fine.
It appears, that the SCP02Wrapper doesn't know how to deal with 3-byte lenghts (Nc) in APDUs. Both when composing a partial APDU for the MAC calculation, and when composing the final APDU, it does this:
The code in SCP03Wrapper is aware of extended lengths:
Is there a reason to not support extended length APDUs with SCP02?