Research brief: Why Random Numbers Matter in Payments

Executive summary

Random numbers are not a minor cryptographic detail in payments. They are part of what makes a transaction fresh, non-replayable, and resistant to pre-computation. In EMV, the terminal generates an Unpredictable Number, commonly EMV tag 9F37, which is used to add variability and uniqueness to the application cryptogram generated by the card.

The security lesson is simple: a payment cryptogram is only as fresh as the challenge that helped create it. If the terminal’s “random” value is predictable, repeated, counter-based, or attacker-controlled, an attacker may be able to prepare valid-looking transaction data in advance. This is the core idea behind the EMV pre-play attack, demonstrated by Cambridge researchers, who found that some ATMs and terminals used weak unpredictable numbers such as counters, timestamps, or home-grown algorithms.

For POS, SmartPOS, SoftPOS, MPoC, CPoC, PIN processing, and HSM-backed acquiring systems, randomness matters in several places: EMV transaction freshness, cryptographic key generation, session keys, DUKPT/IPEK-related material, nonce generation, attestation protocols, secure channels, white-box cryptography, and tokenization flows. PCI PIN and PCI PTS requirements explicitly treat random number generation as security-critical; PCI PTS states that devices generating random numbers for sensitive-data security must be assessed to ensure the numbers are sufficiently unpredictable.

The professional takeaway: do not treat RNG as plumbing. In payments, randomness is part of the trust boundary.

⸻

Key concepts

1.1 Random number vs unpredictable number

In payment systems, “random” usually means unpredictable to an attacker, not merely statistically varied. A counter, timestamp, transaction sequence number, or pseudo-random value seeded badly may look different every time, but still be predictable.

In EMV, the term is deliberately Unpredictable Number, not simply “random number.” EMV tag 9F37 is terminal-generated and provides variability and uniqueness in cryptogram generation.

Confirmed fact: EMV 9F37 is a terminal-originated value used to provide variability and uniqueness to cryptogram generation. Interpretation: The name “Unpredictable Number” reflects the real security requirement: attackers must not be able to predict or force it.

⸻

1.2 Nonce

A nonce is a value used once. In payment protocols, a nonce prevents a valid transaction response from being reused later. The EMV unpredictable number acts like a nonce in the transaction authentication flow.

A nonce does not always need to be secret, but it must satisfy the protocol’s freshness requirement. In EMV, the problem arises when a terminal-generated nonce becomes predictable, repeated, or attacker-controlled.

⸻

1.3 Entropy

Entropy is the uncertainty available to an attacker. A 32-bit value can theoretically represent many possibilities, but if the implementation uses a timestamp, counter, fixed seed, or low-entropy source, the practical entropy may be much lower.

Example: A four-byte unpredictable number looks like it has 32 bits of space. But if half the bits are fixed and the rest behave like a timer or counter, the real attack space is much smaller.

Cambridge researchers observed cases where an ATM’s unpredictable number appeared to contain a fixed portion and a counter-like portion.

⸻

1.4 TRNG, PRNG, CSPRNG, DRBG

A TRNG derives randomness from physical processes such as noise, jitter, or hardware entropy. A PRNG produces deterministic output from a seed. A CSPRNG or DRBG is a cryptographically secure deterministic generator designed so that its output remains unpredictable when seeded correctly.

NIST SP 800-90A specifies deterministic random bit generator mechanisms based on hash functions and block ciphers.

Confirmed fact: Deterministic generators are acceptable in cryptographic systems when properly designed, seeded, instantiated, and reseeded. Interpretation: The main risk is not that software-based randomness exists; the risk is poor seeding, poor implementation, lack of health checks, or misuse in security-critical paths.

⸻

Where random numbers appear in payment systems

2.1 EMV transaction cryptograms

In EMV, the card generates cryptograms such as ARQC, TC, or AAC. The terminal-supplied unpredictable number contributes to transaction uniqueness. EMV tools and references describe ARQC generation as involving transaction data and cryptographic inputs, while EMV tag references identify 9F37 as the terminal value used to provide cryptogram variability.

Practical meaning: Two payments with the same card and amount should not produce reusable authentication material. The unpredictable number helps ensure that each transaction is fresh.

⸻

2.2 Contactless payments

Contactless EMV flows also depend on unpredictable values and dynamic cryptographic data. In some contactless modes, values such as unpredictable numbers and cryptographic checksums help prevent static magnetic-stripe-style replay.

Interpretation: Contactless makes RNG quality even more operationally important because the interaction is fast, user-visible friction is low, and the terminal/card exchange must complete within strict timing constraints.

⸻

2.3 PIN security and key generation

