Mifare DESFire

This is a specification for storing and accessing the data items defined in the LASSeO Services and Data Specification on DESFire® platforms. The DESFire® platform is a memory technology like the Mifare Classic, but with enhanced file handling and security features. This specification is designed to be compatible with all DESFire® variants.

Table 1. DESFire® Platform Differences

  MF3IC40 MF3IC21–EV1 MF3IC41-EV1 MF3IC81-EV1
Memory Size 4k 2k 4k 8k
Free Space 4096 bytes 2272 bytes 4832 bytes 7936 bytes
Max. Applications 28 28 28 28
Max. Files per application 16 32 32 32
Crypto DES,TDES DES, TDES, 3KTDES, AES DES, TDES, 3KTDES, AES DES, TDES, 3KTDES, AES
Support for ISO 7816 Cmds Very Limited Yes Yes Yes

* All values shown in the table above are decimal.

To ensure that this specification is compatible with all the DESFire® platforms listed above, certain preconditions must be set.

Although the EV1 range of DESFire® cards supports a substantial number of ISO 7816-4 commands, this is not the case with the MF3ICD40 platform. This specification is therefore based on the proprietary command set which is common to all platforms.

Similarly, the ‘compatible crypto mode’ must be used. This supports TDES and the Authenticate command 0Ah. AuthenticateISO and AuthenticateAES are not supported.

The Directory application contains certain public data which can be read without any authorisation. Other citizen data stored within Free Access Files inside applications can be accessed without authentication and data transmission will be in plain mode without encryption or MACing. Citizen data stored within individual Elementary Files is subject to scheme specific conditions. In deciding on which items to store in elementary files (EFs), and the access conditions pertaining to them, inter-operability requirements should be considered as well as security needs.

All numeric values appearing in tables in this document are hexadecimal unless otherwise stated. Numeric values in normal text are decimal unless denoted as hexadecimal with an ‘h’ suffix.

Note that MAD3 is not supported and randomID should be disabled.

Card Expiry Date:

This item is also included for convenience. The size and format of the Card Expiry Date is as described in document [4] in Service ID 0001h, Tag DF63h. The overall size of this file is 6 bytes, one byte giving the length of the following data, one byte for the format identifier and 4 bytes of data.

Example File 2

Length Format Date      
05 02 (DATE) 20 09 05 15

A standard file can be used for this data as the contents will not be changed during the lifecycle of the card. This file is created with the CreateStdDataFile command.

Cmd File No Comms Access File Size
CD 02 00 FF EF 06 00 00*

This file is read using the ReadData command and written with the WriteData command.

* The file size information is presented LSB first. 32 bytes of NV memory will be allocated.

2.2.4 Specification Versions:

This item can be used to notify the versions of the relevant specifications which were used for card encoding. There are two relevant specifications. These are the DESFire® specification (this specification) and the Services and Data definitions.

Example File 3

Length Format DESFire   Services and Data
05 01 (BCD) 01 07 10 05

Each version identifier consists of two bytes BCD. The first byte indicates the major version number, and the second byte the minor version number. The above examples show versions as follows:

DESFire 1.7

Services & Data Definitions 10.5

A backup file type should be used as the data in this file may change if a card is re-encoded to a later specification. This file is created using the CreateBackupDataFile command.

Cmd File No Comms Access File Size
CB 03 00 Fx Ex 06 00 00*

This file is read using the ReadData command and written with the WriteData command. When writing data CommitTransaction must be used to complete the writing and backup process. Total NV space used will be doubled due to the creation of a backup file.

* The file size information is presented LSB first. 64 bytes of NV memory will be allocated.

File Access and Communication Conditions:

The table below summarises the communications and access settings for these files.

Description File ID Comms Settings Access Conditions
      R W RW Ch
Services Directory 00 00 0xE *K 0xF *K
CardHolder Number 01 00 0xE 0xF 0xF 0xF
Card Expiry Date 02 00 0xE 0xF 0xF 0xF
Version Information 03 00 0xE *K 0xF *K

*K denotes the scheme specific DES or TDES key number in range 0 to 13. The Communications Settings specify data transmission in clear with no encryption or MACing.

The access conditions allow unconditional Read Access to the files in the Services Directory. Only the Directory File can be written to. Access conditions are coded on to two bytes as follows;

MSb         LSb
0F 0E 0D 0C 0B 0A 09 08 07 06 05 04 03 02 01 00
Read   Write     Read & Write Change

Each 4 bit nibble references a permission in the range 0 to 15 with the following meaning.

DESFire AID byte 1 DESFire AID byte 2 DESFire AID byte 3
Nibble 0 Nibble 1 Nibble 2 Nibble 3 Nibble 4 Nibble 5
F   Mifare Classic AID   0 – F

Mifare® Classic AIDs 4011h, 4012h and 4013h generate the following 48 DESFire® AIDs.  

F40110 F40111 F40112 F40113 F40114 F40115 F40116 F40117
F40118 F40119 F4011A F4011B F4011C F4011D F4011E F4011F
F40120 F40121 F40122 F40123 F40124 F40125 F40126 F40127
F40128 F40129 F4012A F4012B F4012C F4012D F4012E F4012F
F40130 F40131 F40132 F40133 F40134 F40135 F40136 F40137
F40138 F40139 F4013A F4013B F4013C F4013D F4013E F4013F

