MIFARE DESFire is a powerful contactless smart card technology that supports multiple applications on a single card. In this guide, you'll learn the core concepts behind MIFARE DESFire technology, including its its three-tier hierarchical system (cards, applications, files), essential command operations, sample card structure, and known security vulnerabilities and attacks. The MIFARE DESFire family has three evolutions (EV1, EV2, and EV3) and this guide applies to all three of them.
By the end of this tutorial, you'll have an understanding of the DESFire card structure that can be expanded for physical access control, payment systems, transit applications, hospitality services, or other secure NFC applications. It's a bit technical, especially if you're new to smart card operations, but following along will give you a solid foundation for more advanced DESFire implementations and security assessments.
MIFARE DESFire's Hierarchical Architecture
Let's get started. To understand MIFARE DESFire, you have to know that each DESFire card operates on a three-tier hierarchical system that functions like a secure filing cabinet with multiple levels of access control.
On a high level, this is the hierarchy:
Card Level
Master Application Level
Custom Application Level
Let's dive into each of the levels.
Tier 1: PICC Level (The Card level)
The PICC (Proximity Integrated Circuit Card) is the physical card and represents the highest level of the hierarchy. Think of this as the building that contains all the offices.
What lives at the PICC level:
Card-wide settings: For EV1, the maximum number of applications (28), these are the memory allocation policies. For EV2 and EV3, there are an unlimited amount of applications.
Global security policies: Policies that dictate whether applications can be created without master authentication
Manufacturing data: Production batch, hardware/software versions, UID, or any data that the manufacturer would like to include.
Memory management: Total available memory space and the tracking of how the categories of memory are being allocated
The PICC has exactly one key - the PICC Master Key (which is always Key #0). So at this level, the Master Key governs the following:
Creating new applications anywhere on the card
Deleting any application (with proper authentication)
Formatting the entire card (nuclear option - wipes everything)
Changing card-wide security settings
Tier 2: Master Application Level
Every DESFire card has exactly one Master Application with the reserved AID or Application Identifier of 000000. This is not a regular application - it's the card's control center. It's special because the Master Application is hardcoded to the card and can not be deleted, holds the PICC Master Key and card configuration, and it acts as the gateway to card-level operations. You heard that correctly, it must be selected before performing any card-level operations.
These are some of the operations that require Master Application access:
Listing all applications on the card (Get Application IDs)
Creating new applications (Create Application)
Deleting applications (Delete Application)
Changing the PICC Master Key
Formatting the card
Security model: The Master Application uses the same PICC Master Key mentioned in Tier 1. When you authenticate to the Master Application, you're proving you have card-level administrative rights.
Tier 3: Custom Application level (Custom AIDs)
These are the actual functional applications that store your business data. Each application is completely isolated from the others. There are certain Application Identifier (AID) rules that govern the user applications. In the practical world, think a card that has a single use case like a corporate badge.
AID Rules:
Must be exactly 3 bytes (24 bits)
Must be unique across the card
Cannot use 000000 (reserved for Master Application)
Can be any value from 000001 to FFFFFF
Next, we need to discuss keys and files.
Keys: The Security System Think of keys like physical keys to a filing cabinet system. Each application can have up to 14 keys (numbered 0-13). For EV2 and EV3, each application can have 16 keysets each with up to 14 keys.
Key #0: The Office Manager's Key: This is the master that can:
Add or remove entire drawers (create/delete files)
Cut new keys and change locks (modify key permissions)
Reorganize the whole cabinet (security settings)
Keys 1-13: Desk Keys: These are specific keys that grant
Reading rights to certain folders
Writing privileges for specific document
Ledger access for adding/subtracting values
Files: The Storage Containers Think of files as different types of storage boxes. Each application can hold up to 32 files (numbered 0-31). Here are the various types of files:
Standard Files: Basic storage, like a simple folder
Backup Files: Extra-safe storage that lets you undo changes before sending a commit
Value Files: Special boxes for numbers that you can add to or subtract from
Linear Record Files: Like a diary - stores entries in order by date
Cyclic Record Files: Like a circular notepad - when full, new entries replace the oldest ones
Access Rights: The Locks on Each Container Each file has its own set of locks that specify exactly which keys can perform which actions.
When you create a file, you assign four types of access rights:
Read Access: Which key number can open and view the contents (like reading a document)
Write Access: Which key number can modify or replace the contents (like editing a file)
Read/Write Access: Which key number can both view and modify (combined privileges)
Change Rights Access: Which key number can change the locks themselves (rekey the filing cabinet)
Special values:
Key 0xE (14) (Free Access): No key needed - anyone can perform this operation (like an unlocked drawer)
Key 0xF (15) (Never/Deny All): Operation is blocked entirely (like a sealed archive box) even for key #0.
Example: You might create a file where:
Key #3 can read Key #5 can write Key #0 (the Office Manager) can change access rights No one gets free access (0xF for free access) The Big Picture: Keys are what you possess, files are storage containers, and access rights are the locks on each container that determine which keys work on which operations.
Understanding this concept alone won't help you build a working system. To build a working system, you need to choose the Communication mode and Authentication method that works for your security needs. These decisions shape everything else.
Communication Mode: What are the rules for reading the contents of a file in your DESFire app? Choose whether to use Plain, MAC'ed or encrypted communication mode.
Plain: Human-readable data.
MAC'ed: Message Authentication Code (MAC)
Messages include a digital signature to verify message integrity
Data is readable if intercepted
Prevents tampering and forgery
Think: sending a postcard with a tamper-evident seal
Encrypted Communication Mode:
Scrambles all data for privacy
Unreadable if intercepted
Prevents eavesdropping, tampering, and forgery
Think: sending a letter in a locked box with a tamper-evident seal
Bottom Line: MAC'ed protects against tampering and forgery, while encrypted protects against eavesdropping too. Encrypted is more secure but requires more processing power.
Authentication Method: How will cards prove they're legitimate? Think of this as choosing between a password, fingerprint, or ID badge system but in this case it's DES, 3DES, or AES (128-bit).
DES: Data Encryption Standard
An older encryption method from the 1970s
length: 8 bytes
(64 bits, but 56 bits effective due to parity)
Relatively weak security by today's standards
3DES: Triple Data Encryption Standard
Takes DES and runs it three times to make it stronger
length: 16 bytes (2-key variant) or 24 bytes (3-key variant)
112-bit or 168-bit keys
More secure than DES but slower
AES (128-bit) Advanced Encryption Standard
length: 16 bytes
Uses 128-bit keys (much stronger than DES)
Fast, secure, and widely adopted
Default Factory Keys: DESFire cards ship with default keys set to all zeros. So imagine the length of each padded with all zeros in hex.
These two foundational choices—will dictate your entire security framework and directly influence the commands available at each tier of the system, which we'll explore next.
Essential commands you'll need to interact with
Now that you understand the three-tier hierarchical structure of MIFARE DESFire cards, let's explore the essential commands you'll need to interact with each level of this system.
Essential MIFARE DESFire Commands by Hierarchical Level
Tier 1: PICC Level Commands These commands operate at the card level:
GetVersion - Retrieves manufacturing data, hardware/software versions, and card capabilities
FreeMemory - How much memory storage is available
These require PICC Master Key authentication
GetCardUID - Gets the card's unique identifier and response is encrypted so you need to decrypt it.
FormatPICC - The "nuclear option" that wipes the entire card clean
ChangePICCMasterKey - Updates the PICC Master Key (Key #0)
Tier 2: Master Application Level Commands (AID 000000) These commands manage applications across the card and require Master Application access:
SelectApplication - Must select Master Application (000000) before card-level operations
GetApplicationIDs - Lists all applications on the card
CreateApplication - Creates new custom applications with unique AIDs
DeleteApplication - Removes applications from the card
Authenticate/AuthenticateISO/AuthenticateAES - Proves you have the PICC Master Key to perform card-level administrative operations (creating/deleting applications, formatting card)
Tier 3: Custom Application Level Commands (AIDs 000001-FFFFFF) These commands work within individual applications for day-to-day file operations:
GetFileIDs - Lists all files (0-31) within the selected application
CreateStdDataFile - Creates standard files for basic storage
CreateBackupDataFile - Creates backup files with transaction safety
CreateValueFile - Creates value files for add/subtract operations
CreateLinearRecordFile - Creates diary-like sequential record storage. The maximum number of records and record size are defined at file creation and cannot be changed later. When the file is full, no more records can be saved - you must clear the entire record file first to store new entries.
CreateCyclicRecordFile - Creates circular record storage that automatically overwrites the oldest entry when full (unlike Linear Record Files which stop accepting new records)
ReadData - Reads from standard and backup files
WriteData - Writes to standard and backup files
GetValue - Reads current value from value files
Credit/Debit - Adds to or subtracts from value files
ReadRecords - Reads entries from record files
WriteRecord - Adds new entries to record files
ChangeKey - Updates application keys (0-13)
GetFileSettings - Retrieves file configuration and access rights
Authenticate/AuthenticateISO/AuthenticateAES - Proves you possess the required Application Key (0-13) to perform file operations based on access rights
Mastering these commands gives you the tools to navigate all three tiers of the DESFire hierarchy. Next, let's see a sample MIFARE DESFire application structure.
Sample MIFARE DESFire Application Structure
This is a simple example structure for a MIFARE DESFire card implementation in an organizational setting. The choices made here are arbitrary and serve as a learning guide rather than a production recommendation.
PICC Level (Card Level) Configured by the smart card manufacturer
Master Application (AID: 000000) Exists as a default
Custom Applications
This is where you configure your business logic applications. In our case, we are just creating one application.
Application 1: Access Control System
Application ID (AID): F5 64 01
Purpose: Physical door access for employees
Keys:
Key 00 (Master): F0 C1 F4 C0 FF EE 15 DE CA 7B 89 12 34 56 78 90
Can create/delete files
Can change key permissions and security settings
Key 1 (Write Access): 94 B1 05 C0 FF EE 15 DE CA 3F 21 87 65 43 21 AB
Held by: HR department only
Can write and update employee access credentials
Key 2 (Read Access): 7A 3E 92 D1 8F 4C 6B 2A 5D 9E 1F 0C 8B 7D 4A 3C
Held by: Door reader units in the field
Can only read employee credentials to grant/deny access
Security Model: The access credentials are written by the HR department (which has Keys 0, 1, and 2), while door readers only possess Key 2 for reading. This prevents an unwanted compromise: if a door reader unit is stolen or hacked, an attacker can extract Key 2 but cannot modify employee credentials since they don't have the Write Access key. The door readers never need Key 1 stored in their units.
Files:
File 00: Employee access credentials (arbitrary file ID selection)
Communication Settings
Security Level: Encrypted communication with MACing (arbitrary choice for demonstration)
Reasoning: This provides a good balance of security for most organizational needs
Note: Don't forget to apply the AID Rules for custom applications from the previous section when creating the keys.
Key Design Decisions (All Arbitrary)
Why These Specific Values?
AID F5 64 01: Completely arbitrary selection within valid range
Key Values: Random hexadecimal strings for demonstration
File ID 00: Chosen as the first available file ID (arbitrary)
3 Keys, 1 File: Simple structure for learning purposes
Encrypted + MAC Communication: Common security practice, but level chosen arbitrarily
What This Structure Enables:
Card-level administration through the Master Application
Application isolation - access control is completely separate from other potential applications
Flexible key management - Master key can create/modify, Generic key handles specific operations
Secure communication between card and reader
Room for expansion - we can add additional applications possible since we only used one. If EV1, can add 27, for EV2 or EV3 you are only limited by memory constraints.
This sample structure illustrates how DESFire's three-tier hierarchy works in practice, showing both what you'll configure in application portals and what happens behind the scenes at the card and Master Application levels. With this foundation in place, you're ready to explore the security considerations and potential vulnerabilities that exist in MIFARE DESFire implementations.
Quick primer on Key Diversification
When MIFARE DESFire EV1 first launched, many systems deployed it without key diversification, and for good reason. The cryptographic security of DESFire's AES-128 authentication was considered strong enough on its own. Thousands of access control systems were implemented using a single master key across all cards, and this was the industry standard.
Then the threat landscape changed. As computational power increased and side-channel attacks became more sophisticated, security researchers demonstrated that if an attacker could sniff out the master key from one card through physical attacks, they could then clone every card in the system. What was once a theoretical vulnerability became a practical risk for mass exploitation.
Key diversification protects against card cloning
One of the prominent sectors most at risk are transportation systems. Public transit systems rely heavily on fare revenue to fund operations, so security breaches that enable widespread fare evasion can strain already tight municipal budgets and reduce service quality for everyday riders. Without diversified keys, an attacker who successfully extracts the encryption key from a single card can create unlimited clones that work throughout the entire transportation system.
Think of it like having the same house key for every home in a neighborhood. When an attacker figures out how to manipulate one transit card—say, discovering a way to send a fake "add $20 to my balance" command—they can use that exact same technique on thousands of other cards if they all share the same security key.
Key diversification creates different keys for every single DESFire card - making it impossible for attackers to derive every possible key. Check out the "Understanding Key Diversification in MIFARE DESFIRE" guide to learn on a more technical level how the technique works.
Conclusion
Congrats! You made it to the end of the article and have successfully learned the key concepts of MIFARE DESFire. Now that you learned about multi-use smart card applications, if your organization is interested in digitizing the experience of issuing and managing mobile credentials, remember that AccessGrid.com can handle the entire process for you, streamlining operations, saving you effort and reducing errors. If you have any questions or need assistance, just use the chat or email [email protected] for help.