PCI PIN Security Requirements require controlled cryptographic key generation, often inside approved HSMs or secure cryptographic devices. PCI PIN documentation emphasizes that random number generation is critical to cryptographic systems and key generation.

Practical meaning: Weak randomness in key generation is catastrophic. Unlike a single failed transaction, a weak key can compromise many transactions.

⸻

2.4 POI / PED / terminal security

PCI PTS POI requirements state that when random numbers are generated by a payment device in connection with sensitive-data security, the RNG must be assessed to ensure it produces sufficiently unpredictable numbers.

This matters for classic payment terminals, unattended terminals, PIN entry devices, SmartPOS devices, and secure payment components inside broader Android-based architectures.

⸻

2.5 CPoC / MPoC / SoftPOS

For mobile acceptance on commercial off-the-shelf devices, randomness is harder because the payment application runs in a hostile or semi-hostile consumer-device environment. PCI CPoC documentation discusses deterministic RNG use, external seeding, and reseeding requirements for CPoC applications.

Interpretation: SoftPOS and MPoC solutions should not blindly trust app-layer randomness for payment-critical cryptography. Randomness should be generated or mediated through certified SDK components, secure services, attestation-backed flows, HSMs, secure enclaves, or approved cryptographic modules, depending on architecture.

⸻

Current state of the topic

3.1 The standards recognize RNG as security-critical

The payment industry already treats randomness as a formal security requirement. PCI PIN, PCI PTS, CPoC, and cryptographic standards such as NIST SP 800-90A all address random number generation in different ways.

Confirmed fact: RNG quality is part of certification and security evaluation in payment devices and cryptographic systems. Interpretation: RNG should be reviewed as part of terminal architecture, kernel integration, SDK integration, and operational monitoring, not only during lab certification.

⸻

3.2 EMV has a known historical weakness around weak unpredictable numbers

The best-known example is the pre-play attack. Bond, Choudary, Murdoch, Skorobogatov, and Anderson showed that some EMV terminals and ATMs used weak unpredictable numbers, enabling criminals to pre-compute transaction authentication data for later use.

Their finding was not that EMV cryptography itself was trivially broken. The point was more subtle: a strong cryptographic protocol can fail if one supposedly unpredictable input is implemented badly.

⸻

3.3 Formal analysis has continued to find edge cases in EMV

Later academic work has used formal methods to analyze EMV and identify protocol-level weaknesses. Basin, Sasse, and Toro-Pozo modeled EMV in Tamarin and reported flaws affecting Visa contactless and offline transaction behavior.

Interpretation: Randomness is one part of EMV security, but not the whole story. Even good randomness cannot compensate for protocol binding gaps, weak terminal validation, poor kernel configuration, or missing issuer/terminal-side checks.

⸻

Main benefits of strong randomness

4.1 Transaction freshness

Strong unpredictable numbers make every transaction cryptographically fresh. This reduces the value of captured EMV data because the attacker cannot simply replay a previous transaction.

4.2 Resistance to pre-computation

If the terminal challenge is unpredictable, an attacker cannot easily prepare valid cryptographic responses ahead of time.

4.3 Stronger key material

Good entropy is essential for cryptographic keys. HSMs, secure POI devices, and certified modules exist partly to protect the generation and lifecycle of these keys. PCI PIN requirements place strong controls around cryptographic key generation.

4.4 Better protocol binding

Random challenges help bind a transaction to a specific moment, terminal interaction, and cryptographic exchange.

4.5 Reduced fraud ambiguity

Weak randomness can create fraud cases that look like legitimate card-present transactions in logs. The Cambridge pre-play work emphasized that such attacks can appear indistinguishable from card cloning from the issuer’s log perspective.

⸻

Risks and limitations

5.1 Weak RNG can break otherwise strong cryptography

A payment terminal can use approved algorithms and still be vulnerable if the unpredictable number is predictable. The pre-play research specifically found implementations using counters, timestamps, or home-grown algorithms.

5.2 Statistical randomness is not enough

Passing a basic randomness test does not automatically mean the output is secure against prediction. A generator can look statistically balanced while still being predictable if the attacker knows the seed or algorithm.

NIST SP 800-90A focuses on approved DRBG mechanisms, but secure use also depends on entropy input, instantiation, reseeding, and implementation discipline.

5.3 Four bytes is a small field

EMV tag 9F37 is commonly four bytes. That does not mean EMV is automatically insecure, because the unpredictable number is only one input into a broader cryptographic protocol. But it does mean implementation quality matters: if a 32-bit field is further weakened by predictability, counters, repetition, or bad seeding, the margin shrinks quickly.

5.4 Mobile environments are harder

SoftPOS and MPoC run on general-purpose smartphones or tablets, not dedicated PED hardware. This makes threat modeling more complex: malware, hooking, rooting, poor entropy at startup, cloned app state, insecure local storage, and compromised OS services can all affect cryptographic assumptions.

