Mifare Classic cards security

Despite their age, Mifare Classic cards are still widely used around the world. They are employed in public transportation, parking facilities, hotels, access control systems, etc. Mifare Classic cards can be divided into two main versions: one with 1 kB of memory and the other with 4 kB. The primary difference is that the larger version offers more space for user data, but the other mechanisms and security features remain the same. This article will focus on the 1 kB version. 

Physical Mifare Classic cards

Cards operate with readers that are compatible with ISO/IEC 14443. When within a short range (approximately 10 cm), the reader powers the card, allowing communication to begin. The card communicates bidirectionally with the reader using predefined commands encoded in hexadecimal format. Initially, if multiple cards are present in the reader’s electromagnetic field, the reader selects a specific card. This is followed by a three-pass authentication process. Once authenticated, the card and reader can exchange various commands. 

Three-pass authentication 

Once the reader successfully selects a card and establishes a connection, a three-pass authentication process begins, consisting of five steps: 

1. The reader selects either key A or B. 
2. The card selects the secret key and checks the access conditions from the sector trailer. It then sends a challenge n_t, to the reader (pass one). 
3. The reader calculates a response based on the secret key and the received challenge n_t from the card. It then sends the response, a_r, along with a random challenge n_r to the card (pass two). 
4. The card verifies the challenge response a_r from the reader using the previously sent number n_t. It then calculates a response using the challenge n_r received from the reader and transmits it (pass three). 
5. The reader verifies the received response. 

This straightforward mechanism ensures that both the card and the reader possess the same key, enabling encrypted communication using that key. Notably, encryption begins at step 3, when the reader responds. The initial challenge from the card is sent in plaintext. 

Memory organization in Mifare Classic cards

The memory of the cards is organized as follows: 

• 16 sectors, each containing 4 blocks 
• Each block consists of 16 bytes 
• The first block of the first sector is reserved for Manufacturer Data 
• The last block in each sector, known as the Sector Trailer, is reserved for keys and Access Bits 

Access bits in Mifare Classic cards

Sector trailers are crucial components of memory, as they define encryption keys and specify the operations that can be performed on the data or the sector trailer itself. 

• The first 3 bytes set permissions for a particular sector, with some bytes used for error correction. 
• The last byte is optional and can be filled with custom user data. 

The table below outlines the function of each bit. Groups of three bits define the access rights for individual data blocks or the sector trailer. More detailed information on specific privileges will be provided later in this article: 

Access Bits	Valid Commands	Block	Description
C13, C23, C33	read, write	3	sector trailer
C12, C22, C32	read, write, increment, decrement,  transfer, restore	2	data block
C11, C21, C31	read, write, increment, decrement,  transfer, restore	1	data block
C10 ,C20, C30	read, write, increment, decrement,  transfer, restore	0	data block

Access conditions for the sector trailer 

Permissions for sector trailers and data blocks differ. All possible combinations of permissions are detailed in the tables below: 

There are a few important points to note. Key A cannot be read from the Sector Trailer in any configuration. Access bits may be locked from writing, meaning that even with Key A, future changes to them may be impossible. Access Bits should be selected carefully, considering who should have access to each key and what actions can be performed with it. Importantly, if Key B can be read from the Sector Trailer, it cannot be used for authentication in any of the corresponding data blocks. This occurs in three settings: 000, 010, and 001. 

Access conditions for data blocks 

The table below describes how data access can be configured and the operations that can be performed on it. 

Let’s take a closer look at the following example: 

From the tables above, we can categorize the bits as follows: 

Key A = (FFFFFFFFFFFF)₁₆ 

Key B = (EEEEEEEEEEEE)₁₆ 

User Data (Custom) = (11011110)₂ 

Block 0 (data block) = C1₀ ,C2₀, C3₀ = (110)₂ 

Block 1 (data block) = C1₁, C2₁, C3₁ = (011)₂ 

Block 2 (data block) = C1₂, C2₂, C3₂ = (001)₂ 

Block 3 (sector trailer) = C1₃, C2₃, C3₃ = (111)₂ 

This results in access conditions as follows: 

Block 0 (data block): 

• Read – key A|B,  
• Write – key B, 
• Increment – key B, 
• Decrement, Transfer, Restore – key A|B 

