Chapter 6: Secure NFC — DESFire and Beyond

The previous chapters covered MIFARE Classic (with its known cryptographic weaknesses) and MIFARE Ultralight (with simple password protection). For applications that genuinely require strong security — financial transactions, high-assurance access control, government ID — a different class of NFC technology is needed.

This chapter gives a concise overview of the secure NFC landscape: MIFARE DESFire, Java Card / JCOP, and related technologies. It is intentionally brief because open-source tooling for these platforms is limited, and deep engagement with them typically requires proprietary SDKs or hardware security modules.

6.1 Why MIFARE Classic Is Not Enough

As discussed in Chapter 3, MIFARE Classic’s CRYPTO1 cipher can be defeated in seconds with freely available software. Any application where the consequences of a cloned or manipulated card are serious — financial loss, physical security bypass, identity fraud — cannot rely on MIFARE Classic.

The fundamental problems are:

1. Weak cipher: CRYPTO1 is 48-bit, proprietary, and broken.
2. No secure key storage on card: the entire key is derived from NXP’s cipher. Whoever gets the chip out can attempt to extract the key.
3. No application isolation: MIFARE Classic has a flat sector structure — there is no concept of isolating one application from another on the same card.
4. No secure channel: communication is encrypted with CRYPTO1 but that encryption is now trivially breakable.

6.2 MIFARE DESFire

MIFARE DESFire is NXP’s answer to these shortcomings. It was introduced in 2002 and has gone through three major revisions: EV1 (2007), EV2 (2012), and EV3 (2021).

Architecture: Applications and Files

Instead of sectors, DESFire organises data in a hierarchical model:

Card
└── PICC Master Key (card-level key)
    ├── Application 1 (AID: 3 bytes)
    │   ├── Application Master Key
    │   ├── File 1 (Standard Data, Backup Data, Value, Record...)
    │   ├── File 2
    │   └── ...
    └── Application 2 (AID: 3 bytes)
        ├── Application Master Key
        └── ...

Each Application is identified by a 3-byte Application Identifier (AID). An application can have up to 16 keys (numbered 0–15) and up to 32 files. Key 0 of an application is its Application Master Key and controls application-level administration.

This isolation means that a transit application and a payment application can coexist on the same card without either being able to access the other’s data — even if one is completely compromised.

File Types

DESFire supports five file types:

Cryptographic Algorithms

EV3’s SUN (Secure Unique NFC) message is particularly interesting: the tag can embed a cryptographically authenticated counter value directly in a URL it broadcasts as NDEF, allowing a server to verify the tag is genuine and has not been replayed — without any backend infrastructure in the reader.

Authentication Protocol

DESFire uses a 3-pass mutual authentication:

1. Reader selects application and requests authentication with a specific key number
2. Tag generates random nonce (RndB), encrypts it, sends to reader

3. Reader decrypts RndB, generates RndA, sends Enc(RndA

   RndB’) (RndB rotated 1 byte)

4. Tag verifies, decrypts, sends Enc(RndA’) (RndA rotated 1 byte)
5. Reader verifies — mutual authentication complete

After authentication, all subsequent communication is secured with session keys derived from RndA and RndB.

Access Rights Per File

Every file has an access rights byte encoding four 4-bit permission fields:

Bits 15–12: Read access key number  (0–13: key required; 14: free; 15: never)
Bits 11–8:  Write access key number
Bits 7–4:   Read+Write access key number
Bits 3–0:   Change access key number

This granular per-file, per-operation access control is far more flexible than MIFARE Classic’s per-sector Key A / Key B model.

6.3 Why Open Tooling Is Limited

MIFARE DESFire is well-documented in NXP’s application notes (AN10833, AN12343, etc.), and the command set is fully specified. The authentication protocol is not secret. So why is tooling limited compared to MIFARE Classic?

No proprietary cipher to reverse-engineer. MIFARE Classic attracted massive security research because CRYPTO1 was secret and broken. DESFire uses AES-128 and 3DES — standard ciphers with no known weaknesses. There is no shortcut to break the auth.

