Category Archives: Programming

How to enable PC/SC support for Dell Contactless Reader

Finally I found the solution!

In a follow up to my post on the “Dell embedded contactless reader“, here is how you enable PC/SC support for this reader.

Select Dell Latitude and Precision systems comes with an embedded contactless smart card reader. Out of the box, this reader is not PC/SC enabled. The contactless reader is only available through the CV chipset (Dell Credentials Vault), meaning that it will only work in PBA (Pre Boot Authentication), and when enrolling a contactless card through the Dell supported software (EmbassySuite/ControlPoint).

PC/SC support means that you can use this reader in your own and third-party programs, by using the standard PC/SC smartcard API.
I have contacted Dell about PC/SC support for the contactless reader, but they could not provide me with any information (they barely knew what PC/SC was).
After some frustration, I started searching through the installed files (Broadcom/Wave Systems), and I finally found the solution.

There is a utility called “ushradiomode64.exe” in the folder “c:\Program Files\Broadcom Corporation\Broadcom USH Host Components\CV\bin”.

This utility takes 1 parameter, namely the operation mode of the Contactless Reader Radio:

Example to Enable CV Only Radio Mode:
  ushradiomode -c

Example to Enable Normal Radio Mode:
  ushradiomode -n

“CV Only Radio Mode” is the default mode, and in this mode the reader is only available to the CV/PBA. In “Normal Radio Mode”, the reader becomes visible in Device Manager, and can be found when enumerating the PC/SC terminals attached to the system.

Here is how you enable “normal” mode (meaning that the reader will now become listed under “Smart card readers” in Device Manager):

  1. Make sure you have installed the latest version of the “Dell ControlPoint Security Device Driver Pack” from (Latest version as of 2009-10-09 is v1.1.30 A07)
  2. Open command prompt:
    Start -> Run -> cmd.exe
  3. Type the following 2 commands:
     cd c:\Program Files\Broadcom Corporation\Broadcom USH Host Components\CV\bin ushradiomode64.exe -n 
  4. reboot (to make windows load the PC/SC driver)

When the system starts up again, check Device Manager and confirm that there are now 2 entries under “Smart card readers”, both called “USB Smart Card Reader”. (1 for the Contactless and 1 for the Contacted smartcard reader).

I haven’t tested many cards yet, only retrieved the ATR* from a 1k Mifare Classic Card.

(* Note that contactless cards don’t have ATRs. The ATR is this case is generated by the reader or PC/SC driver for the reader. Using the ATR here is just a simple way to check that the reader at least can detect the contactless card.)

If you find time to play around with this reader through PC/SC, please let me know by posting a comment below. What cards did you test? Did everything work as expected?

Nokia 6212: Unlocking the Secure Element

In order to install your own Java Card Applets on to the Nokia 6212 Secure Element (SE) you will need to either talk to the TSM (Trusted Service Manager)(Venyon is the TSM for Nokia phones), OR, you can permanently unlock the SE by using Nokia’s UnlockMidlet (You will need to register to download. Registration is free).

First some warnings:

  • The unlock operation is PERMANENT, and cannot be undone.
  • After unlocking, no TSM will ever trust your secure element anymore, EVER (because you and other people now have access to the default keys).
  • If authentication fails more than 1o times in a row, the card manager will be locked, and you will not be able to install or delete any Applet to/from the SE.
  • Unlocking should only be performed if you want to use your phone for development or testing purposes.

You have been warned!

The UnlockMidlet establishes a secure (encrypted) connection between your SE and a Nokia server. The server will then communicate with your SE and set keyset 42 to the default keys (MAC/ENC/DEK = 404142434445464748494a4b4c4d4e4f), and the Mifare card emulation authentication keys (both key A and B) to FFFFFFFFFFFF.

Step by step:

  1. Download UnlockMidlet
  2. Upload to phone, using either bluetooth or micro-USB cable (in PC Suite mode)
  3. Make sure your phone is configured to use (GPRS) packet data (Settings -> Configuration -> Preferred access pt.)
  4. Start the UnlockMidlet.

At this point the unlock operation might fail due to “No Server Connection” (at least that happend to me). No matter how I configured the packet data settings, the UnlockMidlet always failed with “No Server Connection”.

However, there is another solution to unlock the SE, by using the SDK Emulator and a OmniKey Cardman 5321 reader:

  1. Download UnlockMidlet
  2. Download Nokia 6212 SDK (Requires registration. Registration is free).
  3. Get yourself a OmniKey Cardman 5321 Reader
  4. Download OnmiKey PCSC Driver, Synchronous API and Diagnostics Tool
  5. After installing the OmniKey software, run the Diagnostics Tool, and confirm that there is an ‘API’ tab listing “scardsyn.dll” (this dll is required when using this reader in the Nokia SDK).
  6. Run SDK ‘Emulator’, and in the Phone window, open the file menu and load the unlock midlet.
  7. In the Emulator window, drag and drop the cardman reader from “External Readers” to both 1: “Embedded Tag” and 2: “Embedded Smart Card”.
  8. On the Nokia 6212 phone, go to NFC settings and make sure “cards availability” is set to “always”.
  9. Place the 6212 on the OnmiKey reader, (lay it down on the reader and let it stay there until the unlock operation is completed).
  10. Proceed with the unlock operation in the midlet emulator.

Assuming the unlock operation was successful, you will now be able to install your own Java Card Applets using for example GPShell or GPJ (a pure java version).

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?