EN ISO/IEC 7816-4:1996

SLOVENSKI STANDARD
01-junij-1998
Information technology - Identification cards - Integrated circuit(s) cards with
contacts - Part 4: Interindustry commands for interchange (ISO/IEC 7816-4:1995)
Information technology - Identification cards - Integrated circuit(s) cards with contacts -
Part 4: Interindustry commands for interchange (ISO/IEC 7816-4:1995)
Informationtechnologie - Identifikationskarten - Karten mit integrierten Schaltkreisen und
Kontakten - Teil 4: Interindustrielle Kommandos (ISO/IEC 7816-4:1995)
Technologies de l'information - Cartes d'identification - Cartes a circuit(s) intégré(s) a
contacts - Partie 4: Commandes intersectorielles pour les échanges (ISO/IEC 7816-
4:1995)
Ta slovenski standard je istoveten z: EN ISO/IEC 7816-4:1996
ICS:
35.240.15 Identifikacijske kartice in Identification cards and
sorodne naprave related devices
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

INTERNATIONAL ISO/IEC
STANDARD
7816-4
First edition
1995-09-01
Information technology - Identification
cards - Integrated circuit(s) cards with
contacts -
Part 4:
Interindustry commands for interchange
Technologies de I’information - Cartes d’iden tifica tion - Cartes 2
circuit(s) inttSgrb(s) a contacts -
Pat-tie 4: Commandes intersectorielles pour /es Bchanges
Reference number
lSO/IEC 7816-W 995(E)
ISO/IEC 7816-4: 1995 (E)
Page
Contents
. . .
III
Foreword . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
iv
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Introduction
Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Normative references
Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Abbreviations and notation
.................................................................................... 3
Basic organizations
.................................................................................... 3
5.1 Data structures
.......................................................... 6
5.2 Security architecture of the card
.................................................................... 7
5.3 APDU message structure
5.4 Coding conventions for command headers,
........................................................... 9
data fields and response trailers
................................................................................... 12
5.5 Logical channels
................................................................................ 12
5.6 Secure messaging
6 Basic interindustry commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
....................................................................... 16
6.1 READ BINARY command
...................................................................... 17
6.2 WRITE BINARY command
.................................................................... 17
6.3 UPDATE BINARY command
...................................................................... 18
6.4 ERASE BINARY command
.................................................................. 19
6.5 READ RECORD(S) command
.....................................................................
6.6 WRITE RECORD command
..................................................................
6.7 APPEND RECORD command
..................................................................
6.8 UPDATE RECORD command
............................................................................. 23
6.9 GET DATA command
.............................................................................
6.10 PUT DATA command
.........................................................................
6.11 SELECT FILE command
.................................................................................. 26
‘6.12 VERIFY command
..................................................... 27
6.13 INTERNAL AUTHENTICATE command
..................................................... 27
6.14 EXTERNAL AUTHENTICATE command
................................................................... 28
6.15 GET CHALLENGE command
............................................................... 29
6.16 MANAGE CHANNEL command
.................................... 29
Transmission-oriented interindustry commands
.................................................................... 30
7.1 GET RESPONSE command
........................................................................... 30
7.2 ENVELOPE command
Historical bytes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
9 Application-independent card services
Annexes
............................................. 35
Transportation of APDU messages by T=O
A
.............................................. 39
B Transportation of APDU messages by T=l
Record pointer management .
C
................................................
Use of the basic encoding rules of ASN.l
D
Examples of card profiles .
E
Use of secure messaging .
F
0 lSO/IEC 1995
no part of this publication may be
All rights reserved. Unless otherwise specified,
.......
electronic or mechanical, tncludrng
reproduced or utilized in any form or by any means,
photocopying and microfilm, without permission in writing from the publisher.
l Case Postale 56 l CH-121 I Geneve 20 l Switzerland
I SO/I EC Copy right Off ice
Printed in Switzerland
ii
0 lSO/IEC ISO/IEC 7816-4: 1995 (E)
Foreword
IS0 (the International Organization for Standardization) and IEC (the
International Electrotechnical Commission) form the specialized system for
worldwide standardization. National bodies that are members of IS0 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. IS0 and IEC technical committees collaborate in
fields of mutual interest. Other international organizations, governmental and
non-governmental, in liaison with IS0 and IEC, also take part in the work.
In the field of information technology, IS0 and IEC have established a joint
technical committee, lSO/IEC JTC 1. 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.
International Standard lSO/IEC 7816-4 was prepared by Joint Technical
Committee lSO/IEC JTC 1, information technology.
lSO/IEC 7816 consists of the following parts, under the general title Informa-
tion technology - /den tifica tion - Integrated circuit(s) cards with
cards
contacts.
- Part 7 : Physical characteristics,
- Part 2: Dimensions and location of the contacts,
- Part 3: Electronic signals and transmission protocols,
Interindustry commands for interchange,
- Part 4 :
- Part 5 : Numbering sys tern and regis tra tjon procedure for application
identifiers,
- Part 6: lnterindustry data elements.
Annexes A and B form an integral part of this part of lSO/IEC 7816. Annexes C,
D, E and F are for information only.

