PUK Security

Internal Mechanics Technical Explanation

1. Why Cryptnox PUK Mechanics 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

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
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
Time to exhaustively test the whole keyspace = (6.83167545324743×10²¹) × 0.06 s = 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

Comparison between Cryptnox PUK and others 

6-digit numeric PUK (000000–999999): 10⁶ possibilities.

At 60 ms/try → 10⁶ × 0.06 s = 60,000 s ≈ 16.7 hours to exhaust the space.

 Conclusion: a short numeric PUK is trivially brute-forcible in under a day if an attacker can continuously test guesses. This is why short numeric PUKs are unacceptable.

8-character alphanumeric (≈62 chars): 62⁸ ≈ 2.18×10¹⁴ possibilities.

At 0.06 s/try → ~1.31×10¹³ s ≈ 415,000 years. Still large, but far smaller than our 12-character / 66-alphabet base case.

So, length + alphabet size + randomness all multiply to the total work for an attacker. Small drops in any of those dramatically reduce attacker wor

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