5.5 RNG failures are difficult to detect after the fact

A bad unpredictable number may not cause obvious transaction failures. Transactions may still approve. The problem may only appear later as replay-like fraud, strange issuer disputes, or unexplained duplicate-looking authentication patterns.

⸻

Practical examples

Example 1: EMV ARQC freshness

A customer taps or inserts a card. The terminal generates an unpredictable number, includes it in the data sent to the card, and the card generates an ARQC for online authorization.

Good case: The unpredictable number is fresh and attacker-unpredictable. Captured ARQC data is not reusable.

Bad case: The terminal uses a counter or predictable timestamp. An attacker with temporary access to the card can prepare data for a future transaction where the terminal’s value is predictable.

This is the core idea behind the EMV pre-play attack.

⸻

Example 2: SoftPOS transaction flow

In a SoftPOS architecture, the merchant app should not generate payment-critical EMV randomness itself unless the certified payment component explicitly requires and validates that design. The EMV kernel / certified SDK should own the sensitive transaction cryptographic flow.

Professional interpretation: For MPoC/CPoC designs, randomness belongs inside the certified security boundary as much as possible: SDK, kernel, attestation-protected component, HSM, or approved cryptographic module.

⸻

Example 3: HSM key generation

An acquirer or processor generates PIN keys, MAC keys, or transport keys inside an approved HSM. If the random source is weak, the keys may be guessable or have reduced entropy.

Result: This is not a single-transaction problem. It can become a systemic compromise affecting many merchants, terminals, or transactions.

PCI PIN requirements therefore tightly constrain key generation and approved devices.

⸻

Example 4: Bad startup entropy

A terminal or mobile payment app starts immediately after boot and initializes a PRNG before enough entropy is available.

Risk: Multiple devices may generate similar sequences, especially if seeded with low-quality values like system time, device ID, or predictable counters.

Mitigation: Use OS-provided cryptographic randomness, certified SDK/HSM randomness, hardware entropy where available, and reseeding/health checks aligned with standards such as NIST SP 800-90A and relevant PCI requirements.

⸻

Opposing viewpoints and open debates

Viewpoint A: “The EMV unpredictable number is only 4 bytes, so randomness cannot be that important.”

This view is incomplete. The unpredictable number is not the only security input in EMV, but it is an important freshness input. A predictable 9F37 value can enable practical attacks when combined with protocol and implementation weaknesses, as shown by the pre-play research.

Viewpoint B: “Certification already covers this, so professionals do not need to worry.”

Certification helps, but the historical evidence shows that certified or widely deployed systems can still contain weak implementations. The Cambridge work explicitly criticized shortcomings in specification, certification, implementation testing, and monitoring of complaints.

Viewpoint C: “Use a TRNG and the problem is solved.”

Not necessarily. A TRNG can fail, be biased, blocked, poorly conditioned, or misused. A DRBG can be secure if properly seeded and managed. The real requirement is an end-to-end random subsystem: entropy source, conditioning, DRBG design, reseeding, health tests, access control, and correct protocol use.

Viewpoint D: “Randomness is a cryptography team problem, not a POS engineering problem.”

In payments, POS engineers make decisions that affect randomness indirectly: terminal kernel choice, SDK integration, app lifecycle, startup behavior, offline behavior, device attestation, secure-channel design, logging, and test strategy. Randomness failures often emerge at the boundary between cryptography and product engineering.

⸻

What matters most for professionals

For POS / SmartPOS engineers

Ensure the EMV kernel or certified payment SDK owns generation of EMV unpredictable numbers. Do not replace certified randomness with app-generated timestamps, counters, UUIDs, or custom PRNGs.

For SoftPOS / MPoC architects

Treat randomness as part of the security boundary. The payment app should not be able to tamper with EMV freshness values, PIN-related cryptographic values, or attestation challenges.

For acquirers and processors

Monitor for suspicious patterns in unpredictable numbers, ARQC data, ATC sequences, repeated terminal behavior, and terminal fleets with abnormal cryptographic patterns.

For QA and certification teams

Test more than “transaction approved.” Include RNG behavior, repetition, startup conditions, offline/online transitions, device reboot, low-entropy boot states, and fleet-wide duplicate patterns.

For product and compliance teams

Document who owns randomness in the architecture: terminal, kernel, SDK, HSM, backend, mobile OS, secure enclave, or third-party provider. Ambiguity here is dangerous.

⸻

Article / LinkedIn angle

A strong Corebaseit-style thesis could be:

In payments, a random number is not just a number. It is the difference between a transaction that is fresh and one that may be replayed, pre-computed, or disputed.