ISO/IEC 7816-4:1995
(Main)Information technology - Identification cards - Integrated circuit(s) cards with contacts - Part 4: Interindustry commands for interchange
Information technology - Identification cards - Integrated circuit(s) cards with contacts - Part 4: Interindustry commands for interchange
Specifies the content of the messages, commands and responses, transmitted by the interface device to the card and conversely, the structure and content of the historical bytes, structure of files and data, access methods to files and data in the card, a security architecture defining access rights to files and data in the card.
Technologies de l'information — Cartes d'identification — Cartes à circuit(s) intégré(s) à contacts — Partie 4: Commandes intersectorielles pour les échanges
La présente partie de l'ISO/CEI 7816 spécifie le contenu des messages, commandes et réponses, transmis par le dispositif d'interface à la carte et vice versa, la structure et le contenu des octets historiques émis par la carte lors de la réponse à la remise à zéro, la structure de fichiers et de données, telle qu'elle est visible à l'interface lors du traitement de commandes intersectorielles pour les échanges, des méthodes d'accès à des fichiers et à des données dans la carte, une architecture de sécurité définissant des droits d'accès à des fichiers et à des données dans la carte, des méthodes de messagerie de sécurité, des méthodes d'accès aux algorithmes traités par la carte. Ces algorithmes ne sont pas décrits. Elle ne décrit pas la mise en oeuvre dans la carte et/ou dans le monde extérieur. Elle permet encore la normalisation d'autres commandes intersectorielles et d'autres architectures de sécurité.
General Information
Relations
Frequently Asked Questions
ISO/IEC 7816-4:1995 is a standard published by the International Organization for Standardization (ISO). Its full title is "Information technology - Identification cards - Integrated circuit(s) cards with contacts - Part 4: Interindustry commands for interchange". This standard covers: Specifies the content of the messages, commands and responses, transmitted by the interface device to the card and conversely, the structure and content of the historical bytes, structure of files and data, access methods to files and data in the card, a security architecture defining access rights to files and data in the card.
Specifies the content of the messages, commands and responses, transmitted by the interface device to the card and conversely, the structure and content of the historical bytes, structure of files and data, access methods to files and data in the card, a security architecture defining access rights to files and data in the card.
ISO/IEC 7816-4:1995 is classified under the following ICS (International Classification for Standards) categories: 35.240.15 - Identification cards. Chip cards. Biometrics. The ICS classification helps identify the subject area and facilitates finding related standards.
ISO/IEC 7816-4:1995 has the following relationships with other standards: It is inter standard links to ISO 707:1997, ISO/IEC 7816-4:1995/Amd 1:1997, SIST ISO/IEC 7816-4:2005, SIST ISO/IEC 7816-5:2005, ISO/IEC 7816-9:2004, ISO/IEC 7816-8:2004, ISO/IEC 7816-5:2004, ISO/IEC 7816-4:2005; is excused to ISO/IEC 7816-4:1995/Amd 1:1997. Understanding these relationships helps ensure you are using the most current and applicable version of the standard.
You can purchase ISO/IEC 7816-4:1995 directly from iTeh Standards. The document is available in PDF format and is delivered instantly after payment. Add the standard to your cart and complete the secure checkout process. iTeh Standards is an authorized distributor of ISO standards.
Standards Content (Sample)
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.
ISO/IEC 7816-4: 1995 (E) 0 lSO/IEC
Table IO - Invalid INS codes This part of lSO/IEC 7816 supports the following two
types of TLv-coded data objects in the data fields.
b8 b7 b6 b5 b4 b3 b2 bl 1 Meaning
- BER-TLV data object.
xxxxxxxl - Odd values
- SIMPLE-TLV data object.
0110xxxx - ‘6X’
1001xxxx - ‘9X’
lSO/IEC 7816 uses neither ‘00’ nor ‘FF’ as tag value.
Table 11 shows the INS codes defined in this part of
lSO/IEC 7816. When the value of CLA lies within the
range from ‘00’ to ‘7F’, the other values of INS codes are
Each BER-TLV data object shall consist of 2 or 3 consecu-
to be assigned by lSO/IEC JTC 1 SC17.
tive fields (see lSO/IEC 8825 and annex D).
- The tag field T consists of one or more consecutive
Table 11 - INS codes defined in this part
bytes. It encodes a class, a type and a number.
of ISO/IEC 7816
-The length field consists of one or more consecu-
Command name Clause
Value
tive bytes. It encodes an integer L.
ERASE BINARY
‘OE’ 6.4
- If L is not null, then the value field V consists of L
VERIFY
‘20’ 6.12
consecutive bytes. If L is null, then the data object is
MANAGE CHANNEL empty : there is no value field.
‘70’ 6.16
EXTERNAL AUTHENTICATE
‘82’ 6.14
GET CHALLENGE
‘84’ 6.15
Each SIMPLE-TLV data object shall consist of 2 or 3 con-
INTERNAL AUTHENTICATE
‘88’ 6.13
secutive fields.
‘A4’ SELECT FILE 6.11
-The tag field T consists of a single byte encoding
READ BINARY
‘BO’ 6.1
only a number from 1 to 254 (e.g., a record identifier).
‘BZ’ READ RECORD(S) 6.5
It codes no class and no construction-type.
GET RESPONSE
7.1
‘CO’
-The length field consists of 1 or 3 consecutive
ENVELOPE
7.2
‘CZ’
bytes. If the leading byte of the length field is in the
‘CA’ 6.9 range from ‘00’ to ‘FE’, then the length field consists
GET DATA
of a single byte encoding an integer L valued from 0
WRITE BINARY
6.2
‘DO’
to 254. If the leading byte is equal to ‘FF’,
...
NORME
lSO/CEI
INTERNATIONALE
7816-4
Première édition
1995-09-01
Technologies de l’information - Cartes
d’identification - Cartes à circuit(s) intégré(s) à
contacts -
Partie 4:
Commandes intersectorielles pour les échanges
Information technology - Identification cards - Integrated circuit(s) cards with
con tacts -
Part 4: Interindustry commands for interchange
Numéro de référence
ISO/CEI 7816-43 995(F)
ISO/CEI 7816-4: 1995 (F)
Sommaire Page
. . .
............................................................. III
Avant-propos .
..................................................................................................... iv
Introduction
1 Domaine d’application . 1
2 Références normatives . . 1
3 Définitions . 2
4 Abréviations et notations . . 3
...............................................................................
5 Organisations de base
5.1 Structures des données . .
................................... ...................
5.2 Architecture de sécurité de la carte
5.3 . .
Structure des messages APDU
5.4 Conventions pour coder les préfixes de commande,
les champs de données et les suffixes de réponse . 9
................................ ................................................... 12
5.5 Canaux logiques
5.6 Messagerie de sécurité . . 12
6 Commandes intersectorielles de base . 16
6.1 Commande READ BINARY (lecture binaire) . 16
6.2 Commande WRITE BINARY (écriture binaire) . 17
6.3 Commande UPDATE BINARY (mise à jour binaire) . 18
6.4 Commande ERASE BINARY (effacement binaire) . 18
6.5 Commande READ RECORD(S) (lecture d’enregistrement) . 19
6.6 Commande WRITE RECORD (écriture d’enregistrement) . 20
6.7 Commande APPEND RECORD (ajout d’enregistrement) . 21
UPDATE RECORD (mise à jour d’enregistrement) . 22
6.8 Commande
GET DATA (obtention de données) . 23
6.9 Commande
...................................... 24
6.10 Commande PUT DATA (insertion de données)
SELECT FILE (sélection de fichier) . 25
6.11 Commande
VERIFY (vérification) . .
6.12 Commande 26
6.13 Commande INTERNAL AUTHENTICATE (authentification interne) . 27
6.14 Commande EXTERNAL AUTHENTICATE (authentification externe) .
6.15 Commande GET CHALLENGE (obtention de challenge) . 29
6.16 Commande MANAGE CHANNEL (gestion de canal) . 29
7 Commandes intersectorielles orientées transmission . 30
7.1 Commande GET RESPONSE (obtention de réponse) . 30
7.2 Commande ENVELOPE (enveloppe) . 30
...................................................................................... 31
8 Octets historiques
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9 Services de carte indépendants des applications 34
Annexes
A Acheminement des messages APDU par T=O . 36
B Acheminement des messages APDU par T=l . 40
C Gestion du pointeur d’enregistrement . 42
D Utilisation des règles de base pour coder I’ASN.1 . 43
E Exemples de profils de carte . 44
F Utilisation de la messagerie de sécurité . 46
@ lSO/CEI 1995
Droits de reproduction réservés. Sauf prescription différente, aucune partie de cette publi-
cation ne peut être reproduite ni utilisée sous quelque forme que ce soit et par aucun pro-
cédé, électronique ou mécanique, y compris la photocopie et les microfilms, sans l’accord
écrit de l’éditeur.
lSO/CEI Copyright Office l Case Postale 56 l CH-l 211 Genève 20 l Suisse
Imprimé en Suisse
ii
ISO/CEI 7816-4: 1995 (F)
0 ISO/CEI
Avant-propos
L’ISO (Organisation internationale de normalisation) et la CE1 (Commis-
sion électrotechnique internationale) forment le système spécialisé de la
normalisation mondiale. Les organismes nationaux membres de I’ISO ou
de la CEI participent au développement de Normes internationales par
l’intermédiaire des comités techniques créés par l’organisation concer-
née afin de s’occuper des domaines particuliers de l’activité technique.
Les comités techniques de I’ISO et de la CEI collaborent dans des do-
maines d’intérêt commun. D’autres organisations internationales, gou-
vernementales ou non gouvernementales, en liaison avec I’ISO et la CEI
participent également aux travaux.
Dans le domaine des technologies de l’information, I’ISO et la CEI ont
créé un comité technique mixte, I’ISO/CEI JTC 1. Les projets de Normes
internationales adoptés par le comité technique mixte sont soumis aux
organismes nationaux pour vote. Leur publication en tant que Normes in-
ternationales requiert l’approbation de 75 % au moins des organismes
nationaux votants.
La Norme internationale lSO/CEI 7816-4 a été élaborée par le comité
technique mixte lSO/CEI JTC 1, Technologies de /‘information.
L’ISO/CEI 7816 comprend les parties suivantes, présentées sous le titre
général Technologies de l’information - Cartes d’identification - Cartes
à circuit(s) intégré(s) à contacts:
- Partie ?: Caractéristiques physiques
- Partie 2: Dimensions et emplacements des contacts
- Partie 3: Signaux électroniques et protocoles de transmission
- Partie 4: Commandes intersectorielles pour les échanges
- Partie 5: Système de numérotation et procédure d’enregistrement
d ‘identificateurs d ‘applications
- Partie 6: Éléments de données in tersectoriels
Les annexes A et B font partie intégrante de la présente partie de
I’ISO/CEI 7816. Les annexes C, D, E et F sont données uniquement à
titre d’information.
. . .
Ill
ISO/CEI 7816-4: 1995 (F)
0 ISO/CEI
La présente partie de I’ISO/CEI 7816 fait partie d’une série de normes décrivant
les paramètres des cartes à circuit(s) intégré(s) à contacts, ainsi que l’utilisation
de ces cartes pour les échanges internationaux.
II s’agit de cartes d’identification destinées à l’échange d’informations entre le
monde extérieur et le circuit intégré contenu dans la carte. En résultat d’un
échange, la carte délivre des informations (résultats de calcul, données mémo-
risées) et/ou modifie son contenu (mémorisation de données ou d’événement).
NORME INTERNATIONALE @ ‘so’CE’
ISO/CEI 7816-4: 1995 (F)
Technologies de l’information - Cartes d’identification -
Cartes à circuit(s) intégré(s) à contacts -
Partie 4:
Commandes intersectorielles pour les échanges
1 Domaine d’application 2 Références normatives
Les normes suivantes contiennent des dispositions, qui
La présente partie de l’lSO/CEI 7816 spécifie
par suite de la référence qui en est faite, constituent des
- le contenu des messages, commandes et ré-
dispositions valables pour la présente partie de I’ISO/CEI
ponses, transmis par le dispositif d’interface à la carte
7816. Au moment de la publication, les éditions indiquées
et vice versa,
étaient en vigueur. Toute norme est sujette à révision et
- la structure et le contenu des octets historiques les parties prenantes des accords fondés sur la présente
émis par la carte lors de la réponse à la remise à zéro, partie de l’lSO/CEI 7816 sont invitées à rechercher la
possibilité d’appliquer l’édition la plus récente des normes
- la structure de fichiers et de données, telle qu’elle
indiquées ci-après. Les membres de la CEI et de I’ISO
est visible à l’interface lors du traitement de com-
disposent du registre des Normes internationales en
mandes intersectorielles pour les échanges,
vigueur à un moment donné.
-des méthodes d’accès à des fichiers et à des don-
nées dans la carte, ISO 3166: 1993, Codes pour la représentation des noms
.
de pays.
- une architecture de sécurité définissant des droits
d’accès à des fichiers et à des données dans la carte,
ISO/CEI 7812-1 : 1993, Cartes d’identification -
- des méthodes de messagerie de sécurité, Identification des émetteurs - Partie 1 : Système de
numérotation.
-des méthodes d’accès aux algorithmes traités par
la carte. Ces algorithmes ne sont pas décrits.
lSO/CEI 7816-3 : 1989, Cartes d’identification - Cartes à
circuit(s) intégré(s) à contacts - Partie 3 : Signaux élec-
Elle ne décrit pas la mise en œuvre dans la carte et/ou troniques et protocoles de transmission.
dans le monde extérieur.
Amendement 1 : 1992 à I’ISO/CEI 7816-3: 1989, -
Protocole de type T=l, transmission de blocs asyn-
Elle permet encore la normalisation d’autres commandes
chrones en mode semi-duplex.
intersectorielles et d’autres architectures de sécurité.
ISO/CEI 7816-4: 1995 (F) 0 ISO/CEI
Amendement 2: 1994 à I’ISO/CEI 7816-3: 1989 - 3.5 enregistrement: Train d’octets traité comme un
Révision de la sélection du type de protocole. tout par la carte et référencé par un numéro d’enre-
gistrement ou par un identifiant d’enregistrement.
lSO/CEI 7816-5: 1994, Cartes d’identification - Cartes à
3.6 fichier dédié: Fichier contenant des informations
circuit(s) intégré(s) a contacts - Partie 5: Système de
de contrôle de fichier et, le cas échéant, de la mémoire
numérotation et procédure d’enregistrement pour les
disponible. II peut être le parent de EFs et/ou de DFs.
identificateurs d’applications.
3.7 fichier élémentaire : Ensemble d’unités de don-
,
lSO/CEI 7816-6 : - 1 ) Cartes d’identification - Cartes à
nées ou d’enregistrements partageant le même identifiant
circuit(s) intégré(s) à contacts - Partie 6: Éléments de
de fichier. II ne peut pas être parent d’un autre fichier.
données in tersectoriels.
3.8 fichier élémentaire de travail : Fichier élémen-
lSO/CEI 8825: 1 9902) , Technologies de /‘information -
taire utilisé pour stocker des données qui ne sont pas
Interconnexion de systèmes ouverts - Spécification de
interprétées par la carte.
règles de base, pour coder la notation de syntaxe abs-
traite numéro une (ASN. 7).
3.9 fichi er élémentaire interne: Fichier él émentai re
utilisé pour stocker les données interp rétées par la carte
lSO/CEI 9796 : 1991, Technologies de l’information -
Schéma de signature numé-
Techniques de sécurité -
3.10 fichier maître: Fichier dédié unique et ob Iigatoire,
rique rétablissant le message.
représentant la racine de la structure de fich iers.
lSO/CEI 9797: 1994, Technologies de l’information -
3.11 fichier parent: Fichier dédié situé juste avant un
Techniques de sécurité - Mécanisme d’intégrité des
fichier
donné dans l’arborescence.
données utilisant une fonction de contrôle cryptogra-
3.12 fichier répertoire : Fichier élémentaire défini dans
phique employant un algorithme de chiffrement par blocs.
la partie 5 de l’lSO/IEC 7816.
ISO/CEI 9979 : 1991, Techniques cryptographiques de
3.13 fichier réponse à la remise à zéro : Fichier élé-
données - Procédures pour I’enregis tremen t des
mentaire indiquant des caractéristiques de fonctionne-
algorithmes cryptographiques.
ment de la carte.
lSO/CEI 10116: 1991, Technologies de l’information -
Modes d’opérations d’un algorithme de chiffrement par 3.14 fournisse ur : Autorité qui détient ou qui a obtenu le
blocs de n bits.
droit d e créer un fichier dédié dans la carte.
ISO/CEI 10118-1 : 1994, Technologies de l’information - 3.15 identifiant d’enregistrement: Valeur associée à
Techniques de sécurité - Fonctions de hachage - un enregistrement et qui peut être utilisée pour le référen-
Partie 7 : Généralités. ter. Dans un EF, plusieurs enregistrements peuvent avoir
le même identifiant d’enregistrement.
lSO/CEI 10118-2 : 1994, Technologies de l’information -
Techniques de sécurité - Fonctions de hachage - 3.16 identifiant de fichier: Valeur binaire sur deux
Partie 2 : Fonctions utilisant un algorithme de chiffrement octets, utilisée pour adresser un fichier.
par blocs de n bits.
3.17 message: Train d’octets transmis à la carte par le
dispositif d’interface ou vice versa, à l’exception des
caractères orientés transmission définis à la partie 3 de
I’ISO/CEI 7816.
3 Définitions
3.18 mot de passe: Données devant être présentées à
la carte par son utilisateur à la demande de l’application.
Pour les besoins de la présente partie de I’ISO/CEI 7816,
les définitions suivantes s’appliquent.
3.19 nom de DF: Train d’octets identifiant de façon
unique un fichier dédié dans la carte.
3.1 chemin : Concaténation d’identifiants de fichier,
sans séparateur. Si le chemin commence par l’identifiant
3.20 numéro d’enregistrement: Numéro attribué en
du fichier maître, il s’agit d’un chemin absolu.
séquence à chaque enregistrement pour l’identifier de
façon unique dans le EF auquel il appartient.
3.2 couple commande -réponse: Ensemble de deux
messages : une commande suivie d’une réponse.
Information visible à I’inter-
3.21 objet de données :
3.3 données de gestion de fichier: Toute informa- face, comprenant une étiquette, une longueur et une
valeur (c’est à dire, un élément de données). Dans la
tion concernant un fichier, à l’exception des paramètres
présente partie de I’ISO/CEI 7816, les objets de données
de contrôle du fichier (par exemple, date de péremption,
ont pour références BER-TLV, COMPACT-TLV et SIMPLE-TLV .
étiquette d’application).
3.4 élément de données: Information visible à 3.22 paramètres d e contrôle de fichier: Attributs
l’interface, pour laquelle sont définis un nom, une descrip- logiques, structurels et sécuritaires d’un fichier.
tion du contenu logique, un format et un codage.
3.23 unité de données: L .e plus petit ensemble de bits
pouvant être référencé sans am bigui’té.
l) En cours de publication.
*) En cours de révision.
0 ISO/CEI ISO/CEI 7816-4: 1995 (F)
L’organisation logique des données dans un carte est
4 Abréviations et notations
constituée de l’arborescence structurelle suivante de
fichiers dédiés.
Pour les besoins de la présente partie de l’lSO/CEI 7816,
- Le DF a la racine est appelé fichier maître (MF). Le
les abréviations suivantes s’appliquent.
MF est obligatoire.
APDU Unité de données du protocole d’application
- Les autres DFs sont facultatifs.
ATR Réponse à la remise à zéro
BER Règles de base pour coder I’ASN.1 Les 2 types suivants de EFs sont définis.
CLA Octet de classe
- EF interne - Ces EFs sont destinés a stocker des
données interprétées par la carte, c’est à dire des
DIR Répertoire
données analysées et utilisées par la carte à des fins
DF Fichier dédié
de gestion et de contrôle.
EF Fichier élémentaire
- EF de travail - Ces EFs sont destinés a stocker
FCI Information de contrôle de fichier
des données qui ne sont pas interprétées par la carte,
FCP Paramètre de contrôle de fichier c’est à dire des données qui sont utilisées
exclusivement par le monde extérieur.
FMD Données de gestion de fichier
Octet d’instruction
INS
La figur 'e 1 montre un exemple d’orga on logique des
MF Fichier maître
fichiers da ns une carte.
PI -P2 Octets de paramètre
PTS Sélection de type de protocole
RFU Réservé à un usage futur
SM Messagerie de sécurité
SWI -sw2
Octets d’état
Étiquette, longueur, valeur
TLV
Unité de données du protocole de
TPDU
transmission
Figure 1 - Organisation logique de fichiers (exemple)
Pour les besoins de la présente partie de l’lSO/CEI 7816,
les notations suivantes s’appliquent.
5.1.2 Méthodes de référence des fichiers
‘0’ a ‘9’ and ‘A’ à ‘F’ Les seize nombres hexadécimaux
Lorsqu’un fichier ne peut être implicitement sélectionné,
Valeur de l’octet B 1
(B 1
au moins l’une des méthodes suivantes doit permettre de
BI II B2 Concaténation des octets B1 (le plus significatif)
le sélectionner.
et B2 (le moins significatif)
- Référence par identifiant de fichier - Tout fichier
(B1 Il B2) Valeur de la concaténation des octets B1 et B2
peut être référencé par un identifiant codé sur 2 octets. Si
# le MF est référencé par un identifiant de fichier, la valeur
Numéro
‘3FOO’ (valeur réservée) doit être utilisée. La valeur ‘FFFF’
est RFU. La valeur ‘3FFF’ est réservée (voir référence par
chemin). Afin de sélectionner sans ambiguïté tout fichier
par son identifiant, les EFs et DFs immédiatement sous
un DF donné doivent tous avoir des identifiants différents.
5 Organisations de base
- Référence par chemin - Tout fichier peut être réfé-
rencé par un chemin (concaténation d’identifiants de
5.1 Structures des données
fichier). Le chemin commence par l’identifiant du MF ou
du DF courant et se termine par l’identifiant du fichier à
Le présent article contient des informations sur la struc-
référencer. Si d’autres identifiants figurent sur le chemin,
ture logique des données, visible à l’interface lors du
ce sont ceux des DF parents successifs. Les identifiants
traitement de commandes intersectorielles pour les
de fichier sont toujours classés en allant du parent vers
échanges. L’ISO/CEI 7816 ne couvre pas l’emplacement
l’enfant. Si l’identifiant du DF courant n’est pas connu, la
des données ainsi que diverses informations de structure
valeur ‘3FFF’ (valeur réservée) peut être utilisée au début
autres que celles présentées ici.
du chemin. Le chemin permet une sélection sans ambi-
guïté de tout fichier, à partir du MF ou du DF courant.
5.1.1 Organisation des fichiers - Référence par identifiant court de EF - Tout EF peut
être référencé par un identifiant court codé sur 5 bits et
prenant les valeurs de 1 à 30. La valeur 0 fait référence au
La présente partie de I’ISO/CEI 7816 assume les deux
fichier EF couramment sélectionné. Les identifiants courts
catégories suivantes de fichiers :
de EF ne peuvent pas être utilisés dans un chemin, ni
- fichier dédié (DF),
comme un identifiant de fichier (par exemple, dans une
- fichier élémentaire (EF). commande SELECT FILE).
ISO/CEI 7816-4: 1995 (F) 0 ISO/CEI
- Référence par nom de DF - Tout DF peut être réfé- 5.1.4.1 Référence par enregistrements
rencé par un nom codé sur 1 à 16 octets. Pour que la sé-
lection par nom de DF ne soit pas ambiguë (par exemple, Dans chaque EF à structure d’enregistrements, chaque
en sélectionnant par identifiant d’application, tels que enregistrement peut être référencé par un identifiant
défini à la partie 5 de I’ISO/CEI 7816), chaque nom de DF d’enregistrement et/ou par un numéro d’enregistrement.
doit être unique dans une carte donnée. Les identifiants d’enregistrement et les numéros d’enre-
gistrement sont représentés par des entiers non signés
sur 8 bits, pouvant prendre les valeurs de ‘01’ à ‘FE’. La
5.1.3 Structures des fichiers élémentaires
valeur ‘00’ est réservée à des usages spéciaux, la valeur
‘FF’ est RFU.
Les structures suivantes de EFs sont définies.
La référence par identifiant d’enregistrement suppose la
- Structure transparente - Le EF est visible à I’inter-
gestion d’un pointeur d’enregistrement. Une remise à
face comme une séquence d’unités de données.
zéro de la carte, une commande SELECT FILE ou toute
- Structure d’enregistrements - Le EF est visible à
commande portant un identifiant court et valide de EF
l’interface comme une séquence d’enregistrements
peut agir sur le pointeur d’enregistrement. La référence
identifiables individuellement.
par numéro d’enregistrement ne doit pas agir sur le
pointeur d’enregistrement.
Les attributs suivants sont définis pour les EFs structurés
en enregistrements.
- Référence par identifiant d’enregistrement -
- Taille des enregistrements: fixe ou variable.
Chaque identifiant d’enregistrement est attribué par une
- Organisation des enregistrements : en séquence
application. Si un enregistrement prend la forme d’un
(structure linéaire) ou en anneau (structure cyclique).
objet de données SIMPLE-TLV dans le champ de données
d’un message (voir 5.4.4), l’identifiant d’enregistrement
La carte doit assumer au moins l’une des 4 méthodes
est constitué du premier octet de l’objet de données.
suivantes de structuration de EFs :
Dans un EF à structure d’enregistrements, plusieurs enre-
gistrements peuvent avoir le même identifiant, auquel cas
- EF transparent.
les données contenues dans les enregistrements peuvent
- EF linéaire à enregistrements de taille fixe.
être utilisées pour les distinguer les uns des autres.
- EF linéaire à enregistrements de taille variable.
Chaque fois qu’une référence est faite par un identifiant
- EF cyclique à enregistrements de taille fixe.
d’enregistrement, une indication doit spécifier la position
logique de l’enregistrement cible : la première, dernière,
La figure 2 montre ces 4 structures de EFs.
prochaine ou précédente occurrence par rapport au
Transparent Linéaire fixe Linéaire variable Cyclique fixe
pointeur d’enregistrement.
- Dans chaque EF à structure linéaire, les positions
logiques doivent être attribuées en séquence lors de
El
l’écriture ou de l’ajout, c’est-à-dire suivant l’ordre de
l oooeo
création. Le premier enregistrement créé s’y trouve
\ donc en première position logique.
Figure 2 - Structures de EFs
- Dans chaque EF à structure cyclique, les positions
logiques doivent être attribuées en séquence dans
- La flèche de la figure référence le dernier enregistre-
NOTE
l’ordre inverse, c’est-à-dire que le dernier enregis-
ment écrit.
trement créé se trouve en première position logique.
5.1.4 Méthodes de référence des données De plus, les règles suivantes s’appliquent aux structures
linéaires et aux structures cycliques.
Les données peuvent être référencées en tant qu’enregis-
- La première occurrence doit être l’enregistrement
trements, unités de données ou objets de données. Les
correspondant à l’identifiant spécifié, et situé en pre-
données sont censées être stockées dans une séquence
mière position logique. La dernière occurrence doit
unique et continue d’enregistrements (dans un EF à struc-
être l’enregistrement correspondant à l’identifiant
ture d’enregistrements) ou d’unités de données (dans un
spécifié, lequel est situé en dernière position logique.
EF à structure transparente). La référence à un enregis-
- Lorsqu’il n’y a pas d’enregistrement courant, la
trement ou à une unité de données en dehors d’un EF
prochaine occurrence doit être l’équivalent de la pre-
constitue une erreur.
mière occurrence, la précédente occurrence doit être
l’équivalent de la dernière occurrence.
La méthode de référence des données, la méthode de
numérotation des enregistrements ainsi que la taille des - Lorsqu’il y a un enregistrement courant, la pro-
unités de données constituent des caractéristiques chaine occurrence doit être l’enregistrement le plus
dépendantes du EF. La carte peut fournir des indications proche de même identifiant et situé dans une position
dans I’ATR, dans le fichier ATR ainsi que dans toute
logique supérieure à l’enregistrement courant.
information de contrôle de fichier. Si la carte fournit des
L’occurrence précédente doit être l’enregistrement le
indications en différents endroits, l’indication devant être
plus proche de même identifiant et situé dans une
retenue pour un EF donné est celle qui se situe au plus
position logique inférieure à celle de l’enregistrement
près de celui-ci dans le chemin à partir du MF jusqu’au EF.
courant.
0 ISO/CEI ISO/CEI 7816-4: 1995 (F)
- La valeur ‘00’ doit référencer le premier, dernier, 5.1.5 Information de contrôle de fichier
prochain ou précédent enregistrement dans la
séquence de numérotation, indépendamment de L’information de çontrôle de fichier (FCI) est constituée du
l’identifiant d’enregistrement. train d’octets de données disponible dans la réponse a
une commande SELECT FILE. L’information de contrôle de
fichier peut être présente pour n’importe quel fichier.
- Référence par numéro d’enregistrement - Dans
chaque EF à structure d’enregistrements, les numéros
d’enregistrement sont uniques et séquentiels. Le tableau 1 montre trois gabarits destinés au transport
de l’information de contrôle de fichier lorsqu’elle est
- Dans chaque EF à structure linéaire, les numéros
codée en objets de données BER-TLV.
d’enregistrement doivent être attribués en séquence
lors de l’écriture ou de l’ajout, c’est-a-dire suivant - Le gabarit FCP est destine au transport de para-
l’ordre de création. Le premier enregistrement mètres de contrôle de fichier (FCP), c’est-a-dire tout
(enregistrement numéro un, # 1) est donc le premier objet de données défini dans le tableau 2.
créé.
- Le gabarit FMD est destine au transport de
- Dans chaque EF à structure cyclique, les numéros données de gestion de fichier (FMD), c’est-a-dire les
d’enregistrement doivent être attribués en séquence objets de données BER-TLV spécifiés dans d’autres
dans l’ordre inverse, c’est-a-dire que le premier enre- articles de la présente partie de I’ISO/CEI 7816 ou
gistrement (enregistrement numéro un, # 1) est le dans d’autres parties de cette même norme (par
dernier créé. exemple, l’étiquette d’application définie dans la partie
5 et la date de péremption d’application définie dans
De plus, I a règle suivante s’appl ique aux structures la partie 6).
linéaires et aux stru ctures cyc Ii ques.
- Le gabarit FCI est destine au transport de para-
- La valeur ‘00’ doit référencer l’enregistrement cou- mètres de contrôle de fichier et de données de
rant, c’est-à-dire celui fixé par le pointeur d’enregis- gestion de fichier.
trement.
Tableau 1 - Gabarits pour FCI
I T I
5.1.4.2 Référence par unités de données
‘62’ Paramètres de contrôle de fichier (gabarit FCP)
‘64’ Données de gestion de fichier (gabarit FMD)
Dans chaque fichier EF à structure transparente, chaque
‘6F’ Information de contrôle de fichier (gabarit FCI)
I I
unité de données peut être référencée par un déplace-
ment (par exemple, dans une commande READ BINARY,
voir 6.1). Celui-ci prend la forme d’un entier non signé,
Les options de sélection de la commande SELECT FILE (voir
codé sur 8 ou 15 bits selon l’option spécifiée dans la
tableau 59) permettent de préciser lequel des 3 gabarits
commande respective. Prenant la valeur 0 pour la pre-
est requis. Si l’option FCP ou FMD est positionnée,
mière unité de données du EF, le déplacement s’accroît
l’utilisation du gabarit correspondant est obligatoire. Si
de 1 pour chaque unité de données suivante.
l’option FCI est positionnée, l’utilisation du gabarit FCI est
facultative.
Par défaut, c’est-à-dire si la carte ne fournit aucune indica-
tion, la taille de l’unité de données est de un octet.
Une partie de l’information de contrôle de fichier peut
aussi se trouver dans un EF de travail sous le contrôle
NOTES
d’une application. L’identifiant du EF est donne sous I’éti-
1 Un EF structuré en enregistrements peut accepter la réfé- quette ‘87’. Quand de l’information de contrôle de fichier
rence par unités de données, et si tel est le cas, les unités de
se trouve dans un EF de travail, son codage requiert
données peuvent contenir des informations de structure en plus
l’emploi d’un gabarit, FCP ou FCI.
des données (par exemple, des numéros d’enregistrement dans
une structure linéaire).
Des informations de contrôle de fichier qui ne sont pas
2 Dans un EF structuré en enregistrements, il se peut que la
codées conformément à la présente partie de I’ISO/CEI
référence par unités de données ne donne pas le résultat
7816, peuvent être introduites comme suit.
escompté car l’ordre de stockage des enregistrements n’est pas
connu (dans une structure cyclique par exemple).
à ‘9F’ - Le codage
‘00’ ou toute valeur supérieure
du train d’ octets qui suit est privé.
- Étiquette = ‘53’ - Le champ de valeur de l’objet de
5.1.4.3 Référence par objets de données
données est constitué de données libres non codées
en TLV.
Chaque objet de données (tel que défini dans 5.4.4) débute
- Étiquette = ‘73’ - Le champ de valeur de l’objet de
par une étiquette qui le référence. Les étiquettes sont dé-
crites dans la présente partie de I’ISO/CEI 7816 ainsi que données est constitué d’objets de données libres
dans d’autres parties de la même norme. codés en BER-TLV.
0 lSO/CEI
ISO/CEI 7816-4: 1995 (F)
Tableau 2 - Paramètres de contrôle de fichier
5.2 Architecture de sécurité de la carte
T L v S’applique à 1
Le présent article décrit les éléments suivants:
EFs transpa-
‘80’ 2 Nombre d’octets de données
- états de sécurité,
rents
dans le fichier, à l’exception des
- attributs de sécurité,
informations de structure
- mécanismes de sécurité.
Tout fichier
‘81’ 2 Nombre d’octets de données
dans le fichier, y compris les in-
Lors de l’exécution de commandes et/ou lors de l’accès à
formations de structure s’il y en a
des fichiers, les attributs de sécurité sont comparés à
Tout fichier
‘82’ 1 Octet de description de fichier
l’état de sécurité.
(voir le tableau 3)
Tout fichier
2 Octet de description de fichier
5.2.1 États de sécurité
suivi de l’octet de codage de
données (voir le tableau 86)
L’état de sécurité courant représente l’état atteint après la
3 Octet de description de fichier
complète exécution
ou suivi de l’octet de codage de
4 données et de la longueur maxi-
- de la réponse à la remise à zéro (ATR) et, le cas
mum des enregistrements
échéant, de la sélection d’un type de protocole (PTS),
‘83’ 2 Identifiant de fichier 1 Tout fichier 1
- et/ou d’une ou plusieurs commandes exécutant le
DFs cas échéant des procédures d’authentification.
‘84’ 1 à Nom de DF
I I
L’état de sécurité peut également résulter de I’achève-
‘85’ var. Information privée 1 Tout fichier 1
ment d’une procédure de sécurité visant à identifier les
‘86’ var. Attributs de sécurité (codage non r Toi< fichier /
entités concernées, si elles existent. Cette identification
décrit dans la présente partie de
peut consister par exemple à
I’ISO/IEC 7816)
- prouver la connaissance d’un mot de passe (par
‘87’ 2 Identifiant d’un EF contenant Tout fichier
VERIFY),
exemple à l’aide de la commande
une extension de la FCI
- prouver la connaissance d’une clé (par exemple à
‘88’
l’aide d’une commande GET CHALLENGE suivie d’une
\
RFU
commande EXTERNAL AUTHENTICATE).
GE’
- utiliser la messagerie de sécurité (par exemple en
‘9F RFU
authentification de message).
XY’
Trois états de sécurité sont considérés.
Tableau 3 - Octet de description de fichier
- État de sécurité global - II peut être modifié par
-
l’achèvement d’une procédure d’authentification liée
Signification
b8 b7 b6 b5 b4 b3 b2 bl
au MF (authentification à l’aide d’un mot de passe ou
0x---- -- d’une clé attachés au MF, par exemple).
Accès au fichier
00 - - - - - -
- Fichier non partageable
- État de sécurité spécifique à un fichier - II peut
OI- - - - - -
- Fichier partageable
être modifié par l’achèvement d’une procédure
d’authentification liée au DF (authentification à l’aide
o-xxx- -- Type du fichier
d’un mot de passe ou d’une clé attachés au DF, par
0 - ooo--- - EF de travail
exemple) ; il peut être maintenu, retrouvé ou perdu
0 - OOl--- - EF interne
après une sélection de fichier (voir 6.10.2) ; la portée
0 - OlO--- - Réservés
de cette modification peut être limitée à l’application à
0 - Oll--- aux
laquelle appartient la procédure d’authentification.
0 - lOO--- EFs
0 - lOl--- de type
- État de sécurité spécifique à une commande - Il
0 - llO--- privé
existe uniquement pendant l’exécution d’une com-
0 - 1 1 1 - - - - DF
mande comprenant une authentification à l’aide de la
messagerie de sécurité (voir 5.6). Ce type de com-
o- - - - xxx
Structure du EF
mande peut n’avoir aucune incidence sur les autres
o----o00 - Aucune précision
états de sécurité.
o----o01 -Transparent
o- - - -0 10 - Linéaire fixe, sans précision
Lorsque le concept de canaux logiques est utilise, l’état de
o- - - -0 11 - Linéaire fixe, SIMPLE-TLV
sécurité spécifique à un fichier peut dépendre du canal
o-- --100
- Linéaire variable, sans précision
()- - - - logique (voir 5.5.1).
1 0 1 - Linéaire variable, SIMPLE-TLV
o- - - - II 0
- Cyclique, sans précision
o- - - - III - Cyclique, SI MPLE-TLV
5.2.2 Attributs de sécurité
Ixxxxxxx RFU
Lorsqu’ils existent, les attributs de sécurité définissent les
“Partageable” signifie que le fichier accepte au moins des accès
actions autorisées ainsi que les procédures à exécuter
simultanés sur différents canaux logiques.
pour accomplir ces actions.
0 ISO/CEI
ISO/CEI 7816-4: 1995 (F)
Les attributs de sécurité peuvent être associés a chaque Une unité de données du protocole d’application (APDU)
fichier. Ils fixent les conditions de sécurité devant être contient un message, de commande ou de réponse,
satisfaites pour opérer sur le fichier. Les attributs de transmis par le dispositif d’interface a la carte ou vice
sécurité d’un fichier dépendent de versa.
- sa catégorie (DF ou EF),
Dans un couple commande-réponse, les messages de
- de paramètres facultatifs contenus dans les infor-
commande et de réponse peuvent contenir des données,
mations de contrôle du fichier et/ou dans celles du ou
ce qui se traduit par les quatre cas figurant au tableau 4.
des fichiers parents.
NOTE - Des attributs de sécurité peuvent aussi être associés à Tableau 4 -
Présence de données
d’autres objets (par exemple des clés).
dans un couple commande-réponse
1 Cas 1 Données de commande 1 Données attendues en réponse
52.3 Mécanismes de sécurité
1 Aucune donnée
Aucune donnée
Aucune donnée Données
3 Données
Aucune donnée
La présente partie de I’ISO/CEI 7816 définit les méca-
Données Données
nismes de sécurité suivants.
- Authentification d’entité par mot de passe - La
carte compare des données provenant du monde
53.1 Commande APDU
extérieur à des données secrètes internes. Ce méca-
nisme permet de protéger les droits de l’utilisateur.
La commande APDU, illustrée par la figure 3 (voir aussi le
tableau 6) et définie dans la présente partie de
- Authentification d’entité par clé - L’entité à au-
l’lSO/CEI 7816, est constituée de
thentifier doit prouver qu’elle connaît une clé, grâce à
une procédure d’authentification (une commande GET
- un préfixe obligatoire de 4 octets (CLA INS PI PZ),
CHALLENGE suivie d’une commande EXTERNAL
- un corps conditionnel de longueur variable.
AUTHENTICATE, par exempk).
- Authentification de données -À l’aide de don-
Préfixe
Coms
nées internes, secrètes ou publiques, la carte vérifie
1 CLA INS PI P2 1 [champ L,l [champ de données1 [champ L,l 1
des données redondantes reçues du monde extérieur.
Ou encore, à l’aide de données internes secrètes, la
Figure 3 - Structure de la commande APDU
carte calcule un élément de données (élément de
contrôle cryptographique ou signature numérique) et
Le nombre d’octets présents dans le champ de données
l’insère dans les données transmises au monde
de la commande APDU est indiqué par L,.
extérieur. Ce mécanisme permet de protéger les
droits d’un fournisseur.
Le nombre maximal d’octets attendu dans le champ de
données de la réponse APDU est indiqué par Le (longueur
- Chiffrement de données - À l’aide de données
des données attendues). Lorsque le champ Le ne contient
internes secrètes, la carte déchiffre un cryptogramme
que des zéros, le nombre maximal d’octets de données
reçu dans un champ de données. Ou encore, à l’aide
disponibles est requis.
de données internes, secrètes ou publiques, la carte
calcule un cryptogramme et l’insère dans un champ
La figure 4 montre les 4 structures de commandes APDU,
de données pouvant contenir d’autres informations.
en fonction des 4 cas définis au tableau 4.
Ce mécanisme peut être utilisé comme service de
confidentialité, tel que la gestion de clé ou l’accès
conditionnel. Outre le mécanisme de cryptogramme,
Cas 1
la confidentialité des données peut être obtenue par
masquage. Dans ce cas, la carte produit un train \Préfixe1
d’octets masquants et l’ajoute par ou exclusif avec
des octets de données reçus du monde extérieur ou Cas 2
transmis vers celui-ci. Ce mécanisme peut être utilisé
pour protéger la confidentialité et pour réduire les
possibilités de filtrage de messages.
Cas 3
Préfixe Champ L,
Champ de données
Le résultat d’une authentification peut être consigné dans
un EF interne, en fonction des besoins de l’application.
Cas 4
Préfixe Champ L, Champ Le
Champ de données
5.3 Structure des messages APDU
Figure 4 - Les 4 structures de commandes APDU
Une étape dans un protocole d’application est constituée
de l’envoi d’une commande, du traitement de cette com-
Dans le cas 1, la longueur L, est nulle, ce qui implique que
mande dans l’entité réceptrice et de la transmission de la
le champ L, et le champ de données sont vides. La
réponse. Une réponse spécifique correspond donc à une
longueur Le est nulle aussi, ce qui implique que le champ
commande spécifique, ces deux éléments étant appelés
Le est vide. Le corps de la commande est donc vide.
couple commande-réponse.
ISO/CEI 7816-4: 1995 (F)
0 ISO/CEI
Dans le cas 2, la longueur L, est nulle, ce qui implique que Conventions pour décoder L,
le champ L, et le champ de données sont vides. La
Si la valeur de Le est codée sur un ou deux octets dans
longueur L, n’est pas nulle, ce qui implique que le champ
lesquels les bits ne sont pas nuls, cette valeur est égale à
L, est présent. Le corps de la commande est donc
celle du ou des octets, qui se situe dans la fourchette de 1
constitué d’un champ Le.
à 255 (ou 65 535). Une valeur nulle dans tous les octets
correspond à la valeur maximale de L,: 256 (ou 65 536).
Dans le cas 3, la longueur L, n’est pas nulle, ce qui
implique que le champ L, est présent et que le champ de
données est constitué des L, octets suivants. La longueur
Les 4 premiers cas s’appliquent à toutes les cartes.
Le est nulle, ce qui implique que le champ Le est vide. Le
corps de la commande est donc constitué d’un champ L,
Cas 1 - L = 0 ; le corps est vide.
suivi d’un champ de données.
l Aucun octet pour L, qui vaut 0.
l Pas d’octet de données.
Dans le cas 4, la longueur L, n’est pas nulle, ce qui
l Aucun octet pour L, qui vaut 0.
implique que le champ L, est présent et le champ de
données constitué des L, octets suivants. La longueur L,
Cas 2s -L=l.
n’est pas nulle, ce qui implique que le champ Le est
également présent. Le corps de la commande est donc
l Aucun octet pour L, qui vaut 0.
constitué d’un champ L, suivi d’un champ de données puis
l Pas d’octet de données.
d’un champ Le.
l B1 code L, qui vaut de 1 à 256.
Cas 3s
- L = 1 + (Bj) et (B ,,) # 0.
5.3.2 Conventions pour décoder les corps de
l B1 code L, (# 0) qui vaut de 1 à 255.
commande
l B2 à BL sont les L, octets de données.
l Aucun octet pour L, qui vaut 0.
Dans le cas 1, le corps de commande APDU est vide. Une
telle commande ne comporte aucun champ de longueur.
Cas 4s - L = 2 + (B1) et (B,) ;t 0.
Dans les cas 2, 3 et 4, le corps de commande APDU est
l B1 code L, (# 0) qui vaut de 1 à 255.
constitué d’un train de L octets, appelés B1 à BL comme
l B2 à BL-1 sont les L, octets de données.
l’illustre la figure 5. Un tel corps comporte 1 ou 2 champs
l BL code L, qui vaut de 1 à 256.
de longueur et B 1 fait toujours partie du premier.
Pour les cartes acceptant l’extension de L, et L, (voir
Corps de commande APDU
8.3.6, capacités des cartes), les trois cas suivants s’appli-
B, . . . B,- (L octets)
quent en plus.
Figure 5 - Corps non vide
Cas 2E - L = 3 et (B,) = 0.
La carte indique, parmi ses capacités (voir 8.3.6), que dans
l Aucun octet pour L, qui vaut 0.
les commandes APDU le champ L, et le champ L,
l Pas d’octet de données.
- doivent être courts (un octet, valeur par défaut),
l Le champ L, est constitué de 3 octets où
B2 et B3 codent L, qui vaut de 1 à 65 536.
- ou bien peuvent être étendus (instruction explicite).
Par conséquent, les cas 2, 3 et 4 sont courts (1 octet par
Cas 3E
- L = 3 + (B2 II BS), (B1) = 0 et (B2 Il Bs) + 0.
champ de longueur) ou étendus (B1 a pour valeur ‘00’ et la
l Le champ L, est constitué des 3 premiers
valeur de chaque longueur est codée sur 2 autres octets).
octets où B 2 et B3 codent L, (# 0) qui vaut
de 1 à 65 535.
Le tableau 5 montre le décodage des commandes APDU,
l B4 à BL sont les L, octets de données.
selon les quatre cas définis dans le tableau 4 et la figure 4,
l Aucun octet pour L, qui vaut 0.
en tenant compte de l’extension possible de L, et de L,.
Cas 4E - L = 5 + (B2 II Bs), (B1) = 0 et (B2 II BS) + 0.
Tableau 5 - Décodage des commandes APDU
l Le champ L, est constitué des 3 premiers
Conditions Cas
octets où B2 et Bs codent L, (# 0) qui vaut
L=O 1
del à65535.
l B4 à BL-2 sont les L, octets de données.
L=l Court 2 1 (2s)
l Le champ L, est constitué des 2 derniers
L = l+(B,); (B, If 0 * Court 3 (3%
octets BLD1 et BL qui codent L, valant de
1 à65536.
L = 2+(B,); (B,)#O’ , Court 4 (49
L=3; (B,)=O; - Étendu 2 (2E)
Pour chaque protocole de transmission défini dans la
L = 3+(B2 II BS) ; (B,) = 0 ; (B2 II B3) + o Étendu 3 (3E)
partie 3 de l’lSO/CEI 7816, une annexe rattachée à cette
partie (une annexe par protocole) spécifie le transport des
L = 5+(B2 II B3) ; (B,) = 0 ; (B2 II B3) + o Étendu 4 (4E)
messages APDUs d’un couple commande-réponse, pour
Toute autre commande APDU est incorrecte.
chacun des sept cas évoqués ci-dessus.
0 lSO/CEI
ISO/CEI 7816-4: 1995 (F)
5.3.3 Réponse APDU Sauf indication contraire, les bits RFU de ces octets sont
mis à zéro et les octets RFU a ‘00’.
Illustrée par la figure 6 (voir aussi le tableau 7), la réponse
APDU définie dans la présente partie de I’ISO/CEI 7816,
5.4.1 Octet de classe
est constituée de
- un corps conditionnel de longueur variable,
Comme le montrent conjointement les tableaux 8 et 9,
l’octet de classe (CLA) d’une commande est utilisé pour
- un suffixe obligatoire de 2 octets (SWI SW2).
indiquer
Corps Suffixe
-dans quelle mesure la commande et la réponse
[Champ de données] 1 SWI sw2 1
sont conformes a la présente partie de I’ISO/CEI
7816,
Figure 6 -
Structure des réponses APDU
- et le cas échéant (voir tableau 9), le format de la
Le nombre d’octets présents dans le champ de données
messagerie de sécurité et le numéro du canal logique.
de la réponse APDU est appelé L,.
Tableau 8
- Codage et signification de CLA
Le suffixe code l’état de l’entité réceptrice après
Valeur Signification
traitement du couple commande-réponse.
‘0X’ Structure et codage
NOTE - Si la commande est interrompue, la réponse APDU se
de la commande et de la réponse
limite à un suffixe codant une condition d’erreur sur 2 octets
conformes à la présente partie de I’ISO/IEC 7816
d’état.
(pour coder ‘X’, voir le tableau 9)
‘10’ à ‘7F’
RFU
5.4 Conventions pour coder les préfixes de
‘8X’, ‘9X’
Structure de la commande et de la réponse
commande, les champs de données et les suffixes
conforme à la présente partie de I’ISO/IEC 7816.
de réponse
Sauf pour ‘X’ (pour le coder, voir le tableau 9),
le codage et la signification de la commande
Le tableau 6 montre le contenu de la commande APDU.
et de la réponse sont privés.
- Contenu de la commande APDU
Tableau 6 ‘AX’
Sauf indication contraire dans le contexte
de l’a
...
NORME
lSO/CEI
INTERNATIONALE
7816-4
Première édition
1995-09-01
Technologies de l’information - Cartes
d’identification - Cartes à circuit(s) intégré(s) à
contacts -
Partie 4:
Commandes intersectorielles pour les échanges
Information technology - Identification cards - Integrated circuit(s) cards with
con tacts -
Part 4: Interindustry commands for interchange
Numéro de référence
ISO/CEI 7816-43 995(F)
ISO/CEI 7816-4: 1995 (F)
Sommaire Page
. . .
............................................................. III
Avant-propos .
..................................................................................................... iv
Introduction
1 Domaine d’application . 1
2 Références normatives . . 1
3 Définitions . 2
4 Abréviations et notations . . 3
...............................................................................
5 Organisations de base
5.1 Structures des données . .
................................... ...................
5.2 Architecture de sécurité de la carte
5.3 . .
Structure des messages APDU
5.4 Conventions pour coder les préfixes de commande,
les champs de données et les suffixes de réponse . 9
................................ ................................................... 12
5.5 Canaux logiques
5.6 Messagerie de sécurité . . 12
6 Commandes intersectorielles de base . 16
6.1 Commande READ BINARY (lecture binaire) . 16
6.2 Commande WRITE BINARY (écriture binaire) . 17
6.3 Commande UPDATE BINARY (mise à jour binaire) . 18
6.4 Commande ERASE BINARY (effacement binaire) . 18
6.5 Commande READ RECORD(S) (lecture d’enregistrement) . 19
6.6 Commande WRITE RECORD (écriture d’enregistrement) . 20
6.7 Commande APPEND RECORD (ajout d’enregistrement) . 21
UPDATE RECORD (mise à jour d’enregistrement) . 22
6.8 Commande
GET DATA (obtention de données) . 23
6.9 Commande
...................................... 24
6.10 Commande PUT DATA (insertion de données)
SELECT FILE (sélection de fichier) . 25
6.11 Commande
VERIFY (vérification) . .
6.12 Commande 26
6.13 Commande INTERNAL AUTHENTICATE (authentification interne) . 27
6.14 Commande EXTERNAL AUTHENTICATE (authentification externe) .
6.15 Commande GET CHALLENGE (obtention de challenge) . 29
6.16 Commande MANAGE CHANNEL (gestion de canal) . 29
7 Commandes intersectorielles orientées transmission . 30
7.1 Commande GET RESPONSE (obtention de réponse) . 30
7.2 Commande ENVELOPE (enveloppe) . 30
...................................................................................... 31
8 Octets historiques
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9 Services de carte indépendants des applications 34
Annexes
A Acheminement des messages APDU par T=O . 36
B Acheminement des messages APDU par T=l . 40
C Gestion du pointeur d’enregistrement . 42
D Utilisation des règles de base pour coder I’ASN.1 . 43
E Exemples de profils de carte . 44
F Utilisation de la messagerie de sécurité . 46
@ lSO/CEI 1995
Droits de reproduction réservés. Sauf prescription différente, aucune partie de cette publi-
cation ne peut être reproduite ni utilisée sous quelque forme que ce soit et par aucun pro-
cédé, électronique ou mécanique, y compris la photocopie et les microfilms, sans l’accord
écrit de l’éditeur.
lSO/CEI Copyright Office l Case Postale 56 l CH-l 211 Genève 20 l Suisse
Imprimé en Suisse
ii
ISO/CEI 7816-4: 1995 (F)
0 ISO/CEI
Avant-propos
L’ISO (Organisation internationale de normalisation) et la CE1 (Commis-
sion électrotechnique internationale) forment le système spécialisé de la
normalisation mondiale. Les organismes nationaux membres de I’ISO ou
de la CEI participent au développement de Normes internationales par
l’intermédiaire des comités techniques créés par l’organisation concer-
née afin de s’occuper des domaines particuliers de l’activité technique.
Les comités techniques de I’ISO et de la CEI collaborent dans des do-
maines d’intérêt commun. D’autres organisations internationales, gou-
vernementales ou non gouvernementales, en liaison avec I’ISO et la CEI
participent également aux travaux.
Dans le domaine des technologies de l’information, I’ISO et la CEI ont
créé un comité technique mixte, I’ISO/CEI JTC 1. Les projets de Normes
internationales adoptés par le comité technique mixte sont soumis aux
organismes nationaux pour vote. Leur publication en tant que Normes in-
ternationales requiert l’approbation de 75 % au moins des organismes
nationaux votants.
La Norme internationale lSO/CEI 7816-4 a été élaborée par le comité
technique mixte lSO/CEI JTC 1, Technologies de /‘information.
L’ISO/CEI 7816 comprend les parties suivantes, présentées sous le titre
général Technologies de l’information - Cartes d’identification - Cartes
à circuit(s) intégré(s) à contacts:
- Partie ?: Caractéristiques physiques
- Partie 2: Dimensions et emplacements des contacts
- Partie 3: Signaux électroniques et protocoles de transmission
- Partie 4: Commandes intersectorielles pour les échanges
- Partie 5: Système de numérotation et procédure d’enregistrement
d ‘identificateurs d ‘applications
- Partie 6: Éléments de données in tersectoriels
Les annexes A et B font partie intégrante de la présente partie de
I’ISO/CEI 7816. Les annexes C, D, E et F sont données uniquement à
titre d’information.
. . .
Ill
ISO/CEI 7816-4: 1995 (F)
0 ISO/CEI
La présente partie de I’ISO/CEI 7816 fait partie d’une série de normes décrivant
les paramètres des cartes à circuit(s) intégré(s) à contacts, ainsi que l’utilisation
de ces cartes pour les échanges internationaux.
II s’agit de cartes d’identification destinées à l’échange d’informations entre le
monde extérieur et le circuit intégré contenu dans la carte. En résultat d’un
échange, la carte délivre des informations (résultats de calcul, données mémo-
risées) et/ou modifie son contenu (mémorisation de données ou d’événement).
NORME INTERNATIONALE @ ‘so’CE’
ISO/CEI 7816-4: 1995 (F)
Technologies de l’information - Cartes d’identification -
Cartes à circuit(s) intégré(s) à contacts -
Partie 4:
Commandes intersectorielles pour les échanges
1 Domaine d’application 2 Références normatives
Les normes suivantes contiennent des dispositions, qui
La présente partie de l’lSO/CEI 7816 spécifie
par suite de la référence qui en est faite, constituent des
- le contenu des messages, commandes et ré-
dispositions valables pour la présente partie de I’ISO/CEI
ponses, transmis par le dispositif d’interface à la carte
7816. Au moment de la publication, les éditions indiquées
et vice versa,
étaient en vigueur. Toute norme est sujette à révision et
- la structure et le contenu des octets historiques les parties prenantes des accords fondés sur la présente
émis par la carte lors de la réponse à la remise à zéro, partie de l’lSO/CEI 7816 sont invitées à rechercher la
possibilité d’appliquer l’édition la plus récente des normes
- la structure de fichiers et de données, telle qu’elle
indiquées ci-après. Les membres de la CEI et de I’ISO
est visible à l’interface lors du traitement de com-
disposent du registre des Normes internationales en
mandes intersectorielles pour les échanges,
vigueur à un moment donné.
-des méthodes d’accès à des fichiers et à des don-
nées dans la carte, ISO 3166: 1993, Codes pour la représentation des noms
.
de pays.
- une architecture de sécurité définissant des droits
d’accès à des fichiers et à des données dans la carte,
ISO/CEI 7812-1 : 1993, Cartes d’identification -
- des méthodes de messagerie de sécurité, Identification des émetteurs - Partie 1 : Système de
numérotation.
-des méthodes d’accès aux algorithmes traités par
la carte. Ces algorithmes ne sont pas décrits.
lSO/CEI 7816-3 : 1989, Cartes d’identification - Cartes à
circuit(s) intégré(s) à contacts - Partie 3 : Signaux élec-
Elle ne décrit pas la mise en œuvre dans la carte et/ou troniques et protocoles de transmission.
dans le monde extérieur.
Amendement 1 : 1992 à I’ISO/CEI 7816-3: 1989, -
Protocole de type T=l, transmission de blocs asyn-
Elle permet encore la normalisation d’autres commandes
chrones en mode semi-duplex.
intersectorielles et d’autres architectures de sécurité.
ISO/CEI 7816-4: 1995 (F) 0 ISO/CEI
Amendement 2: 1994 à I’ISO/CEI 7816-3: 1989 - 3.5 enregistrement: Train d’octets traité comme un
Révision de la sélection du type de protocole. tout par la carte et référencé par un numéro d’enre-
gistrement ou par un identifiant d’enregistrement.
lSO/CEI 7816-5: 1994, Cartes d’identification - Cartes à
3.6 fichier dédié: Fichier contenant des informations
circuit(s) intégré(s) a contacts - Partie 5: Système de
de contrôle de fichier et, le cas échéant, de la mémoire
numérotation et procédure d’enregistrement pour les
disponible. II peut être le parent de EFs et/ou de DFs.
identificateurs d’applications.
3.7 fichier élémentaire : Ensemble d’unités de don-
,
lSO/CEI 7816-6 : - 1 ) Cartes d’identification - Cartes à
nées ou d’enregistrements partageant le même identifiant
circuit(s) intégré(s) à contacts - Partie 6: Éléments de
de fichier. II ne peut pas être parent d’un autre fichier.
données in tersectoriels.
3.8 fichier élémentaire de travail : Fichier élémen-
lSO/CEI 8825: 1 9902) , Technologies de /‘information -
taire utilisé pour stocker des données qui ne sont pas
Interconnexion de systèmes ouverts - Spécification de
interprétées par la carte.
règles de base, pour coder la notation de syntaxe abs-
traite numéro une (ASN. 7).
3.9 fichi er élémentaire interne: Fichier él émentai re
utilisé pour stocker les données interp rétées par la carte
lSO/CEI 9796 : 1991, Technologies de l’information -
Schéma de signature numé-
Techniques de sécurité -
3.10 fichier maître: Fichier dédié unique et ob Iigatoire,
rique rétablissant le message.
représentant la racine de la structure de fich iers.
lSO/CEI 9797: 1994, Technologies de l’information -
3.11 fichier parent: Fichier dédié situé juste avant un
Techniques de sécurité - Mécanisme d’intégrité des
fichier
donné dans l’arborescence.
données utilisant une fonction de contrôle cryptogra-
3.12 fichier répertoire : Fichier élémentaire défini dans
phique employant un algorithme de chiffrement par blocs.
la partie 5 de l’lSO/IEC 7816.
ISO/CEI 9979 : 1991, Techniques cryptographiques de
3.13 fichier réponse à la remise à zéro : Fichier élé-
données - Procédures pour I’enregis tremen t des
mentaire indiquant des caractéristiques de fonctionne-
algorithmes cryptographiques.
ment de la carte.
lSO/CEI 10116: 1991, Technologies de l’information -
Modes d’opérations d’un algorithme de chiffrement par 3.14 fournisse ur : Autorité qui détient ou qui a obtenu le
blocs de n bits.
droit d e créer un fichier dédié dans la carte.
ISO/CEI 10118-1 : 1994, Technologies de l’information - 3.15 identifiant d’enregistrement: Valeur associée à
Techniques de sécurité - Fonctions de hachage - un enregistrement et qui peut être utilisée pour le référen-
Partie 7 : Généralités. ter. Dans un EF, plusieurs enregistrements peuvent avoir
le même identifiant d’enregistrement.
lSO/CEI 10118-2 : 1994, Technologies de l’information -
Techniques de sécurité - Fonctions de hachage - 3.16 identifiant de fichier: Valeur binaire sur deux
Partie 2 : Fonctions utilisant un algorithme de chiffrement octets, utilisée pour adresser un fichier.
par blocs de n bits.
3.17 message: Train d’octets transmis à la carte par le
dispositif d’interface ou vice versa, à l’exception des
caractères orientés transmission définis à la partie 3 de
I’ISO/CEI 7816.
3 Définitions
3.18 mot de passe: Données devant être présentées à
la carte par son utilisateur à la demande de l’application.
Pour les besoins de la présente partie de I’ISO/CEI 7816,
les définitions suivantes s’appliquent.
3.19 nom de DF: Train d’octets identifiant de façon
unique un fichier dédié dans la carte.
3.1 chemin : Concaténation d’identifiants de fichier,
sans séparateur. Si le chemin commence par l’identifiant
3.20 numéro d’enregistrement: Numéro attribué en
du fichier maître, il s’agit d’un chemin absolu.
séquence à chaque enregistrement pour l’identifier de
façon unique dans le EF auquel il appartient.
3.2 couple commande -réponse: Ensemble de deux
messages : une commande suivie d’une réponse.
Information visible à I’inter-
3.21 objet de données :
3.3 données de gestion de fichier: Toute informa- face, comprenant une étiquette, une longueur et une
valeur (c’est à dire, un élément de données). Dans la
tion concernant un fichier, à l’exception des paramètres
présente partie de I’ISO/CEI 7816, les objets de données
de contrôle du fichier (par exemple, date de péremption,
ont pour références BER-TLV, COMPACT-TLV et SIMPLE-TLV .
étiquette d’application).
3.4 élément de données: Information visible à 3.22 paramètres d e contrôle de fichier: Attributs
l’interface, pour laquelle sont définis un nom, une descrip- logiques, structurels et sécuritaires d’un fichier.
tion du contenu logique, un format et un codage.
3.23 unité de données: L .e plus petit ensemble de bits
pouvant être référencé sans am bigui’té.
l) En cours de publication.
*) En cours de révision.
0 ISO/CEI ISO/CEI 7816-4: 1995 (F)
L’organisation logique des données dans un carte est
4 Abréviations et notations
constituée de l’arborescence structurelle suivante de
fichiers dédiés.
Pour les besoins de la présente partie de l’lSO/CEI 7816,
- Le DF a la racine est appelé fichier maître (MF). Le
les abréviations suivantes s’appliquent.
MF est obligatoire.
APDU Unité de données du protocole d’application
- Les autres DFs sont facultatifs.
ATR Réponse à la remise à zéro
BER Règles de base pour coder I’ASN.1 Les 2 types suivants de EFs sont définis.
CLA Octet de classe
- EF interne - Ces EFs sont destinés a stocker des
données interprétées par la carte, c’est à dire des
DIR Répertoire
données analysées et utilisées par la carte à des fins
DF Fichier dédié
de gestion et de contrôle.
EF Fichier élémentaire
- EF de travail - Ces EFs sont destinés a stocker
FCI Information de contrôle de fichier
des données qui ne sont pas interprétées par la carte,
FCP Paramètre de contrôle de fichier c’est à dire des données qui sont utilisées
exclusivement par le monde extérieur.
FMD Données de gestion de fichier
Octet d’instruction
INS
La figur 'e 1 montre un exemple d’orga on logique des
MF Fichier maître
fichiers da ns une carte.
PI -P2 Octets de paramètre
PTS Sélection de type de protocole
RFU Réservé à un usage futur
SM Messagerie de sécurité
SWI -sw2
Octets d’état
Étiquette, longueur, valeur
TLV
Unité de données du protocole de
TPDU
transmission
Figure 1 - Organisation logique de fichiers (exemple)
Pour les besoins de la présente partie de l’lSO/CEI 7816,
les notations suivantes s’appliquent.
5.1.2 Méthodes de référence des fichiers
‘0’ a ‘9’ and ‘A’ à ‘F’ Les seize nombres hexadécimaux
Lorsqu’un fichier ne peut être implicitement sélectionné,
Valeur de l’octet B 1
(B 1
au moins l’une des méthodes suivantes doit permettre de
BI II B2 Concaténation des octets B1 (le plus significatif)
le sélectionner.
et B2 (le moins significatif)
- Référence par identifiant de fichier - Tout fichier
(B1 Il B2) Valeur de la concaténation des octets B1 et B2
peut être référencé par un identifiant codé sur 2 octets. Si
# le MF est référencé par un identifiant de fichier, la valeur
Numéro
‘3FOO’ (valeur réservée) doit être utilisée. La valeur ‘FFFF’
est RFU. La valeur ‘3FFF’ est réservée (voir référence par
chemin). Afin de sélectionner sans ambiguïté tout fichier
par son identifiant, les EFs et DFs immédiatement sous
un DF donné doivent tous avoir des identifiants différents.
5 Organisations de base
- Référence par chemin - Tout fichier peut être réfé-
rencé par un chemin (concaténation d’identifiants de
5.1 Structures des données
fichier). Le chemin commence par l’identifiant du MF ou
du DF courant et se termine par l’identifiant du fichier à
Le présent article contient des informations sur la struc-
référencer. Si d’autres identifiants figurent sur le chemin,
ture logique des données, visible à l’interface lors du
ce sont ceux des DF parents successifs. Les identifiants
traitement de commandes intersectorielles pour les
de fichier sont toujours classés en allant du parent vers
échanges. L’ISO/CEI 7816 ne couvre pas l’emplacement
l’enfant. Si l’identifiant du DF courant n’est pas connu, la
des données ainsi que diverses informations de structure
valeur ‘3FFF’ (valeur réservée) peut être utilisée au début
autres que celles présentées ici.
du chemin. Le chemin permet une sélection sans ambi-
guïté de tout fichier, à partir du MF ou du DF courant.
5.1.1 Organisation des fichiers - Référence par identifiant court de EF - Tout EF peut
être référencé par un identifiant court codé sur 5 bits et
prenant les valeurs de 1 à 30. La valeur 0 fait référence au
La présente partie de I’ISO/CEI 7816 assume les deux
fichier EF couramment sélectionné. Les identifiants courts
catégories suivantes de fichiers :
de EF ne peuvent pas être utilisés dans un chemin, ni
- fichier dédié (DF),
comme un identifiant de fichier (par exemple, dans une
- fichier élémentaire (EF). commande SELECT FILE).
ISO/CEI 7816-4: 1995 (F) 0 ISO/CEI
- Référence par nom de DF - Tout DF peut être réfé- 5.1.4.1 Référence par enregistrements
rencé par un nom codé sur 1 à 16 octets. Pour que la sé-
lection par nom de DF ne soit pas ambiguë (par exemple, Dans chaque EF à structure d’enregistrements, chaque
en sélectionnant par identifiant d’application, tels que enregistrement peut être référencé par un identifiant
défini à la partie 5 de I’ISO/CEI 7816), chaque nom de DF d’enregistrement et/ou par un numéro d’enregistrement.
doit être unique dans une carte donnée. Les identifiants d’enregistrement et les numéros d’enre-
gistrement sont représentés par des entiers non signés
sur 8 bits, pouvant prendre les valeurs de ‘01’ à ‘FE’. La
5.1.3 Structures des fichiers élémentaires
valeur ‘00’ est réservée à des usages spéciaux, la valeur
‘FF’ est RFU.
Les structures suivantes de EFs sont définies.
La référence par identifiant d’enregistrement suppose la
- Structure transparente - Le EF est visible à I’inter-
gestion d’un pointeur d’enregistrement. Une remise à
face comme une séquence d’unités de données.
zéro de la carte, une commande SELECT FILE ou toute
- Structure d’enregistrements - Le EF est visible à
commande portant un identifiant court et valide de EF
l’interface comme une séquence d’enregistrements
peut agir sur le pointeur d’enregistrement. La référence
identifiables individuellement.
par numéro d’enregistrement ne doit pas agir sur le
pointeur d’enregistrement.
Les attributs suivants sont définis pour les EFs structurés
en enregistrements.
- Référence par identifiant d’enregistrement -
- Taille des enregistrements: fixe ou variable.
Chaque identifiant d’enregistrement est attribué par une
- Organisation des enregistrements : en séquence
application. Si un enregistrement prend la forme d’un
(structure linéaire) ou en anneau (structure cyclique).
objet de données SIMPLE-TLV dans le champ de données
d’un message (voir 5.4.4), l’identifiant d’enregistrement
La carte doit assumer au moins l’une des 4 méthodes
est constitué du premier octet de l’objet de données.
suivantes de structuration de EFs :
Dans un EF à structure d’enregistrements, plusieurs enre-
gistrements peuvent avoir le même identifiant, auquel cas
- EF transparent.
les données contenues dans les enregistrements peuvent
- EF linéaire à enregistrements de taille fixe.
être utilisées pour les distinguer les uns des autres.
- EF linéaire à enregistrements de taille variable.
Chaque fois qu’une référence est faite par un identifiant
- EF cyclique à enregistrements de taille fixe.
d’enregistrement, une indication doit spécifier la position
logique de l’enregistrement cible : la première, dernière,
La figure 2 montre ces 4 structures de EFs.
prochaine ou précédente occurrence par rapport au
Transparent Linéaire fixe Linéaire variable Cyclique fixe
pointeur d’enregistrement.
- Dans chaque EF à structure linéaire, les positions
logiques doivent être attribuées en séquence lors de
El
l’écriture ou de l’ajout, c’est-à-dire suivant l’ordre de
l oooeo
création. Le premier enregistrement créé s’y trouve
\ donc en première position logique.
Figure 2 - Structures de EFs
- Dans chaque EF à structure cyclique, les positions
logiques doivent être attribuées en séquence dans
- La flèche de la figure référence le dernier enregistre-
NOTE
l’ordre inverse, c’est-à-dire que le dernier enregis-
ment écrit.
trement créé se trouve en première position logique.
5.1.4 Méthodes de référence des données De plus, les règles suivantes s’appliquent aux structures
linéaires et aux structures cycliques.
Les données peuvent être référencées en tant qu’enregis-
- La première occurrence doit être l’enregistrement
trements, unités de données ou objets de données. Les
correspondant à l’identifiant spécifié, et situé en pre-
données sont censées être stockées dans une séquence
mière position logique. La dernière occurrence doit
unique et continue d’enregistrements (dans un EF à struc-
être l’enregistrement correspondant à l’identifiant
ture d’enregistrements) ou d’unités de données (dans un
spécifié, lequel est situé en dernière position logique.
EF à structure transparente). La référence à un enregis-
- Lorsqu’il n’y a pas d’enregistrement courant, la
trement ou à une unité de données en dehors d’un EF
prochaine occurrence doit être l’équivalent de la pre-
constitue une erreur.
mière occurrence, la précédente occurrence doit être
l’équivalent de la dernière occurrence.
La méthode de référence des données, la méthode de
numérotation des enregistrements ainsi que la taille des - Lorsqu’il y a un enregistrement courant, la pro-
unités de données constituent des caractéristiques chaine occurrence doit être l’enregistrement le plus
dépendantes du EF. La carte peut fournir des indications proche de même identifiant et situé dans une position
dans I’ATR, dans le fichier ATR ainsi que dans toute
logique supérieure à l’enregistrement courant.
information de contrôle de fichier. Si la carte fournit des
L’occurrence précédente doit être l’enregistrement le
indications en différents endroits, l’indication devant être
plus proche de même identifiant et situé dans une
retenue pour un EF donné est celle qui se situe au plus
position logique inférieure à celle de l’enregistrement
près de celui-ci dans le chemin à partir du MF jusqu’au EF.
courant.
0 ISO/CEI ISO/CEI 7816-4: 1995 (F)
- La valeur ‘00’ doit référencer le premier, dernier, 5.1.5 Information de contrôle de fichier
prochain ou précédent enregistrement dans la
séquence de numérotation, indépendamment de L’information de çontrôle de fichier (FCI) est constituée du
l’identifiant d’enregistrement. train d’octets de données disponible dans la réponse a
une commande SELECT FILE. L’information de contrôle de
fichier peut être présente pour n’importe quel fichier.
- Référence par numéro d’enregistrement - Dans
chaque EF à structure d’enregistrements, les numéros
d’enregistrement sont uniques et séquentiels. Le tableau 1 montre trois gabarits destinés au transport
de l’information de contrôle de fichier lorsqu’elle est
- Dans chaque EF à structure linéaire, les numéros
codée en objets de données BER-TLV.
d’enregistrement doivent être attribués en séquence
lors de l’écriture ou de l’ajout, c’est-a-dire suivant - Le gabarit FCP est destine au transport de para-
l’ordre de création. Le premier enregistrement mètres de contrôle de fichier (FCP), c’est-a-dire tout
(enregistrement numéro un, # 1) est donc le premier objet de données défini dans le tableau 2.
créé.
- Le gabarit FMD est destine au transport de
- Dans chaque EF à structure cyclique, les numéros données de gestion de fichier (FMD), c’est-a-dire les
d’enregistrement doivent être attribués en séquence objets de données BER-TLV spécifiés dans d’autres
dans l’ordre inverse, c’est-a-dire que le premier enre- articles de la présente partie de I’ISO/CEI 7816 ou
gistrement (enregistrement numéro un, # 1) est le dans d’autres parties de cette même norme (par
dernier créé. exemple, l’étiquette d’application définie dans la partie
5 et la date de péremption d’application définie dans
De plus, I a règle suivante s’appl ique aux structures la partie 6).
linéaires et aux stru ctures cyc Ii ques.
- Le gabarit FCI est destine au transport de para-
- La valeur ‘00’ doit référencer l’enregistrement cou- mètres de contrôle de fichier et de données de
rant, c’est-à-dire celui fixé par le pointeur d’enregis- gestion de fichier.
trement.
Tableau 1 - Gabarits pour FCI
I T I
5.1.4.2 Référence par unités de données
‘62’ Paramètres de contrôle de fichier (gabarit FCP)
‘64’ Données de gestion de fichier (gabarit FMD)
Dans chaque fichier EF à structure transparente, chaque
‘6F’ Information de contrôle de fichier (gabarit FCI)
I I
unité de données peut être référencée par un déplace-
ment (par exemple, dans une commande READ BINARY,
voir 6.1). Celui-ci prend la forme d’un entier non signé,
Les options de sélection de la commande SELECT FILE (voir
codé sur 8 ou 15 bits selon l’option spécifiée dans la
tableau 59) permettent de préciser lequel des 3 gabarits
commande respective. Prenant la valeur 0 pour la pre-
est requis. Si l’option FCP ou FMD est positionnée,
mière unité de données du EF, le déplacement s’accroît
l’utilisation du gabarit correspondant est obligatoire. Si
de 1 pour chaque unité de données suivante.
l’option FCI est positionnée, l’utilisation du gabarit FCI est
facultative.
Par défaut, c’est-à-dire si la carte ne fournit aucune indica-
tion, la taille de l’unité de données est de un octet.
Une partie de l’information de contrôle de fichier peut
aussi se trouver dans un EF de travail sous le contrôle
NOTES
d’une application. L’identifiant du EF est donne sous I’éti-
1 Un EF structuré en enregistrements peut accepter la réfé- quette ‘87’. Quand de l’information de contrôle de fichier
rence par unités de données, et si tel est le cas, les unités de
se trouve dans un EF de travail, son codage requiert
données peuvent contenir des informations de structure en plus
l’emploi d’un gabarit, FCP ou FCI.
des données (par exemple, des numéros d’enregistrement dans
une structure linéaire).
Des informations de contrôle de fichier qui ne sont pas
2 Dans un EF structuré en enregistrements, il se peut que la
codées conformément à la présente partie de I’ISO/CEI
référence par unités de données ne donne pas le résultat
7816, peuvent être introduites comme suit.
escompté car l’ordre de stockage des enregistrements n’est pas
connu (dans une structure cyclique par exemple).
à ‘9F’ - Le codage
‘00’ ou toute valeur supérieure
du train d’ octets qui suit est privé.
- Étiquette = ‘53’ - Le champ de valeur de l’objet de
5.1.4.3 Référence par objets de données
données est constitué de données libres non codées
en TLV.
Chaque objet de données (tel que défini dans 5.4.4) débute
- Étiquette = ‘73’ - Le champ de valeur de l’objet de
par une étiquette qui le référence. Les étiquettes sont dé-
crites dans la présente partie de I’ISO/CEI 7816 ainsi que données est constitué d’objets de données libres
dans d’autres parties de la même norme. codés en BER-TLV.
0 lSO/CEI
ISO/CEI 7816-4: 1995 (F)
Tableau 2 - Paramètres de contrôle de fichier
5.2 Architecture de sécurité de la carte
T L v S’applique à 1
Le présent article décrit les éléments suivants:
EFs transpa-
‘80’ 2 Nombre d’octets de données
- états de sécurité,
rents
dans le fichier, à l’exception des
- attributs de sécurité,
informations de structure
- mécanismes de sécurité.
Tout fichier
‘81’ 2 Nombre d’octets de données
dans le fichier, y compris les in-
Lors de l’exécution de commandes et/ou lors de l’accès à
formations de structure s’il y en a
des fichiers, les attributs de sécurité sont comparés à
Tout fichier
‘82’ 1 Octet de description de fichier
l’état de sécurité.
(voir le tableau 3)
Tout fichier
2 Octet de description de fichier
5.2.1 États de sécurité
suivi de l’octet de codage de
données (voir le tableau 86)
L’état de sécurité courant représente l’état atteint après la
3 Octet de description de fichier
complète exécution
ou suivi de l’octet de codage de
4 données et de la longueur maxi-
- de la réponse à la remise à zéro (ATR) et, le cas
mum des enregistrements
échéant, de la sélection d’un type de protocole (PTS),
‘83’ 2 Identifiant de fichier 1 Tout fichier 1
- et/ou d’une ou plusieurs commandes exécutant le
DFs cas échéant des procédures d’authentification.
‘84’ 1 à Nom de DF
I I
L’état de sécurité peut également résulter de I’achève-
‘85’ var. Information privée 1 Tout fichier 1
ment d’une procédure de sécurité visant à identifier les
‘86’ var. Attributs de sécurité (codage non r Toi< fichier /
entités concernées, si elles existent. Cette identification
décrit dans la présente partie de
peut consister par exemple à
I’ISO/IEC 7816)
- prouver la connaissance d’un mot de passe (par
‘87’ 2 Identifiant d’un EF contenant Tout fichier
VERIFY),
exemple à l’aide de la commande
une extension de la FCI
- prouver la connaissance d’une clé (par exemple à
‘88’
l’aide d’une commande GET CHALLENGE suivie d’une
\
RFU
commande EXTERNAL AUTHENTICATE).
GE’
- utiliser la messagerie de sécurité (par exemple en
‘9F RFU
authentification de message).
XY’
Trois états de sécurité sont considérés.
Tableau 3 - Octet de description de fichier
- État de sécurité global - II peut être modifié par
-
l’achèvement d’une procédure d’authentification liée
Signification
b8 b7 b6 b5 b4 b3 b2 bl
au MF (authentification à l’aide d’un mot de passe ou
0x---- -- d’une clé attachés au MF, par exemple).
Accès au fichier
00 - - - - - -
- Fichier non partageable
- État de sécurité spécifique à un fichier - II peut
OI- - - - - -
- Fichier partageable
être modifié par l’achèvement d’une procédure
d’authentification liée au DF (authentification à l’aide
o-xxx- -- Type du fichier
d’un mot de passe ou d’une clé attachés au DF, par
0 - ooo--- - EF de travail
exemple) ; il peut être maintenu, retrouvé ou perdu
0 - OOl--- - EF interne
après une sélection de fichier (voir 6.10.2) ; la portée
0 - OlO--- - Réservés
de cette modification peut être limitée à l’application à
0 - Oll--- aux
laquelle appartient la procédure d’authentification.
0 - lOO--- EFs
0 - lOl--- de type
- État de sécurité spécifique à une commande - Il
0 - llO--- privé
existe uniquement pendant l’exécution d’une com-
0 - 1 1 1 - - - - DF
mande comprenant une authentification à l’aide de la
messagerie de sécurité (voir 5.6). Ce type de com-
o- - - - xxx
Structure du EF
mande peut n’avoir aucune incidence sur les autres
o----o00 - Aucune précision
états de sécurité.
o----o01 -Transparent
o- - - -0 10 - Linéaire fixe, sans précision
Lorsque le concept de canaux logiques est utilise, l’état de
o- - - -0 11 - Linéaire fixe, SIMPLE-TLV
sécurité spécifique à un fichier peut dépendre du canal
o-- --100
- Linéaire variable, sans précision
()- - - - logique (voir 5.5.1).
1 0 1 - Linéaire variable, SIMPLE-TLV
o- - - - II 0
- Cyclique, sans précision
o- - - - III - Cyclique, SI MPLE-TLV
5.2.2 Attributs de sécurité
Ixxxxxxx RFU
Lorsqu’ils existent, les attributs de sécurité définissent les
“Partageable” signifie que le fichier accepte au moins des accès
actions autorisées ainsi que les procédures à exécuter
simultanés sur différents canaux logiques.
pour accomplir ces actions.
0 ISO/CEI
ISO/CEI 7816-4: 1995 (F)
Les attributs de sécurité peuvent être associés a chaque Une unité de données du protocole d’application (APDU)
fichier. Ils fixent les conditions de sécurité devant être contient un message, de commande ou de réponse,
satisfaites pour opérer sur le fichier. Les attributs de transmis par le dispositif d’interface a la carte ou vice
sécurité d’un fichier dépendent de versa.
- sa catégorie (DF ou EF),
Dans un couple commande-réponse, les messages de
- de paramètres facultatifs contenus dans les infor-
commande et de réponse peuvent contenir des données,
mations de contrôle du fichier et/ou dans celles du ou
ce qui se traduit par les quatre cas figurant au tableau 4.
des fichiers parents.
NOTE - Des attributs de sécurité peuvent aussi être associés à Tableau 4 -
Présence de données
d’autres objets (par exemple des clés).
dans un couple commande-réponse
1 Cas 1 Données de commande 1 Données attendues en réponse
52.3 Mécanismes de sécurité
1 Aucune donnée
Aucune donnée
Aucune donnée Données
3 Données
Aucune donnée
La présente partie de I’ISO/CEI 7816 définit les méca-
Données Données
nismes de sécurité suivants.
- Authentification d’entité par mot de passe - La
carte compare des données provenant du monde
53.1 Commande APDU
extérieur à des données secrètes internes. Ce méca-
nisme permet de protéger les droits de l’utilisateur.
La commande APDU, illustrée par la figure 3 (voir aussi le
tableau 6) et définie dans la présente partie de
- Authentification d’entité par clé - L’entité à au-
l’lSO/CEI 7816, est constituée de
thentifier doit prouver qu’elle connaît une clé, grâce à
une procédure d’authentification (une commande GET
- un préfixe obligatoire de 4 octets (CLA INS PI PZ),
CHALLENGE suivie d’une commande EXTERNAL
- un corps conditionnel de longueur variable.
AUTHENTICATE, par exempk).
- Authentification de données -À l’aide de don-
Préfixe
Coms
nées internes, secrètes ou publiques, la carte vérifie
1 CLA INS PI P2 1 [champ L,l [champ de données1 [champ L,l 1
des données redondantes reçues du monde extérieur.
Ou encore, à l’aide de données internes secrètes, la
Figure 3 - Structure de la commande APDU
carte calcule un élément de données (élément de
contrôle cryptographique ou signature numérique) et
Le nombre d’octets présents dans le champ de données
l’insère dans les données transmises au monde
de la commande APDU est indiqué par L,.
extérieur. Ce mécanisme permet de protéger les
droits d’un fournisseur.
Le nombre maximal d’octets attendu dans le champ de
données de la réponse APDU est indiqué par Le (longueur
- Chiffrement de données - À l’aide de données
des données attendues). Lorsque le champ Le ne contient
internes secrètes, la carte déchiffre un cryptogramme
que des zéros, le nombre maximal d’octets de données
reçu dans un champ de données. Ou encore, à l’aide
disponibles est requis.
de données internes, secrètes ou publiques, la carte
calcule un cryptogramme et l’insère dans un champ
La figure 4 montre les 4 structures de commandes APDU,
de données pouvant contenir d’autres informations.
en fonction des 4 cas définis au tableau 4.
Ce mécanisme peut être utilisé comme service de
confidentialité, tel que la gestion de clé ou l’accès
conditionnel. Outre le mécanisme de cryptogramme,
Cas 1
la confidentialité des données peut être obtenue par
masquage. Dans ce cas, la carte produit un train \Préfixe1
d’octets masquants et l’ajoute par ou exclusif avec
des octets de données reçus du monde extérieur ou Cas 2
transmis vers celui-ci. Ce mécanisme peut être utilisé
pour protéger la confidentialité et pour réduire les
possibilités de filtrage de messages.
Cas 3
Préfixe Champ L,
Champ de données
Le résultat d’une authentification peut être consigné dans
un EF interne, en fonction des besoins de l’application.
Cas 4
Préfixe Champ L, Champ Le
Champ de données
5.3 Structure des messages APDU
Figure 4 - Les 4 structures de commandes APDU
Une étape dans un protocole d’application est constituée
de l’envoi d’une commande, du traitement de cette com-
Dans le cas 1, la longueur L, est nulle, ce qui implique que
mande dans l’entité réceptrice et de la transmission de la
le champ L, et le champ de données sont vides. La
réponse. Une réponse spécifique correspond donc à une
longueur Le est nulle aussi, ce qui implique que le champ
commande spécifique, ces deux éléments étant appelés
Le est vide. Le corps de la commande est donc vide.
couple commande-réponse.
ISO/CEI 7816-4: 1995 (F)
0 ISO/CEI
Dans le cas 2, la longueur L, est nulle, ce qui implique que Conventions pour décoder L,
le champ L, et le champ de données sont vides. La
Si la valeur de Le est codée sur un ou deux octets dans
longueur L, n’est pas nulle, ce qui implique que le champ
lesquels les bits ne sont pas nuls, cette valeur est égale à
L, est présent. Le corps de la commande est donc
celle du ou des octets, qui se situe dans la fourchette de 1
constitué d’un champ Le.
à 255 (ou 65 535). Une valeur nulle dans tous les octets
correspond à la valeur maximale de L,: 256 (ou 65 536).
Dans le cas 3, la longueur L, n’est pas nulle, ce qui
implique que le champ L, est présent et que le champ de
données est constitué des L, octets suivants. La longueur
Les 4 premiers cas s’appliquent à toutes les cartes.
Le est nulle, ce qui implique que le champ Le est vide. Le
corps de la commande est donc constitué d’un champ L,
Cas 1 - L = 0 ; le corps est vide.
suivi d’un champ de données.
l Aucun octet pour L, qui vaut 0.
l Pas d’octet de données.
Dans le cas 4, la longueur L, n’est pas nulle, ce qui
l Aucun octet pour L, qui vaut 0.
implique que le champ L, est présent et le champ de
données constitué des L, octets suivants. La longueur L,
Cas 2s -L=l.
n’est pas nulle, ce qui implique que le champ Le est
également présent. Le corps de la commande est donc
l Aucun octet pour L, qui vaut 0.
constitué d’un champ L, suivi d’un champ de données puis
l Pas d’octet de données.
d’un champ Le.
l B1 code L, qui vaut de 1 à 256.
Cas 3s
- L = 1 + (Bj) et (B ,,) # 0.
5.3.2 Conventions pour décoder les corps de
l B1 code L, (# 0) qui vaut de 1 à 255.
commande
l B2 à BL sont les L, octets de données.
l Aucun octet pour L, qui vaut 0.
Dans le cas 1, le corps de commande APDU est vide. Une
telle commande ne comporte aucun champ de longueur.
Cas 4s - L = 2 + (B1) et (B,) ;t 0.
Dans les cas 2, 3 et 4, le corps de commande APDU est
l B1 code L, (# 0) qui vaut de 1 à 255.
constitué d’un train de L octets, appelés B1 à BL comme
l B2 à BL-1 sont les L, octets de données.
l’illustre la figure 5. Un tel corps comporte 1 ou 2 champs
l BL code L, qui vaut de 1 à 256.
de longueur et B 1 fait toujours partie du premier.
Pour les cartes acceptant l’extension de L, et L, (voir
Corps de commande APDU
8.3.6, capacités des cartes), les trois cas suivants s’appli-
B, . . . B,- (L octets)
quent en plus.
Figure 5 - Corps non vide
Cas 2E - L = 3 et (B,) = 0.
La carte indique, parmi ses capacités (voir 8.3.6), que dans
l Aucun octet pour L, qui vaut 0.
les commandes APDU le champ L, et le champ L,
l Pas d’octet de données.
- doivent être courts (un octet, valeur par défaut),
l Le champ L, est constitué de 3 octets où
B2 et B3 codent L, qui vaut de 1 à 65 536.
- ou bien peuvent être étendus (instruction explicite).
Par conséquent, les cas 2, 3 et 4 sont courts (1 octet par
Cas 3E
- L = 3 + (B2 II BS), (B1) = 0 et (B2 Il Bs) + 0.
champ de longueur) ou étendus (B1 a pour valeur ‘00’ et la
l Le champ L, est constitué des 3 premiers
valeur de chaque longueur est codée sur 2 autres octets).
octets où B 2 et B3 codent L, (# 0) qui vaut
de 1 à 65 535.
Le tableau 5 montre le décodage des commandes APDU,
l B4 à BL sont les L, octets de données.
selon les quatre cas définis dans le tableau 4 et la figure 4,
l Aucun octet pour L, qui vaut 0.
en tenant compte de l’extension possible de L, et de L,.
Cas 4E - L = 5 + (B2 II Bs), (B1) = 0 et (B2 II BS) + 0.
Tableau 5 - Décodage des commandes APDU
l Le champ L, est constitué des 3 premiers
Conditions Cas
octets où B2 et Bs codent L, (# 0) qui vaut
L=O 1
del à65535.
l B4 à BL-2 sont les L, octets de données.
L=l Court 2 1 (2s)
l Le champ L, est constitué des 2 derniers
L = l+(B,); (B, If 0 * Court 3 (3%
octets BLD1 et BL qui codent L, valant de
1 à65536.
L = 2+(B,); (B,)#O’ , Court 4 (49
L=3; (B,)=O; - Étendu 2 (2E)
Pour chaque protocole de transmission défini dans la
L = 3+(B2 II BS) ; (B,) = 0 ; (B2 II B3) + o Étendu 3 (3E)
partie 3 de l’lSO/CEI 7816, une annexe rattachée à cette
partie (une annexe par protocole) spécifie le transport des
L = 5+(B2 II B3) ; (B,) = 0 ; (B2 II B3) + o Étendu 4 (4E)
messages APDUs d’un couple commande-réponse, pour
Toute autre commande APDU est incorrecte.
chacun des sept cas évoqués ci-dessus.
0 lSO/CEI
ISO/CEI 7816-4: 1995 (F)
5.3.3 Réponse APDU Sauf indication contraire, les bits RFU de ces octets sont
mis à zéro et les octets RFU a ‘00’.
Illustrée par la figure 6 (voir aussi le tableau 7), la réponse
APDU définie dans la présente partie de I’ISO/CEI 7816,
5.4.1 Octet de classe
est constituée de
- un corps conditionnel de longueur variable,
Comme le montrent conjointement les tableaux 8 et 9,
l’octet de classe (CLA) d’une commande est utilisé pour
- un suffixe obligatoire de 2 octets (SWI SW2).
indiquer
Corps Suffixe
-dans quelle mesure la commande et la réponse
[Champ de données] 1 SWI sw2 1
sont conformes a la présente partie de I’ISO/CEI
7816,
Figure 6 -
Structure des réponses APDU
- et le cas échéant (voir tableau 9), le format de la
Le nombre d’octets présents dans le champ de données
messagerie de sécurité et le numéro du canal logique.
de la réponse APDU est appelé L,.
Tableau 8
- Codage et signification de CLA
Le suffixe code l’état de l’entité réceptrice après
Valeur Signification
traitement du couple commande-réponse.
‘0X’ Structure et codage
NOTE - Si la commande est interrompue, la réponse APDU se
de la commande et de la réponse
limite à un suffixe codant une condition d’erreur sur 2 octets
conformes à la présente partie de I’ISO/IEC 7816
d’état.
(pour coder ‘X’, voir le tableau 9)
‘10’ à ‘7F’
RFU
5.4 Conventions pour coder les préfixes de
‘8X’, ‘9X’
Structure de la commande et de la réponse
commande, les champs de données et les suffixes
conforme à la présente partie de I’ISO/IEC 7816.
de réponse
Sauf pour ‘X’ (pour le coder, voir le tableau 9),
le codage et la signification de la commande
Le tableau 6 montre le contenu de la commande APDU.
et de la réponse sont privés.
- Contenu de la commande APDU
Tableau 6 ‘AX’
Sauf indication contraire dans le contexte
de l’a
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...