Smart Card File Structures and Security Architecture
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
How a smart card organises data, and how it protects it
Two ideas do most of the work in Part 4: a file structure that gives data an address, and a security architecture that decides who may touch it. They are designed together, because on a card an access rule is a property of the file rather than of the application asking.
The file hierarchy
The card presents a tree. At the root is the Master File (MF), implicitly selected after reset. Beneath it sit Dedicated Files (DF), which behave like directories and normally correspond to applications, and Elementary Files (EF), which hold the actual data.
An EF is either a working EF, holding data intended for the outside world, or an internal EF, holding data the card interprets itself — keys, counters, configuration. The distinction is not cosmetic: it is why a well-behaved card will refuse to read key material no matter how the request is phrased.
Four elementary file structures
The structure chosen at creation time determines how the file can be addressed for the rest of its life.
- Transparent. A flat sequence of bytes with no internal structure. Addressed by offset. Read and written with READ BINARY and UPDATE BINARY. Use it for blobs: certificates, images, free-form data.
- Linear fixed. A sequence of records, all the same length. Addressed by record number. Efficient and predictable; the usual choice for tabular data.
- Linear variable. A sequence of records of differing lengths. More space-efficient for ragged data, at the cost of more work inside the card.
- Cyclic. A fixed-size ring of equal-length records where writing a new record overwrites the oldest. The natural structure for transaction logs, and the one whose numbering surprises people most: record 1 is the most recently written record, not the first one ever written.
Four ways to reference a file
- File identifier. A two-byte value.
3F00is reserved for the MF. - Path. Concatenated file identifiers, absolute from the MF or relative to the current DF. Useful when identifiers are only unique within a directory.
- Short EF identifier (SFI). A five-bit reference carried inside a command’s parameter bytes, letting a single command name a file and act on it without a preceding SELECT. This is the mechanism that makes high-performance flows — transit gates, payment terminals — feasible, because it halves the number of exchanges.
- DF name / AID. Up to sixteen bytes identifying an application, used to select a DF without knowing where it sits in the tree.
Referencing data inside a file
Within a file, three addressing models apply depending on structure: data unit referencing by offset in transparent files; record referencing by number or by identifier in record-structured files; and data object referencing by BER-TLV tag, which is independent of file structure and is how GET DATA and PUT DATA work.
Record referencing has a subtlety worth stating plainly: a record number is a position and is unique; a record identifier is a value and may repeat within a file. Commands that search by identifier therefore support notions such as first, last, next and previous occurrence. Code written against a test card where every identifier happens to be unique will fail on a production card where they are not.
File control information
Selecting a file can return File Control Information — the file’s structure, size and access rules, encoded as BER-TLV within the FCP and FMD templates. Parsing it is far more robust than hard-coding a card layout: it lets middleware discover what it is talking to, and it makes an integration survive a card profile change that would otherwise break it silently.
The security architecture
Access control on a card rests on three pieces that fit together.
Security status is the card’s memory of what has been proven during this session — a PIN verified, an external authentication completed, a secure channel established. It is volatile: it resets when the card is deactivated, and a well-designed card also drops it when the selected application changes.
Security attributes are the rules attached to a file or data object, stating what security status is required for each operation. Read, update, append, and administrative operations are controlled independently, so a file can be world-readable but PIN-protected for update.
Security mechanisms are the means of moving the status — password verification, challenge-response authentication of the terminal to the card or the card to the terminal, and secure messaging.
Practical implications
- Choose the file structure for the access pattern, not for tidiness. A cyclic file is the right answer for a bounded log and the wrong answer for a lookup table.
- Design for the round-trip count. On a contactless interface, an exchange costs real time. SFI-based access and reading FCI once rather than repeatedly are the levers that matter.
- Do not infer permission from success. A read that works after a PIN verification tells you nothing about whether it would work without one. Test the negative case explicitly.
- Assume security status is lost. Any reset, deselect, or application switch should be treated as invalidating it. Re-establishing it is cheaper than debugging an intermittent failure.
- Illustrative example. A cardholder data file might reasonably be created as linear fixed with read access unconditional and update access requiring both PIN verification and secure messaging, while the key file alongside it is an internal EF with no read access at all. That combination gives a terminal what it needs without ever exposing what it must not have.
Authoritative source
For the normative specification of file structures, referencing methods and the security architecture, refer to ISO/IEC 7816-4:2020, published by ISO. This page is Ambimat’s own engineering explanation and does not reproduce or replace the standard.