ISO/IEC 7816-4:2005

INTERNATIONAL ISO/IEC
STANDARD 7816-4
Second edition
2005-01-15
Identification cards — Integrated circuit
cards —
Part 4:
Organization, security and commands for
interchange
Cartes d'identification — Cartes à circuit intégré —
Partie 4: Organisation, sécurité et commandes pour les échanges

Reference number
©
ISO/IEC 2005
PDF disclaimer
This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but
shall not be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In
downloading this file, parties accept therein the responsibility of not infringing Adobe's licensing policy. The ISO Central Secretariat
accepts no liability in this area.
Adobe is a trademark of Adobe Systems Incorporated.
Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation
parameters were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In
the unlikely event that a problem relating to it is found, please inform the Central Secretariat at the address given below.

©  ISO/IEC 2005
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means,
electronic or mechanical, including photocopying and microfilm, without permission in writing from either ISO at the address below or
ISO's member body in the country of the requester.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail copyright@iso.org
Web www.iso.org
Published in Switzerland
ii © ISO/IEC 2005 – All rights reserved

Contents Page
Foreword. iv
Introduction . v
1 Scope. 1
2 Normative references . 1
3 Terms and definitions. 2
4 Symbols and abbreviated terms. 5
5 Organization for interchange. 7
5.1 Command-response pairs. 7
5.2 Data objects. 13
5.3 Structures for applications and data . 17
5.4 Security architecture . 22
6 Secure messaging . 28
6.1 SM fields and SM data objects . 28
6.2 Basic SM data objects . 29
6.3 Auxiliary SM data objects. 31
6.4 SM impact on command-response pairs. 35
7 Commands for interchange . 36
7.1 Selection . 36
7.2 Data unit handling. 39
7.3 Record handling. 41
7.4 Data object handling. 47
7.5 Basic security handling. 50
7.6 Transmission handling. 57
8 Application-independent card services. 57
8.1 Card identification. 58
8.2 Application identification and selection. 61
8.3 Selection by path . 64
8.4 Data retrieval . 65
8.5 Data element retrieval. 65
8.6 Card-originated byte strings. 67
Annex A (informative) Examples of object identifiers and tag allocation schemes. 69
Annex B (informative) Examples of secure messaging. 71
Annex C (informative) Examples of AUTHENTICATE functions by GENERAL AUTHENTICATE commands. 78
Annex D (informative) Application identifiers using issuer identification numbers . 82
Bibliography . 83

© ISO/IEC 2005 — All rights reserved iii

Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that are members of
ISO or IEC participate in the development of International Standards through technical committees
established by the respective organization to deal with particular fields of technical activity. ISO and IEC
technical committees collaborate in fields of mutual interest. Other international organizations, governmental
and non-governmental, in liaison with ISO and IEC, also take part in the work. In the field of information
technology, ISO and IEC have established a joint technical committee, ISO/IEC JTC 1.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of the joint technical committee is to prepare International Standards. Draft International
Standards adopted by the joint technical committee are circulated to national bodies for voting. Publication as
an International Standard requires approval by at least 75 % of the national bodies casting a vote.
ISO/IEC 7816-4 was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology,
Subcommittee SC 17, Cards and personal identification.
This second edition cancels and replaces the first edition (ISO/IEC 7816-4:1995), and incorporates material
extracted from ISO/IEC 7816-5:1994, ISO/IEC 7816-6:1996, ISO/IEC 7816-8:1999 and ISO/IEC 7816-9:2000.
It also incorporates the Amendment ISO/IEC 7816-4:1995/Amd.1:1997.
In addition, material has been extracted from the first edition and moved to the third edition of ISO/IEC 7816-3,
so that the transmission protocols T=0 and T=1 are now present only in ISO/IEC 7816-3, no longer in
ISO/IEC 7816-4.
ISO/IEC 7816 consists of the following parts, under the general title Identification cards — Integrated circuit
cards:
 Part 1: Cards with contacts: Physical characteristics
 Part 2: Cards with contacts: Dimensions and location of the contacts
 Part 3: Cards with contacts: Electrical interface and transmission protocols
 Part 4: Organization, security and commands for interchange
 Part 5: Registration of application providers
 Part 6: Interindustry data elements for interchange
 Part 7: Interindustry commands for Structured Card Query Language (SCQL)
 Part 8: Commands for security operations
 Part 9: Commands for card management
 Part 10: Cards with contacts: Electronic signals and answer to reset for synchronous cards
 Part 11: Personal verification through biometric methods
 Part 12: Cards with contacts: USB electrical interface and operating procedures
 Part 15: Cryptographic information application

iv © ISO/IEC 2005 — All rights reserved

