Secure Messaging
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
Secure messaging: protecting the command, not just the channel
Secure messaging protects APDUs themselves — their integrity, and optionally their confidentiality — between the terminal and the card. It matters because the physical link is not trustworthy: contact lines can be probed, contactless traffic can be intercepted, and readers can be tampered with. Protection applied end to end between the terminal’s secure component and the card survives all of that.
The two services
- Authentication. A cryptographic checksum — a MAC — computed over the protected parts of the APDU. It proves the message came from a party holding the key and was not altered.
- Confidentiality. The data field is enciphered, so an observer learns nothing from it.
They are independent. Authentication alone is common and often sufficient; confidentiality alone is rarely appropriate, because an attacker who can modify an enciphered field undetected can still cause harm.
How it is signalled and carried
Secure messaging is indicated in the class byte of the command, which also distinguishes whether the command header itself is included in the protection. Including the header matters: without it, an attacker may be able to alter the instruction or parameter bytes while leaving a valid MAC over the data.
The protected content is carried as TLV data objects in the command and response data fields. Distinct object types exist for plain values that are authenticated but not enciphered, for enciphered values, for the expected response length, and for the cryptographic checksum itself. A control reference template may accompany them, stating which key and which algorithm are to be used.
Establishing the keys
Secure messaging needs session keys, and those come from an authentication step first — typically GET CHALLENGE to obtain a random value from the card, followed by mutual authentication that leaves both sides holding freshly derived session keys. Deriving per-session keys rather than using a static key is what makes replay infeasible.
Common mistakes
These are the failures we see most often, and each has caused real defects:
- Not authenticating the header. Protecting only the data field leaves the instruction and parameters malleable.
- Encrypt-only, no MAC. Confidentiality without integrity permits undetected modification.
- Static session keys. Reusing keys across sessions makes captured traffic replayable.
- Verifying the MAC after acting. The response must be authenticated before any of its content is trusted or used.
- Re-encoding before verifying. A MAC is computed over exact bytes. Parsing a structure and re-serialising it rarely reproduces the original encoding, so verify against the bytes as received.
- Ignoring padding rules. Padding is part of the cryptographic computation; mismatched padding produces MAC failures that look like key problems and waste days.
- Leaving secure messaging optional at runtime. If a terminal falls back to unprotected commands when the card returns an error, an attacker simply forces that error.
Practical guidance
- Implement secure messaging as a wrapper in the transport layer, applied uniformly, rather than per command.
- Fail closed. A MAC verification failure should abort the transaction, not warn and continue.
- Keep the raw bytes of every received APDU for verification, alongside the parsed form for use.
- Confirm what the card actually supports before designing around a particular mode; secure messaging options vary considerably between platforms.
Authoritative source
For the normative specification of secure messaging, refer to ISO/IEC 7816-4:2020, published by ISO, and to ISO/IEC 7816-8:2021 for commands and mechanisms for security operations. This page is Ambimat’s own explanation and does not reproduce or replace the standard.