Modern NFC systems often advertise 3DES or AES security, but real‑world attacks keep showing that the randomness layer is where things quietly fall apart. The BREAKMEIFYOUCAN work on 3DES/AES‑protected NFC technologies is a textbook example: the ciphers are fine, yet attackers still recover keys because the protocol’s randomness is weak and structurally flawed.
In that setting, tags and readers rely on “random” values for challenges, nonces, and sometimes even keys. When those values come from low‑entropy or poorly designed PRNGs, the effective search space collapses. Instead of exploring the full 2^112 or 2^128 space, the system revisits a tiny, predictable corner—making brute‑force and precomputation attacks practical. This kind of weakness is very common in classical PRNGs with bad seeding or limited entropy sources.
What Goes Wrong With the Protocol’s Randomness?
The core problems in protocols like the one studied in the paper fall into three categories:
- Low‑entropy “random” values Embedded devices often seed PRNGs with clocks, counters, or static IDs. The result is that only a small subset of keys or nonces is ever generated, no matter what the theoretical key length is.
- Predictable or biased nonces Authentication challenges that should be fresh and unpredictable can become partially predictable across sessions, or use fewer independent bits than their nominal length suggests. This enables attackers to prune the search space or precompute responses.
- Structural keyspace reduction Once you know that keys or challenges live in a restricted region of the space, you can mount targeted brute‑force attacks that are orders of magnitude faster than a full search. Real incidents have shown that weak randomness allows attackers to reconstruct private keys or forge sessions despite “strong” algorithms.
Key properties of a good QRNG implementation:
- True unpredictability Output is not the result of a deterministic algorithm with a hidden seed, so there is no internal state an attacker can reconstruct by observing a few values.
- High, measurable entropy Certified QRNGs provide statistically tested, high‑entropy output (e.g., passing NIST SP 800‑22 and SP 800‑90B criteria), with continuous health checks to detect failures.
- No hidden structure or bias after conditioning Post‑processing (typically hashing or a DRBG) removes any residual physical bias, so keys and nonces are uniform over their full bit‑length.
- Nonces and challenges become independent, uniform, and non‑predictable across sessions.
- Keys and per‑device secrets are drawn from the full keyspace, not a small, implementation‑dependent subset.
- Attackers lose the ability to meaningfully model your randomness or prune the search space—their only option is a full brute‑force against the nominal key length, which is infeasible for 3DES/AES‑scale keys.
From Weak PRNG to QRNG‑Backed Design: What to Change
To actually eliminate the randomness weaknesses seen in the paper’s protocol, you need to do more than drop a QRNG chip into the schematic. You have to redesign the randomness pipeline so that every cryptographic decision depends on QRNG‑grade entropy. The high‑level pattern mirrors what’s advocated in modern QRNG and crypto‑engineering work.-
- Central entropy pool seeded by QRNG
- Use QRNG output as the primary entropy source in the secure element or NFC controller.
- Feed it into a standard DRBG (e.g., per NIST SP 800‑90A) and draw all cryptographic random values from that DRBG
- All protocol randomness goes through this pool
- Authentication challenges, nonces, IVs, per‑session keys, and key diversification values must all be generated via the DRBG, never via ad‑hoc PRNGs or counters.
- Enforce this in firmware: no direct use of local “fast” PRNGs for security‑critical fields.
- Per‑device and per‑domain keys
- Use QRNG‑backed randomness to generate unique master keys and diversified keys per tag/device.
- This ensures that even if one device is compromised, the attacker gains no statistical advantage over others; there is no shared low‑entropy structure to exploit.
- Continuous health monitoring
- Implement QRNG health tests and entropy‑threshold monitoring so that hardware faults or source manipulation cannot silently degrade entropy while still passing naive statistical tests.
- With this architecture, the kind of reduced‑space keysearch that BREAKMEIFYOUCAN exploits simply cannot get started: the protocol never reuses or restricts itself to a tiny subset of the key/nonce space, and there is no deterministic PRNG state to learn or predict.
- Central entropy pool seeded by QRNG
What Risks Remain (and Why That’s a Good Thing)
Even with a perfectly implemented QRNG, you still need distance‑bounding against relay, robust access‑control on key pages, and sane post‑authentication semantics. Randomness is only one layer. But by putting a QRNG at the foundation, you:- Remove an entire attack class—anything that depends on weak, biased, or predictable randomness.
- Ensure your 3DES/AES‑based NFC protocol actually delivers its advertised security level in terms of search space.
- Make remaining attacks more expensive, more visible, and more dependent on protocol or physical weaknesses rather than silent entropy failures.
That’s exactly the kind of shift you want: from “crypto that fails quietly because of bad randomness” to “crypto that fails, if at all, only under much more demanding and detectable attack conditions.”