Tag Archives: iso7816

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 http://support.dell.com. (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?

Advertisements

Mifare Desfire communication example

MiFare DESFire are iso14443A compliant contactless smartcards, and support all layers including iso14443-4. These cards are so-called “stored value” cards, so you cannot install and execute your own program code on DESFire cards. DESFire is like a memory card with access control.

Typical usage is within public transportation and access control.

DESFire cards are considered secure. Even though there are some theoretical security flaws, no public working hack has been published like there has been for Mifare classic (standard) cards. (The new DESFire EV1 cards are supposed to address the flaws found in v0.6).

Depending on the version of the card, a DESFire card might support commands in native, native-wrapped or iso7816-4 command set styles.

  • Software version v0.4 does not support APDU (only native commands)
  • v0.5 adds support for wrapping native commands inside ISO 7816 style APDUs
  • v0.6 adds ISO/IEC 7816 command set compatibility. 

 New versions of DESFire cards (EV1) (v1.3) support extended APDU commands.

“Application” in DESFire terms is more like a DF (Directory File) in iso7816. DESFire AIDs (Application IDs) are 3 bytes long.

The command style of the first command determines the mode for the rest of the session. You cannot mix different command modes in the same session.

First, lets look at Native command mode.

Native Command mode:

Most of these commands are one byte long, and the card responds with “statusbyte + [optional data]”

Statusbyte examples:
00 : Command successful
af : More data (send command 'af' to fetch remaining data)
9d : Permission Denied
Communication flow:
--> To card
<-- From card

Example using a blank DESFire v0.6 card:

Get Version:
--> 60
<-- af 04 01 01 00 02 18 05
--> af
<-- af 04 01 01 00 06 18 05
--> af
<-- 00 XX XX XX XX XX XX XX ZZ ZZ ZZ ZZ ZZ 05 06

The first response denotes the hardware releated data: version is 0.2 (00 02), and storage size is 18 (4096 bytes)
The second response denotes the software releated data: version is 0.6 (00 06), and storage size is 18 (4096 bytes)
The X’s are the 7-byte UID
The Z’s are the 5-byte batch number
05 = Calendar week of production
06 = Production year

Get Application IDs:
--> 6a
<-- 00

No applications available (blank card)

Select PICC Application:
--> 5a 00 00 00
<-- 00

OK

Get File IDs (for PICC Application):
--> 6f
<-- 9d

Permission denied.

Get Key Settings (for PICC Application):
--> 45
<-- 00 0f 01

0f = All bits in the lower nibble are set, meaning configuration can be changed, CreateApplication/GetApplicationIDs/GetKeySettings can be performed without master key, and master key is changeable
01 = Only 1 key can exist for this application (the PICC application)

Get Key Version for key 00 (for PICC Application):
--> 64 00
<-- 00 00

The PICC master key version is 0x00

Authentication with key 00 (for PICC Application):
--> 0a 00
<-- af a2 be cd 03 d8 46 cb 33
--> af b0 cc bc ed 8f c8 38 c9 08 dc e2 4d 86 ca ec 3c
<-- 00 76 73 d9 49 71 3f f2 d1

This example only showed authentication with the PICC application. In a real world transaction, you would typicall select a specific AID (!= 00 00 00), authenticate, and then read/write to files within that application.

After a successful authentication, further communication with the card is done in plain/plain+MAC/encrypted+MAC, depending on the access bits for the particular file.
Authentication is done using DES or Triple-DES, depending on keysize. If key is 8 bytes: Single DES. If key is 16 bytes, and the first 8 bytes of the key are different from the last 8 bytes: Triple-DES. The card terminal (PCD) always use DECRYPT_MODE (both when recieving and sending encrypted data), and the card always uses ENCRYPT_MODE. However, the DESFire crypto is a bit different from the normal DES/CBC scheme: The PCD uses DES “send mode” when sending data (xor before DES), and the card uses DES “recieve mode” when recieving data (xor after DES). But when the PCD recieves data, it uses normal DES/CBC mode (xor after DES), and the card uses normal DES send mode when sending data (xor before DES).

DESFire encryption:
Send encrypted data Recieve encrypted data
PCD (DECRYPT) DES/CBC “send mode” Normal DES/CBC “recieve mode”
Card (ENCRYPT) Normal DES/CBC “send mode” DES/CBC “recieve mode”

The last 2 modes are useful if you need to communicate with a DESFire card through PC/SC, or you need to emulate DESFire on Java Cards.

Native Wrapped command style:

In this mode, native commands are wrapped inside iso7816 style APDUs.

The mapping is done as follows:
cls ins          p1 p2 lc [data] le
90  [native ins] 00 00 lc [data] 00

SW1 SW2
91  [native status code]
Wrapped version of the commands shown above:
--> 90 60 00 00 00 00
<-- 04 01 01 00 02 18 05 91 af
--> 90 af 00 00 00 00
<-- 04 01 01 00 06 18 05 91 af
--> 90 af 00 00 00 00
<-- 04 28 3b 61 5b 1b 80 8e 64 55 61 10 05 06 91 00
--> 90 6a 00 00 00 00
<-- 91 00
--> 90 5a 00 00 03 00 00 00 00
<-- 91 00
--> 90 6f 00 00 00 00
<-- 91 9d
--> 90 45 00 00 00 00
<-- 0f 01 91 00
--> 90 64 00 00 01 00 00
<-- 00 91 00
--> 90 0a 00 00 01 00 00
<-- a2 be cd 03 d8 46 cb 33 91 af
--> 90 af 00 00 10 b0 cc bc ed 8f c8 38 c9 08 dc e2 4d 86 ca ec 3c 00
<-- 76 73 d9 49 71 3f f2 d1 91 00

The last mode is the iso7816 command set mode:

Full support for these commands require DESFire v1.3 (EV1)
ISO SELECT (A4)
ISO GET CHALLENGE (84)
ISO EXTERNAL AUTHENTICATE (82)
ISO INTERNAL AUTHENTICATE (88)
ISO READ BINARY (B0)
ISO UPDATE BINARY (D6)
INS READ RECORDS (B2)
ISO APPEND RECORD (E2)

As you can see, not all functions are available using the iso7816 command set. If you need more functions, you must use native or native-wrapped mode.


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?