Tag Archives: desfire protocol

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.