Smart Card Terminology
ISO 7816 Part 4: Interindustry Commands for Interchange
ISO 7816 part 4, section..1 2 3 4 5 6 7 8 9 annex.. A B C D E F
Smart-card vocabulary, explained
Part 4 uses a compact vocabulary very precisely, and most confusion in smart-card projects comes from using these words loosely. The explanations below are Ambimat’s own, written to make the concepts usable rather than to restate any definition list.
The file system
- Master File (MF). The root of the card’s file structure. There is exactly one, and it is implicitly selected after reset. Conventionally identified as
3F00. - Dedicated File (DF). A directory. It groups files and usually corresponds to an application. A DF can hold other DFs and elementary files.
- Elementary File (EF). A leaf that actually stores data. Two flavours matter: a working EF holds data the card does not interpret, meant for the outside world; an internal EF holds data the card interprets itself, such as keys or configuration.
- Parent file. The DF immediately above a given file. Relevant because selection and access rules are frequently expressed relative to it.
- Path. A concatenation of file identifiers. A path starting at the MF identifier is absolute; anything else is relative to the currently selected DF.
- File control information. What the card returns when you select a file — its structure, size, and access conditions. Reading it is the reliable way to discover a card’s layout instead of guessing.
Records and data units
- Record. A string of bytes the card handles as a unit inside a record-structured EF.
- Record number. A sequential position within the file. Unique by construction.
- Record identifier. A value associated with a record, used to find it by content rather than position. Crucially, it need not be unique — several records in one file may share an identifier, which is why searching by identifier has a “next occurrence” notion and searching by number does not.
- Data unit. The smallest addressable quantum in a transparent (unstructured) EF — effectively how the card lets you address bytes within a flat blob.
- Data object. A tag-length-value structure addressed by tag rather than by position. Retrieved and stored with GET DATA and PUT DATA.
Messages and security
- Message. The string of bytes exchanged in one direction, excluding whatever framing the transmission protocol adds.
- APDU. The application-level message: a command APDU from the terminal, a response APDU from the card.
- Security status. The card’s current view of what has been proven to it in this session — a PIN verified, an external authentication passed. Access conditions are evaluated against it.
- Security attribute. The rule attached to a file or data object stating what security status is required for a given operation.
- Secure messaging. Protection applied to the APDUs themselves, providing authenticity, and optionally confidentiality, between terminal and card.
- Password / PIN. A value the cardholder or terminal presents to the card to raise its security status. From the card’s point of view it is simply reference data to be compared.
- Provider. The authority entitled to create a DF on the card — the organisation owning an application in a multi-application deployment.
Why the distinctions are worth keeping
Two examples make the case. Confusing record number with record identifier produces code that works on a test card where they happen to coincide and fails on a production card where they do not. Confusing working EF with internal EF produces designs that expect to read key material the card will never expose — correctly.
Authoritative source
For the normative definitions, refer to ISO/IEC 7816-4:2020, published by ISO. The explanations above are Ambimat’s own and are not a reproduction of the standard’s definitions clause.