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, station gates and gantries. 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 | |
|---|---|---|
| Algorithms | MIFARE Crypto1, TDEA, AES, RSA | MIFARE Crypto1, DES, TDEA (112 / 168-bit), AES-128 / 192 / 256, RSA up to 2048-bit, ECC up to 256-bit |
| Key storage | 128 symmetric key entries, 3 RSA key entries; key usage counters | 128 symmetric, 3 RSA, 8 ECC public-key entries, 48 EMV CA public keys; fine-grained key access control |
| Key diversification | TDEA- and AES-based diversification of per-card keys | Same, plus generic CMAC-based key derivation; Programmable Logic can run a project-specific diversification inside the SAM |
| Host ↔ SAM protection | 3-pass symmetric authentication for confidentiality and integrity; RSA-based protection for key updates from the back end | Same, with AES-256 available for SAM-host protection |
| Reader integration | ISO/IEC 7816-3 T=1 up to 1.5 Mbit/s, up to four logical channels; X-mode variants for RC52x (T1AD2060) and RC663 (T1AR1070) reader ICs | Same contact interface and four logical channels; X-mode with RC663, RC52x and PN512; optional I²C target interface (HVQFN package only) |
| Cards it can authenticate | MIFARE Classic 1K / 4K, Ultralight, Ultralight C, Plus, DESFire, DESFire EV1 | Adds DESFire EV2 / EV3 / Light, MIFARE Plus EV1 / EV2 (incl. Transaction MAC and EV2 secure messaging), LRP, NTAG / ICODE / UCODE DNA |
X-mode is not a security mode: it means the SAM is wired to the host microcontroller and the contactless reader IC at the same time, which NXP positions as the faster way to connect reader and SAM. The practical AV2-or-AV3 question is the card estate: DESFire EV2 / EV3 features such as Transaction MAC and EV2 secure messaging, and LRP, need AV3; a fleet that only reads DESFire EV1 can stay on AV2 until the validators are refreshed. Source: NXP product short data sheets P5DF081 (MIFARE SAM AV2, Rev. 3.3, 13 September 2023) and MF4SAM3X (MIFARE SAM AV3, Rev. 3.2, 5 March 2024).
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 and every key injection is logged against the SAM’s identity.
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, then open a protected host channel to the SAM (3-pass mutual authentication; fresh session keys for each session).
- 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 protected (MAC or signature) with keys that stay in 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?
One deployment’s architecture — AV2 SAMs, DESFire EV2 cards, offline validation — is written up in the closed-loop transit case study. Tell us your card family and validator platform.