PUK Security - Technical Explanation

1. Why Cryptnox PUK is very secure?

The Cryptnox card accepts an unlimited number of PUK attempts
Security does not rely on a fixed attempt limit; it relies on the astronomical size of the keyspace and the hardware-limited verification rate of the secure element
If the PUK is strong and randomly generated, brute force is practically impossible. If the PUK is weak or guessable, security drops drastically
The card enforces a minimum per-attempt processing time (measured at ~60 ms per try)  The secure element’s hardware and firmware set this speed and it cannot be meaningfully accelerated by an attacker. The card also enforces a fixed pin lengh of 12 characters.

2. How does the base case number make a random PUK secure?

We use the following base-case example to explain why a random PUK is secure:

Alphabet: 66 characters (alphanumeric, case-sensitive, + 4 special characters)
Length: 12 characters (fixed lengh requirement)
Total number of possible PUK values = 66¹² = 6,831,675,453,247,430,000,000 (≈ 6.83×10²¹)

Minimum measured time to test one PUK on the card: 60 milliseconds (0.06 seconds)

From that: 

Attempts per second ≈ 16.6667 (60 ms/try)
Time to exhaustively test the whole keyspace = (6.83167545324743×10²¹) × 60ms = 4.0990×10²⁰ seconds
Convert to years: 4.0990×10²⁰ s ÷ (31,536,000 s/year) = 12,997,860,451,384 years (≈ 1.3×10¹³ years)

So, with our base-case 12-character random PUK and the card’s 60 ms per-try verification time, a full brute-force would take ~13 trillion years

3. Why do the number matters for security?

Entropy explanation: 

Entropy per character for a 66-character alphabet = log₂(66) ≈ 6.044 bits
For a 12-character PUK: total entropy ≈ 12 × 6.044 ≈ 72.53 bits

So, ~72.5 bits of entropy means the search space is large enough that brute forcing is computationally infeasible given the physical per-try speed enforced by the hardware

Why this is secure (mechanics & threat model): 

Large keyspace: 66¹² combinations ≫ anything an attacker can enumerate within reasonable time when each try costs real time
Hardware-limited verification speed: the secure element enforces the verification routine and its timing characteristics (≈60 ms/try)  This timing is set by the chip’s CPU/firmware and I/O constraints; it cannot be sped up by a remote attacker because the attacker must interact with the card’s secure element to test candidates
Tamper-resistance: the secure element’s design (tamper protection, firmware verification chain) prevents an attacker from simply replacing firmware or increasing clock rate to speed up verification  Any attempt at physical tampering or invasive modification is expensive, detectable, and out-of-scope for casual attackers
Practical infeasibility: given the above, a brute-force attack requires astronomical time and resources — effectively impossible in practice

What about a 12 digit numerical PUK only ?

12-digit numeric PUK (000000000000–999999999999) = 10 possibilities per digit – 1,000,000,000,000 possibilities

At 60 ms/try → 1,903 years to exhaust the space.

So, length + alphabet size + randomness all multiply to the total work for an attacker. Small drops in any of those dramatically reduce attacker work. We do NOT advise using a PUK with numbers only, as it significantly reduces the security

4. Why chip speed can't be trivially changed?

The 60 ms/try baseline is not an arbitrary UI delay — it arises from the secure element’s internal processing (APDU handling, crypto operations, signature checks, secure memory accesses) and NFC/transport latency
Secure elements are black-box hardware with signed, verified firmware and tamper protection. To change the per-try rate an attacker would need to:  (a) modify the secure element firmware (blocked by signature checks), or  (b) physically alter the chip to run faster (requires invasive tampering, destructive, and detectible)  Both are outside plausible threat vectors for typical attackers and carry high cost and risk
Therefore the practical attacker model must accept the enforced per-try timing

5. What to consider for better PUK security

Important caveats and what reduces security; 

Non-random or guessable PUKs (dictionary words, birthdays, reused tokens): these massively reduce effective entropy Attackers will try common patterns first — if users pick weak PUKs, the effective search space collapses to the subset of common values
Reuse across systems: if a user reuses a PUK elsewhere and that other system leaks it, security is lost.
Automated testing via physical access: unlimited tries means an attacker with continuous physical access could attempt guesses  The defense remains the keyspace size and the card’s enforced per-try time, but physical access makes attacks more feasible if the PUK is weak