Design error in javax.smartcardio?

I just hit a problem that makes me believe there is a bug or design error in javax.smartcardio.

When SmartcardIO recieves the procedure bytes 61xx, it issues a GET RESPONSE-command with the class byte from the previous “main” command. This conflics with the EMV specifications (and possibly also the ISO-7816 spec).

Here’s my problem:

When you send commands to an EMV card, the card usually responds by sending procedure bytes (SW1SW2 = 61xx or 6Cxx). These bytes should (according to 7816 and EMV spec) be handled by the TTL (Terminal Transport Layer, eg the smartcardIO API), and not by the TAL (Terminal Application Layer, eg your own code).
And smartcardio does this. So far so good. But the problem occurs when I issue the EMV command “GET PROCESSING OPTIONS”.
This command has CLA=0x80 and INS=0xA8. When the TTL (that is, the smartcardio API) recieves the procedure bytes 61xx from the card, SmartcardIO issues the GET RESPONSE command with CLA=0x80 and INS=0xC0, however the EMV specs clearly states that this command must use CLA=0x00. So in other words, SmartcardIO uses the CLA from “GET PROCESSING OPTS” (the main command) when issuing the GET RESPONSE command. Some EMV cards ignore the value of the CLA-byte at this stage, but others are not so forgiving.

Look here at lines 198-210

I’ve tried reading the 7816-4 specs about the GET RESPONSE-command,
but it doesn’t state specifically that the GET RESPONSE command should use the CLASS byte from the previous “main” command.

I’m considering submitting this to Sun as a bug.

Am I missing something, or is this a design error in smartcardio?


4 responses to “Design error in javax.smartcardio?

  • Mike

    Hi, did you managed to overcome the GET RESPONSE problem? I am deciding now what should I base my EMV application: on javax.smartcardio or maybe on jaccal ( so this is really interesting for me if there is still a bug in jdk


  • Chuan

    Hi, this auto GetResponse feature can be turned off by adding this VM argument

  • Maarten Bodewes

    Yes, this is probably a bug in the smartcardio API. The first bit of the CLA byte indicates that the APDU is proprietary or not. GET RESPONSE is certainly not proprietary. The trouble of course is that if you use proprietary APDU’s, then all best are off.

    The other problem is that ISO 7816 is probably one of the worst standards in existence. It is incomplete and does not establish a baseline functionality, let alone that it handles all situations that may occur. I’ll not go into their way of handling ASN.1 structures (BER/DER) or secure messaging (which is handled as part of the APDU specification instead of a layer by almost all applications).

    So my general advise with ISO 7816 is to forget all implementations that you did and start over for each new application, with the exception of CommandAPDU and ResponseAPDU if you are lucky. Use Chauns advice and do it yourself.

    PS very late response, for those other smartcardio devs out there

  • Martin Paljak


    ISO7816-4 tells:
    If SW1 is set to ’61’, then the process is completed and before issuing any other command, a GET RE- SPONSE command may be issued with the same CLA and using SW2 (number of data bytes still available) as short Le field.

    So I believe this is a non-conformance/difference/misunderstanding between EMV and 7816-4 (regarding interindustry and proprietary CLA appliance)

    Thanks for the tip on YetAnotherOptionToTweakPCSC with javax.smartcardio !

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: