SECURE MODULES<\/p>\n
A transport reader is physically exposed and operationally distributed. It may be installed in a gate, validator, vehicle or sales device, far from the systems that manage keys and accounts. It needs to authenticate cards and complete transactions quickly, but it should not become a portable copy of the system\u2019s most powerful secrets.<\/p>\n
A secure access module, or SAM, introduces a smaller cryptographic boundary beside that reader. Keys can remain inside the module while the host requests authentication, diversification, secure messaging or transaction-related operations.<\/p>\n
That is a meaningful architectural improvement. It is not a complete security model.<\/p>\n
Work with programmable SAM applications, reader firmware and later-generation modules such as NXP\u2019s MIFARE SAM AV3 illustrates the real design task: decide exactly which authority moves into the module, which decisions remain in the host and what an attacker controlling the reader can still ask the module to do.<\/p>\n
The simplest SAM story is that the key is not stored in reader firmware. A compromised host cannot read the raw master key from a configuration file or binary.<\/p>\n
But non-exportability alone may leave the host with an unrestricted cryptographic oracle. If any process can ask the SAM to authenticate any card, derive keys for any identifier or calculate arbitrary MACs, control of the reader may still provide most of the useful authority associated with the key.<\/p>\n
A stronger design constrains use as well as export. Key entries carry type, version and permitted operations. Host authentication can limit which external application opens a sensitive session. Application logic can bind several low-level operations into one narrower business command.<\/p>\n
The relevant question is therefore not only \u201cCan the key be extracted?\u201d It is also \u201cWhat can a compromised host accomplish without extracting it?\u201d<\/p>\n
A contactless transaction crosses several components: card, RF front end, reader processor, SAM and back office. Each boundary affects what can be observed or altered.<\/p>\n
In one model, the host relays card messages to the SAM and receives the cryptographic output needed for the next step. This provides flexibility but exposes more protocol state to host software.<\/p>\n
In another, supported by configurations such as the MIFARE SAM AV3 X interface, the SAM communicates more directly with a compatible RF front end. That can reduce host mediation and improve transaction performance. It also changes diagnostics, firmware responsibilities and the exact messages protected on each link.<\/p>\n
Neither topology should be selected by a diagram alone. The design needs to trace:<\/p>\n
Otherwise the system may protect the card channel while leaving the host free to substitute the amount, account reference or transaction meaning around it.<\/p>\n
Using one identical card key across a population makes every reader interaction simple and every key compromise systemic. Key diversification derives per-card or per-application keys from protected master material and defined diversification inputs.<\/p>\n
A SAM is a natural place to hold the master and perform the derivation. The per-card result may remain inside the module or exist only as session material needed for the transaction.<\/p>\n
The derivation scheme must be stable and versioned. Card identifiers, application identifiers and other inputs need unambiguous encoding. Changing their representation can make legitimately issued cards unreachable. Reusing the same master and input structure across purposes can cause keys intended for different roles to collide conceptually even when the primitive remains secure.<\/p>\n
Diversification is therefore both cryptographic and operational. It needs test vectors, key-version rules, issuance coordination and a path for moving to a new master without requiring every component to guess which derivation was used.<\/p>\n
Some secure modules allow proprietary logic or applets to execute inside the boundary. MIFARE SAM AV3, for example, offers optional programmable logic that can reuse intrinsic cryptographic functions and combine a business flow behind a smaller number of external calls.<\/p>\n
This can improve more than performance. A custom function can validate inputs, select internal keys and return only a bounded result. The host no longer needs access to every primitive step.<\/p>\n
It also introduces software lifecycle inside the secure boundary. The applet or logic requires secure loading, version control, testing, rollback policy and an allocation of privileges. A defect inside the module may be harder to diagnose and update than a reader-firmware defect.<\/p>\n
Programmability should be used to reduce exposed authority or preserve a genuinely proprietary protocol\u2014not simply to move ordinary application code into a more expensive processor.<\/p>\n
It is also important not to confuse distinct implementations. A Java Card applet on a programmable secure module and a product-specific SAM function may solve related problems through different platforms, APIs and assurance models. The public description should preserve that distinction.<\/p>\n
If commands and responses between host and SAM are unauthenticated, an attacker with access to the reader bus may observe, replay or modify them. Sensitive keys may remain internal while the use of those keys is manipulated externally.<\/p>\n
SAM products can support an authenticated protected channel with the host. Deploying it requires host credentials, session establishment, sequence handling and recovery from interrupted sessions. The channel protects communication; it does not make compromised host logic honest.<\/p>\n
The module still needs to reject commands that exceed the host\u2019s role. A maintenance device, production reader and personalisation station should not automatically share identical access to all key entries and management functions.<\/p>\n
Separation by key entry, host credential and permitted command provides defence when one class of device is lost or compromised.<\/p>\n
SAM preparation is part of the production key ceremony, not a routine device configuration task. The module receives key entries, identifiers, permissions, host-authentication material and lifecycle settings that may later be difficult or impossible to change casually.<\/p>\n
A credible process separates development, test and production material. It authenticates management operations, records versions without exposing secret values and verifies the resulting configuration through safe test operations. Spare and replacement modules need the same controlled path.<\/p>\n
Fleet management must answer practical questions:<\/p>\n
Secure silicon does not remove these responsibilities. It makes them more explicit.<\/p>\n
Fare collection imposes short interaction times. Additional APDUs between host and SAM, communication with the contactless card and protected-channel overhead all contribute to latency.<\/p>\n
Optimisation cannot mean skipping authentication or reusing session state beyond its intended scope. Instead, the transaction should minimise redundant boundary crossings, use the module\u2019s supported combined operations where appropriate and benchmark the complete path on production hardware.<\/p>\n
Timeouts need safe semantics. If the card is removed or the host resets after a protected write, the reader must determine whether the transaction committed before retrying. Otherwise a performance problem becomes a double-debit or inconsistent-state problem.<\/p>\n
The fastest primitive is irrelevant if the distributed transaction around it cannot recover correctly.<\/p>\n
Reader firmware decides when the SAM is invoked, how responses are interpreted and which errors become acceptance or rejection. It also transports the resulting event toward the back office.<\/p>\n
Integration testing needs more than cryptographic success vectors. It should include wrong key versions, invalid card responses, interrupted secure messaging, stale host sessions, module replacement, communication corruption and unexpected card types. Failure paths should default to a defined limited state rather than silently falling back to weaker processing.<\/p>\n
Firmware from a reader manufacturer can be an important part of this work. The technically meaningful public account is not a logo list but a bounded description of the integration: which protocol boundary was implemented, what interoperability problem was solved and how responsibilities were divided. Any partner or manufacturer should be named only after the factual scope and permission are confirmed.<\/p>\n
A well-integrated SAM changes four important properties:<\/p>\n
It does not prove that the surrounding transaction is correct, prevent a malicious host from abusing every permitted operation, solve back-office key governance or compensate for unsafe personalisation.<\/p>\n
The security boundary is smaller, which makes it easier to defend. The system boundary remains large.<\/p>\n
Secure modules are most valuable when they change the authority exposed to the reader\u2014not merely the location of key bytes.<\/p>\n
That requires a narrow interface, per-purpose permissions, protected lifecycle and reader firmware that treats every transition and failure explicitly. Programmable logic can push a coherent protocol step inside the boundary; standard SAM functions can provide interoperable card operations and key management. Both depend on the design around them.<\/p>\n
Putting the trust boundary beside the reader is a strong architectural move. The engineering work is deciding what is allowed to cross it.<\/p>\n
This note draws on engineering involving programmable SAM applications, contactless-card systems, NXP MIFARE SAM AV3 and reader-firmware integration. It deliberately avoids production keys, internal command definitions, transport-operator details and unconfirmed partner attribution.<\/p>\n
A SAM can keep master keys out of reader firmware and perform card protocols locally. The security result still depends on permissions, host integration and lifecycle.<\/p>\n","protected":false},"author":2,"featured_media":271,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[11],"tags":[],"nlabs_article_type":[],"class_list":["post-214","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-in-practice"],"_links":{"self":[{"href":"https:\/\/neodata.com.uy\/labs\/wp-json\/wp\/v2\/posts\/214","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/neodata.com.uy\/labs\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/neodata.com.uy\/labs\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/neodata.com.uy\/labs\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/neodata.com.uy\/labs\/wp-json\/wp\/v2\/comments?post=214"}],"version-history":[{"count":2,"href":"https:\/\/neodata.com.uy\/labs\/wp-json\/wp\/v2\/posts\/214\/revisions"}],"predecessor-version":[{"id":225,"href":"https:\/\/neodata.com.uy\/labs\/wp-json\/wp\/v2\/posts\/214\/revisions\/225"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/neodata.com.uy\/labs\/wp-json\/wp\/v2\/media\/271"}],"wp:attachment":[{"href":"https:\/\/neodata.com.uy\/labs\/wp-json\/wp\/v2\/media?parent=214"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/neodata.com.uy\/labs\/wp-json\/wp\/v2\/categories?post=214"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/neodata.com.uy\/labs\/wp-json\/wp\/v2\/tags?post=214"},{"taxonomy":"nlabs_article_type","embeddable":true,"href":"https:\/\/neodata.com.uy\/labs\/wp-json\/wp\/v2\/nlabs_article_type?post=214"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}