ISO/IEC 7816-4 Basic Interindustry Commands: The APDU Command Set

Home / ISO/IEC 7816-4 Basic Interindustry Commands: The APDU Command Set

Basic Interindustry Commands

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

The interindustry command set, from an implementer’s point of view

Part 4 defines a general-purpose command set that any card may implement and any terminal may use. This page explains how those commands are shaped, what the common ones do, and where implementations diverge in practice.

The APDU, once and precisely

Every command the terminal sends has the same shape:

  • CLA — class byte: command class, logical channel, and whether secure messaging is applied.
  • INS — instruction byte: which command this is.
  • P1, P2 — two parameter bytes whose meaning is defined per command.
  • Lc — length of the data sent to the card, present only if there is data.
  • Data — the command data field.
  • Le — how many bytes of response are expected, present only if a response body is expected.

The card replies with an optional data field followed by exactly two bytes, SW1 and SW2. The status word is always present; the data field often is not.

Because Lc and Le are each optional, commands fall into four cases: no data either way; no data in, data out; data in, no data out; and data in both directions. This taxonomy is not academic — it is exactly what determines how a command must be mapped onto T=0, and it is why the same command can behave differently on two protocols.

Length fields come in short form (one byte, values 1–255, with zero conventionally meaning 256 for Le) and extended form (three bytes, allowing much larger transfers). Extended length is optional and support for it is a real interoperability variable; a card that advertises it may still only accept it over T=1.

Commands for transparent files

  • READ BINARY (INS B0) — read bytes from a transparent EF at a given offset. P1–P2 carry the offset, or an SFI plus a short offset.
  • UPDATE BINARY (INS D6) — replace bytes at a given offset. This is the command you almost always want for modification.
  • WRITE BINARY (INS D0) — write bytes, where the card combines the new value with the existing one according to a card-defined logical rule. Because that rule varies, WRITE BINARY is far less portable than UPDATE BINARY and is best avoided unless a profile requires it.
  • ERASE BINARY (INS 0E) — set a range back to its erased state.

Commands for record files

  • READ RECORD (INS B2) — read a record by number, or search by identifier for the first, last, next or previous occurrence. P1 carries the record number or identifier; P2 carries the SFI and the selection mode.
  • UPDATE RECORD (INS DC) — replace an existing record in place.
  • APPEND RECORD (INS E2) — add a record. On a cyclic file this is what rotates the ring, overwriting the oldest entry.
  • WRITE RECORD (INS D2) — the record analogue of WRITE BINARY, with the same portability caveat.

Commands for data objects

  • GET DATA (INS CA) — retrieve a data object by its BER-TLV tag, carried in P1–P2. Independent of file structure.
  • PUT DATA (INS DA) — store a data object by tag, subject to access conditions.

Selection and security

  • SELECT (INS A4) — choose the MF, a DF, an EF, or an application by name. P1 says how the target is being identified — by file identifier, by path, by DF name — and P2 controls what File Control Information comes back. SELECT is the most parameter-sensitive command in the set and the one where terminal code most often needs card-specific handling.
  • VERIFY (INS 20) — present reference data such as a PIN. A failure typically returns a status word whose low nibble carries the remaining retry count, which is why blind retry loops are dangerous: they can block a card permanently.
  • GET CHALLENGE (INS 84) — obtain a random challenge from the card, the first step of most authentication flows.
  • INTERNAL AUTHENTICATE (INS 88) — the card proves itself to the terminal.
  • EXTERNAL AUTHENTICATE (INS 82) — the terminal proves itself to the card, usually raising the security status.
  • MANAGE CHANNEL (INS 70) — open or close a logical channel, allowing more than one application context concurrently.

Reading status words

The status word is the card’s entire diagnostic vocabulary, and learning to read it saves enormous time. 9000 means success. Values beginning 61 mean success with a stated number of response bytes still to collect. Values beginning 6C mean the expected length was wrong and give the correct one. The 69 range covers command-not-allowed conditions, prominently security status not satisfied. The 6A range covers wrong parameters, including file or application not found and incorrect P1–P2. 6D00 means the instruction is not supported, and 6E00 means the class is not supported.

That last pair is worth internalising: 6D00 and 6E00 almost always mean you are talking to the wrong application or the wrong card, not that your data is malformed.

Practical implementation notes

  • Optionality is the rule. A card implements a subset. Discover it from the card’s own File Control Information and capability data rather than assuming.
  • Prefer UPDATE over WRITE. The write-combining behaviour of WRITE BINARY and WRITE RECORD is card-defined and will not survive a change of supplier.
  • Handle 61xx and 6Cxx centrally. Put GET RESPONSE and length-correction retry in one place in your stack. Scattering it through application code is a reliable source of protocol-dependent bugs.
  • Never retry a failed VERIFY automatically. Read the retry counter and surface it to the user.
  • Illustrative example. A typical read flow is: SELECT the application by AID, parse the returned FCI to learn the file layout, then READ RECORD using the short EF identifier so that no further SELECT is needed. On a contactless interface, removing that second SELECT is often the difference between meeting and missing a transaction time budget.

Authoritative source

For the normative definition of these commands, their parameters and their status conditions, refer to ISO/IEC 7816-4:2020, published by ISO, and to ISO/IEC 7816-8 for security operations. This page is Ambimat’s own engineering explanation and does not reproduce or replace the standard.