BREAKMEIFYOUCAN! - Exploiting Keyspace Reduction and Relay Attacks in 3DES and AES-protected NFC Technologies

This research demonstrates vulnerabilities in widely deployed NFC technologies used for access control, ticketing, and hospitality. We show that cryptographic keys protecting MIFARE Ultralight C, MIFARE Ultralight AES, and NTAG 223/224 DNA tags can be recovered through a combination of relay attacks, partial key overwrites, and EEPROM manipulation techniques.

The core issue is that these tags lack adequate post-authentication integrity protection, and many deployments fail to properly configure available security features like lock bytes and key diversification.

No. The underlying cryptographic algorithms (3DES and AES-128) remain secure. The vulnerabilities arise from:

• Protocol design choices that allow unauthenticated memory writes after initial authentication
• Lack of atomicity when writing cryptographic keys across multiple memory pages
• Widespread misconfiguration in real-world deployments (unlocked memory, static keys)
• Non-NXP compatible chips with severely flawed random number generators

Yes. We initiated contact with NXP Semiconductors in July 2025 and provided them with a complete draft of our findings. NXP confirmed the findings in August 2025 and requested additional time for product recertification. We coordinated the publication timeline with NXP, balancing their recertification needs with the importance of informing the security community and affected parties.

The title comes directly from the default factory key programmed into every MIFARE Ultralight C chip by NXP. When you read the 16-byte 3DES key from a fresh Ultralight C tag, it spells out the ASCII string BREAKMEIFYOUCAN!.

This appears to be a deliberately playful challenge left by NXP's engineers in 2008 for the security research community, and embedded directly in the Ultralight C's memory. We chose the paper's title to reflect this challenge, having demonstrated multiple practical attacks.

Of course, in any properly configured deployment, this default key should be replaced with a unique, securely generated key before deployment.

The risk to individual hotel guests is generally low for opportunistic attacks. These attacks require specialized equipment and technical knowledge. However, our research did demonstrate a successful credential forgery attack against a real hospitality system using a discarded room key.

Practical advice:

• Don't leave your key card unattended for extended periods
• Don't discard key cards in publicly accessible areas near the hotel
• Report lost cards immediately so they can be deactivated
• Use in-room safes and additional door locks when available

Likely yes, to some degree. Our survey found that 100% of MIFARE Ultralight C systems examined were affected by one or more issues. The severity depends on your configuration:

• High risk: Static keys shared across all cards, unlocked key memory pages, non-NXP compatible cards in your supply chain
• Medium risk: Key diversification implemented but lock bytes not configured, CMAC not enabled on Ultralight AES
• Lower risk: Proper key diversification, locked memory pages, verified genuine NXP chips, CMAC enabled (for Ultralight AES)

We strongly recommend auditing your deployment against the mitigations listed below.

Some transit systems use MIFARE Ultralight C for limited-use tickets. If your system uses static keys and doesn't lock key memory pages, it could be vulnerable to the multi-tag key recovery attack. However, transit systems often have backend validation that may limit the practical impact.

Systems using MIFARE DESFire or other more advanced technologies are not affected by this specific research.

Our sampling found that approximately 34% of cards from hospitality deployments were not genuine NXP products. Non-NXP compatible cards (like Giantec GT23SC4489 "ULCG", Feiju FJ8010, or USCUID-UL) have severely flawed random number generators that allow key recovery from a single card in under 60 seconds.

How to check:

• Use hf mfu info from the latest Proxmark3 firmware, which integrates fingerprinting for all counterfeit cards mentioned in the paper
• ULCG cards can be quickly identified by their UID suffix ending in 1589
• See details in our paper and other fingerprinting tools available in our GitHub repository for deeper inspection
• Audit your supply chain and verify card sources

MIFARE DESFire: Not affected by this research. DESFire provides end-to-end encrypted sessions with integrity protection and is recommended as an upgrade path.

MIFARE Classic and MIFARE Plus: Not in scope for this paper, but MIFARE Classic has its own well-documented vulnerabilities (Crypto1 weaknesses) which are mitigated in MIFARE Plus, provided it is properly configured.

ICODE DNA, UCODE DNA, NTAG 424 DNA: We examined these briefly. NTAG 424 DNA appears to require authentication before key modification, which mitigates the partial key overwrite attack. See the full paper for details.

