ISO/IEC 7816-8:1999

Identification cards - Integrated circuit(s) cards with contacts - Part 8: Security related interindustry commands

Cartes d'identification — Cartes à circuit(s) intégr(é)s à contacts — Partie 8: Commandes intersectorielles de sécurité

General Information

• Status: Withdrawn
• Publication Date: 01-Dec-1999
• Withdrawal Date: 01-Dec-1999
• ICS: 35.240.15 - Identification cards. Chip cards. Biometrics
• Technical Committee: ISO/IEC JTC 1/SC 17 - Cards and security devices for personal identification
• Drafting Committee: ISO/IEC JTC 1/SC 17/WG 4 - Generic interfaces and protocols for security devices
• Current Stage: 9599 - Withdrawal of International Standard
• Start Date: 11-Jun-2004
• Completion Date: 30-Oct-2025

Relations

• Revised: SIST ISO/IEC 7816-5:2005 - Identification cards -- Integrated circuit cards -- Part 5: Registration of application providers
• Effective Date: 12-May-2008
• Revised: SIST ISO/IEC 7816-4:2005 - Identification cards -- Integrated circuit cards -- Part 4: Organization, security and commands for interchange
• Effective Date: 12-May-2008
• Revised: ISO/IEC 7816-5:2004 - Identification cards - Integrated circuit cards - Part 5: Registration of application providers
• Effective Date: 15-Apr-2008
• Revised: ISO/IEC 7816-9:2004 - Identification cards - Integrated circuit cards - Part 9: Commands for card management
• Effective Date: 15-Apr-2008
• Revised: ISO/IEC 7816-4:2005 - Identification cards - Integrated circuit cards - Part 4: Organization, security and commands for interchange
• Effective Date: 15-Apr-2008
• Revised: ISO/IEC 7816-8:2004 - Identification cards - Integrated circuit cards - Part 8: Commands for security operations
• Effective Date: 15-Apr-2008

Standards Content (Sample)

INTERNATIONAL ISO/IEC
STANDARD 7816-8
First edition
1999-10-01
Identification cards — Integrated circuit(s)
cards with contacts —
Part 8:
Security related interindustry commands
Cartes d'identification — Cartes à circuit(s) intégré(s) à contacts —
Partie 8: Commandes intersectorielles de sécurité
B C Reference number
Contents
1 Scope .1
2 Normative references .1
3 Terms and definitions .2
4 Symbols (and abbreviated terms) .2
5 Security environments .2
6 Extended headerlist DE.4
7 Security support .5
8 Secure messaging extensions .7
9 Command chaining .9
10 MANAGE SECURITY ENVIRONMENT command .9
11 PERFORM SECURITY OPERATION command .11
12 Manage verification process.15
13 GENERATE PUBLIC KEY PAIR command .18
14 MUTUAL AUTHENTICATE function .18
15 Tags defined in ISO/IEC 7816-8 .19
(informative)
Annex A Structure and usage of certificates interpreted by the card.20
Annex B (informative) Usage of digital signature relevant operations.22
©  ISO/IEC 1999
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced
or utilized in any form or by any means, electronic or mechanical, including photocopying and
microfilm, without permission in writing from the publisher.
ISO/IEC Copyright Office • Case postale 56 • CH-1211 Genève 20 • Switzerland
Printed in Switzerland
ii
© ISO/IEC ISO/IEC 7816-8:1999(E)
Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical Commission)
form the specialized system for worldwide standardization. National bodies that are members of ISO or IEC
participate in the development of International Standards through technical committees established by the
respective organization to deal with particular fields of technical activity. ISO and IEC technical committees
collaborate in fields of mutual interest. Other international organizations, governmental and non-governmental, in
liaison with ISO and IEC, also take part in the work.
In the field of information technology, ISO and IEC have established a joint technical committee, ISO/IEC JTC 1.
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 ISO/IEC 7816-8 was prepared by Joint Technical Committee ISO/IEC JTC 1, Information
technology, Subcommittee SC 17, Identification cards and related devices.
ISO/IEC 7816 consists of the following parts, under the general title Identification cards — Integrated circuit(s) cards
with contacts:
 Part 1: Physical characteristics
 Part 2: Dimensions and location of the contacts
 Part 3: Electronic signals and transmission protocols
 Part 4: Interindustry commands for interchange
 Part 5: Numbering system and registration procedure for application identifiers
 Part 6: Interindustry data elements
 Part 7: Interindustry commands for Structured Card Query Language (SCQL)
 Part 8: Security related interindustry commands
 Part 9: Additional interindustry commands and security attributes
 Part 10: Electronic signals and answer to reset for synchronous cards