Introduction
ISO/IEC 7816 is a series of standards specifying integrated circuit cards and the use of such cards for
interchange. These cards are identification cards intended for information exchange negotiated between the
outside world and the integrated circuit in the card. As a result of an information exchange, the card delivers
information (computation result, stored data), and / or modifies its content (data storage, event memorization).
 Five parts are specific to cards with galvanic contacts and three of them specify electrical interfaces.
• ISO/IEC 7816-1 specifies physical characteristics for cards with contacts.
• ISO/IEC 7816-2 specifies dimensions and location of the contacts.
• ISO/IEC 7816-3 specifies electrical interface and transmission protocols for asynchronous cards.
• ISO/IEC 7816-10 specifies electrical interface and answer to reset for synchronous cards.
• ISO/IEC 7816-12 specifies electrical interface and operating procedures for USB cards.
 All the other parts are independent from the physical interface technology. They apply to cards accessed
by contacts and / or by radio frequency.
• ISO/IEC 7816-4 specifies organization, security and commands for interchange.
• ISO/IEC 7816-5 specifies registration of application providers.
• ISO/IEC 7816-6 specifies interindustry data elements for interchange.
• ISO/IEC 7816-7 specifies commands for structured card query language.
• ISO/IEC 7816-8 specifies commands for security operations.
• ISO/IEC 7816-9 specifies commands for card management.
• ISO/IEC 7816-11 specifies personal verification through biometric methods.
• ISO/IEC 7816-15 specifies cryptographic information application.
[13] [15] [17]
ISO/IEC 10536 specifies access by close coupling. ISO/IEC 14443 and ISO/IEC 15693 specify
access by radio frequency. Such cards are also known as contactless cards.
ISO and IEC draw attention to the fact that it is claimed that compliance with this document may involve the
use of the following patents and the foreign counterparts.
JPN 2033906, Portable electronic device
JPN 2557838, Integrated circuit card
JPN 2537199, Integrated circuit card
JPN 2856393, Portable electronic device
JPN 2137026, Portable electronic device
JPN 2831660, Portable electronic device
DE 198 55 596, Portable microprocessor-assisted data carrier that can be used with or without contacts
ISO and IEC take no position concerning the evidence, validity and scope of these patent rights.
The holders of these patent rights have assured ISO and IEC that they are willing to negotiate licences under
reasonable and non-discriminatory terms and conditions with applications throughout the world. In this respect,
© ISO/IEC 2005 — All rights reserved v

the statements of the holders of these patent rights are registered with ISO and IEC. Information may be
obtained from:
Contact Patent details
Toshiba Corporation JPN 2033906 (priority date: 1986-02-18; publication date: 1996-03-19),
Intellectual Property Division
FRA 8614996, KOR 44664
1-1, Shibaura 1-Chome
JPN 2557838 (priority date: 1986-02-18; publication date: 1996-09-05),
Minato-ku, Tokyo
FRA 8700343, GER 3700504, KOR 42243, USA 4841131
105-8001, Japan
JPN 2537199 (priority date: 1986-06-20; publication date: 1996-07-08),
FRA 8708646, FRA 8717770, USA 4833595, USA 4901276
JPN 2856393 (priority date: 1987-02-17; publication date: 1998-11-27),
FRA 8801887, KOR 43929, USA 4847803
JPN 2137026 (priority date: 1987-02-20; publication date: 1998-06-26),
JPN 3054119, FRA 8802046, KOR 44393, USA 4891506
JPN 2831660 (priority date: 1988-08-26; publication date: 1998-09-25),
FRA 8911249, KOR 106290, USA 4988855
Orga Kartensysteme Gmbh DE 198 55 596 (priority date: 1998-12-02; publication date: 2000-06-29)
Am Hoppenhof 33
Applications pending in Europe, Russia, Japan, China, USA, Brazil, Australia
D-33104 Paderborn
Germany
vi © ISO/IEC 2005 — All rights reserved

INTERNATIONAL STANDARD ISO/IEC 7816-4:2005(E)

Identification cards — Integrated circuit cards —
Part 4:
Organization, security and commands for interchange
1 Scope
This part of ISO/IEC 7816 specifies
 contents of command-response pairs exchanged at the interface,
 means of retrieval of data elements and data objects in the card,
 structures and contents of historical bytes to describe operating characteristics of the card,
 structures for applications and data in the card, as seen at the interface when processing commands,
 access methods to files and data in the card,
 a security architecture defining access rights to files and data in the card,
 means and mechanisms for identifying and addressing applications in the card,
 methods for secure messaging,
 access methods to the algorithms processed by the card. It does not describe these algorithms.
