Sub-300 ms validators, offline trust, and a backend that can be down.

A metropolitan transit operator rolling out closed-loop DESFire EV2 ticketing across 700+ validator gates and onboard buses, with a hard requirement that fare collection continue uninterrupted during backend outages of up to several hours.

The challenge

The operator was replacing a previous generation of magnetic-stripe tickets with contactless smart cards. The procurement brief was specific:

• Sub-300 ms tap-and-go. Anything slower and the gate becomes the morning-rush bottleneck.
• Offline trust. If the central server is unreachable, fare validation must continue using only what the validator and the card know between themselves.
• Auditable revenue. Every tap, online or offline, must be reconcilable against a single source of truth once connectivity returns.
• Resistance to cloning and replay. A successful clone of a single card cannot become a long-lived attack against the system.

The previous generation had been compromised by a card-cloning attack a decade earlier. The procurement team wanted hardware-rooted trust this time, not a software whitelist.

Architecture overview

The deployment is a textbook SAM-backed DESFire architecture, sized for a real metropolitan fleet:

The design points the operator cared about:

1. The validator can’t leak the master key because the validator never has it — the SAM does.
2. The card can’t be cloned in a way that produces working fare value because the SAM-derived per-card key is required to spend the purse, and a cloned card’s UID would either collide with the original (rejected) or be unrecognised by the SAM (also rejected).
3. The backend can be unreachable and the validator still does the right thing.

Standards involved

• ISO/IEC 14443 Type A — contactless interface.
• ISO/IEC 7816-4 — APDU command structure.
• NXP MIFARE DESFire EV2 — the card platform. (See DESFire EV1 vs EV2 vs EV3.)
• AV2 SAM — the secure access module class. (See Technology: SAM.)
• EN 1545 — transit fare-product data model, optional but referenced.

Deployment constraints

• Validator BoM. Each validator is mechanical hardware in the field, so the SAM has to be embedded at manufacture time and replaceable in field-service windows only.
• Key custody. Master keys are generated in an HSM at the operator’s data centre, loaded into SAMs at the personalisation line under M-of-N control, and never leave that boundary in cleartext.
• Tap throughput. A morning-rush gate cycle is roughly 30–40 taps per minute per validator. Anything that adds more than ~50 ms to the tap budget is unacceptable.
• Card population. The deployment is sized for millions of cards in circulation. Per-card key derivation has to scale.

Trust model

The threats the architecture addresses, in order of priority:

Implementation approach

Delivery was three tracks:

1. Card programme. Master keys generated, SAMs personalised, blank DESFire EV2 stock issued under operator artwork. Per-card AES-128 keys diversified using UID + master-key derivation.
2. Validator firmware. Reader-side application implementing the EV2 mutual-auth + spend flow. Local tap journal with monotonic sequence + SAM-MAC.
3. Backend reconciliation. Tap-journal ingestion service, hot-list management, revenue-side ledger reconciliation against the SAM-signed tap stream.

A single tap, instrumented

// Validator-side tap flow (simplified)
1. RF: ISO/IEC 14443-3 anticollision  -> UID
2. SELECT DESFire application AID
3. APDU: AuthenticateAES <keyno>        -> SAM derives per-card key from UID
4. SAM:  Authenticate with derived key   -> mutual session keys + IV
5. Read purse value file (encrypted, MAC'd)
6. SAM:  Authorise debit (offline policy + revocation hotlist)
7. APDU: Debit purse, commit, MAC
8. Local tap journal: append (UID, ts, debit, seq++, SAM-MAC)
9. Gate opens.

Budget (50% percentile): ~190 ms reader-to-gate.
Worst case (cold SAM session): ~260 ms.

The cold-SAM session is the worst case in practice. Once the SAM has cached the derived key for a brief window, subsequent taps from the same card are inside 150 ms. The window is short enough that a stolen card whose user has been added to the hot-list still gets caught.

Operational considerations

• Hot-list size. A hot-list of every lost/cloned card grows monotonically. The customer chose a tiered approach: full hotlist on backend, short-window hot-deny list on validators, plus the SAM-side authentication check which catches any cloned card regardless of hot-list membership.
• SAM replacement. A failed SAM in the field is a service ticket, not an outage. The validator falls back to a deny-by-default policy until the SAM is replaced.
• Key rotation. The master key never rotates in the field. A future card generation will roll to a new master under a planned multi-year migration. The architecture supports running two SAM keysets simultaneously during a transition.
• Audit trail. Every tap, online or offline, generates a SAM-signed tap-journal entry. Revenue audits reconcile against this stream rather than against the central server’s view of "what taps did we see".

Integration flow

The validator’s view of the world:

1. Card presented. Anticollision returns a UID.
2. SAM consulted. The validator asks the SAM "what is the per-card key for this UID?" The SAM derives it from the master and a key-derivation function.
3. Mutual auth. Standard DESFire AES-128 mutual auth between the validator and the card, using the SAM-derived per-card key. If anything fails, the gate stays closed.
4. Spend. Encrypted, MAC’d debit of the purse value file.
5. Journal. Append-only local journal, every entry MAC’d by the SAM. The validator’s own MCU has no way to forge journal entries.
6. Sync. When connectivity returns, the journal is uploaded; the backend verifies SAM MACs; revenue reconciliation proceeds.

Lessons learned

1. The SAM is the architecture, not an accessory. Once you understand that the master key never leaves the SAM and that the validator is fundamentally a SAM-and-radio sandwich, the whole system makes more sense. The validator firmware is the thinnest layer of the trust stack.
2. Offline policy is more important than online policy. Backends fail. SAMs don’t. The architecture has to do the right thing when the backend is unreachable, because that’s when it will be attacked.
3. SAM-MAC’d journals are worth their weight in audit. A revenue auditor with a SAM-signed tap journal has fewer questions than one with a backend log.
4. Hot-list strategy needs three tiers, not one. Real-time deny on validators is brittle. Periodic deny lists are too slow. The SAM-derived per-card authentication is the only one that actually catches cloned cards. Use all three.

Related products and services

• Closed-loop ticketing solution
• Technology: DESFire EV2/EV3
• Technology: SAM
• Transit ticketing overview
• Offline authentication architecture

Related references & reading

• DESFire EV1 vs EV2 vs EV3
• Why SAMs Matter in Closed-Loop Transit
• Designing Low-Latency Secure Transit Validators
• APDU From First Principles
• Reference: card ↔ reader ↔ SAM flow
• Tool: APDU Parser
• Tool: ATR Parser