Annexes A and B of this part of ISO/IEC 7816 are for information only.
iii
Introduction
The International Organization for Standardization (ISO) and International Electrotechnical Commission (IEC) draw
attention to the fact that it is claimed that compliance with this part of ISO/IEC 7816 may involve the use of a patent
concerning smart cards and terminals given in the body of the text.
The ISO and IEC take no position concerning the evidence, validity and scope of this patent right.
The holder of this patent right has assured ISO and IEC that he is willing to negotiate licences under reasonable
and non-discriminatory terms and conditions with applicants throughout the world. In this respect, the statement of
the holder of this patent right is registered with ISO and IEC. Information may be obtained from:
Director of Intellectual Property
BULL CP8, S.A.
68, route de Versailles
B.P. 45
78431 Louveciennes Cédex
France
Attention is drawn to the possibility that some of the elements of this part of ISO/IEC 7816 may be subject of patent
rights other than those identified above. ISO and IEC shall not be held responsible for identifying any or all such
patent rights.
iv
INTERNATIONAL STANDARD  © ISO/IEC ISO/IEC 7816-8:1999(E)
Identification cards -
Integrated circuit(s) cards with
contacts - Part 8: Security
related interindustry
1 Scope 2 Normative references
This part of ISO/IEC 7816 specifies: The following normative documents contain
provisions which, through reference in this text,
 security protocols for use in cards;
constitute provisions of this part of ISO/IEC 7816. For
dated references, subsequent amendments to, or
 secure messaging extensions;
revisions of, any of these publications do not apply.
However parties to agreements based on this part of
 the mapping of the security mechanisms on to
ISO/IEC 7816 are encouraged to investigate the
the card’s security functions/services, including
possibility of applying the most recent editions of the
a description of the in-card security
normative documents indicated below. Members of
mechanisms;
ISO and IEC maintain registers of currently valid
International Standards.
 data elements for security support;
ISO/IEC 7816-3:1997, Information technology —
 the use of algorithms implemented on the card
Identification cards — Integrated circuit(s) cards with
(though the algorithms themselves are not
contacts — Part 3: Electronic signals and
described in detail);
transmission protocols.
 the use of certificates;
ISO/IEC 7816-4:1995, Information technology —
Identification cards — Integrated circuit(s) cards with
 security related commands.
contacts — Part 4: Interindustry commands for
interchange.
This part of ISO/IEC 7816 does not cover the internal
implementation within the card and/or the outside
ISO/IEC 7816-4:1995/Amd.1:1997, Information
world.
technology — Identification cards — Integrated
circuit(s) cards with contacts — Part 4: Interindustry
The choice and conditions of use of cryptographic
commands for interchange — Amendment 1: Impact
mechanisms may affect card exportability. The
of secure messaging on the structures of APDU
evaluation of the suitability of algorithms and
messages.
protocols is outside the scope of this part of ISO/IEC
7816.
ISO/IEC 7816-6:1996, Identification cards —
Integrated circuit(s) cards with contacts — Part 6:
It shall not be mandatory for cards complying to this
Interindustry data elements.
part of ISO/IEC 7816 to support all the described
commands or all the options of supported
ISO/IEC 9796:1991, Information technology —
commands.
Security techniques — Digital signature scheme
giving message recovery.
© ISO/IEC
ISO/IEC 9798-2:1994, Information technology —
CA Certification authority
Security techniques — Entity authentication
CC Cryptographic checksum
mechanisms — Part 2: Mechanism using symmetric
CCT Cryptographic checksum template
encipherment algorithms.
CK Common key
ISO/IEC 9798:1991, Information technology —
CRDO Control reference data object
Security techniques — Entity authentication
mechanisms — Part 3: Entity authentication using a
CRT Control reference template
public-key algorithm.
CT Confidentiality template
ISO/IEC 9979:1991, Data cryptographic techniques DE Data element
— Procedures for the registration of cryptographic
DF Dedicated file
algorithms.
DO Data object
DS Digital signature
3 Terms and definitions
DSI Digital signature input
DST Digital signature template
For the purposes of this part of ISO/IEC 7816, the
following definitions apply.
EF Elementary file
HT Hash template
3.1
Certification Authority
IFD Interface device
CA
PK Public key
a trusted third party that establishes a proof that links
PSO PERFORM SECURITY OPERATION command
a public key and other relevant information to its
RFU Reserved for future use
owner
SE Security environment
3.2
SK Secret key
cryptographic mechanisms
functions provided by the card as a result of its imple-
SM Secure messaging
mentation of cryptographic algorithms with a specific
SST Security support template
set of operational parameters e.g. the mode of
operation and the size of data or keys
3.3
5 Security environments
secure messaging
provides a means for cryptographic protection on the
5.1 Description
data exchanged during a command (as described in
ISO/IEC 7816-4)
The security environment (SE) in a card is the logical
container of a set of fully specified security
3.4
security environment mechanisms which are available for reference in
security related commands and in secure messaging
a mechanism to specify to the card system the
(SM) as defined in this part of ISO/IEC 7816 and in
security functions that are available to provide
ISO/IEC 7816-4.
protection to commands for a specific application of
the card
Any SE shall specify references to the cryptographic
algorithm(s) to be executed, the mode(s) of
operation, the key(s) to be used and any additional
4 Symbols (and abbreviated terms)
data needed by a security mechanism. It may specify
a template describing data elements (DEs) stored in
For the purposes of this part of ISO/IEC 7816, the
the card or resulting from some computation, to be
following abbreviations apply
included by the algorithms specified in the security
environment definition. It also may provide directions
APDU Application protocol data unit
for handling the data resulting from the computation,
AT Authentication template e.g. storage in the card memory. Any relative
references to files (keys or data) specified with a
BER-TLV Basic Encoding Rules - Tag Length Value
mechanism in the environment definition shall be
© ISO/IEC ISO/IEC 7816-8:1999(E)
resolved with respect to the dedicated file (DF) 5.3 Components
selected at the time the mechanism is used to
perform a computation. Control Reference Templates (CRT) may be used to
describe the various components of a SE (see Table
Absolute references (e.g. absolute path) need not be
2).
resolved.
Five such templates are defined for:
NOTE  ISO maintains a register of cryptographic
algorithms (see ISO/IEC 9979) and, separately, provides
protocol standards.  cryptographic checksum;
 digital signature;
 confidentiality;
 hash;