It does not cover the internal implementation within the card or the outside world.
This part of ISO/IEC 7816 is independent from the physical interface technology. It applies to cards accessed
by one or more of the following methods: contacts, close coupling and radio frequency.
2 Normative references
The following referenced documents are indispensable for the application of this document. For dated refer-
ences, only the edition cited applies. For undated references, the latest edition of the referenced document
(including any amendments) applies.
ISO/IEC 7816-3, Identification cards — Integrated circuit cards — Part 3: Cards with contacts: Electrical
interface and transmission protocols
ISO/IEC 7816-6, Identification cards — Integrated circuit cards — Part 6: Interindustry data elements for
interchange
ISO/IEC 8825-1:2002, Information technology — ASN.1 encoding rules: Specification of Basic Encoding
Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)
© ISO/IEC 2005 — All rights reserved 1

3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
3.1
access rule
data element containing an access mode referring to an action and security conditions to fulfil before acting
3.2
Answer-to-Reset file
optional EF indicating operating characteristics of the card
3.3
application
structures, data elements and program modules needed for performing a specific functionality
3.4
application DF
structure hosting an application in a card
3.5
application identifier
data element (up to sixteen bytes) that identifies an application
3.6
application label
data element for use at the man-machine interface
3.7
application provider
entity providing the components that make up an application in the card
3.8
application template
set of application-relevant data objects including one application identifier data object
3.9
asymmetric cryptographic technique
cryptographic technique that uses two related operations: a public operation defined by public numbers or by
a public key and a private operation defined by private numbers or by a private key (the two operations have
the property that, given the public operation, it is computationally infeasible to derive the private operation)
3.10
certificate
digital signature binding a particular person or object and its associated public key (the entity issuing the
certificate also acts as tag allocation authority with respect to the data elements in the certificate)
3.11
command-response pair
set of two messages at the interface: a command APDU followed by a response APDU in the opposite
direction
3.12
data element
item of information seen at the interface for which are specified a name, a description of logical content, a
format and a coding
2 © ISO/IEC 2005 — All rights reserved

3.13
data object
information seen at the interface consisting of the concatenation of a mandatory tag field, a mandatory length
field and a conditional value field
3.14
data unit
the smallest set of bits that can be unambiguously referenced within an EF supporting data units
3.15
dedicated file
structure containing file control information and, optionally, memory available for allocation
3.16
DF name
data element (up to sixteen bytes) that uniquely identifies a DF in the card
3.17
digital signature
data appended to, or cryptographic transformation of, a data string that proves the origin and the integrity of
the data string and protects against forgery, e.g., by the recipient of the data string
3.18
directory file
optional EF containing a list of applications supported by the card and optional related data elements
3.19
elementary file
set of data units or records or data objects sharing the same file identifier and the same security attribute(s)
3.20
file
structure for application and / or data in the card, as seen at the interface when processing commands
3.21
file identifier
data element (two bytes) used to address a file
3.22
header list
concatenation of pairs of tag field and length field without delimitation
3.23
identification card
card identifying its holder and issuer, which may carry data required as input for the intended use of the card
and for transactions based thereon
[2]
[ISO/IEC 7810 ]
3.24
internal elementary file
EF for storing data interpreted by the card
3.25
key
sequence of symbols controlling a cryptographic operation (e.g., encipherment, decipherment, a private or a
public operation in a dynamic authentication, signature production, signature verification)
© ISO/IEC 2005 — All rights reserved 3

3.26
master file
unique DF representing the root in a card using a hierarchy of DFs
3.27
offset
number sequentially referencing a data unit in an EF supporting data units, or a byte in a record
3.28
parent file
DF immediately preceding a given file within a hierarchy of DFs
3.29
password
data that may be required by the application to be presented to the card by its user for authentication purpose
3.30
path
concatenation of file identifiers without delimitation
3.31
private key
that key of an entity's asymmetric key pair that should only be used by that entity
[8]
[ISO/IEC 9798-1 ]
3.32
provider
authority who has or who obtained the right to create a DF in the card
3.33
public key
that key of an entity's asymmetric key pair that can be made public
[8]
[ISO/IEC 9798-1 ]
3.34
record
string of bytes referenced and handled by the card within an EF supporting records
3.35
record identifier
number used to reference one or more records within an EF supporting records
3.36
record number
sequential number that uniquely identifies each record within an EF supporting records
3.37
registered application provider identifier
data element (five bytes) that uniquely identifies an application provider
3.38
secret key
key used with symmetric cryptographic techniques by a set of specified entities
[14]
[ISO/IEC 11770-3 ]
3.39
secure messaging
set of means for cryptographic protection of [parts of] command-response pairs
4 © ISO/IEC 2005 — All rights reserved

