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.
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).
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
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
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,
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
GetKeySettingscommands succeed independently of a preceding application master key authentication
b0: AMK is changeable (
0x00- AMK is frozen,
Bytes meaning of
b7-b6: Crypto method of the application (
b5: Indicates use of 2 byte ISO/IEC 7816-4 File Identifies for files within the Application (
0x00- not used,
b4: RFU (has to be
b3-b0: Number of keys that can be stored within the application (
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.
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), if that is not
the case, Fidesmo API will not be able to remove the application.
In this tutorial there are some examples depicting how to use Fidesmo API to operate MIFARE DESFire® EV1.
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.