1. Audit your current deployment:

• Check if lock bytes are configured on key pages (Lock byte 3, bit 7 for Ultralight C)
• Verify whether you're using static or diversified keys
• Test sample cards for non-NXP compatible chips
• For Ultralight AES: check if SEC_MSG_ACT is enabled

2. For new card issuance:

• Implement key diversification using UID and a site-specific salt
• Permanently lock key memory pages after personalization
• Enable authentication attempt limits where available
• Verify genuine NXP chips before deployment

3. For existing deployments with static keys:

• If key pages can still be locked, do so immediately
• Plan migration to diversified keys or more secure technology
• Implement additional backend validation where possible

Partially. If the key memory pages and configuration bytes are not yet locked, you can:

• Lock the key pages to prevent the partial key overwrite attack
• Enable AUTH_LIM on Ultralight AES to limit brute-force attempts

However: If you're using static keys across your deployment, locking the pages only prevents new attacks—it doesn't change the fact that an attacker with enough cards could still recover the key through other means. Migration to diversified keys is the proper long-term solution.

For non-NXP compatible cards: These cannot be meaningfully secured and should be replaced with genuine NXP products.

For applications requiring higher security assurance, we recommend migrating to MIFARE DESFire EV3 or similar advanced contactless smart card technologies. These provide:

• End-to-end encrypted communication sessions
• Mandatory integrity protection (not optional)
• Hardware-level countermeasures against tearing and manipulation
• Secure key storage with proper atomicity guarantees

While Ultralight AES is an improvement over Ultralight C, its security still depends heavily on proper configuration, whereas DESFire provides stronger security by default.

MIFARE Ultralight C stores its 112-bit 2TDEA key across four 4-byte memory pages (pages 44-47). The tag's firmware doesn't enforce atomic writes across all four pages—each page can be written independently.

After gaining authenticated access via a relay attack, an attacker can:

• Overwrite three of the four key pages with known values (e.g., zeros)
• Brute-force the remaining 28 bits (~2²⁸ possibilities)
• Repeat on different tags, targeting different key quarters each time
• Combine the four recovered segments to reconstruct the full key

This reduces the attack complexity from 2¹¹² to roughly 4 × 2²⁸, making it feasible with modest hardware.

The mutual authentication in Ultralight C does work correctly—both the reader and tag prove they know the shared secret. The problem is what happens after authentication.

Unlike MIFARE DESFire, Ultralight C has no post-authentication integrity protection. All commands after authentication are sent in plaintext without any MAC or encryption. An attacker who relays the authentication exchange can then inject their own commands to the now-authenticated tag.

Crucially, the tag has no timing constraints—it will wait indefinitely for the reader's response during authentication, eliminating the tight timing windows that normally make relay attacks difficult.

The attacks can be performed with relatively inexpensive, commercially available hardware:

• Relay attack: Two Flipper Zero devices communicating over 433 MHz, or Proxmark3 devices
• Online brute-force: Proxmark3 or Flipper Zero (~100 auth attempts/second)
• Offline computation: Standard laptop (for non-NXP cards) or GPU cluster (for 2-tag variant on genuine cards)
• Tearing attacks: Proxmark3 with precise timing, or even Flipper Zero with busy-loop timing

Total equipment cost is well under $500, and the techniques are within reach of moderately skilled attackers.

All tools and scripts are available on GitHub at github.com/zc-public/breakme-resources. Relevant code has also been contributed to:

• Proxmark3 firmware repository
• Flipper Zero firmware (version 1.4.0+)
• ChameleonUltra firmware

The tools include key recovery scripts, fingerprinting utilities, and optimized brute-force implementations.

Initiated contact with NXP; NXP acknowledged initial contact

Sent draft of vulnerability report to NXP; NXP acknowledged receipt

NXP confirmed findings and requested changes to draft

Acknowledged feedback, shared research updates, requested NTAG-22x sample sources

Delivered second draft of vulnerability report; requested publication timeline

NXP indicated additional time needed for recertification

NXP requested disclosure delay to Q2 2026 for product recertification

Anticipated publication date communicated to NXP; disclosure timeline scoped to customer risk mitigation

Paper and Proof-of-Concept exploits published