3.40
security attribute
condition of use of objects in the card including stored data and data processing functions, expressed as a
data element containing one or more access rules
3.41
security environment
set of components required by an application in the card for secure messaging or for security operations
3.42
symmetric cryptographic technique
cryptographic technique using the same secret key for both the originator's and the recipient's operation
(without the secret key, it is computationally infeasible to compute either operation)
3.43
tag list
concatenation of tag fields without delimitation
3.44
template
set of BER-TLV data objects forming the value field of a constructed BER-TLV data object
3.45
working elementary file
EF for storing data not interpreted by the card
4 Symbols and abbreviated terms
AID application identifier
APDU application protocol data unit
ARR access rule reference
ASN.1 abstract syntax notation one (see ISO/IEC 8825-1)
AT control reference template for authentication
ATR Answer-to-Reset
BER basic encoding rules of ASN.1 (see ISO/IEC 8825-1)
CCT control reference template for cryptographic checksum
CLA class byte
CRT control reference template
CT control reference template for confidentiality
DF dedicated file
DIR directory
DST control reference template for digital signature
EF elementary file
EF.ARR access rule reference file
© ISO/IEC 2005 — All rights reserved 5

EF.ATR Answer-to-Reset file
EF.DIR directory file
FCI file control information
FCP file control parameter
FMD file management data
HT control reference template for hash-code
INS instruction byte
KAT control reference template for key agreement
L field length field for coding the number N
c c
LCS byte life cycle status byte
L field length field for coding the number N
e e
MF master file
N number of bytes in the command data field
c
N maximum number of bytes expected in the response data field
e
N number of bytes in the response data field
r
PIX proprietary application identifier extension
P1-P2 parameter bytes (inserted for clarity, the dash is not significant)
RFU reserved for future use
RID registered application provider identifier
SC security condition
SCQL structured card query language
SE security environment
SEID byte security environment identifier byte
SM secure messaging
SW1-SW2 status bytes (inserted for clarity, the dash is not significant)
(SW1-SW2) value of the concatenation of the bytes SW1 and SW2 (the first byte is the most significant byte)
TLV tag, length, value
{T-L-V} data object (inserted for clarity, the dashes and curly brackets are not significant)
'XX' notation using the hexadecimal digits '0' to '9' and 'A' to 'F', equal to XX to the base 16
6 © ISO/IEC 2005 — All rights reserved

5 Organization for interchange
For organizing interchange, this clause specifies the following basic features.
1) Command-response pairs
2) Data objects
3) Structures for applications and data
4) Security architecture
5.1 Command-response pairs
Table 1 shows a command-response pair, namely a command APDU followed by a response APDU in the
opposite direction (see ISO/IEC 7816-3). There shall be no interleaving of command-response pairs across
the interface, i.e., the response APDU shall be received before initiating another command-response pair.
Table 1 — Command-response pair
Field Description Number of bytes
Class byte denoted CLA 1
Command header
Instruction byte denoted INS 1
Parameter bytes denoted P1-P2 2
L field
c Absent for encoding N = 0, present for encoding N > 0 0, 1 or 3
c c
Command data field
Absent if N = 0, present as a string of N bytes if N > 0 N
c c c c
L field Absent for encoding N = 0, present for encoding N > 0 0, 1, 2 or 3
e e e
Response data field
Absent if N = 0, present as a string of N bytes if N > 0 N (at most N )
r r r r e
Response trailer
Status bytes denoted SW1-SW2 2
In any command-response pair comprising both L and L fields (see ISO/IEC 7816-3), short and extended
c e
length fields shall not be combined: either both of them are short, or both of them are extended.
If the card explicitly states its capability of handling “extended L and L fields” (see Table 88, third software
c e
function table) in the historical bytes (see 8.1.1) or in EF.ATR (see 8.2.1.1), then the card handles short and
extended length fields. Otherwise (default value), the card handles only short length fields.
N denotes the number of bytes in the command data field. The L field encodes N .
c c c
 If the L field is absent, then N is zero.
c c
 A short L field consists of one byte not set to '00'.
c
• From '01' to 'FF', the byte encodes N from one to 255.
c
 An extended L field consists of three bytes: one byte set to '00' followed by two bytes not set to '0000'.
c
• From '0001' to 'FFFF', the two bytes encode N from one to 65 535.
c
N denotes the maximum number of bytes expected in the response data field. The L field encodes N .
e e e
 If the L field is absent, then N is zero.
e e
 A short L field consists of one byte with any value.
