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
Current Stage
9599 - Withdrawal of International Standard
Completion Date
11-Jun-2004
Ref Project

Relations

Buy Standard

Standard
ISO/IEC 7816-8:1999 - Identification cards -- Integrated circuit(s) cards with contacts
English language
27 pages
sale 15% off
Preview
sale 15% off
Preview

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
ISO/IEC 7816-8:1999(E)

---------------------- Page: 1 ----------------------
ISO/IEC 7816-8:1999(E)
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

---------------------- Page: 2 ----------------------
© 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

---------------------- Page: 3 ----------------------
ISO/IEC 7816-8:1999(E) © ISO/IEC
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

---------------------- Page: 4 ----------------------
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.
1

---------------------- Page: 5 ----------------------
© ISO/IEC
ISO/IEC 7816-8:1999(E)
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
2

---------------------- Page: 6 ----------------------
© 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
3

---------------------- Page: 7 ----------------------
© ISO/IEC
ISO/IEC 7816-8:1999(E)
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 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
3
 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
4

---------------------- Page: 8 ----------------------
© 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;
5

---------------------- Page: 9 ----------------------
© ISO/IEC
ISO/IEC 7816-8:1999(E)
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
6

---------------------- Page: 10 ----------------------
© 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
7

---------------------- Page: 11 ----------------------
© ISO/IEC
ISO/IEC 7816-8:1999(E)
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
6
'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.
8

---------------------- Page: 12 ----------------------
© 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).
9

---------------------- Page: 13 ----------------------
© ISO/IEC
ISO/IEC 7816-8:1999(E)
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
...

Questions, Comments and Discussion

Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.