Transmission-Oriented Commands: GET RESPONSE and ENVELOPE
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
Commands that exist because of the transport
Most commands in Part 4 do something to the card’s data. A small group does something to the conversation instead. GET RESPONSE and ENVELOPE exist to work around limitations of the underlying transmission protocol, which is why they behave differently depending on whether you are running T=0 or T=1.
GET RESPONSE
Under T=0 the protocol has no way to express a command that both sends data to the card and receives data back. When such a command completes, the card cannot simply hand over the response — it signals that a response is waiting, using a status word beginning 61 whose second byte gives the number of bytes available. The terminal then issues GET RESPONSE (INS C0) to collect them.
The mechanism also appears when the terminal asked for the wrong length. A status word beginning 6C means the expected length was incorrect and its second byte carries the correct value; the terminal reissues the original command with the corrected Le.
Two practical rules follow:
- GET RESPONSE must immediately follow the command it belongs to. Anything else in between and the pending response is gone.
- Put this in one place. A single chunk of code in your transport layer should handle
61xxand6Cxxfor every command. Handling it per-command guarantees that some path eventually gets it wrong.
Under T=1 the protocol carries both directions naturally, so GET RESPONSE is usually unnecessary. This asymmetry is exactly why an application validated over one protocol can fail over the other, and why any stack supporting both should be tested on both.
ENVELOPE
ENVELOPE (INS C2) wraps one command inside another. Its two established uses are:
- Carrying a command larger than the transport allows. A long command APDU can be split and delivered as a sequence of ENVELOPE commands, each carrying a fragment, with the card reassembling them.
- Carrying a secure-messaging-protected command. The protected APDU becomes the data field of an ENVELOPE, so that even the header of the inner command is covered by protection.
ENVELOPE is optional and support varies considerably. Where a card supports extended length fields, extended APDUs are usually the simpler answer to the size problem.
How to think about this group
These commands are plumbing. They do not appear in a functional specification of what a card stores or does, and application code should generally never construct them directly. If GET RESPONSE handling is visible in your business logic, that is a sign the transport abstraction has leaked and is worth fixing before it multiplies.
Common mistakes
- Treating a
61xxstatus word as an error. It is a success indication with more data pending. - Interpreting the second byte of
6Cxxas a byte count of data returned rather than as the corrected Le to retry with. - Assuming a card that accepts extended length over T=1 will also accept it over T=0.
- Building ENVELOPE support before confirming the card actually implements it.
Authoritative source
For the normative definition of GET RESPONSE and ENVELOPE and their status conditions, refer to ISO/IEC 7816-4:2020, published by ISO, and to ISO/IEC 7816-3 for the transmission protocols themselves. This page is Ambimat’s own explanation and does not reproduce or replace the standard.