5.2 Activation of a security environment
 authentication.
At any time during operation of the card a current SE
Within the SE, components may have two aspects;
shall be active, either by default or as a result of
one being valid for the protection of command
commands from the interface device (IFD). The
APDUs (application protocol data units) and the other
default SE may be empty. The content of the default
for the protection of response APDUs.
SE is not defined in this part of ISO/IEC 7816.
SEs may be numbered for storing, restoring (see
The current SE may explicitly be set or replaced with
clause 10) and referencing, in which case the
the MANAGE SECURITY ENVIRONMENT
numbering is context specific.
command (see clause 10). An SE may contain a
mechanism to perform initialisation of non-persistent
SE numbers represented by:
data used by mechanisms in the environment, e.g. a
session key.
 all zeroes (0) denote an empty environment,
where no authentication no SM procedure is
In SM, data objects transmitted in a control reference
defined;
data object (CRDO) shall take precedence over any
corresponding data object (DO) present in the
 all ones (1) denote that no operation can be
current SE.
performed in this environment;
Definitions of associated SE’s may be grouped into
 11101111 is Reserved for Future Use (RFU).
the following sets:
The current SE contains one or more:
 One global SE set, which may be provided by
the card. The first SE of this set is the default
 components belonging to the default stored SE
SE;
associated with the current DF;
 One or more application specific SE sets which
 components transmitted in SM commands (see
are provided by applications.
ISO/IEC 7816-4);
The global SE set shall be active by default, unless
 components transmitted in MANAGE
otherwise specified. A SE or set of SEs may be
SECURITY ENVIRONMENT commands (see
associated with a DF or EF such that after selecting
clause 10);
the DF or EF the associated SE or a specific SE in
the set is implicitly set. The method of specifying this
all the components of a stored SE, invoked by its

functional association between a file and a set of SEs
number in a MANAGE SECURITY
is outside the scope of this part of ISO/IEC 7816.
ENVIRONMENT command.
The current SE is valid until there is a change of
context (e.g. by selecting a different application with
5.4 Algorithm referencing
the SELECT FILE command), a MANAGE
SECURITY ENVIRONMENT command, a warm
The Algorithm Object Identifier DO is a data object
reset or deactivation of the contacts (see ISO/IEC
which identifiers the cryptographic algorithm
7816-3).
associated with an algorithm reference, as defined in
ISO/IEC 7816-4. One or more such DOs may be
© ISO/IEC
present in the file control information (FCI) of a DF A constructed tag followed by a length = 00 is
with a tag ‘AC’. ignored.
This DO encapsulates two mandatory DOs and an A primitive tag followed by a length = 00 indicates
optional DO, in the following sequence: that the complete DO or DE is to be included in the
byte string.
 the first mandatory DO is the algorithm reference
DO, tag ‘80’, as used in Table 3; A DO, the value of which is an extended headerlist,
uses tag '4D'. According to their use, other DOs may
 the second mandatory DO is an ASN.1 DO have the implicit type 'extended headerlist'.
Identifier, tag ‘06’, referencing the algorithm
6.2 Examples of extended headerlists
uniquely;
 the optional DO (tag dependent on the Object Given an extended headerlist:
Identifier) indicates the algorithm parameters.
Primitive T 00 Const L Primitive T 00 Primitive T L
1 2 3
. tag = =
Example coding (see ISO/IEC 7816-6, Annex B) -
4 5
AC II 09 II 80-01-01 II 06-04-28CC4701
This Object Identifier (28CC4701) refers to algorithm
describing 3 primitive DOs:
1 in ISO/IEC 9979, with no parameter.
Primitive T
1 L Value
1 1
6 Extended headerlist DE
6.1 Construction and use
Primitive T
L Value
2 2
An extended headerlist DE is a concatenation of
tag/lengths without delimiters.
Primitive T
3 L (‡5) Value
3 3
An extended headerlist is normally used for
referencing DOs to be signed.
An extended headerlist references a byte string built
Result in Case 1 (the headerlist referring to the
as follows:
concatenation of the DEs)
Value
Value Value truncated at 5 bytes
 each tag/length is replaced by data referenced 1
2 3
by the tag when the DO is primitive;
 when a tag/length denotes a constructed DO, its
value is interpreted as an extended headerlist
Result in Case 2 (the headerlist referring to the
DE.
concatenation of the DOs)
According to the conditions of use of an extended
Primitive L Value Const. L = L + 9 Primitive
1 1 2
headerlist, the data to include in the byte string are
T tag T
1 2
 either the values of the referenced primitive

