Card structure of a MIFARE DESFire card
Overview
- A MIFARE DESFire card memory consists of several applications, e.g. for access control, cafeteria payment, etc.
- Each application contains several files and a key list.
- To access data on the card you'll basically need to know:
- In which application is the relevant data stored?
- In which file within the application is the data stored?
- How to decrypt the file?
- What's the location of the data within the file?
- In what data format is the data encoded?
Mapping to configuration values
Below, the card structure is illustrated in more detail. Move your mouse over a question mark to get details about each element and how it corresponds to the values in the configuration components Autoread MIFARE DESFire Number in File and MIFARE DESFire VHL File in BALTECH ConfigEditor.
A MIFARE DESFire card can host several applications, e.g. for access control, cafeteria payment, etc. Each of them has a unique application ID (AID) consisting of 3 bytes.
Enter the AID in hexa-decimal encoding and most significant byte first (MSB first).
Each application can contain multiple files. Each file has a unique number within the application, ranging from 0 to 31.
Enter the number of the file that contains the programmed card number (PCN).
File content is organized in bytes. To indicate the position of the programmed card number (PCN) within the file, specify the following:
- PCN start position, i.e. the number of the byte in which the PCN starts. The byte number is unique within the file, starting from 0.
- PCN length, i.e. how many bytes the PCN consists of.
Usually, access to files is protected with a key from the key list that is part of the application. If this is true for the file containing the programmed card number (PCN), check the box.
Specify the encryption algorithm used to protect access to the relevant file. Options include AES, DES, 3DES, or 3K3DES.
The key number identifies which key from the application's key list is needed to access the file. The number ranges from 0 to 13. Each application can have multiple keys for different purposes (e.g., read, write, modify). Only the read key is needed.
Specify the read key number and the read key. Key length depends on the encryption algorithm. Usually, it's 16 bytes.
By default, all cards in a project use the same read key. To add more security, the card issues can diversify the read key: Then, a unique read key per card is generated based on that project-wide read key and the card's unique identifier (UID).
Only used rarely and in high-security projects. When in doubt and you lack info from your card issuer, keep this option disabled.
While the read key is always used to authenticate with the card, it may or may not be used in subsequent communication between reader and card,. This depends on the card's communication settings. Options are:
- Encrypted
- Protected via MAC (Message Authenication Code) to keep communication in plaintext but prevent attackers from manipulating the communication
- Plain
Data format in which the programmed card number (PCN) is encoded on the card. It tells the reader how to interprete the data on the card, so the correct number is transmitted to your host system.
Download request form
Send the following form to your card issuer to request the card structure details needed for reading a programmed card number (PCN) from your MIFARE DESFire cards.
A MIFARE DESFire card can host several applications, e.g. for access control, cafeteria payment, etc. Each of them has a unique application ID (AID) consisting of 3 bytes.
Enter the AID in hexa-decimal encoding and most significant byte first (MSB first).
Each application can contain multiple files. Each file has a unique number within the application, ranging from 0 to 31.
Enter the number of the file that contains the relevant data.
File content is organized in bytes. To indicate the position of the relevant data within the file, specify the following:
- Data start position, i.e. the number of the byte where the relevant data starts. The byte number is unique within the file, starting from 0.
- Data length, i.e. how many bytes the relevant data consists of.
Usually, access to files is protected with a key from the key list that is part of the application. If this is true for the file containing the relevant data, check the box.
Specify the encryption algorithm used to protect access to the relevant file. Options include AES, DES, 3DES, or 3K3DES.
The key number identifies which key from the list within the application is needed to access the file. The number ranges from 0 to 13. Each application can have multiple keys for different purposes (e.g., read, write, modify). Use the key needed for your operation.
Specify the key number and the key. Key length depends on encryption algorithm. Usually, it's 16 bytes.
By default, all cards in a project use the same read key. To add more security, the card issues can diversify the read key: Then, a unique read key per card is generated based on that project-wide read key and the card's unique identifier (UID).
Only used rarely and in high-security projects. When in doubt and you lack info from your card issuer, keep this option disabled.
- Encrypted
- Protected via MAC (Message Authenication Code) to keep communication in plaintext but prevent attackers from manipulating the communication
- Plain
Analyze card structure yourself
If it's not feasible for you to request the card structure details from your card issuer, you can analyze the card structure yourself using BALTECH ID-engine Explorer.