These AIDs will be used as follows:  

F40110 Reserved for the Service Directory Application
F40111 Reserved for the CCDA Application
F40112 – F4012F Available for Service Applications
F40130 – F4013F RFU

The CCDA application has been given a dedicated AID as it is a mandatory application. All other applications are optional. 

The Services Directory file facilitates interoperability between different schemes in which the mapping between USIDs and AIDs may be different. When creating this file it is recommended that space be reserved for a sufficient number of entries to cater for any future expansion. Reserved records should be padded with FFh. Please see section 3 for guidance on how many records this file may need to support.

A scheme may use any of the 30 AIDs in the range F40112h – F4012Fh which are reserved for citizen applications. All Linear record files are treated as backup files. Following any change to the Services Directory File a Commit Transaction command must be issued to activate the backup process.

This file is created with the CreateLinearRecordFile command.  

Cmd File No Comms Access Record Size Max Records
C1 00 00 Fx Ex* 5 As required

This file is read using the ReadRecord command and written using the WriteRecord command. When writing data CommitTransaction must be used to complete the writing and backup process. Total NV space used will be double that needed for the actual data due to the creation of a backup file.

*Note these two bytes are sent LSB first. ‘x’ denotes scheme specific key number.

CardHolder Number:

This file is included in the Services Directory for convenience and ease of access. It is also part of the CCDA data set. The standard size and format of the Cardholder Number is as described in document [4] in Service ID 0001h, Tag DF23h. However, there are some schemes with non-standard numbering systems and these can also be accommodated. The size of this example file is 10 bytes, one byte for the length of the following data, one byte for the format identifier and 8 bytes of data.

Example File 1

Length Format Cardholder Number        
09 01 (BCD) 63 45 89 12 78 90 23 05

A standard file can be used for this data as the contents will not be changed during the lifecycle of the card. This file is created with the CreateStdDataFile command.

Cmd File No Comms Access File Size
CD 01 00 FF EF 0A 00 00*

This file is read using the ReadData command and written with the WriteData command.

* The file size information is presented LSB first. Although the file itself is only 10 bytes long, a minimum of 32 bytes of NV memory will be allocated.

DESFire® AIDs in the range F40112h- F4012Fh are available to identify citizen services on a DESFire® card. Which of these AIDs are used to identify which USIDs is a scheme specific issue.

Please note that when creating applications using the Create Application command the AID is specified in little endian format. 

CMD AID Key Settings 1 Key Settings 2
CA 2F01F4 xx yy

This example shows the creation of an application with AID F4012F. Also note that for compatibility across the range of DESFire® platforms bits 6 & 7 in Key Settings 2 should be set to ‘00’ indicating DES and 3DES operation.

The Service Directory Application

The AID F40110h will always identify the Service Directory application. The application will contain four mandatory EFs.

File Description File ID File Type
     
Services Directory 00 Linear Record File
CardHolder Number 01 Standard File
Card Expiry Date 02 Standard File
Specification Versions 03 Backup File
RFU 04 -> 09 RFU
Scheme Specific 0A -> 0F As required

File IDs 04 to 09 are Reserved for Future Use. However, schemes may create scheme specific files in this application with IDs in the range 0A to 0F. The nature and content of these files is beyond the scope of this specification.

Unlike Mifare Classic, DESFire® comes with a flexible filing system based on distinct applications and files contained within these applications. Every Service, as defined in the LASSeO Services and Data definitions document, will be an application on the card, and all the data items for a Service will be held in files within that application.

There will be a dedicated Directory application which will contain directory information on mapping Service USIDs on to applications, and other card level data such as cardholder number and expiry date.

DESFire® AIDs

DESFire® allows up to 32 applications on a card. Every application has a three byte Application Identifier (AID) by means of which it can be found and selected.

An already reserved Mifare® Classic AID can be used to create 16 unique DESFire® application AIDs. This means that there is no need to register any further AIDs for DESFire® use as the following Mifare® Classic AIDS are already registered; 4011h, 4012h and 4013h.

The mapping to 3 byte AIDs is as follows.

DESFire AID byte 1 DESFire AID byte 2 DESFire AID byte 3
Nibble 0 Nibble 1 Nibble 2 Nibble 3 Nibble 4 Nibble 5
F   Mifare Classic AID   0 – F

Mifare® Classic AIDs 4011h, 4012h and 4013h generate the following 48 DESFire® AIDs.

F40110 F40111 F40112 F40113 F40114 F40115 F40116 F40117
F40118 F40119 F4011A F4011B F4011C F4011D F4011E F4011F
F40120 F40121 F40122 F40123 F40124 F40125 F40126 F40127
F40128 F40129 F4012A F4012B F4012C F4012D F4012E F4012F
F40130 F40131 F40132 F40133 F40134 F40135 F40136 F40137
F40138 F40139 F4013A F4013B F4013C F4013D F4013E F4013F

These AIDs will be used as follows:

F40110 Reserved for the Service Directory Application
F40111 Reserved for the CCDA Application
F40112 – F4012F Available for Service Applications
F40130 – F4013F RFU

The CCDA application has been given a dedicated AID as it is a mandatory application. All other applications are optional.

Example Directory File 0