DOs, truncated according to the length indicated
in the extended headerlist (Case 1) or L Value Primitive 5 Value truncated at 5
2 2 3
T bytes
 the primitive DOs themselves, truncated
according to the length indicated in the extended
headerlist, and nested in the respective
template, the length of which is adjusted
indicated by the appropriate parameter of the
according to BER-TLV (Basic Encoding Rules -
command (e.g. ‘AC’, ‘BC’ in PERFORM SECURITY
Tag length Value) rules (Case 2).
OPERATION, see 11.7.3) or by the appropriate
© ISO/IEC ISO/IEC 7816-8:1999(E)
structure of the data field: constructed for those  A session identifier, that may be computed from
containing DOs; primitive for those containing DEs). the card session counter and possibly data
provided by the outside world.
Cryptographic protection of data exchanges may be
7 Security support
supported with data elements, called progression
values. Their values are increased at specific events
7.1 Description and rules
throughout the life of the card.
The security support data elements are a collection
Two progression value types are specified:
of specially defined DEs with rules governing the way
their values are handled. These DEs may be
 Internal Progression Values which, if so
provided by the card as generic support to
specified for an application, register the number
cryptographic protection mechanisms performed by
of times specific events are performed. The data
an application.
element shall be incremented after the event has
occurred; the card may provide a reset function
The security support DEs may be referenced by
for these counters which if so specified for an
applications for inclusion in operations executed by
application sets its value to zero. Internal
the card when performing commands e.g. in secure
progression values cannot be controlled by the
messaging or in the PERFORM SECURITY
outside world and are suitable for use as
OPERATION command. The security support DEs
secured in-card approximate representations of
extend and refine the auxiliary data elements for
real time. Their values can be used in
secure messaging as defined in ISO/IEC 7816-4.
cryptographic computations.
The rules for maintenance and use of the value of
 External Progression Values which, if so
security support DEs shall be governed by the card.
specified for an application, shall only be
They are based on the following principles:
updated by a data value from the outside world.
The new value shall be numerically larger than
its current stored value.
 update is done with new values computed by the
card or provided by the outside world, in
accordance with the specific rule for a specific
type of security support DE;
7.3 Data element referencing
 update is performed before any output is
produced for a command which causes an
Access to the value of security support data
update. The update is independent of the
elements may be provided in a card by:
completion status of the command;
 an EF contained in the master file (MF), e.g. for
 if the value is to be used by the application in an
card session counter;
operation that causes an update, the update is
performed before the value is used;
 an EF contained in a DF associated with an
 access to application specific security support
application, e.g. for application specific
DEs is restricted to functions performed by the
progression values;
specific application.
 a reference as a data object with BER-TLV
encoding as defined in the first column of Table
NOTE  the actual security achieved in a data exchange
1;
ultimately depends on the algorithms and protocols
specified by the application, the card only provides
 a reference as auxiliary data (tags '88', '92', '93')
support with these DEs and associated usage rules.
in a control reference template (CRT, see Table
7.2 Data elements 3). These tags can be used if the SE supports
unambiguous use of these data elements.
The card may support security of data exchanges
Characteristics of the security support data elements,
with data elements having values that are different
e.g. length of the data, and the algorithms which alter
each time the card is activated. They include the
their value are not defined in this part of ISO/IEC
following:
7816.
 A card session counter, that is incremented
