MIFARE DESFire Explained: Essential Concepts for Secure Contactless Applications

September 15, 2025

Michael Pichardo

Overview

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 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

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 cannot 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 of 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 documents.
• 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.

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 is 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 ab@accessgrid.com for help.