Block 1 (data block): 

• Read – Key B 
• Write – Key B 
• Increment – Never 
• Decrement, Transfer, Restore – Never 

Block 2 (data block): 

• Read – Key B 
• Write – Key B 
• Increment – Never 
• Decrement, Transfer, Restore – Never 

Block 3 (sector trailer): 

• Read Key A  – Never 
• Write Key A  – Never 
• Read Access Bits – key A|B 
• Write Access Bits – Never 
• Read Key B – Never 
• Write Key B – Never

Security in Mifare Classic Cards

Cards internal mechanisms 

The problem with security by obscurity is that it will eventually be compromised. This is what happened with Mifare Classic cards, which kept their algorithms secret until 2007 when Nohl and Plotz reverse-engineered them. They meticulously revealed the internal chip layer by layer, eventually exposing the layer with transistors. Using a microscope and image recognition software, they grouped the transistors into logical gates. They also intercepted communication between the card and the reader. By combining all this information, they were able to reconstruct the internal algorithms of the cards. Further analysis revealed security vulnerabilities. 

Researchers initially focused on the cryptographic algorithms, reversing the encryption scheme along with the pseudo-random number generator (PRNG) used in processes like the three-pass authentication for generating challenges. 

Cipher 

The cipher used in Mifare Classic cards is a stream cipher, which consists of a 48-bit linear feedback shift register (LFSR) combined with a nonlinear function f(). Twenty bits from the register are fed into the nonlinear function, which generates one bit of the keystream. This keystream is then XOR-ed with the plaintext to produce the ciphertext. 

The polynomial used in the LFSR is as follows: 

L(x0x1 . . . x47) := x0 ⊕x5 ⊕x9 ⊕x10 ⊕ x12 ⊕x14 ⊕x15 ⊕x17 ⊕x19 ⊕x24 ⊕x25 ⊕x27 ⊕x29 ⊕ x35 ⊕ x39 ⊕ x41 ⊕ x42 ⊕ x43. 

PRNG 

The generation of pseudo-random numbers is handled by a 16-bit LFSR. Although the numbers are 32 bits in length, only 16 bits are derived from this second LFSR. It updates every 106 kHz clock cycle, producing one bit every 9.44 µs. The cycle repeats every 2¹⁶-1 iterations, lasting approximately 619 ms in total. Additionally, if the card field is interrupted, the cycle restarts with the same bit pattern. Considering these factors, an attacker can manipulate the pseudo-random numbers based on timing, potentially controlling the challenges sent during the three-pass authentication process. 

The polynomial used in the PRNG is described below: 

L16(x0x1 . . . x15) := x0 ⊕ x2 ⊕ x3 ⊕ x5 

Parity bits 

Parity bits are appended to each byte of the encrypted text. Unfortunately, they are calculated based on the plaintext rather than the ciphertext. Additionally, the bit from the keystream used to encrypt the parity bit is reused to encrypt the first bit of the next byte of plaintext. These characteristics will be exploited in subsequent attacks. 

During authentication, when the reader sends a challenge and a response to the challenge, the card checks the parity bits before responding to the reader. If at least one of the eight parity bits is incorrect, the card does not respond. If all the parity bits are correct but the response to the challenge is wrong, the card returns an encrypted 4-bit error code. 

LFSR Rollback 

Initially, the cipher’s internal state is set to the secret key. With each encryption operation, the LFSR advances, altering the state. Given the internal state of the cipher, along with the UID, n_t, and encrypted n_r, it is possible to revert the LFSR to its initial state, which is the sector key. 

Brute-force attack 

Is a 48-bit secret key sufficient? From the perspective of an online attack where the algorithms are unknown, it should be adequate. The delay between an authentication attempt and the reader’s response is significant enough to assume that, in the worst-case scenario, a brute-force attack would take several thousand years. 

However, with the reverse-engineered algorithms, the attack can be performed offline. Using parity bits, it is possible to brute-force the key offline. In the three-pass authentication process, the challenge from the card n_t is sent in plaintext. If we successfully authenticate to one sector, the next authentication attempt to another sector will provide an encrypted challenge, encrypted by the card key. Each encrypted byte is accompanied by a parity bit. A brute-force attack on each byte can be verified using this parity bit: if the key is correct, the parity bit will match; if not, the parity bit will match with a 50% probability. 

