Card ↔ Reader ↔ SAM — the mutual-authentication architecture.
A reference walkthrough of the trust chain that powers every well-architected closed-loop deployment we have shipped: the card holds the credential, the SAM holds the issuer key, the reader is a router. Everything below is conceptual — we educate engineers on architecture, not on attack tooling.
1. The four trust zones
Every reasoning step in the rest of this page comes back to one diagram: the four trust zones, what each holds, and what crosses each boundary.
2. Key hierarchy
Everything below the master key is derived. No two cards share a working key; no two SAMs share a session key. Compromise is contained.
3. Mutual authentication — with a SAM
The reader is a state machine that pumps APDUs between two parties that know the same key (the SAM and the card). The reader never sees the key. Crypto operations happen inside the card on one side and inside the SAM on the other; the reader stitches the two halves together.
4. Same flow — without a SAM
For comparison, the no-SAM variant. K_card has to live somewhere; if there is no SAM, it lives in reader firmware. One field-stolen reader becomes a system-wide leak. Acceptable for development benches and small-scale closed-system pilots; not acceptable for transit, payments, or any deployment with more than a handful of readers.
5. The offline transaction lifecycle
Most of the world’s transit gates are not online when you tap. They authorise locally against information cached at the validator and reconcile in batches when network is available. The lifecycle below is the reference shape we ship.
6. Three validator form factors
The same trust chain runs on three very different physical platforms. Each adds operational constraints; the architecture survives them all.
Gate / turnstile validator
Mains-powered, wired or Wi-Fi backhaul, ~300 ms tap-to-decision budget. Highest throughput. Often dual-redundant SAMs for 24×7 operation.
Bus / on-vehicle validator
Battery-buffered, intermittent cellular backhaul, vibration / temperature stress. Depot sync at start of shift; uploads at end of shift.
Handheld inspector
Battery-only, field inspection. Read-only relative to the card; signed inspection records buffered locally, uploaded on shift return.
All three carry a SAM. All three implement the same Card↔Reader↔SAM flow. The only thing that differs is the cadence of depot sync and upload; the field operation is identical.
7. Threats this architecture neutralises
| Threat | What stops it |
|---|---|
| Stolen / tampered validator | No working key on the reader CPU. Replacing the SAM resets exposure to a single device. |
| Cloned card | Diversified per-card key. Cloning one card does not reveal any other. Card-side counters detect duplication on collision in the depot reconciliation. |
| Replayed transaction | Per-tap session keys + transaction MAC + monotonic counter. Captured cryptograms expire. |
| Reader firmware downgrade | SAM enforces firmware-version attestation on host secure-channel open. |
| Backend compromise | Issuer master key lives in HSM, not in backend application memory. Settlement is signature-verified, not trusted-by-source. |
No architecture neutralises every threat. This one neutralises the threats with the worst consequences for an issuer at scale — the ones where one bad day puts the entire deployment in jeopardy.
Designing a closed-loop deployment?
From SAM personalisation through validator firmware to back-office settlement, we ship the chain.