Secure Access Modules — the issuer’s key custodian.
A SAM is a tamper-resistant smart-card-class module mounted inside a reader. It holds the issuer’s long-term keys, performs cryptographic operations on behalf of the reader, and never exposes the keys to the host. In well-architected closed-loop deployments, the validator firmware can be reflashed by a thief without leaking a single transit key.
Why a SAM at all?
The threat model behind transit ticketing is unusual. There are millions of cards in the field, tens of thousands of validators, and tens of thousands of devices that can be physically removed from buses, gates, and gentry stations. If a single validator’s firmware leaks the issuer key, every card on the system is compromised — instantly.
The fix is to move issuer keys out of validator firmware entirely. The reader becomes a routing layer: it sees APDUs flow between the card and the SAM, but it does not learn the keys. A SAM is the secure element that lives inside the reader; it can be NXP MIFARE SAM AV2 / AV3 family, a HID iCLASS SAM-class component, or an internally-developed SAM-class secure element. They all share the same architectural commitment: keys never appear on the reader CPU.
Trust zones
Capabilities
| SAM AV2 | SAM AV3 | |
|---|---|---|
| Crypto suites | 3DES · 3K3DES · AES-128 | + AES-192 / 256 (in some profiles), hardened side-channel |
| Key diversification | Built-in: KDF over UID for per-card keys | Same; faster derivation; SP800-108-style options |
| Secure host channel | Encrypted/authenticated channel from reader CPU to SAM (X-mode / Y-mode) | Same shape, refined session profile |
| Offline counters | Internal monotonic counters (anti-replay, anti-rollback) | + broader counter pool |
| Audit / unlock | Issuer-signed unlock, master-key rotation, log readout | + richer audit trail |
In practice the choice between AV2 and AV3 is driven by your validator estate and your back-office tooling. New validators — AV3. Existing fleets — AV2 with planned cycle to AV3 as estates refresh.
Core principles
Keys never leave the SAM
The reader CPU sees ciphertext, never plaintext keys. A compromised reader leaks transactions, not the system.
Diversification per card
K_card[i] = KDF(K_app, UID_i). Cracking one card does not give you any other card.
Bounded validity
Session keys are per-tap; offline counters bound how long a captured cryptogram remains useful.
Mutual authentication
Reader and SAM authenticate to each other before any application crypto. Same for SAM and card.
Auditable provisioning
Every SAM is personalised on a controlled line; key injection is logged; unlock requires issuer signature.
Replaceable
SAM modules are field-replaceable units (FRUs). Compromise of one validator means swapping the SAM, not pulling a fleet.
What the reader actually does
- Boot, initialise itself; does not trust its own configuration without a SAM-attested boot record.
- Open a secure host channel to the SAM (mutual auth, session keys derived from a per-boot challenge).
- Wait for a card. On tap, run the card-side authentication via the SAM — the reader forwards APDUs, the SAM does crypto.
- Receive the authorisation result from the SAM. Open the gate / debit the value file / log the trip.
- Periodically pull blacklist updates and push transaction batches to the back office, both signed by the SAM.
Every step where keys would otherwise touch the reader CPU is delegated to the SAM. The reader becomes a high-throughput router with a state machine. This is what makes the architecture safe to deploy on cheap, unattended hardware.
Designing a SAM-protected reader?
From SAM personalisation lines to validator firmware to back-office settlement — we have shipped the full chain.