Tag Archives: Java

Listing available PC/SC terminals

In a followup to my post on the Dell embedded contactless smartcard reader, here are some simple methods you can use to list the available PC/SC terminals on your system.

Choose one of the following:

  1. Java (Windows + Linux):
    Make sure you have (Sun) Java 6 JDK installed
    (Note: Other JDKs might also work, but not all support the javax.smartcardio API)
    (On Linux distros you might have to do this to make it work)
    Compile and run the following little program:
    import javax.smartcardio.CardTerminal;
    import javax.smartcardio.TerminalFactory;
    * This program lists the available
    * PC/SC terminals on the current system
    public class PCSCTerminals {
        public static void main(String[] args) throws Exception {
            TerminalFactory factory = TerminalFactory.getDefault();
            for (CardTerminal terminal: factory.terminals().list()) {
                System.out.println("Terminal: " + terminal);

    Here’s the output when executed on my Dell Precision M6400:

    Terminal: PC/SC terminal Broadcom Corp Contacted SmartCard 0
    Terminal: PC/SC terminal Dell USB Reader 0

    That last terminal is the SIM card reader in the Dell WWAN 5530 HSDPA (“Turbo” 3G) card.

  3. Native Smartcard program (Windows):
    For example Scriptis EMV Explorer Tool
    This program is used to explore an EMV card (VISA, Mastercard etc smartcard), but can also be used to list PC/SC terminals.
  4. Mac ?

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?