e
• From '01' to 'FF', the byte encodes N from one to 255.
e
• If the byte is set to '00', then N is 256.
e
 An extended L field consists of either three bytes (one byte set to '00' followed by two bytes with any
e
value) if the L field is absent, or two bytes (with any value) if an extended L field is present.
c c
• From '0001' to 'FFFF', the two bytes encode N from one to 65 535.
e
• If the two bytes are set to '0000', then N is 65 536.
e
N denotes the number of bytes in the response data field. N shall be less than or equal to N . Therefore in
r r e
any command-response pair, the absence of L field is the standard way for receiving no response data field.
e
If the L field contains only bytes set to '00', then N is maximum, i.e., within the limit of 256 for a short L field,
e e e
or 65 536 for an extended L field, all the available bytes should be returned.
e
© ISO/IEC 2005 — All rights reserved 7

If the process is aborted, then the card may become unresponsive. However if a response APDU occurs, then
the response data field shall be absent and SW1-SW2 shall indicate an error.
P1-P2 indicates controls and options for processing the command. A parameter byte set to '00' generally
provides no further qualification. There is no other general convention for encoding the parameter bytes.
General conventions are specified hereafter for encoding the class byte denoted CLA (see 5.1.1), the
instruction byte denoted INS (see 5.1.2) and the status bytes denoted SW1-SW2 (see 5.1.3). In those bytes,
the RFU bits shall be set to 0 unless otherwise specified.
5.1.1 Class byte
CLA indicates the class of the command. Due to specifications in ISO/IEC 7816-3, the value 'FF' is invalid. Bit
8 of CLA distinguishes between the interindustry class and the proprietary class.
Bit 8 set to 0 indicates the interindustry class. The values 000x xxxx and 01xx xxxx are specified hereafter.
The values 001x xxxx are reserved for future use by ISO/IEC JTC 1/SC 17.
 Table 2 specifies 000x xxxx as the first interindustry values.
• Bits 8, 7 and 6 are set to 000.
• Bit 5 controls command chaining (see 5.1.1.1).
• Bits 4 and 3 indicate secure messaging (see 6).
• Bits 2 and 1 encode a logical channel number from zero to three (see 5.1.1.2).
Table 2 — First interindustry values of CLA
b8 b7 b6 b5 b4 b3 b2 b1 Meaning
0 0 0 x - - - - Command chaining control (see 5.1.1.1)
0 0 0 0 - - - - — The command is the last or only command of a chain
0 0 0 1 - - - - — The command is not the last command of a chain
0 0 0 - x x - - Secure messaging indication
0 0 0 - 0 0 - - — No SM or no indication
0 0 0 - 0 1 - - — Proprietary SM format
0 0 0 - 1 0 - - — SM according to 6, command header not processed according to 6.2.3.1
0 0 0 - 1 1 - - — SM according to 6, command header authenticated according to 6.2.3.1
0 0 0 - - - x x Logical channel number from zero to three (see 5.1.1.2)
 Table 3 specifies 01xx xxxx as further interindustry values.
• Bits 8 and 7 are set to 01.
• Bit 6 indicates secure messaging (see 6).
• Bit 5 controls command chaining (see 5.1.1.1).
• Bits 4 to 1 encode a number from zero to fifteen; this number plus four is the logical channel number
from four to nineteen (see 5.1.1.2).
Table 3 — Further interindustry values of CLA
b8 b7 b6 b5 b4 b3 b2 b1 Meaning
0 1 x - - - - - Secure messaging indication
0 1 0 - - - - - — No SM or no indication
0 1 1 - - - - - — SM according to 6, command header not processed according to 6.2.3.1
0 1 - x - - - - Command chaining control (see 5.1.1.1)
0 1 - 0 - - - - — The command is the last or only command of a chain
0 1 - 1 - - - - — The command is not the last command of a chain
Logical channel number from four to nineteen (see 5.1.1.2)
0 1 - - x x x x
Bit 8 set to 1 indicates the proprietary class, except for the value 'FF' which is invalid. The application-context
defines the other bits.
8 © ISO/IEC 2005 — All rights reserved

5.1.1.1 Command chaining
This clause specifies a mechanism whereby in the interindustry class, consecutive command-response pairs
can be chained. The mechanism may be used when executing a multi-step process, e.g., transmitting a data
string too long for a single command.
If the card supports the mechanism, then it shall indicate it (see Table 88, third software function table) in the
historical bytes (see 8.1.1) or in EF.ATR (see 8.2.1.1).
This document specifies the card behaviour only in the case where, once initiated, a chain is terminated
before initiating a command-response pair not part of the chain. Otherwise the card behaviour is not specified.
For chaining in the interindustry class, bit 5 of CLA shall be used while the other seven bits are constant.
 If bit 5 is set to 0, then the command is the last or only command of a chain.
 If bit 5 is set to 1, then the command is not the last command of a chain.
