MIFARE DESFire EV2 Cards

DESFire EV2 card samples and bulk orders

For an existing EV2 installation, start with the approved chip and card specification. Request the required memory capacity, card body, printing and delivery state together so the quotation and sample address the same project. Current supply of the exact EV2 part and the available finished-card options are confirmed in the quotation.

• Card body: specify dimensions, thickness and material, such as an ID-1 card (85.6 × 54 mm). Confirm the proposed construction and antenna design; discuss other formats through the DESFire tag and fob page.
• Printing and finishing: send artwork for both sides, finish, visible numbering, barcodes or QR codes, and any magnetic stripe or signature-panel requirement. Confirm which options are included in the sample and quotation.
• Encoding and personalisation: agree factory-default or transport-key delivery versus cards prepared with your application, files and permissions. A visually blank card is not necessarily in an untouched chip state. Provide the required delivery profile and numbering scheme, without live secret keys in the RFQ.
• Key-management handover: any loading of production keys is arranged separately with the party responsible for issuance, and encoding is performed only for the organisation that administers the system.
• Samples and lead time: free standard samples are available (a customised sample carries a setup fee), and the standard lead time for standard products is generally two to three weeks; the schedule and the availability of a specific EV2 part are confirmed in the quotation.

Compare EV2 2K, 4K and 8K card requirements

This table compares 2K, 4K and 8K card requirements; it is not the complete EV2 memory range. NXP’s public short data sheet also lists 16 KB and 32 KB devices. Confirm the exact part and current finished-card availability in the quotation. Choose capacity from your integrator’s application and file plan, including file-system overhead and planned growth, because memory size alone does not make cards interchangeable.

The listed standard parts have 17 pF input capacitance; the “H” parts have 70 pF, which NXP offers for small-form-factor antenna designs. The inlay design still needs validation in the finished card or tag. NXP specifies 25-year data retention and typical 500,000 write cycles at 22 °C in the short data sheet; these IC figures do not guarantee the service life of a printed card. Send the exact part or approved card specification so the sample can be checked against the system you use.

Reader and firmware compatibility

A displayed card number proves identification, not successful application authentication. Before a repeat order or migration, ask the reader or lock vendor to confirm the points below and test the proposed card with the issuing software and installed firmware.

• Air interface: the reader implements ISO/IEC 14443-2/3 Type A and the ISO/IEC 14443-4 (T=CL) transmission protocol that DESFire uses. A 13.56 MHz rating on its own does not confirm 14443-4 support.
• Command set: the firmware supports the DESFire and ISO/IEC 7816-4 commands your application needs — selecting the application, authenticating, and reading or writing the file types you use — not only UID reading.
• Secure messaging: confirm the D40, EV1 or EV2 mode, key type and file communication settings your application uses. Check every required EV2 feature against the reader firmware and approved card profile.
• Backward compatibility: if EV1 or D40 (MF3ICD40) cards are still in the field, verify the reader keeps reading them alongside EV2 during a migration.
• Keys and diversification: agree who holds the application master keys, how they are diversified per card, and how the readers are loaded with them.
• Sample test: authenticate and run the real transaction — issue, read and write, an interrupted transaction and its recovery — with production reader firmware and software before any bulk order.

Before you order: EV2 checklist

1. Exact EV2 part and memory capacity, or the approved card specification from your integrator; the 2K/4K/8K comparison on this page is not the entire chip-family range.
2. Whether this is a repeat order that must match an installed specification, or a new project for which EV3 was evaluated first.
3. Reader brand, model and firmware, the secure-messaging mode and key type, and the application and file plan.
4. Delivery profile: factory-default/transport settings or project-personalised cards, plus who loads production keys, enrols cards and approves the sample.
5. Card construction, artwork, numbering, quantity, destination and required date.
6. Sample acceptance: verify application authentication and the required read/write transactions on the actual issuing software and readers; keep the approved configuration for repeat orders.

What MIFARE DESFire EV2 is

MIFARE DESFire EV2 is an NXP contactless multi-application IC that works at 13.56 MHz on the ISO/IEC 14443 Type A air interface and communicates with the ISO/IEC 14443-4 transmission protocol. Data is held in an application and file structure addressed with ISO/IEC 7816-4 commands, and applications can use hardware cryptography: DES, 2K3DES and 3K3DES for compatibility, and AES with 128-bit keys for current designs. NXP marks EV2 as not recommended for new designs and directs new projects to DESFire EV3; this page supports enquiries for installations that already specify it. The sections below describe the IC. The availability of a specific EV2 part, and of any finished-card batch, is confirmed in the quotation.

EV1, EV2 and EV3: what changed

These three DESFire generations share the 13.56 MHz ISO/IEC 14443 Type A interface, the ISO/IEC 7816-4 file commands and the DES/2K3DES/3K3DES/AES-128 cryptographic engine, and each newer chip keeps backward-compatibility modes for the older ones. What changes between generations is the set of application-security features and the certification level. A feature benefits your project only when the chip, the reader firmware and the application all implement it.

EV2 provides backward-compatible D40 and EV1 secure-messaging modes, but a replacement card still needs the application configuration, keys and reader support expected by the installed system. EV2 features such as multiple key sets, Transaction MAC, Proximity Check and delegated application management need the relevant configuration and command support. Have the integrator confirm and test the features the project actually uses.

Application and file structure