Nested attack 

Requirements: Knowledge of one sector key 

To perform this attack, you need to know one of the keys for any sector. This is a relatively easy requirement, as default keys are often set for unused sectors. The default key for Mifare Classic cards is FFFFFFFFFFFF. 

The attack can be divided into several steps: 

1. The attacker applies a card to the reader and authenticates to a sector for which they know the key. The card generates a 32-bit challenge n_t, which is known to the attacker. 
2. Next, the attacker authenticates to the sector whose key they want to break. This time, the card generates a challenge n_t’ encrypted with the sector key. Exploiting the weakness in the PRNG, the attacker can predict the plaintext form of the challenge. 
3. Knowing the encrypted challenge n_t’ and its plaintext form n_t, the attacker obtains 32 bits of the keystream used to encrypt this challenge. 

n_t’ =  n_t ⊕ Ks -> Ks = n_t ⊕ n_t’ 

4. Using LFSR rollback, the attacker can reverse the keystream and obtain 32 bits of the sector key. This leaves 216 bits of the key remaining. 
5. The rest of the key can be brute-forced. Due to the weakness of the parity bits, this can be reduced to 2^16-3 = 2¹³ = 8192 candidates. 

Darkside attack

 

Requirements: NACK bug 

If an attacker does not know any of the sector keys, they may attempt a darkside attack. 

One more mechanism in Mifare Classic cards needs to be explained. When the reader responds to a card challenge, the card first verifies the parity bits. If the parity bits are correct, the card then verifies the challenge. If the challenge is correct, communication continues. However, if the parity bits are correct but the challenge response is incorrect, the card sends a 4-bit encrypted NACK code. 

The attack proceeds as follows: 

1. The card sends a challenge n_t to the reader. 
2. The attacker calculates the response and sends the challenge along with the calculated parity bits. With a probability of 1/256, the parity bits will be correct, as the attacker does not know the key used to decrypt them. If the attacker correctly guesses the parity bits but the challenge response does not match, the card responds with a 4-bit encrypted NACK code. 
3. The attacker can then XOR the plaintext NACK code with the encrypted one to obtain 4 bits of the keystream. 

Since the attacker brute-forced 8 parity bits and obtained 4 bits of the NACK code, they now have 12 bits of the keystream. In practice, 6 attempts are sufficient, so the attacker needs 256 * 6 = 1536 authentication attempts to obtain the required keystream bits. The attacker can then brute-force the key. 

By exploiting this bug, the attacker can recover all data from the card. 

Hardnested attack 

NXP attempted to fix the discovered vulnerabilities while maintaining backward compatibility with existing systems. They improved the PRNG to generate unpredictable 32-bit nonces and eliminated the NACK bug. These two fixes significantly enhanced security but did not resolve all algorithm-related issues. 

In 2015, Carlo Meijer and Roel Verdult discovered a ciphertext-only attack on the hardened versions of Mifare Classic. This attack requires approximately 1600-2200 nonces from the card to likely retrieve the sector key. As noted, this attack necessitates having at least one valid key for any sector to obtain the required encrypted nonces. If no valid key is known, nonces can be obtained from the corresponding reader. 

This attack is closely tied to vulnerabilities in the encryption algorithm, making it nearly impossible to fix while preserving backward compatibility. The issue remained unresolved until 2020, when the company producing chips for NXP cards introduced a variant with a static encrypted nonce. However, this solution introduced additional problems, which will be discussed in the next chapter. 

Static nested attack 

In 2020, the company responsible for producing chips for Mifare Classic introduced new chips with the serial number FM11RF08S. These chips were designed to resist any known card-only attacks while maintaining backward compatibility. 

Instead of generating a random challenge, the card always returns the same nonce for the same card and sector. The nonce’s value depends on: 

• The card (which could be the UID, block 0, the 8-byte manufacturer data, the 6-byte “signature,” a unique random seed inaccessible to the card, block 128 key A, block 128 key B, or any other personalized value not yet discovered) 
• Sector number 
• Sector key 

This design makes all known attacks ineffective: 

• Darkside attack – NACK bug is fixed 
• Nested attack – PRNG is improved 
• Darknested attack – Impossible to generate the required number of nonces 