once during card activation;
© ISO/IEC
Table 1 — Tags for security support data objects The coding of 'X' in Table 1 is an index of a specific
internal progression value e.g. a counter of file
Tag Meaning
selections.
'7A' Security Support Template (SST), to encapsulate
DOs with the following tags
The coding of 'Y' in Table 1 is an index of a specific
'80' Card session counter
external progression value e.g. an external time
'81' Session identifier
stamp.
‘82’ - ‘8E’ File selection counter
‘93’ Digital signature counter
'9F2X' Internal progression value
'9F3Y' External progression value
© ISO/IEC ISO/IEC 7816-8:1999(E)
8 Secure messaging extensions
8.1 Secure messaging data objects
Table 2 lists the SM data objects defined in ISO/IEC 7816-4 and Amendment 1, and the SM data objects defined in
this part of ISO/IEC 7816.
Table 2 - Secure messaging data objects
ISO/IEC Tag Value
7816 Part-
4 '80' '81' Plain value (non BER-TLV coded data)
4 'B0', 'B1' Plain value (BER-TLV, including SM related data objects)
4 'B2', 'B3' Plain value (BER-TLV, but not SM related data objects)
4 '96', '97' Value of Le in an unsecured command (see ISO/IEC 7816-4, Amendment 1)
4 '99' Status information (e.g. SW1-SW2)
4 '82' '83' Cryptogram, the plain value consisting of BER-TLV including SM related data objects
4 '84' '85' Cryptogram, the plain value consisting of BER-TLV, but not SM related data objects
4 '86' '87' Padding indicator byte (see ISO/IEC 7816-4) followed by cryptogram (plain value not coded in BER-TLV)
4 '8E' Cryptographic checksum (at least 4 bytes)
4 '9E' Digital signature
8 ‘90’ Hash Code
4 '9A' Input for Digital Signature (non BER-TLV coded data)
8 'A0' Input template for Hash Code
8 'A2' Input template for cryptographic checksum verification
8 'A8' Input template for DS verification
8 'AC' Input template for DS (BER-TLV coded data, the concatenation of the value fields are signed)
8 'BC' Input template for DS (BER-TLV coded data, TLV data are signed)
8 ‘92’ Certificate (non BER-TLV coded data)
8 'AE' Input template for certificate verification (signed signature input consisting of non BER-TLV coded data)
8 'BE' Input template for certificate verification (signed signature input consisting of BER-TLV coded data)
8 'A4', 'A5' CRT for authentication (AT)
8 'AA', 'AB' CRT for hash code (HT)
4 'B4', 'B5' CRT for cryptographic checksum (CCT)
4 'B6', 'B7' CRT for digital signature (DST)
4 'B8', 'B9' CRT for confidentiality (CT)
4 'BA', 'BB' Response descriptor
© ISO/IEC
8.2 Control reference data objects
Table 3 lists the CRDOs defined in ISO/IEC 7816-4 and this part of ISO/IEC 7816. The table indicates to which
CRT they are relevant: cryptographic checksum template (CCT), digital signature template (DST), confidentiality
template (CT), hash template (HT) and authentication template (AT).
Table 3 - Data objects within control reference templates
Tag Value CCT DST CT - Asym CT - Sym HT AT
'B4', 'B5' 'B6', 'B7' 'B8', 'B9' 'B8', 'B9' 'AA', 'AB' 'A4', 'A5'
'4D' L„0, extended headerlist of DOs as defined xx
in clause 6
'5D' L„0, Headerlist, as defined in ISO/IEC 7816- xx
'80' Algorithm reference * x x x x x x
File reference *
'81' - file identifier or path x x x x x
'82' - DF name x x x x x
Key reference *
'83' - for direct use in symmetric cases x x x (CK) x
- for referencing a public key in asymmetric xx x x
cases
'84' - for computing a session key in symmetric x xx
cases
- for referencing a private key in asymmetric
xx
cases
Initial check block *
'85' L=0, null block x x x
'86' L=0, chaining block x x x
'87' L=0, e.g. previous initial value block + 1 x x
L=k, initial value block (IV block)
Auxiliary data
'88' L=0, previous challenge + 1 xx x x
L„0, reference data object not specified
'90' L=0, hash code provided by the card x x
'91' L=0, random no. provided by the card xx x
L„0, random number x x
'92' L=0, time stamp provided by the card x x x
L„0, time stamp x x
'93' L=0, previous counter + 1** x x x x
L„0, counter x x x
'89' to L=0, index of a proprietary data item x
'8D' L„0, value of a proprietary data item
'8E' Cryptogram contents reference * x x
'94' Challenge or data item for deriving a key x x x
* = as defined in ISO/IEC 7816-4
** = Digital signature counter.
© ISO/IEC ISO/IEC 7816-8:1999(E)
8.3 Input data objects
Table 4 lists data objects present in input templates to perform security operations, according to this part of
ISO/IEC 7816. The table indicates to which input template the DOs are relevant.
Table 4 - Input data objects
Tag Value Hash Cryptographic Digital Digital Certificate
checksum signature signature verification
verification verification
'80' Plain value x x x x x
'8E' Cryptographic checksum x x
'90' Hash Code x x x x
'92' Certificate x
'9C' Public Key x x
'9E' Digital signature x x
Table 6 - Command chaining specific status
9 Command chaining
coding
Many security processes are multi-stage. Such
SW1 SW2 Meaning
processes can be naturally carried out using several
'68' '83' Final command expected
consecutive command-response pairs with the same
'68' '84' Command chaining not supported
INS code. In this case a different CLA value shall be
used for the last (or only) command involved.
Table 5 - CLA coding for command chaining
10 MANAGE SECURITY ENVIRONMENT
CLA coding Meaning
command
'0X' for the last (or only) command involved
10.1 Definition and scope
1X' for a command which is not the last command
The MANAGE SECURITY ENVIRONMENT
The interpretation of the least significant nibble is as
command supports the following functions:
defined in Table 9 of ISO/IEC 7816-4.
 replacing the current SE by a SE stored in the
During command chaining each command shall have
card (RESTORE);
the same value of X in the CLA.
 setting, or replacing, one component of the
When a security process has been initiated it shall be
current SE (SET);
completed before any other command is issued.
Otherwise the behaviour of the card is not specified.
 saving the current SE under a SE number
(STORE);
If SW1-SW2 is set to '9000' in a response to a
command which is not the last command, then it
 erasing a SE identified with a SE number
means that the processing has been successful so
(ERASE);
far.
 initializing cryptographic commands.
