Transporting APDUs over T=0
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
Carrying APDUs over T=0
T=0 is a byte-oriented, half-duplex protocol in which the card, not the terminal, drives the flow of each exchange. Because it has no native concept of a command that both sends and receives data, application-level APDUs have to be mapped onto it — and that mapping is where a great deal of smart-card integration effort is spent.
The shape of a T=0 exchange
The terminal begins with a five-byte header: class, instruction, the two parameters, and a single length byte whose meaning depends on the command’s direction. The card then replies with procedure bytes that control what happens next:
- A byte equal to the instruction byte means “send or receive all remaining data”.
- A byte equal to the complement of the instruction byte means “send or receive one byte”.
- A NULL byte means “I am still working — do not time out”.
- A status byte begins the ending of the exchange.
The exchange ends with the two status bytes. Everything the terminal does between header and status is dictated by the card.
The four cases, and where they hurt
The case taxonomy from Part 4 maps onto T=0 as follows:
- Case 1 — no data in either direction. Sent with a length byte of zero. Straightforward.
- Case 2 — no data in, data out. The length byte carries the expected response length. If the terminal guessed wrong, the card answers with a status word beginning
6Cwhose second byte gives the correct length, and the terminal reissues the command. - Case 3 — data in, no data out. The length byte carries the data length. Straightforward.
- Case 4 — data in and data out. This is the one T=0 cannot express directly. The command is sent as a case 3 exchange; the card completes it and replies with a status word beginning
61indicating how many response bytes are waiting; the terminal then issues GET RESPONSE to collect them.
Case 4 is the reason GET RESPONSE exists, and the reason an application that works over T=1 can fail over T=0 without a single line of application logic changing.
Extended length
Where a command’s data or expected response exceeds what a single-byte length field can express, extended length fields are used. Over T=0 these cannot be sent as-is, because the header has only one length byte. The transmission layer therefore has to break the transfer into a sequence of exchanges, using GET RESPONSE to retrieve the response in chunks. Support is optional and varies by card; where both ends support T=1, that protocol handles large transfers far more comfortably.
Implementation guidance
- Isolate this layer completely. Procedure bytes, GET RESPONSE chaining and
6Cxxretry belong in one module. Application code should hand over a command APDU and receive a response APDU. - Honour the NULL procedure byte. It exists because cryptographic operations take time. A stack that treats it as noise will time out on compliant cards performing legitimate work.
- Do not interleave. GET RESPONSE must directly follow the command whose response it collects.
- Test both protocols. If your product supports T=0 and T=1, case 4 commands and extended length are the two areas where behaviour diverges, and both need explicit coverage.
- PC/SC hides most of this. Desktop middleware performs the mapping for you. That is a convenience until you are debugging at the byte level, at which point knowing the mapping is essential.
Authoritative source
For the normative mapping of APDUs onto T=0, refer to ISO/IEC 7816-4:2020, published by ISO, together with ISO/IEC 7816-3, which specifies the T=0 protocol itself. This page is Ambimat’s own explanation and does not reproduce or replace the standard.