A DESFire card behaves like a small on-card file system with three levels. At the top is the PICC — the card itself — which holds the card master key, the card-wide configuration and the list of applications. Each application is addressed by a 3-byte Application ID (AID) and carries its own keys and its own set of files: EV1 allows up to 28 applications, while EV2 and EV3 remove the practical limit and are bounded only by available memory. Each application holds up to 32 files (file IDs 0x00–0x1F), and every file has its own access rights and communication mode, so one card can keep an access credential, a stored-value purse and a ticket side by side without any of them sharing a key.

Each file carries four access-rights fields — read, write, read-and-write, and change-access-rights — and each field names one of the application's keys, or is set to “free” (no authentication) or “deny” (never). Backup, value and record files take part in transactions: a set of writes is staged and then committed atomically, so an interrupted tap never leaves a fare balance or a log half-written.

Authentication and secure messaging

Reading a UID does not authenticate a DESFire application. In mutual authentication, the card and reader prove possession of the required key and establish session protection. The selected authentication mode and each file’s access and communication settings determine what can be read, written or transmitted in plain form. The card, reader firmware and application must implement the agreed configuration.

• D40 compatibility mode: retained for legacy installations using the original DES/2K3DES scheme. Confirm the configured key type and reader requirements; do not assume this provides AES protection.
• EV1 secure messaging: AuthenticateISO supports 2K3DES or 3K3DES keys, while AuthenticateAES uses AES keys. These retain the corresponding EV1 compatibility mode.
• EV2 secure messaging: AuthenticateEV2First and AuthenticateEV2NonFirst use AES keys. The first starts the transaction’s EV2 authentication; the latter supports subsequent authentication within that transaction. Confirm the required commands and settings with the integrator.

File communication can be plain, protected with a cryptographic checksum, or encrypted, depending on the authentication and file settings. Authentication alone does not mean every file is encrypted or every read requires a key. NXP’s public EV2 short data sheet describes these choices and the supported authentication commands; use the detailed product documentation for implementation. Key diversification is covered separately in NXP application note AN10922.

Key management: keys, versions and key sets

Keys live at two levels. The PICC holds a card master key governing card-level management. Each application can hold up to 14 keys and has its own key settings and file access rights. Key-version information helps an issuer manage updates, but it is not a substitute for the secret key or the required permissions. Confirm the selected ChangeKey or ChangeKeyEV2 procedure against the exact application configuration.

EV2 supports multiple key sets per application, allowing the issuer to prepare and roll to another key set when the reader estate supports that process. An integrator may use per-card diversification, such as the scheme in NXP AN10922, with protected master-key storage in an HSM or SAM. This is a deployment design decision, not an automatic property of a blank card. Agree who creates, holds and loads the keys and how the readers obtain the required credentials before ordering. Do not put live secret keys in an RFQ.

The DESFire command set

DESFire supports native commands and ISO/IEC 7816-4 wrapping over ISO/IEC 14443-4. The overview below helps identify what the reader stack must implement; it is not an encoding specification. NXP’s public EV2 short data sheet lists command families, and the detailed product documentation defines their parameters and security requirements. The card configuration, reader firmware and application must support the operations selected by the integrator.

Security certification

The generations differ in their Common Criteria evaluation as well as their features. Public NXP material rates DESFire EV1 at Common Criteria EAL4+ and both EV2 and EV3 at EAL5+ — the EV3 hardware and operating system are evaluated to EAL5+ augmented with AVA_VAN.5. Certification covers the chip and its operating system, not a finished card or a deployment: a card left with default keys is not secure whatever the chip's rating. Treat the EAL level as one input to a tender requirement and confirm the exact certified part with your integrator.

Why upgrade from MIFARE Classic to DESFire

MIFARE Classic uses Crypto-1, whose published security weaknesses make it unsuitable to treat as equivalent to modern AES application authentication. An installation that authorises a card from its UID alone also has a separate problem: the UID is an identifier, not proof that the card holds an application secret. Assess both the credential technology and the reader’s actual authentication behaviour when planning a migration.

DESFire supports AES-128 mutual authentication and configurable file permissions and communication protection. Copying a UID alone does not reproduce an authenticated application, but installing a DESFire chip does not automatically secure the system. Files configured for free access or plain communication may expose data; default keys and poorly protected issuer keys also weaken the deployment. Configure the application’s access rights, secure messaging and key management, and make the reader authenticate the application. Random ID can reduce disclosure of the fixed UID during card selection; it does not replace authentication or guarantee that a card cannot be tracked.

• Reader firmware: move the readers to a build that authenticates the DESFire application with the project's keys, rather than accepting the UID.
• Key ceremony: generate the master keys in an HSM or SAM, choose the AN10922 diversification scheme, and record who holds and loads the keys before the first card is encoded.
• Dual-technology period: run multi-technology readers that accept the legacy cards and the new DESFire cards together, reissue cards on natural attrition, then set a hard date to disable the legacy card types in the access software so old clones stop working.

For a new system NXP directs designs to DESFire EV3; order EV2 to match an installation that already specifies it, and treat any generation change as a change to the approved specification. See MIFARE Classic cards, the MIFARE DESFire family and MIFARE Plus cards for the migration options.

Related choices: MIFARE DESFire family, MIFARE Plus cards, the DESFire tag and fob and all RFID cards.

Technical references: NXP MIFARE DESFire EV2 product and lifecycle page, the DESFire EV2 short data sheet and the NXP DESFire EV3 page. Chip documentation describes IC capabilities; it does not establish Proud Tek’s stock or a finished card’s compatibility.