If an error occurs in the middle of a series of chained
commands, it is indicated by an appropriate value of
The usage of a master key concept may require the
SW1-SW2.
derivation of a key in the card containing the master
key (see 10.6).
© ISO/IEC
10.2 Conditional usage and security 10.4 Response message
No conditions are described in this part of Table 10 - MANAGE SECURITY ENVIRONMENT
ISO/IEC 7816. response APDU
Data field Empty
10.3 Command message
SW1-SW2 Status bytes
Table 7 - MANAGE SECURITY ENVIRONMENT
command APDU
10.5 Status conditions
CLA As defined in ISO/IEC 7816-4 and clause 9
INS '22'
The following specific error conditions may occur:
P1 See Table 8
P2 See
— SW1 = '66' with SW2 =
Table 9
• '00' : The environment cannot be set or modified, no
Lc Either length of subsequent data field in the
further information;
case of SET or
empty in the case of STORE, RESTORE and
— SW1 = '69' with SW2 =
ERASE
Data field Either a concatenation of CRDOs (in the case of
• '87': Expected SM data objects missing;
SET) or
• '88': SM data objects incorrect;
empty in the case of STORE, RESTORE and
ERASE
— SW1 = '6A' with SW2 =
Le Empty
• '88': Referenced data not found.
Table 8 - Coding of P1
10.6 Computing a derived key with
MANAGE SECURITY ENVIRONMENT
b b b b b b b b Meaning
8 7 6 5 4 3 2 1
Table 11 shows the usage of the MANAGE
- - - 1 - - - - SM command
SECURITY ENVIRONMENT command for deriving a
--1 ---- - SM response
key. It is assumed that in the card the master key
-1 - ---- - Computation, decipherment and and the algorithm is implicitly selected (if not, the key
internal authentication
and the algorithm can be selected in the MANAGE
SECURITY ENVIRONMENT command additionally).
1 - - ---- - Verification, encipherment and
external authentication
Table 11 - Command message APDU
--- -0 0 0 1 SET
CLA As defined in ISO/IEC 7816-4
111 1001 0 STORE
INS '22'
111 1001 1 RESTORE
P1 'X4' = SET (see Table 8)
111 1010 0 ERASE
P2 Tag of the related CRT (e.g. 'A4', if an
authentication related command follows (e.g.
EXTERNAL AUTHENTICATE) or 'B4', if a crypto-
Table 9 - Coding of P2
graphic checksum related command follows (e.g.
b8.b1 Meaning
PSO: VERIFY CC))
in case of STORE, RESTORE and ERASE
Lc Length of subsequent data field
'xy' SE number
Data field '94' - L - Data for deriving a key (mandatory -
further DOs are possible (see Table 3)
in the case of SET
Le Empty
'B4' value of CCT in data field
'B6' value of DST in data field
'AA' value of HT in data field
Table 12 - Response message APDU
'B8' value of CT in data field
Data field Empty
'A4' value of AT in data field
SW1-SW2 Status bytes
Any other value RFU
© ISO/IEC ISO/IEC 7816-8:1999(E)
NOTE  Depending on the algorithm reference the data
11.3 Command message
for deriving a key from a master key may be part of the
input data of the subsequent command (e.g. EXTERNAL
Table 13 - PERFORM SECURITY OPERATION
AUTHENTICATE). In this case the usage of the MANAGE
command APDU
SECURITY ENVIRONMENT command for deriving the
key is not necessary.
CLA As defined in ISO/IEC 7816-4 and clause 9
INS '2A'
11 PERFORM SECURITY OPERATION
P1 Tag of the DO, the value field of which is
command transmitted in the response data field, or
'00' data field in response is empty
11.1 Definition and scope
'FF' = RFU
The PERFORM SECURITY OPERATION command
P2 Tag of the DO, the value field of which is
initiates the following security operations:
transmitted in the command data field, or
'00' data field in command is empty
 computation of a cryptographic checksum;
'FF' RFU
 computation of a digital signature;
Lc field Length of the subsequent data field
 calculation of a hash code;
Data field Value of the DO specified in P2, or empty
Le field Empty or maximum length of the data expected in
 verification of a cryptographic checksum;
response
 verification of a digital signature;
 verification of a certificate;
 encipherment;
11.4 Response message
 decipherment.
For response messages see the relevant clause
under each operation.
The security operations initiated are related to the
DOs specified in P1 and P2. The command may be
performed in one or several steps, possibly using the
11.5 Status conditions
command chaining function (see 9).
Unless specifically stated, as defined in ISO/IEC
11.2 Conditional usage and security
7816-4 and in this part of ISO/IEC 7816.
The PERFORM SECURITY OPERATION command
may be preceded by a MANAGE SECURITY
11.6 COMPUTE CRYPTOGRAPHIC
ENVIRONMENT command. The successful
CHECKSUM operation
execution of the command may be subject to
successful completion of prior commands (e.g.
11.6.1 Definition and scope
VERIFY before the computation of a digital
signature).
The COMPUTE CRYPTOGRAPHIC CHECKSUM
operation initiates the computation of a cryptographic
The key reference as well as the algorithm reference
checksum.
shall be
11.6.2 Conditional usage and security
 either implicitly known or
specified in a CRT in a MANAGE SECURITY The command can be performed only if the security

ENVIRONMENT command. status satisfies the security attributes for this
operation.
If present, a headerlist defines the order and the data
items which form the input for the security
operations.
© ISO/IEC
11.6.3 Command message 11.7.2 Conditional usage and security
Table 14 - COMPUTE CRYPTOGRAPHIC The command can be performed only if the security
CHECKSUM parameter and command DOs status satisfies the security attributes for this
operation.
P1 '8E'
P2 '80'
11.7.3 Command message
Data field data for which the cryptographic checksum
shall be computed Table 16 - COMPUTE DIGITAL SIGNATURE
parameter and command DOs
NOTE  this operation may be subject to command
P1 '9E'
chaining
P2 '9A', 'AC' or 'BC'
11.6.4 Response message
Data field If P2 = '9A': data to be signed or integrated in
the signature process
Table 15 - COMPUTE CRYPTOGRAPHIC
if P2 = 'AC': DOs relevant for DSI (the value
CHECKSUM response APDU
field of these DOs are signed or integrated in
the signature process)
Data field Cryptographic checksum
if P2 = 'BC': DOs relevant for DSI (the DOs are
SW1-SW2 Status bytes
signed or integrated in the signature process)
NOTE  Tags 'AC' and 'BC' are not integrated into the
11.7 COMPUTE DIGITAL SIGNATURE
digital signature input.
operation
11.7.4 Response message
11.7.1 Definition and scope
Table 17 - COMPUTE DIGITAL SIGNATURE
The COMPUTE DIGITAL SIGNATURE operation
response APDU
initiates the computation of a digital signature.
Data field Digital Signature
SW1-SW2 Status bytes
For the computation of a digital signature the data to
be signed or to be integrated in the signing process
are transmitted in the data field of the PERFORM
SECURITY OPERATION command. In P2 the digital 11.8 HASH operation
signature is specified with tags '9A', 'AC' or 'BC'
11.8.1 Definition and scope
according to the structure of the input (see Table 2).
The HASH operation initiates the calculation of a
The algorithm may be either a digital signature
hash code by performing:
algorithm or a combination of a hash algorithm and a
digital signature algorithm.
 either complete hashing inside the card or
If auxiliary data (see Table 3) are to be included in
 partly hashing inside the card (e.g. last round of
the Digital Signature Input (DSI - see Table 3), then a
computation.
reference has to be made in the CRT (see 6.1). If an
empty reference data object for auxiliary data is
The algorithm reference for computing a hash code
present, then the auxiliary data are to be inserted by
(see Table 3) is indicated in the CRT for Hash
the card.
computation ('AA', 'AB'), see Table 2.
Auxiliary data present or referenced in the data field
For the further processing of a computed hash code
take precedence over any headerlist.
the following cases have to be distinguished:
The value to be returned by the card is a digital
 the hash code is stored in the card: the
signature specified in P1 ('9E').
calculated hash code is stored in the card and
available for use in a subsequent command and
the Le field is empty;
© ISO/IEC ISO/IEC 7816-8:1999(E)
11.9.3 Command message
 the hash code is delivered by the card in the
response: if the hash code is delivered in the
Table 20 - VERIFY CRYPTOGRAPHIC CHECKSUM
response then the Le field has to be set to the
parameter and command DOs
appropriate length.
P1 '00'
The data to be hashed shall be presented to the card
P2 'A2'
in successive blocks (one or more at a time), the
Data field DOs relevant to the VERIFY
length of which is algorithm dependent. Depending
CRYPTOGRAPHIC CHECKSUM operation
on the hash algorithm the last block presented may
(e.g. DO ‘80’, ‘8E’ see Table 2)
have a length equal or shorter than the block length.
NOTE  this operation may be subject to command
The padding mechanism, if appropriate, is part of the
chaining.
definition of the hash algorithm.
11.9.4 Response message
11.8.2 Conditional usage and security
Table 21 - VERIFY CRYPTOGRAPHIC CHECKSUM
The command can be performed only if the security
response APDU
status satisfies the security attributes for this
Data field Empty
operation.
SW1-SW2 Status bytes
11.8.3 Command message
Table 18 - HASH parameter and command DOs
11.10 VERIFY DIGITAL SIGNATURE
P1 '90'
operation
P2 '80' or 'A0'
11.10.1 Definition and scope
Data field If P2 = '80': data to be hashed
If P2 = 'A0': DOs relevant for hashing The VERIFY DIGITAL SIGNATURE operation
(e.g. '90' for the intermediate hash code,
initiates the verification of a digital signature to be
'80' for the last text block)
delivered as a DO in the data field. Other verification
relevant data are to be transmitted in a command
chaining process or may be present in the card.
11.8.4 Response message
The public key as well as the algorithm may be
Table 19 - HASH response APDU
Data field Hash code or empty
 either implicitly known or
SW1-SW2 Status bytes
 referenced in a DST ('B6') of a MANAGE
SECURITY ENVIRONMENT command or
 available as a result from a preceding VERIFY
CERTIFICATE operation.
11.9 VERIFY CRYPTOGRAPHIC CHECKSUM
operation
The algorithm may be either a digital signature only
algorithm or a combined hash code and digital
11.9.1 Definition and scope
signature algorithm.
The VERIFY CRYPTOGRAPHIC CHECKSUM
If the reference of the algorithm in the card declares
operation initiates the verification of a cryptographic
a signature only algorithm then the data consists of a
checksum.
hash code, or the signature is of message recovery
type according to ISO/IEC 9796. Otherwise the
11.9.2 Conditional usage and security
hash code calculation is performed in the card and
the algorithm reference additionally contains a
The command can be performed only if the security
reference to a hash algorithm.
status satisfies the security attributes for this
operation.
© ISO/IEC
11.10.2 Conditional usage and security 11.11.2 Conditional usage and security
The command can be performed only if the security The command can be performed only if the security
status satisfies the security attributes for this status satisfies the security attributes for this
operation. operation.
11.10.3 Command message
If the public key is stored, it will be the default key for
subsequent VERIFY DIGITAL SIGNATURE opera-
Table 22 - VERIFY DIGITAL SIGNATURE
tion.
parameter and command DOs
11.11.3 Command message
P1 '00'
P2 'A8'
Table 24 - VERIFY CERTIFICATE parameter and
Data field DOs relevant to the VERIFY DIGITAL command DOs
SIGNATURE operation (e.g. DO ‘9A’, ‘AC’ and
P1 '00'
‘BC’, and DO ‘9E’, see Table 2)
P2 '92', 'AE', 'BE'
If the data field contains an empty DO, the card is Data field DEs or DOs relevant to the VERIFY
CERTIFICATE operation (see Table 2)
expected to know its values for use in the verification.
11.10.4 Response message
NOTE  If a limited message recovery algorithm is used
and part of the information is already stored in the card,
Table 23 - VERIFY DIGITAL SIGNATURE
then the DO for auxiliary data shall be sent empty, with the
Response APDU
data to be inserted later by the card.
Data field Empty
11.11.4 Response message
SW1-SW2 Status bytes
Table 25 - VERIFY CERTIFICATE response APDU
11.11 VERIFY CERTIFICATE operation
Data field Empty
SW1-SW2 Status bytes
11.11.1 Definition and scope
For the verification of a certificate in a card (see
Annex A) the digital signature of a certificate to be
verified is delivered as a DO in the data field. The
11.12 ENCIPHER operation
public key of the certification authority to be used in
the verification process shall be present in the card
11.12.1 Definition and scope
and is either implicitly selected or may be referenced
in a DST using the MANAGE SECURITY
The ENCIPHER operation enciphers data
ENVIRONMENT command. The algorithm to be
transmitted in the command data field.
applied is implicitly known or may be referenced in a
DST. If other DOs are to be used in the verification
NOTE  this operation may also be used to generate
process (e.g. hash code) then these DOs shall be
diversified keys.
present in the card or shall be transmitted by the
command chaining process described in clause 9.
11.12.2 Conditional usage and security
The following cases have to be distinguished:
The command can be performed only if the security
status satisfies the security attributes for this
operation.
 the certificate is self descriptive (P2 = 'BE'): the
card retrieves a public key identified by its tag in
The usage of this operation may be restricted.
the (recovered) certificate content;
 the certificate is not self descriptive (P2 = 'AE'):
the card retrieves a public key in the certificate
either implicitly or explicitly by using the public
key tag in a headerlist describing the content of
the certificate.
© ISO/IEC ISO/IEC 7816-8:1999(E)
11.12.3 Command message
12 Manage verification process
Table 26 - ENCIPHER parameter and command
12.1 Introduction
DOs
P1 '82', '84', '86' (cryptogram, see Table 2)
The following commands belong to the manage
verification process:
P2 '80' (plain value)
Data field data to be enciphered
 VERIFY, as defined in ISO/IEC 7816-4;
 CHANGE REFERENCE DATA;
 ENABLE VERIFICATION REQUIREMENT;
11.12.4 Response message
 DISABLE VERIFICATION REQUIREMENT;
Table 27 - ENCIPHER response APDU
 RESET RETRY COUNTER.
Data field enciphered data
Specific warning and error conditions for the manage
SW1-SW2 Status bytes verification process commands are given in clause
12.6.
The security status may be set by the command itself
if it contains the appropriate parameters. If not the
security status may be set by different means e.g.
11.13 DECIPHER operation
secure messaging, previous authentication.
11.13.1 Definition and scope
The security status may be modified as a result of a
comparison. Unsuccessful comparisons may be
The DECIPHER operation deciphers data
recorded in the card (e.g. to limit the number of
transmitted in the command data field.
further attempts of the use of the reference data).
11.13.2 Conditional usage and security
The command can be performed only if the security
status satisfies the security attributes for this 12.2 CHANGE REFERENCE DATA
operation. command
The usage of this operation may be restricted. 12.2.1 Definition and scope
11.13.3 Command message The CHANGE REFERENCE DATA command is
used
Table 28 - DECIPHER parameter and command
DOs
 either to replace the existing reference data with
P1 '80' (plain value)
new reference data or
P2 '82' ,'84' ,'86' (cryptogram, see Table 2)
 to initiate the comparison of the verification data
Data field data to be deciphered
with the reference data, and then to conditionally
replace the existing reference data with new
reference data sent to the card in the command.
12.2.2 Conditional usage and security
11.13.4 Response message
This command can be performed only if the security
Table 29 - DECIPHER response APDU
status satisfies the security attributes valid for this
Data field Deciphered data
command.
SW1-SW2 Status bytes
...