In response to a command that is not the last command of a chain, SW1-SW2 set to '9000' means that the
process has been completed so far; warning indications are prohibited (see 5.1.3); moreover, the following
specific error conditions may occur.
 If SW1-SW2 is set to '6883', then the last command of the chain is expected.
 If SW1-SW2 is set to '6884', then command chaining is not supported.
5.1.1.2 Logical channels
This clause specifies a mechanism whereby in the interindustry class, command-response pairs can refer to
logical channels.
If the card supports the mechanism, then it shall indicate the maximum number of available channels (see
Table 88, third software function table) in the historical bytes (see 8.1.1) or in EF.ATR (see 8.2.1.1).
 If the indicated number is four or less, then only Table 2 applies.
 If the indicated number is five or more, then Table 3 also applies.
For referring to logical channels in the interindustry class, the following rules apply.
 CLA encodes the channel number of the command-response pair.
 The basic channel shall be permanently available, i.e., it cannot be closed. Its channel number is zero.
 Cards not supporting the mechanism (default value) shall use only the basic channel.
 Any other channel shall be opened by completion of either a SELECT command (see 7.1.1) where CLA
encodes a channel number not yet in use, or a MANAGE CHANNEL command with open function (see 7.1.2).
 Any other channel can be closed by the completion of a MANAGE CHANNEL command with close function.
After closing, the channel shall be available for re-use.
 Only one channel shall be active at a time. The use of logical channels does not remove the prohibition of
interleaving command-response pairs across the interface, i.e., the response APDU shall be received
before initiating another command-response pair (see 5.1).
 If not explicitly excluded by the file descriptor byte (see Table 14), more than one channel may be opened
to the same structure (see 5.3), i.e., to a DF, possibly an application DF, and also possibly to an EF.
Each logical channel has its own security status (see 5.4). The way to share a security status is outside the
scope of this document.
© ISO/IEC 2005 — All rights reserved 9

5.1.2 Instruction byte
INS indicates the command to process. Due to specifications in ISO/IEC 7816-3, the values '6X' and '9X' are
invalid.
Table 4 lists all the commands specified in ISO/IEC 7816 at the time of publication.
 Table 4.1, i.e., the left side, lists the command names in the alphabetic order.
 Table 4.2, i.e., the right side, lists the INS codes in the numeric order.