A basic approach to attacking these cards might involve requesting different sectors and cards with the same sector key. Assuming the nonce is encrypted with the sector key and its value varies between sectors/cards, unique nonces can be obtained by requesting different sectors/cards. While theoretically possible, this attack is challenging in practice. 

Researchers attempted to fuzz commands responsible for sector authentication. According to documentation, command 60XX authenticates with key A and 61XX with key B, where XX is the sector number. During fuzzing, they discovered additional valid commands: 

• 60XX, 62XX, 68XX, 6aXX – Valid authentication with key A, returns the same nonce 
• 61XX, 63XX, 69XX, 6bXX – Valid authentication with key B, returns a different repeated nonce 

They found some commands that returned a different repeated nonce and ended authentication with an error: 

• 64XX, 66XX, 6cXX, 6eXX – Different static nonce, authentication ends with an error 
• 65XX, 67XX, 6dXX, 6fXX – Similar situation, but with a different nonce 

With the same keys A and B, the above pairs returned the same nonce. This suggests the existence of a backdoor key capable of authenticating to other sectors. Researchers used an attack similar to the nested attack to obtain this key. 

The attack was similar to the nested attack but required generating 65,535 nonce candidates, which were reduced to 8,192 candidates using parity bits. This allowed them to obtain the keystream and roll it back to the original key. This attack is only possible with the same keys, which is a valid assumption with the backdoor key. 

The backdoor key is A396EFA4E24F and exists on all cards with these chips. It has interesting properties: it allows reading all data from all sectors, even if access bits do not permit it, and there is no need to authenticate again to other sectors. Importantly, it does not allow reading any key A or B. 

Further analysis shows that the nonce generated when authenticating with key A is the same as when authenticating with the backdoor key. This allows performing a nested attack even if no key A/B is known for the entire card. 

1. Authenticate with the backdoor key and receive unencrypted n_t1. 
2. Perform nested authentication with key A and receive encrypted {n_t2}. 
3. Since n_t1 = n_t2, so ks₀ = n_t1 ⊕ {n_t2}. 
4. Rollback and repeat until the key is recovered. 

This attack works even if all keys are diversified, as one key is always known. 

Researchers also revealed backdoor keys for older cards FM11RF32: A31667A8CEC1 and 518B3354E760. 

These card-only attacks take a few minutes to break all card keys, but with access to the reader, only a few seconds with the card are required to authenticate successfully. 

Magic cards 

A successfully cloned card can be emulated using devices like Flipper or Proxmark. However, in real-world scenarios, this might attract too much attention, which is why Magic Cards were invented. Mifare Classic cards have a fixed UID by default, meaning it can’t be changed. Therefore, if a system relies solely on the card’s UID for authentication, it’s possible to clone the card using a Magic Card. 

There are four generations of Magic Cards: 

Gen 1a 

• Allows modification of UID 
• Does not automatically calculate the checksum, risking card bricking if calculated incorrectly (Flipper or Proxmark will calculate it automatically) 
• Compatible with Mifare Classic 1k 
• May be detected and blocked by a reader (supports commands that official cards do not) 
• Unblocked with code 0x43 0x40 

Gen 1b 

• Same properties as Gen 1a, but unblocked with a custom code 

Gen 2 

• Modifiable 4 and 7 bytes of UID 
• Supports Mifare Classic 1k/4k 
• May be detected and blocked by a reader (supports commands that official cards do not) 

Gen 2 OTW 

• Same capabilities as Gen 2, but with a one-time write UID, making it undetectable as a Magic Card by a reader 

Gen 4 

• Supports MIFARE Classic®, MIFARE Ultralight® EV1, MIFARE Ultralight® EV2, NTAG® 203/213/215/216 cards 
• Allows modification of UID + Length, SAK, ATQA, ATS 
• Recovery mode to unlock the card if bricked 
• Auto-BCC calculation for automatic checksum calculation 
• Password protected, preventing the execution of magic commands without the password, thus functioning like Gen 2 OTW and remaining undetectable by a reader 
• Shadow mode, enabling the card to be preconfigured with data; when written and read with new data, it returns to the preconfigured state 

Practical attacks 

Attacking with Flipper Zero 

