Reputation: 21
I am new to Java Card development, so I might not be correct in my statements, but I have at least tried to do my research.
I am trying to install an applet onto my smart card using a custom program which uses WinSCard for APDU communication (SCardTransmit function). This program was successful in installing applets for the previous card I used, which was a JavaCOS A22, but unsuccessful with my new card, which is an NXP J3H145. The error happens in the INITIALIZE UPDATE command, which returns the error code 67 00, or "Wrong length".
The sequence is the following:
There are no commands preceding these commands.
Now, "wrong length" sounds like it could be talking about the Lc or the Le, which you may notice is not present in either of my commands.
Lc I have triple-checked to be correct. Its value is set directly with the length of the byte array that is sent as data.
Le I have tried to append to the APDU's data field (where I understand it should go) with several different values: 00 (as the GlobalPlatform Card Specification 2.2.1 says it should be (E.5.1.2)), 20 (32 in decimal, the maximum length of the INITIALIZE UPDATE response in bytes according to SCP03's specification (7.1.1.6)) and FF (maximum value), but the error message is still the same (67 00, "Wrong length").
I also happen to have another one of these new cards, so I have tested it as well, and it behaves the same way.
I also tried sending the SELECT command twice to see if the second APDU was always failing (I have heard that this happens sometimes), but it was successful, and the INITIALIZE UPDATE command after that was still unsuccessful the same way.
I have also sent different length host challenges in case the challenge is not supposed to be the 8 bytes that the GlobalPlatform Card Specification specifies. The lengths I tried were 16, 32, 64, 4, 6, 7, 9, 10 and 12, but they all resulted in the same "wrong length" error.
Hopefully there's some kind of answer to this. I've been at this for quite a while. Thank you for your time.
Upvotes: 1
Views: 241
Reputation: 21
I managed to figure it out! It turns out that the lack of the Le byte was indeed the problem, but I'd executed my attempts to add it incorrectly. I added it in such a way that it was included in the length that was given to Lc, which meant that the Lc became the erroneous value and the new reason behind the 67 00, which I mistakenly thought was still caused by the same issue.
As for the SELECT command going through "without" the Le, it seems that it did so because it was reading my Lc (value 00) as the Le because it assumed there was no Lc since the data field was empty.
I did run into another problem right after figuring this out, but it seems unrelated to this, so I'll close this now and make another question for it if the need arises. Thank you all for your attention and patience.
Upvotes: 0