Table 4.1 — Commands in the alphabetic order       Table 4.2 — Commands in the numeric order
Command name INS See INS Command name See
ACTIVATE FILE '44' Part 9 '04' DEACTIVATE FILE Part 9
APPEND RECORD 'E2' 7.3.7 '0C' ERASE RECORD (S) 7.3.8
CHANGE REFERENCE DATA '24' 7.5.7 '0E', '0F' ERASE BINARY 7.2.7
CREATE FILE 'E0' Part 9 '10' PERFORM SCQL OPERATION Part 7
DEACTIVATE FILE '04' Part 9 '12' PERFORM TRANSACTION OPERATION Part 7
DELETE FILE 'E4' Part 9 '14' PERFORM USER OPERATION Part 7
DISABLE VERIFICATION REQUIREMENT '26' 7.5.9 '20', '21' VERIFY 7.5.6
ENABLE VERIFICATION REQUIREMENT '28' 7.5.8 '22' MANAGE SECURITY ENVIRONMENT 7.5.11
ENVELOPE 'C2', 'C3' 7.6.2 '24' CHANGE REFERENCE DATA 7.5.7
ERASE BINARY '0E', '0F' 7.2.7 '26' DISABLE VERIFICATION REQUIREMENT 7.5.9
ERASE RECORD (S) '0C' 7.3.8 '28' ENABLE VERIFICATION REQUIREMENT 7.5.8
EXTERNAL (/ MUTUAL) AUTHENTICATE '82' 7.5.4 '2A' PERFORM SECURITY OPERATION Part 8
GENERAL AUTHENTICATE '86', '87' 7.5.5 '2C' RESET RETRY COUNTER 7.5.10
GENERATE ASYMMETRIC KEY PAIR '46' Part 8 '44' ACTIVATE FILE Part 9
GET CHALLENGE '84' 7.5.3 '46' GENERATE ASYMMETRIC KEY PAIR Part 8
GET DATA 'CA', 'CB' 7.4.2 '70' MANAGE CHANNEL 7.1.2
GET RESPONSE 'C0' 7.6.1 '82' EXTERNAL (/ MUTUAL) AUTHENTICATE 7.5.4
INTERNAL AUTHENTICATE '88' 7.5.2 '84' GET CHALLENGE 7.5.3
MANAGE CHANNEL '70' 7.1.2 '86', '87' GENERAL AUTHENTICATE 7.5.5
MANAGE SECURITY ENVIRONMENT '22' 7.5.11 '88' INTERNAL AUTHENTICATE 7.5.2
PERFORM SCQL OPERATION '10' Part 7 'A0', 'A1' SEARCH BINARY 7.2.6
PERFORM SECURITY OPERATION '2A' Part 8 'A2' SEARCH RECORD 7.3.7
PERFORM TRANSACTION OPERATION '12' Part 7 'A4' SELECT 7.1.1
PERFORM USER OPERATION '14' Part 7 'B0', 'B1' READ BINARY 7.2.3
PUT DATA 'DA', 'DB' 7.4.3 'B2', 'B3' READ RECORD (S) 7.3.3
READ BINARY 'B0', 'B1' 7.2.3 'C0' GET RESPONSE 7.6.1
READ RECORD (S) 'B2', 'B3' 7.3.3 'C2', 'C3' ENVELOPE 7.6.2
RESET RETRY COUNTER '2C' 7.5.10 'CA', 'CB' GET DATA 7.4.2
SEARCH BINARY 'A0', 'A1' 7.2.6 'D0', 'D1' WRITE BINARY 7.2.6
SEARCH RECORD 'A2' 7.3.7 'D2' WRITE RECORD 7.3.4
SELECT 'A4' 7.1.1 'D6', 'D7' UPDATE BINARY 7.2.5
TERMINATE CARD USAGE 'FE' Part 9 'DA', 'DB' PUT DATA 7.4.3
TERMINATE DF 'E6' Part 9 'DC', 'DD' UPDATE RECORD 7.3.5
TERMINATE EF 'E8' Part 9 'E0' CREATE FILE Part 9
UPDATE BINARY 'D6', 'D7' 7.2.5 'E2' APPEND RECORD 7.3.6
UPDATE RECORD 'DC', 'DD' 7.3.5 'E4' DELETE FILE Part 9
VERIFY '20', '21' 7.5.6 'E6' TERMINATE DF Part 9
WRITE BINARY 'D0', 'D1' 7.2.4 'E8' TERMINATE EF Part 9
WRITE RECORD 'D2' 7.3.4 'FE' TERMINATE CARD USAGE Part 9
 In the interindustry class, any valid INS code not defined in ISO/IEC 7816 is reserved for future use by ISO/IEC JTC 1/SC 17.
ISO/IEC 7816 specifies the use of those commands in the interindustry class.
 This document (see 7) specifies commands for interchange.
[4]
 ISO/IEC 7816-7 specifies commands for structured card query language (SCQL).
[4]
 ISO/IEC 7816-8 specifies commands for security operations.
[4]
 ISO/IEC 7816-9 specifies commands for card management.
10 © ISO/IEC 2005 — All rights reserved

In the interindustry class, bit 1 of INS indicates a data field format as follows.
 If bit 1 is set to 0 (even INS code), then no indication is provided.
 If bit 1 is set to 1 (odd INS code), then BER-TLV encoding (see 5.2.2) shall apply as follows.
• In unchained commands with SW1 not set to '61', data fields, if any, shall be encoded in BER-TLV.
• Command chaining and / or the use of SW1 set to '61' allow the transmission of data strings too long
for a single command. Such a process may split data objects in data fields consecutively sent as a
sequence in one direction, i.e., while sending no data field in the opposite direction. When chaining
commands and / or using SW1 set to '61', the concatenation of all the consecutive data fields in the
same direction in the same sequence shall be encoded in BER-TLV.
5.1.3 Status bytes
SW1-SW2 indicates the processing state. Due to specifications in ISO/IEC 7816-3, any value different from
'6XXX' and '9XXX' is invalid; any value '60XX' is also invalid.
The values '61XX', '62XX', '63XX', '64XX', '65XX', '66XX', '68XX', '69XX', '6AXX' and '6CXX' are interindustry.
Due to specifications in ISO/IEC 7816-3, the values '67XX', '6BXX', '6DXX', '6EXX', '6FXX' and '9XXX' are
proprietary, except the values '6700', '6B00', '6D00', '6E00', '6F00' and '9000' that are interindustry.
Figure 1 shows the structural scheme of the values '9000' and '61XX' to '6FXX' for SW1-SW2.
SW1-SW2
Process completed Process aborted
Normal processing Warning processing
Execution error Checking error
'9000' and '61XX' '62XX' and '63XX'
'64XX' to '66XX' '67XX' to '6FXX'
Figure 1 — Structural scheme of values of SW1-SW2
Table 5 lists all the interindustry values of SW1-SW2 and shows their general meaning. ISO/IEC JTC 1/SC 17
reserves for future use any interindustry value of SW1-SW2 not defined in ISO/IEC 7816.
Table 5 — General meaning of the interindustry values of SW1-SW2
SW1-SW2 Meaning
Normal '9000' No further qualification
processing
'61XX' SW2 encodes the number of data bytes still available (see text below)
Warning
'62XX' State of non-volatile memory is unchanged (further qualification in SW2)
processing '63XX' State of non-volatile memory has changed (further qualification in SW2)
'64XX' State of non-volatile memory is unchanged (further qualification in SW2)
Execution
'65XX' State of non-volatile memory has changed (further qualification in SW2)
error
'66XX' Security-related issues
'6700' Wrong length; no further indication