SAM (Secure Access Module) requirements. High-security deployments store the master keys in a SAM — a tamper-resistant hardware module that never exposes keys in plaintext, only performs crypto operations internally. Open-source tools cannot easily interact with SAMs.

Proprietary SDK ecosystem. NXP provides the NXP MIFARE SDK and the NXP TagWriter SDK for production applications. These are closed-source. Open-source implementations exist but are incomplete.

What open tooling exists:

• libnfc + libfreefare: libfreefare (C library on top of libnfc) has partial DESFire support — enough to authenticate, list applications, and read/write standard data files with AES or 3DES keys. It does not support all EV2/EV3 features.
• Proxmark3: The Proxmark3 firmware has DESFire read/list capabilities. Full authenticated read/write requires knowing the keys.
• nfcpy: Has limited DESFire support; mostly useful for basic tag identification and NDEF operations.
• Android NFC API: The IsoDep technology class gives raw APDU access to any ISO 14443-4 tag including DESFire. A Java/Kotlin application can implement the full DESFire protocol on top of this.

6.4 Java Card / JCOP

Java Card is an open standard (now maintained by Oracle) for running Java programs on smart card chips. JCOP (Java Card Open Platform) is NXP’s Java Card implementation, found in contactless payment cards, SIM cards, and high-end access cards.

Architecture

A Java Card chip runs a Java Card Virtual Machine (JCVM) and can host multiple independently developed applets (analogous to DESFire applications). Applets are installed post-manufacture and communicate via APDU (ISO 7816) commands.

Card OS (JCOP)
├── GlobalPlatform (card management)
│   ├── Card Manager (install, delete, select applets)
│   └── Security Domains
├── EMV Payment Applet
├── Access Control Applet
└── NDEF Applet (optional)

Each applet has a unique AID (Application Identifier, 5–16 bytes). A reader selects an applet by sending SELECT FILE (ISO 7816) with the AID, then exchanges APDUs with it.

Security Model

Java Card provides strong isolation between applets through the Java Card Firewall — applets cannot access each other’s objects unless explicitly shared via a shareable interface. The on-card JVM enforces type safety and prevents pointer-based attacks that would be possible in C.

GlobalPlatform defines a secure channel protocol (SCP02, SCP03) for applet installation and management, using session keys derived from a card master secret held in the issuer’s HSM.

Contactless Payment (EMV)

The contactless payment chip in your bank card is a JCOP card running an EMV payment applet. From an NFC protocol perspective:

• Physical layer: ISO 14443 Type A or B
• Protocol layer: ISO 14443-4 (T=CL, APDU transport)
• Application layer: ISO 7816-4 command structure, EMV specification commands

The reader (payment terminal) selects the payment applet, runs a cryptographic transaction protocol that generates a transaction-specific cryptogram, and submits it to the payment network for authorisation. The card never transmits its key — only derived cryptograms.

6.5 MIFARE Plus

MIFARE Plus is NXP’s migration path from MIFARE Classic — designed for transit operators who need to upgrade security without immediately replacing all their readers. A MIFARE Plus card can operate in “Classic compatibility mode” (SL1 — Security Level 1, using CRYPTO1) or in full AES mode (SL3). The card starts in SL1 and can be permanently upgraded to SL3 by the card issuer using a secure upgrade command.

MIFARE Plus is relevant for transit modernisation but rarely encountered in hobbyist or developer contexts.

6.6 When to Choose What

Summary

• DESFire organises data in a hierarchical Application → File model, with per-file access control and AES-128 mutual authentication.
• DESFire EV2/EV3 adds relay attack prevention and secure tag origin verification (SUN).
• Open-source DESFire tooling exists (libfreefare, Proxmark3) but is incomplete — full feature access typically requires NXP’s proprietary SDKs.
• Java Card / JCOP provides a programmable applet environment used in contactless payment cards and high-security applications.
• For any new high-security deployment, use DESFire EV2/EV3 or JCOP — not MIFARE Classic.