The card can be read using the NFC app on Flipper Zero. 

In the example above, not all keys were present in the dictionary, so Flipper didn’t read the entire card. Flipper automatically gathers useful information and saves it in a text file located at /ext/nfc/.nested.log. 

Several pieces of information are required to break all keys, such as the keystream and parity bits. Using the MFKey application, the card can be compromised. Keys can also be cracked on a computer or mobile device, which accelerates the process. 

If the process is completed successfully, the key will be added to the user dictionary. 

Reading the card again with the NFC app will grant access to the entire card. 

From the screenshot above, it can be observed that key A is A0B1C2D3E4F5, key B is A1B2C3D4E5F6, and the data is ABCDEF0123456789. 

Flipper can execute brute-force, nested, darkside, and darknested attacks. If none of the keys are known, nonces can be obtained from the reader. Using the same strategy as in a darknested attack, the card can then be compromised. 

Attacking with Proxmark: 

The easiest way to break all keys is to execute the autopwn command, allowing Proxmark to select the optimal strategy. 

[usb] pm3 –> hf mf autopwn 

To sum up: 

• Keys A and B from sector 0 were retrieved from the dictionary using the default key FFFFFFFFFFFF.  
• Nested attacks were executed on most sectors.  
• Sector 4 reused the same key.  
• Nearly all keys B were accessed by key A, as permitted by the sector trailer. 

What if the dictionary key is missing in sector 0? Let’s investigate: 

In this scenario, the card cannot be compromised using cards-only attacks, as it is not susceptible to darkside attacks and does not use a static nonce variant. However, it can be breached by collecting nonces from the reader and then applying the darknested attack strategy to break the keys. 

Conclusions 

To sum up, the key takeaways are: 

1. Security by obscurity is a poor choice as a primary security mechanism, though it can serve as an additional layer of security. 
2. Creating custom cryptographic algorithms is highly challenging and likely to result in insecure implementations. 

For Mifare Classic users, the best recommendation is to switch to more secure versions, like Mifare DESFire. If replacement isn’t feasible, consider these measures to reduce the attack surface: 

• Physically protect cards from unauthorized access. Ensure cards are not left unattended and are concealed during transportation. 
• Avoid using card UID for user authorization, as it can be copied without needing any keys. 
• Ensure all sectors have unique, non-dictionary keys. 
• Use EV1 or Mifare Plus versions of cards, which offer backward compatibility and fix issues, like the NACK bug and PRNG. 
• Control and monitor access to readers. 
• Train employees on the risks of badge copying and preventive measures. 
• Avoid static encryption variants for cards. 

Resources: 

• A Practical Attack on the MIFARE Classic – Gerhard de Koning Gans, Jaap-Henk Hoepman and Flavio D. Garcia Institute for Computing and Information Sciences Radboud University Nijmegen P.O. Box 9010, 6500 GL Nijmegen, The Netherlands 
• Nohl, S.K., Evans, D., Pl¨otz, H.: Reverse-Engineering a Cryptographic RFID Tag. In: USENIX Security Symposium, San Jose, CA, 31 July (2008) 
• Study of vulnerabilities in MIFARE Classic cards – Lucas de Araújo https://www.sidechannel.blog/en/mifare-classic-2/ 
• Ciphertext-only Cryptanalysis on Hardened Mifare Classic Cards – Carlo Meijer, The Kerckhoffs Institute Radboud University, The Netherlands. Roel Verdult, Institute for Computing and Information Sciences Radboud University, The Netherlands. 
• Card-Only Attacks on MiFare Classic or How to Steal Your Oyster Card and Break into Buildings Worldwide – Nicolas T. Courtois University College London, UK 
• Wirelessly Pickpocketing a Mifare Classic – Card Flavio D. Garcia, Peter van Rossum, Roel Verdult, Ronny Wichers Schreur, Radboud University Nijmegen, The Netherlands 
• MIFARE Classic: exposing the static encrypted nonce variant I’ve got a bit more, should I throw it in? – Philippe Teuwen Quarkslab 
• MIFARE Classic EV1 1K – Mainstream contactless smart card IC for fast and easy solution development – https://www.nxp.com/docs/en/data-sheet/MF1S50YYX_V1.pdf 

Bartosz Klinowski IT Security Consultant