'68XX' Functions in CLA not supported (further qualification in SW2)

'69XX' Command not allowed (further qualification in SW2)

'6AXX' Wrong parameters P1-P2 (further qualification in SW2)
Checking
'6B00' Wrong parameters P1-P2
error
'6CXX' Wrong L field; SW2 encodes the exact number of available data bytes (see text below)
e
'6D00' Instruction code not supported or invalid
'6E00' Class not supported
'6F00' No precise diagnosis
If the process is aborted with a value of SW1 from '64' to '6F', then the response data field shall be absent.
If SW1 is set to '63' or '65', then the state of the non-volatile memory has changed. If SW1 is set to '6X' except
for '63' and '65', then the state of the non-volatile memory is unchanged.
© ISO/IEC 2005 — All rights reserved 11

In response to a command that is not the last command of a chain (see 5.1.1.1), interindustry warning
indications are prohibited (see also ISO/IEC 7816-3), i.e., SW1 shall be set to neither '62' nor '63'.
Two interindustry values of SW1 are independent from any transmission protocol.
 If SW1 is set to '61', then the process is completed and before issuing any other command, a GET RE-
SPONSE command may be issued with the same CLA and using SW2 (number of data bytes still available)
as short L field.
e
 If SW1 is set to '6C', then the process is aborted and before issuing any other command, the same
command may be re-issued using SW2 (exact number of available data bytes) as short L field.
e
Table 6 lists all the specific interindustry warning and error conditions used in ISO/IEC 7816 at the time of
publication.
Table 6 — Specific interindustry warning and error conditions
SW1 SW2 Meaning
'62' '00' No information given
(warning) '02' to '80' Triggering by the card (see 8.6.1)
'81' Part of returned data may be corrupted
'82' End of file or record reached before reading N bytes
e
'83' Selected file deactivated
'84' File control information not formatted according to 5.3.3
'85' Selected file in termination state
'86' No input data available from a sensor on the card
'63' '00' No information given
(warning) '81' File filled up by the last write
'CX' Counter from 0 to 15 encoded by 'X' (exact meaning depending on the command)
'64' '00' Execution error
(error) '01' Immediate response required by the card
'02' to '80' Triggering by the card (see 8.6.1)
'65' '00' No information given
(error) '81' Memory failure
'68' '00' No information given
(error) '81' Logical channel not supported
'82' Secure messaging not supported
'83' Last command of the chain expected
'84' Command chaining not supported
'69' '00' No information given
(error) '81' Command incompatible with file structure
'82' Security status not satisfied
'83' Authentication method blocked
'84' Reference data not usable
'85' Conditions of use not satisfied
'86' Command not allowed (no current EF)
'87' Expected secure messaging data objects missing
'88' Incorrect secure messaging data objects
'6A' '00' No information given
(error) '80' Incorrect parameters in the command data field
'81' Function not supported
'82' File or application not found
'83' Record not found
'84' Not enough memory space in the file
'85' N inconsistent with TLV structure
c
'86' Incorrect parameters P1-P2
'87' N inconsistent with parameters P1-P2
c
'88' Referenced data or reference data not found (exact meaning depending on the command)
'89' File already exists
'8A' DF name already exists
 Any other value of SW2 is reserved for future use by ISO/IEC JTC 1/SC 17.

12 © ISO/IEC 2005 — All rights reserved

5.2 Data objects
If encoded in TLV, any data field, or concatenation of data fields, is a sequence of data objects. This clause
specifies two categories of data objects: SIMPLE-TLV data objects and BER-TLV data objects.
5.2.1 SIMPLE-TLV data objects
Each SIMPLE-TLV data object shall consist of two or three consecutive fields: a mandatory tag field, a
mandatory length field and a conditional value field. A record (see 7.3.1) may be a SIMPLE-TLV data object.
 The tag field consists of a single byte encoding a tag number from 1 to 254. The values '00' and 'FF' are
invalid for tag fields. If a
...