Book demo

MIFARE DESFire® EV1

MIFARE® DESFire® EV1 is a contactless solution from NXP® Semiconductors for safe data storage on chips, with security features and a flexible file system. MIFARE DESFire® product-based cards are widely used in access management, transportation, E-Government, loyalty programs etc. The Fidesmo platform supports integration with MIFARE DESFire® EV1 on chips that implement that technology. Such implementation allows the chips to work both as regular JavaCard + GlobalPlatform Secure Elements and as MIFARE DESFire® EV1 devices. Fidesmo integration is based on an applet that ‘routes’ commands to the MIFARE DESFire® implementation on the chip.

How MIFARE DESFire® works

MIFARE DESFire® EV1 allows to install up to 28 different applications. An application is basically a secured folder to safely store data on files. Each application can be selected using a 3 byte application ID (AID). Each application/folder can have up to 1 application keys assigned (APKs). First key (key #0) is the application master key (AMK). Depending on the application configuration the AMK will be required to perform file creation/deletion. MIFARE DESFire® products use a PICC/Card Master Key (CMK) and can be configured so the CMK is required to carry out specific operations such as creation/deletion of apps.

Each application can create up to 32 files. Files inside the application required to have a 1 byte long ID. Following file types are supported:

  • Standard data files. Used to store any arbitrary data.
  • Backup data files. Similar to standard data files, but have a transaction mechanism allowing all or none write operations.
  • Value files with backup. Value files store an integer value which can be transactionally updated with credit/debit operations
  • Linear record files with backup. Those file able to handle records of user-defined size in bytes. Supports transactional updates.
  • Cyclic record files with backup. Similar to linear record files, but when file is full next writing operation overwrites the first record. Supports transactional updates.

Commands that change the file structure (e.g. creation or deletion of applications, change of keys) activate an automatic rollback mechanism, which protects the file structure from being corrupted.

Security settings

MIFARE DESFire® EV1 has two security levels:

  • Card level security: DESFire® uses TDES (k1=k2) by default, but can be changed to 3KTDES or AES by using ChangeKey command. Can be freezed (made not changeable). The DESFire® implementations carried by Fidesmo chips use TDES (k1=k2). Card level security is not accessible by users in Fidesmo chips as no user has access to the CMK.
  • Application level security: crypto algorithm has to be defined during application creation and cannot be changed afterwards. Keys can be changed (if allowed by application settings). Fidesmo API supports the creation of any valid encryption scheme: 2KTDES, 3KTDES and AES. But only applications using AES can be deleted through Fidesmo API. It is the responsibility of the application owner to handle its keys safely, Fidesmo does not keep any application key.

The following figure overviews how applications, files and keys are organized in DESFire®:

Fidesmo MIFARE DESFire® API

The Fidesmo platform has 3 endpoints to manage MIFARE DESFire® applications. These endpoints can be used by Service Providers (see the description of Fidesmo architecture for a good introductory explanation of Fidesmo architecture and key concepts such as Service Provider).

Application creation

POST /desfire/ev1/createApp is an API to create MIFARE DESFire® applications on a card. Required parameters are the DESFire-AID, 16 or 24 bytes AMK and two key settings bytes: keySettings1 and keySettings2.

According to DESFire® rules, AID must be 3 bytes long. Please note that 0x000000 AID is reserved and cannot be used.

The keySettings bytes specify the rules for the application keys. Bits meaning of keySettings1 byte:

  • b7-b4: holds which key can use the ChangeKey command
    • 0x00: Application master key authentication is necessary to change any key
    • 0x01-0x0D: Authentication with the specified key is necessary to change any key
    • 0x0E: Authentication with the key to be changed (same KeyNo) is necessary to change a key
    • 0x0F: All Keys (except the Application Master Key, see b0) within this application are frozen
  • b3: AMK settings are changeable (0x00 – configuration is frozen, 0x01 – changeable)
  • b2: AMK is required to create/delete files
    • 0x00: CreateFile/DeleteFile is permitted only with application master key authentication
    • 0x01: CreateFile/DeleteFile is permitted also without application master key authentication
  • b1: AMK is required for file directory access
    • 0x00: Successful application master key authentication is required for executing the GetFileIDs GetFileSettings and GetKeySettings commands
    • 0x01: GetFileIDs, GetFileSettings and GetKeySettings commands succeed independently of a preceding application master key authentication
  • b0: AMK is changeable (0x00 – AMK is frozen, 0x01 – changeable)

Bytes meaning of keySettings2 byte:

  • b7-b6: Crypto method of the application (0x00 – 2KTDES, 0x01 – 3KTDES, 0x02 – AES)
  • b5: Indicates use of 2 byte ISO/IEC 7816-4 File Identifies for files within the Application (0x00 – not used, 0x01 – used)
  • b4: RFU (has to be 0x00)
  • b3-b0: Number of keys that can be stored within the application (0x01-0x0D).

Sending commands to the application

POST /desfire/ev1/transceive sends a set of APDU MIFARE DESFire® commands to the application and returns the result of each command in an operation callback. Several transceive requests can be send during the same service delivery session, in case several commands need to be sent (which is often the case). Typically, first transceive will select the DESFire® application to work with. Then, several other transceive requests will be performed to authenticate against that application. Once the authentication has succeeded, commands can be sent to the application (create file, read data, etc.). As only the application owner holds its keys, the application is protected.

Application deletion

POST /desfire/ev1/deleteApp deletes application from a card. Requires AID and 16 bytes AMK both represented as byte strings. AMK is required to ensure that only the application owner can actually request its deletion. This operation assumes the application was created so it uses AES for encryption (see keySettings2 in the Application Creation Section above), if that is not the case, Fidesmo API will not be able to remove the application.

Remarks

Note that Fidesmo does not keep any track of the applications keys, including their AMKs. Thus, it is the responsibility of the Service Provider to manage the keys of its applications. On the other hand Fidesmo it is in charge of the CMK of each chip, so applications can be created and deleted only through Fidesmo API.

It is possible to send MIFARE DESFire® APDUs to any application both using the transceive method of Fidesmo API, or directly using a reader able to read MIFARE DESFire® products. But of course before performing any operation with some application it is necessary to authenticate. As only the owner of the application will know its keys, the application is protected.

At this point Fidesmo MIFARE DESFire® API supports:

  • Card level security uses TDES (k1=k2). No user has access to this security level.
  • Applications can be created with any valid crypto scheme using Fidesmo API. But app deletion through Fidesmo API is only possible if the application uses AES.

NXP®, MIFARE, and DESFire® are registered trademarks of NXP® B.V. and are used under license.