ISO/IEC 7816-4: 1995 (E) 0 lSO/IEC
Introduction
This part of lSO/lEC 7816 is one of a series of standards describing the
parameters for integrated circuit(s) cards with contacts and the use of such
cards for international interchange.
These cards are identification cards intended for information exchange nego-
tiated between the outside and the integrated circuit in the card. As a result of
an information exchange, the card delivers information (computation results,
stored data), and/or modifies its content (data storage, event memorization).

INTERNATIONAL STANDARD @ ‘So”EC
ISO/IEC 7816-4: 1995 (E)
Information technology -
Identification cards
- Integrated circuit(s) cards with contacts -
Part 4:
Interindustry commands for interchange
1 Scope 2 Normative references
This part of lSO/IEC 7816 specifies
The following standards contain provisions which,
through reference in this text, constitute provisions of this
-the content of the messages, commands and res-
part of lSO/IEC 7816. At the time of publication, the
ponses, transmitted by the interface device to the
editions indicated were valid. All standards are subject to
card and conversely,
revision, and parties to agreements based on this part of
- the structure and content of the historical bytes lSO/IEC 7816 are encouraged to investigate the possibility
sent by the card during the answer to reset, of applying the most recent editions of the standards
indicated below. Members of IEC and IS0 maintain
- the structure of files and data, as seen at the
registers of currently valid International Standards.
interface when processing interindustry commands
for interchange,
IS0 3166: 1993, Codes for the representation of names
-access methods to files and data in the card,
of countries.
- a security architecture defining access rights to
files and data in the card,
lSO/IEC 7812-I : 1993, identification cards - Identification
of issuers - Part 1 : Numbering system.
- methods for secure messaging,
- access methods to the algorithms processed by
lSO/IEC 7816-3 : 1989, Identification cards - Integrated
the card. It does not describe these algorithms.
circuit(s) cards with contacts - Part 3: Electronic signals
and transmission protocols.
It does not cover the internal implementation within the
card and/or the outside world.
Amendment I : 1992 to lSO/IEC 7816-3 : 1989, Protocol
type T=?, asynchronous half duplex block transmission
It allows further standardization of additional interindustry
protocol.
commands and security architectures.
ISO/IEC 7816-4: 1995 (E) 0 lSO/IEC
Amendment 2 : 1994 to lSO/IEC 7816-3 : 1989, Revision element). In this part of lSO/IEC 7816, data objects are
of protocol type selection. referred to as BER-TLV, COMPACT-TLV and SIMPLE-TLV data
objects.
lSO/lEC 7816-5 : 1994, Identification cards - Integrated
circuit(s) cards with contacts - Part 5 : Numbering sys-
3.6 dedicated file: File containing file control infor-
tem and registration procedure for application identifiers.
mation and, optionally, memory available for allocation. It
may be the parent of EFs and/or DFs.
1 ) /den tification cards - Integrated
lSO/IEC 7816-6 : -
circuit(s) cards with Contacts - Part 6: Inter-industry data
DF name: String of bytes which uniquely identifies
3.7
elements.
a dedicated file in the card.
lSO/IEC 8825: 1990 2), Information technology - Open
3.8 directory file: Elementary file defined in part 5 of
- Specification of Basic Encod-
Systems Interconnection
lSO/IEC 7816.
ing Rules for Abstract Syntax Notation One (ASN. 7).
Set of data units or records
3.9 elementary file :
lSO/IEC 9796 : 1991, Information technology - Security
which share the same file identifier. It cannot be the
techniques - Digital signature scheme giving message
parent of another file.
recovery.
eters : Logical, structural and
3.10 fi le control pa ram
lSO/IEC 9797 : 1994, Information technology - Security
attributes of a file.
security
techniques - Data integrity mechanism using a crypto-
graphic check function employing a block cipher
3.11 file identifier: A Z-bytes binary value used to
algorithm.
address a file.
lSO/IEC 9979 : 1991, Data cryptographic techniques -
3.12 file management data: Any information about a
Procedures for the registration of cryptographic algo-
file except the file control parameters (e.g., expiration
rithms.
date, application label).
ISO/IEC 10116: 1991, Information technology - Modes of
3.13 i nternal element ary file: Elementary file for
operation for an n-bit block cipher algorithm.
data interpreted by the card.
storin
g
ISO/IEC 10118-1 : 1994, Information technology -
Security techniques - Hash-functions - Part 7 : General.
3.14 master file : The mandatory unique ded icate d file
t of the file structure.
repres enting the roo
ISO/I EC 10118-Z : 1994, Information technology -
Security techniques - Hash-functions - Part 2 : Hash-
String of bytes transmitted by the
3.15 message:
functions using an n-bit block cipher algorithm.
interface device to the card or vice-versa, excluding
transmission-oriented characters as defined in part 3 of
ISO/I EC 7816.
3.16 parent file: The dedicated file immediately pre-
ceding a given file within the hierarchy.
3 Definitions
ch may be required by the
3.17 pas swor d: Data whi
to be presented to the card its user.
application
bY
For the purposes of this part of lSO/IEC 7816, the follow-
ing definitions apply.
3.18 path : Concatenation of file identifiers without
delimitation. If the path starts with the identifier of the
3.1 Answer-to-Reset file : Elementary file which
master file, it is an absolute path.
indicates operating characteristics of the card.
provid er : Authority w ho has or w ‘ho obtained the
3.19
command-respo nse pair: Set of two messages:
3.2 in the card.
right to create ad edicated file
mmand followed by a response.
a co
3.20 record: String of bytes which can be handled as a
.3 data unit : The sma llest set of bits which can be
whole by the card and referenced by a record number or
U nambiguously referen ted.
by a record identifier.
3.4 data element: Item of information seen at the
3.21 record identifier: Value associated with - a record
interface for which are defined a name, a description of
that can be used to reference that record. Several records
logical content, a format and a coding.
may have the same identifier within an elementary file.
: Information seen at the interface
3.5 data object
3.22 record number: Sequential number assigned to
which cons1 sts of a tag, a length and a value (i.e., a data
each record which uniquely identifies the record within its
elementary file.
3.23 working elementary file : Elementary file for
I) To be published.
storing data not interpreted by the card.
*) Currently under revision.
0 lSO/IEC ISO/IEC 7816-4: 1995 (E)
The logical organization of data in a card consists of the
4 Abbreviations and notation
following structural hiera rchy of dedicated files.
For the purposes of this part of lSO/IEC 7816, the follow- -The DF at the root is called the master file (MF).
ing abbreviations apply.
The MF is mandatory.
Application protocol data unit
APDU
-The other DFs are optional.
ATR Answer to reset
The following two types of EFs are defined.
BER Basic encoding rules of ASN.1 (see annex D)
- Internal EF - Those EFs are intended for storing
CLA Class byte
data interpreted by the card, i.e., data analyzed and
DIR Directory
used by the card for management and control
DF Dedicated file purposes.
EF Elementary file
Those EFs are intended for storing
- Working EF -
data not interpreted by the card, i.e., data to be used
FCI File control information
by the outside world exclusively.
FCP File control parameter
FMD File management data
Figure 1 illustrates an example of the logical file organiza-
tion in a card.
INS Instruction byte
MF Master file
PI -P2 Parameter bytes
-
PTS Protocol type selection
RFU Reserved for future use
Secure messaging
SM
SW1 -SW2 Status bytes
TLV Tag, length, value
TPDU Transmission protocol data unit
Figure 1 - Logical file organization (example)
For the purposes of this part of lSO/IEC 7816, the follow-
51.2 File referencing methods
ing notation applies.
The sixteen hexadecimal digits
‘0’ to ‘9’ and ‘A’ to ‘F’
When a file cannot be implicitly selected, it shall be possi-
ble to select it by at least one of the following methods.
Value of byte B1
(B 1
B1 II B2
Concatenation of bytes B1 (the most significant
- Referencing by file identifier - Any file may be ref-
byte) and B2 (the least significant byte)
erenced by a file identifier coded on 2 bytes. If the MF is
(B1 II B2) Value of the concatenation of bytes B1 and B2
referenced by a file identifier, ‘3FOO’ shall be used
(reserved value). The value ‘FFFF’ is reserved for future
# Number
use. The value ‘3FFF’ is reserved (see referencing by
path). In order to select unambiguously any file by its
identifier, all EFs and DFs immediately under a given DF
shall have different file identifiers.
5 Basic organizations
- Any file may be referenced by
- Referencing by path
a path (concatenation of file identifiers). The path begins
5.1 Data structures
with the identifier of the MF or of the current DF and ends
with the identifier of the file itself. Between those two
This clause contains information on the logical structure
identifiers, the path consists of the identifiers of the
of data as seen at the interface, when processing
successive parent DFs if any. The order of the file
interindustry commands for interchange. The actual
identifiers is always in the direction parent to child. If the
storage location of data and structural information
identifier of the current DF is not known, the value ‘3FFF’
beyond what is described in this clause are outside the
(reserved value) can be used at the beginning of the path.
scope of lSO/IEC 7816.
The path allows an unambiguous selection of any file
from the MF or from the current DF.
51.1 File organization
- Referencing by short EF identifier - Any EF may be
referenced by a short EF identifier coded on 5 bits valued
This part of lSO/IEC 7816 supports the following two cate-
in the range from 1 to 30. The value 0 used as a short EF
gories of files.
identifier references the currently selected EF. Short EF
- Dedicated file (DF). identifiers cannot be used in a path or as a file identifier
(e.g., in a SELECT FILE command).
- Elementary file (EF).
ISO/IEC 781’6-4: 1995 (E)
0 lSO/IEC ,
- Referencing by DF name - Any DF may be refer-
5.1.4.1 Record referencing
enced by a DF name coded on 1 to 16 bytes. In order to
select unambiguously by DF name (e.g., when selecting
Within each EF of record structure, each record can be
by means of application identifiers as defined in part 5 of
referenced by a record identifier and/or by a record
lSO/IEC 7816), each DF name shall be unique within a
number. Record identifiers and record numbers are
given card.
unsigned 8-bit integers with values in the range from ‘01’
to ‘FE’. The value ‘00’ is reserved for special purposes.
The value ‘FF’ is RFU.
51.3 Elementary file structures
Referencing by record identifier shall induce the man-
The following structures of EFs are defined.
agement of a record pointer. A reset of the card, a
- Transparent structure - The EF is seen at the SELECT FILE and any command carrying a valid short EF
interface as a sequence of data units. identifier can affect the record pointer. Referencing by
record number shall not affect the record pointer.
- Record structure - The EF is seen at the interface
as a sequence of individually identifiable records.
- Referencing by record identifier - Each record iden-
The following attributes are defined for EFs structured in tifier is provided by an application. If a record is a SIMPLE-
records. TLV data object in the data field of a message (see 5.4.4),
then the record identifier is the first byte of the data
- Size of the records : either fixed or variable.
object. Within an EF of record structure, records may
- Organization of the records: either as a sequence
have the same record identifier, in which case data
(linear structure) or as a ring (cyclic structure).
contained in the records may be used for discriminating
between them.
The card shall support at least one of the following four
methods for structuring EFs.
Each time a reference is made with a record identifier, an
indication shall specify the logical position of the target
- Transparent EF.
record: the first or last occurrence, the next or previous
- Linear EF with records of fixed size.
occurrence relative to the record pointer.
- Linear file with records of variable size.
-Within each EF of linear structure, the logical posi-
- Cyclic EF with records of fixed size.
tions shall be sequentially assigned when writing or
appending, i.e., in the order of creation. Therefore the
Figure 2 shows those four EF structures.
first created record is in the first logical position.
1 Transparent Linear fixed Linear variable Cyclic fixed
- Within each EF of cyclic structure, the logical posi-
I
tions shall be sequentially assigned in the opposite
order, i.e., the most recently created record is in the
El first logical position.
0.00.
0 The following additional rules are defined for linear struc-
tures and for cyclic structures.
Figure 2 - EF structures
NOTE -The arrow on the figure references the most recently
-The first occurrence shall be the record with the
written record.
specified identifier and in the first logical position ; the
last occurrence shall be the record with the specified
identifier and in the last logical position.
5.1.4 Data referencing methods
-When there is no current record, the next occur-
rence shall be equivalent to the first occurrence; the
Data may be referenced as records, as data units or as
previous occurrence shall be equivalent to the last
data objects. Data is considered to be stored in a single
occurrence.
continuous sequence of records (within an EF of record
structure) or of data units (within an EF of transparent
-When there is a current record, the next occur-
structure). Reference to a record or to a data unit outside
rence shall be the closest record with the specified
an EF is an error.
identifier but in a greater logical position than the cur-
rent record ; the previous occurrence shall be the
Data referencing method, record numbering method and
closest record with the specified identifier but in a
data unit size are EF-dependent features. The card can
smaller logical position than the current record.
provide indications in the ATR, in the ATR file and in any
file control information. When the card provides indica-
-The value ‘00’ shall refer to the first, last, next or
tions in several places, the indication valid for a given EF
previous record in the numbering sequence, indepen-
is the closest one to that EF within the path from the MF
dently from the record identifier.
to that EF.
0 lSO/IEC
ISO/IEC 7816-4: 1995 (E)
- Referencing by record number - Within each EF of
5.1.5 File control information
record structure, the record numbers are unique and
sequential. The file control information (FCI) is the string of data bytes
available in response to a SELECT FILE command. The file
-Within each EF of linear structure, the record num-
control information may be present for any file.
bers shall be sequentially assigned when writing or
appending, i.e., in the order of creation. Therefore the
Table 1 introduces 3 templates intended for conveying f ile
first record (record number one, # 1) is the first
control information when coded as BER-TLV data objects
created record.
- The FCP template is intended for conveying file
control parameters (FCP), i.e., any B ER-TLV data
- Within each EF of cyclic structure, the record num-
objects defined in table 2.
bers shall be sequentially assigned in the opposite
order, i.e., the first record (record number one, # 1) is
-The FMD template is intended for conveying file
the most recently created record.
management data (FMD), i.e., BER-TLV data objects
specified in other clauses of this part or in other parts
of lSO/IEC 7816 (e.g., application label as defined in
The following addi tional rule is defined for linear struc-
part 5 and application expiration date as defined in
tures and for cyclic structures.
part 6).
- The value ‘00’ shall refer to the current reco rd, i.e.,
- The FCI templa te is int ended for co nvey ing file
that record fixed by the record pointer.
control parameters and file management data.
Table 1 - Templates relevant to FCI
5.1.4.2 Data unit referencing
Value
Tag
Within each EF of transparent structure, each data unit
‘62’ File control parameters (FCP template)
can be referenced by an offset (e.g., in READ BINARY
‘64’ File management data (FMD template)
command, see 6.1). It is an unsigned integer, limited to ‘6F’ File control information (FCI template)
either 8 or 15 bits according to an option in the respective
command. Valued to 0 for the first data unit of the EF, the
The 3 templates may be retrieved according to selection
offset is incremented by 1 for every subsequent data unit.
options of the SELECT FILE command (see table 59). If the
FCP or FMD option is set, then the use of the corre-
default, i.e., if the card gives no i ndicatio n, the size of
BY
sponding template is mandatory. If the FCI option is set,
the data un it is on e byte.
then the use of the FCI template is optional.
NOTES
Part of the file control information may additionally be
present in a working EF under control of an application
1 An EF of record structure may support data unit referencing
and referenced under tag ‘87’. The use of the FCP or FCI
and, in case it does, data units may contain structural informa-
template is mandatory for the coding of file control
tion along with data, e.g., record numbers in a linear structure.
information in such an EF.
2 Within an EF of record structure, data unit referencing may
not provide the intended result because the storage order of
the records in the EF is not known, e.g., storage order in a cyclic
File control information not coded according to this part
structure.
of lSO/IEC 7816 may be introduced as follows.
- ‘00’ or any value higher than ‘9F’ - The coding of
the subsequent string of bytes is proprietary.
5.1.4.3 Data object referencing
- Tag = ‘53’ - The value field of the data object
consists of discretionary data not coded in TLV.
Each data object (as defined in 5.4.4) is headed by a tag
which references it. Tags are specified in this part and - Tag = ‘73’ - The value field of the data object
other parts of lSO/IEC 7816. consists of discretionary BER-TLV data objects.
ISO/IEC 7816-4: 1995 (E) 0 lSO/IEC
Table 2 - File control parameters
5.2 Security architecture of the card
L Value Applies to
Tag
This clause describes the following features :
2 Number of data bytes Transparen
‘80’
- security status,
in the file, excluding t EFs
structural information
- security attributes,
Any file
‘81’ 2 Number of data bytes
- security mechanisms.
in the file, including
structural information if any
‘82’ 1 Any file Security attributes are compared with the security status
File descriptor byte
(see table 3) to execute commands and/or to access files.
Any file
2 File descriptor byte followed
by data coding byte
(see table 86)
5.2.1 Security status
3 or4 File descriptor byte followed EFs with
record
by data coding byte and
Security status represents the current state possibly
structure
maximum record length
achieved after completion of
Any file
‘83’ 2 File identifier
- answer to reset (ATR) and possible protocol type
DFs
‘84’ 1 to16 DF name
selection (PTS) and/or
Any file
‘85’ var. Proprietary information
-a single command or a sequence of commands,
Any file
‘86’ var. Security attributes possibly performing authentication procedures.
(coding outside the scope
of this part of lSO/IEC 7816)
The security status may also result from the completion
Any file
‘87’ 2 Identifier of an EF containing
of a security procedure related to the identification of the
an extension of the FCI
involved entities, if any, e.g.,
RFU
‘88’ to
- by proving the knowledge of a password (e.g.,
‘9E’
using a VERIFY command),
‘9FXY’ RFU
- by proving the knowledge of a key (e.g., using a
command followed by an
- File descriptor byte GET CHALLENGE
Table 3
EXTERNAL AUTHENTICATE command).
Meaning
la8 b7 b6 b5 b4 b3 b2 bl
- by secure messaging (e.g., message authenti-
ox---- -- cation).
File accessibility
0 0 - - - - - - - Not shareable file
0 1 - - - - - - - Shareable file
Three security statuses are considered.
o-xxx- -- File type
- Global security status - It may be modified by the
completion of an MF-related authentication procedure
0 - 0 0 0 - - - -Working EF
0 - 0 0 1 - - - - Internal EF (e.g., entity authentication by a password or by a key
0 - 0 1 0 - - - - Reserved
attached to the MF).
0 - Oll--- for
0 - lOO--- proprietary
- File-specific security status - It may be modified
0 - lOl---
types
by the completion of a DF-related authentication pro-
0 - llO--- of EFs
cedure (e.g., entity authentication by a password or
0 - 1 1 1 - - - -DF
by a key attached to the specific DF) ; it may be main-
tained, recovered or lost by file selection (see 6.10.2) ;
o----xxx EF structure
this modification may be relevant only for the applica-
0 - - - - 0 0 0 - No information given
tion to which the authentication procedure belongs.
0 - - - - 0 0 1 -Transparent
0 - - - - 0 1 0 - Linear fixed, no further info
- Command-specific security status - It only exists
0 - - - - 0 I 1 - Linear fixed, SIMPLE-TLV
during the execution of a command involving authen-
o- - - - 1 oo- Linear variable, no further info
tication using secure messaging (see 5.6); such a
- Linear variable, SIMPLE-TLV
O----101
command may leave the other security status
0 - - - - 1 1 0 -Cyclic, no further info
unchanged.
0 - - - - 1 1 1 -Cyclic, SIMPLE-TLV
lxxxxxxx RFU
If the concept of logical channels is applied, the file specific
“Shareable” means that the file supports at least concurrent
security status may depend on the logical channel (see
access on different logical channels.
5.5.1).
0 lSO/IEC ISO/IEC 7816-4: 1995 (E)
5.2.2 Security attributes
5.3 APDU message structure
A step in an application protocol consists of sending a
The security attributes, when they exist, define the
command, processing it in the receiving entity and
allowed actions and the procedures to be performed to
sending back the response. Therefore a specific response
complete such actions.
corresponds to a specific command, referred to as a
command-response pair.
Security attributes may be associated with each file and
fix the security conditions that shall be satisfied to allow
An application protocol data unit (APDU) contains either a
operations on the file. The security attributes of a file
command message or a response message, sent from
depend on
the interface device to the card or conversely.
- its category (DF or EF),
In a command-response pair, the command message and
- optional parameters in its file control information
the response message may contain data, thus inducing
and/or in that of its parent file(s).
four cases which are summarized by table 4.
NOTE - Security attributes may also be associated to other
Table 4 - Data within a command-response pair
objects (e.g., keys).
Case Command data Expected response data
I
1 No data No data
5.2.3 Security mechanisms
2 No data Data
3 Data No data
4 Data Data
This part of lSO/IEC 7816 defines the following security
mechanisms.
53.1 Command APDU
- Entity authentication with password - The card
compares data received from the outside world with
Illustrated by figure 3 (see also table 6), the command
secret internal data. This mechanism may be used for
APDU defined in this part of lSO/IEC 7816 consists of
protecting the rights of the user.
-a mandatory header of 4 bytes (CLA INS PI PZ),
- Entity authentication with key - The entity to be
- a conditional body of variable length.
authenticated has to prove the knowledge of the
relevant key in an authentication procedure (e.g.,
Header Bodv
using a GET CHALLENGE command followed by an
CLA INS PI P2 [L, field] [Data field1 IL, field1
EXTERNAL AUTHENTICATE command).
Figure 3 - Command APDU structure
- Data authentication - Using internal data, either
secret or public, the card checks redundant data
The number of bytes present in the data field of the
received from the outside world. Alternately, using
command APDU is denoted by L,.
secret internal data, the card computes a data
element (cryptographic checksum or digital signature)
The maximum number of bytes expected in the data field
and inserts it in the data sent to the outside world.
of the response APDU is denoted by L, (length of ex-
This mechanism may be used for protecting the rights
pected data). When the L, field contains only zeroes, the
of a provider.
maximum number of available data bytes is requested.
- Data encipherment - Using secret internal data, Figure 4 shows the 4 structures of command APDUs
the card deciphers a cryptogram received in a data according to the 4 cases defined in table 4.
field. Alternately, using internal data, either secret or
public, the card computes a cryptogram and inserts it
Case 1
in a data field, possibly together with other data. This
mechanism may be used to provide a confidentiality
pIiz!zq
service, e.g., for key management and conditional
access. In addition to the cryptogram mechanism,
Case 2
data confidentiality can be achieved by data
Command header Le field
concealment. In this case, the card computes a string
of concealing bytes and adds it by exclusive-or to data
Case 3
bytes received from or sent to the outside world. This
mechanism may be used for protecting privacy and Lc field Data field
Command header
for reducing the possibilities of message filtering.
Case 4
1 Le field 1
1 Command header 1 Lc field 1 Data field
The result of an authentication may be logged in an inter-
nal EF according to the requirements of the application.
Figure 4 - The 4 structures of command APDUs
ISO/IEC 7816-4: 1995 (E)
0 lSO/IEC
In case 1, the length L, is null; therefore the L, field and Decoding conventions for L,
the data field are empty. The length L, is also null;
therefore the L, field is empty. Consequently, the body is If the value of L, is coded on 1 (or 2) byte(s) where the bits
empty. are not all null, then the value of L, is equal to the value of
the byte(s) which lies in the range from 1 to 255 (or
In case 2, the length L, is null; therefore the L, field and 65 535); the null value of all the bits means the maximum
the data field are empty. The length L, is not null; value of L,: 256 (or 65 536).
therefore the L, field is present. Consequently, the body
consists of the L, field.
The first 4 cases apply to all cards.
In case 3, the length L, is not null ; therefore the L, field is
present and the data field consists of the L, subsequent
Case 1 - L = 0; the body is empty.
bytes. The length L, is null ; therefore the L, field is empty.
Consequently, the body consists of the L, field followed l No byte is used for L, valued to 0.
by the data field. l No data byte is present.
l No byte is used for L, valued to 0.
In case 4, the length L, is not null ; therefore the L, field is
present and the data field consists of the L, subsequent
Case2S-L=l.
bytes. The length L, is also not null ; therefore the L, field
l No byte is used for L, valued to 0.
is also present. Consequently, the body consists of the L,
l No data byte is present.
field followed by the data field and the L,field.
l B1 codes L, valued from 1 to 256.
5.3.2 Decoding conventions for command bodies
Case 3s - L = 1 + (B,) and (B1) # 0.
l B1 codes L, (+ 0) valued from 1 to 255.
In case 1, the body of the command APDU is empty. Such
l B2 to BL are the L, bytes of the data field.
a command APDU carries no length field.
l No byte is used for L, valued to 0.
In cases 2, 3 and 4, the body of the command APDU
consists of a string of L bytes denoted by B1 to BL as Case 4s - L = 2 + (B,) and (B1) + 0.
illustrated by figure 5. Such a body carries 1 or 2 length
l B1 codes L, (+ 0) valued from 1 to 255.
fields ; B1 is [part of] the first length field.
l B2 to BLD1 are the L, bytes of the data field.
l BL codes L, from 1 to 256.
Command body
B, a. BL (L bytes)
For cards indicating the extension of L, and L, (see 8.3.6,
Figure 5 - Not empty body
card capabilities), the next 3 cases also apply.
In the card capabilities (see 8.3.6), the card states that,
Case 2E - L=3and(B1)=0.
within the command APDU, the L, field and the L, field
- either shall be short (one byte, default value),
l No byte is used for L, valued to 0.
l No data byte is present.
- or may be extended (explicit statement).
l The L, field consists of the 3 bytes where
B2 and B3 code L, valued from 1 to 65 536.
Consequently, the cases 2, 3 and 4 are either short (one
byte for each length field) or extended (B1 is valued to ‘00’
and the value of each length is coded on 2 other bytes).
Case 3E - L = 3 + (B2 II Bs), (B,) = 0 and (B2 II Bs) f: 0.
Table 5 shows the decoding of the command APDUs
l The L, field consists of the first 3 bytes where
according to the four cases defined in table 4 and figure 4
B2 and Bs code L, (z 0) valued from 1 to 65 535.
and according to the possible extension of L, and L,.
l B4 to BL are the L, bytes of the data field.
l No byte is used for L, valued to 0.
Table 5 - Decoding of the command APDUs
Conditions Case
I
Case 4E - L = 5 + (B2 II Bs), (B,) = 0 and (B2 II Bs) # 0.
IL -1 I
I
l The L, field consists of the first 3 bytes where
L=l Short 2 m
B2 and Bs code L, (+ 0) valued from 1 to 65 535.
L = l+(B,); Short 3 (39
IB, 1 z 0 ;
l B4 to BL-2 are the L, bytes of the data field.
l The L, field consists of the last 2 bytes BL-,
Short 4 (43
L = 2+(B,); (B, 1 f 0 ;
and BL which code L, valued from 1 to 65 536.
(B,)=O; - Extended 2 (2E)
L=3;
*
r
L = 3+(B2 II B3) ; (B,) = 0 ; (B2 II B3) # 0
Extended 3 (3E)
For each transmission protocol defined in part 3 of
L = 5+(B2 II B$ ; (B, ) = 0 ; (B2 II B3) # 0
Extended 4 (4E)
lSO/IEC 7816, an annex attached to this part (one per
protocol) specifies the transport of the APDUs of a
Any other command APDU is invalid.
command-response pair for each of the previous 7 cases.
0 lSO/IEC
ISO/IEC 7816-4: 1995 (E)
5.3.3 Response APDU Unless otherwise specified, in those bytes, RFU bits are
coded zero and RFU bytes are coded ‘00’.
Illustrated by figure 6 (see also table 7), the response
APDU defined in this part of lSO/IEC 7816 consists of 5.4.1 Class byte
- a conditional body of variable length,
According to table 8 used in conjunction with table 9, the
- a mandatory trailer of 2 bytes (SW1 SW2). class byte CLA of a command is used to indicate
-to what extent the command and the response
Bodv Trailer
comply with this part of lSO/IEC 7816,
[Data field1 1 SW1 SW2 1
I
- and when applicable (see table 9), the format of
secure messaging and the logical channel number.
Figure 6 - Response APDU structure
Table 8 -Coding and meaning of CLA
The number of bytes present in the data field of the
response APDU is denoted by L,. Value Meaning
‘OX’ Structure and coding of command and response
The trailer codes the status of the receiving entity after
according to this part of lSO/IEC 7816
processing the command-response pair.
(for coding of ‘X’, see table 9)
NOTE - If the command is aborted, then the response APDU is
‘10’ to ‘7F’ RFU
a trailer coding an error condition on 2 status bytes.
‘8X’, ‘9X’ Structure of command and response
according to this part of lSO/IEC 7816.
Except for ‘X’ (for coding, see table 9),
the coding and meaning of command
and response are proprietary
5.4 Coding conventions for command headers,
‘AX’ Unless otherwise specified
data fields and response trailers
by the application context,
structure and coding of command and response
according to this part of lSO/IEC 7816
Table 6 shows the contents of the command APDU.
(for coding of ‘X’, see table 9)
Table 6 - Command APDU contents
‘BO’ to ‘CF’ Structure of command and response
according to this part of lSO/IEC 7816
1 Code I Name 1 Length 1 Description
I
CLA Class 1 Class of instruction ‘DO’ to ‘FE’ Proprietary structure and coding
of command and response
INS Instruction 1 Instruction code
PI Parameter 1 1 Instruction parameter 1
‘FF’ Reserved for PTS
P2 Parameter 2 1 Instruction parameter 2
Length variable Number of bytes present in
Lc Table 9 - Coding and meaning of nibble ‘X’
field 1 or 3 the data field of the command
I I I I I
when CLA = ‘OX’, ‘8X’, ‘9X’ or ‘AX’
Data Data variable String of bytes sent in the
b4 b3 b2 bl Meaning
=
field data field of the command
L,
I I I I I
xx- - Secure messaging (SM) format
1 fikd 1 Length lvaza!le / t~{~~~~~f?~t{~~~~d /
ox- - l No SM or SM not according to 5.6
00 - - - No SM or no SM indication
Ol- - - Proprietary SM format
lx- - l Secure messaging according to 5.6
Table 7 shows the contents of the response APDU.
1 0 - - - Command header not authenticated
1 1 - - - Command header authenticated
Table 7 - Response APDU contents
(see 5.6.3.1 for command header usage)
Code Name Length Description - -
x x Logical channel number (according to 5.5)
(b2 bl = 00 when logical channels are not used
Data Data variable String of bytes received in
or when logical channel # 0 is selected)
=
field the data field of the response
Lr
SW1 Status byte 1 1 Command processing status
SW2 Status byte 2 1 Command processing qualifier
5.4.2 Instruction byte
The instruction byte INS of a command shall be coded to
allow transmission with any of the protocols defined in
The subsequent clauses specify coding conventions for
part 3 of lSO/IEC 7816. Table 10 shows the INS codes
the class byte, the instruction byte, the parameter bytes,
that are consequently invalid.
the data field bytes and the status bytes.
SIST EN
...