ISO/IEC 7816-9:2017

INTERNATIONAL ISO/IEC
STANDARD 7816-9
Third edition
2017-12
Identification cards — Integrated
circuit cards —
Part 9:
Commands for card management
Cartes d'identification — Cartes à circuit intégré —
Partie 9: Commandes pour la gestion des cartes
Reference number
©
ISO/IEC 2017
© ISO/IEC 2017, Published in Switzerland
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized otherwise in any form
or by any means, electronic or mechanical, including photocopying, or posting on the internet or an intranet, without prior
written permission. Permission can be requested from either ISO at the address below or ISO’s member body in the country of
the requester.
ISO copyright office
Ch. de Blandonnet 8 • CP 401
CH-1214 Vernier, Geneva, Switzerland
Tel. +41 22 749 01 11
Fax +41 22 749 09 47
copyright@iso.org
www.iso.org
ii © ISO/IEC 2017 – All rights reserved

Contents Page
Foreword .iv
Introduction .v
1 Scope .1
2 Normative references .1
3 Terms and definitions .1
4 Symbols and abbreviated terms . 2
5 Life cycle .3
5.1 General properties . 3
5.2 Generic life cycle status . 4
5.3 Command-dependent life cycle status transition . 6
5.4 Life cycle status inheritance and evaluation . 7
5.4.1 General. 7
5.4.2 General rules for life cycle status evaluation . 7
5.4.3 Behaviour for effective LCS . 8
6 Commands for card management .8
6.1 General . 8
6.2 create file command . 9
6.3 delete command .10
6.4 deactivate command .10
6.5 activate command .11
6.6 terminate command .11
6.7 terminate ef command .12
6.8 manage data command .12
6.9 create command .13
6.10 terminate card usage command .14
6.11 import card secret command .14
Annex A (informative) Command-dependent LCS transition examples .16
Annex B (informative) Life cycle status handling examples.18
Bibliography .21
© ISO/IEC 2017 – All rights reserved iii

Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that are
members of ISO or IEC participate in the development of International Standards through technical
committees established by the respective organization to deal with particular fields of technical
activity. ISO and IEC technical committees collaborate in fields of mutual interest. Other international
organizations, governmental and non-governmental, in liaison with ISO and IEC, also take part in the
work. In the field of information technology, ISO and IEC have established a joint technical committee,
ISO/IEC JTC 1.
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular the different approval criteria needed for the
different types of ISO documents should be noted. This document was drafted in accordance with the
editorial rules of the ISO/IEC Directives, Part 2 (see www.iso.org/directives).
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. ISO shall not be held responsible for identifying any or all such patent rights. Details of
any patent rights identified during the development of the document will be in the Introduction and/or
on the ISO list of patent declarations received (see www.iso.org/patents).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation on the voluntary nature of standards, the meaning of ISO specific terms and
expressions related to conformity assessment, as well as information about ISO's adherence to the
World Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT) see the following
URL: www.iso.org/iso/foreword.html.
This document was prepared by ISO/IEC JTC 1, Information technology, Subcommittee SC 17, Cards and
security devices for personal identification.
This third edition cancels and replaces the second edition (ISO/IEC 7816-9:2004), which has been
technically revised.
The main changes compared to the previous edition are as follows:
— a template ‘AE’ has been proposed for the configuration of command-dependent LCS transitions
(see create command);
— Figure 1 (generic LCS transition diagram) has been modified;
— delete, activate, deactivate, terminate commands have been redesigned with a common
generic P1 parameter, and existing commands have remained unchanged for legacy reasons; 6.1
describes generic or legacy command options and Table 3 describes the bitmap of P1 and P2 for
legacy commands and extended command (generic ones);
— manage data and delete data commands have been reserved for DO only; enquiry on delete data
usefulness has been confirmed and the command maintained but declared as likely to be deprecated
in future revisions of this document;
— dedicated subclauses have been provided addressing LCS inheritance and LCS evaluation;
— new terminology and rules for evaluated LCS category have been provided: directly assigned or
effective, with addition of a recursive table for effective LCS allotment to the child object;
— the command create data has been renamed create and assigned a P1 parameter borrowed from
generic commands for the sake of harmonization.
A list of all parts in the ISO/IEC 7816 series can be found on the ISO website.
iv © ISO/IEC 2017 – All rights reserved

Introduction
ISO/IEC 7816 is a series of International Standards specifying integrated circuit cards and the use of
such cards for interchange. These cards are identification cards intended for information exchange
negotiated between the outside world and the integrated circuit in the card. As a result of an information
exchange, the card delivers information (computation result, stored data) and/or modifies its content
(data storage, event memorization).
— Five parts in the series are specific to cards with galvanic contacts and three of them specify
electrical interfaces.
— ISO/IEC 7816-1 specifies physical characteristics for cards with contacts.
— ISO/IEC 7816-2 specifies dimensions and location of the contacts.
— ISO/IEC 7816-3 specifies electrical interface and transmission protocols for asynchronous cards.
— ISO/IEC 7816-10 specifies electrical interface and answer to reset for synchronous cards.
— ISO/IEC 7816-12 specifies electrical interface and operating procedures for USB cards.
— All the other parts in the series are independent from the physical interface technology. They apply
to cards accessed by contacts and/or by radio frequency.
— ISO/IEC 7816-4 specifies organization, security and commands for interchange.
— ISO/IEC 7816-5 specifies registration of application providers.
— ISO/IEC 7816-6 specifies interindustry data elements for interchange.
— ISO/IEC 7816-7 specifies commands for structured card query language.
— ISO/IEC 7816-8 specifies commands for security operations.
— ISO/IEC 7816-9 specifies commands for card management.
— ISO/IEC 7816-11 specifies personal verification through biometric methods.
— ISO/IEC 7816-13 specifies commands for application management in a multi-application
environment.
— ISO/IEC 7816-15 specifies cryptographic information application.
ISO/IEC 10536 (all parts) specifies access by close coupling. ISO/IEC 14443 (all parts) and
ISO/IEC 15693 (all parts) specify access by radio frequency. Such cards are also known as
contactless cards.
© ISO/IEC 2017 – All rights reserved v

INTERNATIONAL STANDARD ISO/IEC 7816-9:2017(E)
Identification cards — Integrated circuit cards —
Part 9:
Commands for card management
1 Scope
This document specifies interindustry commands for card, file and other structure management, i.e.
data object and security object. These commands cover the entire life cycle of the card and therefore
some commands are used before the card has been issued to the cardholder or after the card has
expired. For details on record life cycle status, refer to ISO/IEC 7816-4.
It is not applicable to the internal implementation within the card and/or the outside world.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements of this document. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any amendments) applies.
ISO/IEC 7816-4:2013, Identification cards — Integrated circuit cards — Part 4: Organization, security and
commands for interchange
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
— IEC Electropedia: available at http://www.electropedia.org/
— ISO Online browsing platform: available at https://www.iso.org/obp
3.1
object
structure (according to ISO/IEC 7816-4) or security object (3.3)
3.2
secure messaging
set of means for cryptographic protection of (parts of) command-response pairs
[SOURCE: ISO/IEC 7816-4:2013, 3.50]
3.3
security object
standalone object (3.1) nested in an EF, a record, a data object, a DataString or a combination thereof
that endorses security handling according to ISO/IEC 7816-4
© ISO/IEC 2017 – All rights reserved 1

4 Symbols and abbreviated terms
AID application identifier
AMF access mode field
AT control reference template for authentication
CCT control reference template for cryptographic checksum
CLA class byte
CP control parameter
CP DO control parameter data object (bearing the tag ‘62’)
CRT control reference template
DF dedicated file
DO BER-TLV data object
DST control reference template for digital signature
EF elementary file
EF.ATR/INFO Answer-to-Reset file or Information file
FCP file control parameter
FID file identifier
GAKP generate asymmetric key pair command
ICC integrated circuit card
IFD interface device
INS instruction byte
L field length field for coding the number of bytes in the command data field
c
L field length field for coding maximum number of bytes expected in the response data field
e
LCS life cycle status
MF master file
N number of bytes in the command data field
c
N maximum number of bytes expected in the response data field
e
OID object identifier
P1-P2 parameter bytes
RFU reserved for future use by ISO/IEC JTC 1/SC 17
SE security environment
SEID security environment identifier
2 © ISO/IEC 2017 – All rights reserved

SCB security condition byte
SM secure messaging
SPT security parameter template (using DO‘AD’ under DO‘62’)
SW1-SW2 status bytes
TLV tag, length, value
VA validity area
5 Life cycle
5.1 General properties
A life cycle status (see coding in ISO/IEC 7816-4:2013, 7.4.10) may be associated with any object in the
card and with the card itself. The card shall use the life cycle status in combination with additional
security attributes when present and applicable, unless defined otherwise by the application, to
determine whether an operation on an object is in accordance with a security policy. The life cycle
status determines the use of objects when the card supports life cycle status dependent security
attributes according to the following rules.
— If an object is in creation state, then no security attribute shall apply unless otherwise specified.
— If an object is in initialization state, then any security attribute specific to this state may apply.
— If an object is in operational state, then any associated security attribute specific to this state
shall apply.
— If an object is in termination state, then the value of the object shall not be accessed unless determined
otherwise by its associated security attributes, e.g. it can be deleted.
In addition to the behaviour described above, distinguishing characteristics for primary states of life
cycle are defined as follows.
— Creation state — an object is newly created (e.g. by create or create file command) or appended
(e.g. update data, put data commands) to an existing object. These operations may fit the created
item with its control parameters and may provision it with data elements.
— Initialization state — a newly created object or an existing object in creation state may be initialized.
The object is not active but selectable and may be provisioned with data.
— Operational state comprises two secondary states: operational activated and operational deactivated.
When activated, the object and its contents may be accessed according to its security attributes.
When deactivated, the object is logically reduced with restricted capabilities or functionality but
selectable and the access to its content depends on the application. From these states, the object can
be terminated.
— Termination state — the object is logically reduced with restricted capabilities or functionality but
selectable. The only applicable command is for object deletion unless determined otherwise by the
application. Upon selection of a selectable terminated object, the warning status SW1-SW2 = ‘6285’
shall be returned; otherwise, i.e. not selectable object, an error code shall be returned. Further
possible actions are not defined in ISO/IEC 7816 (all parts).
— Card Termination state — after a successful completion of the TERMINATE CARD USAGE command,
the card shall reject the select command.
After creation, the object is either in creation state or in initialization state or operational (activated
or deactivated) state. Transitions between primary life cycle statuses are irreversible and occur only
© ISO/IEC 2017 – All rights reserved 3

from creation to termination. In addition, the application may define secondary life cycle status: each
primary state may have reversible secondary states. Changes are controlled by the card and may be
performed in a pre-defined order, reflecting reversible or irreversible changes in states. Commands
that may be used for initiating a life cycle status transition for either card and file management or for
data object or further object management are listed in Table 1.
Commands may set the value of the life cycle status when they execute. However, the card shall maintain
the integrity of this value in accordance with this document.
For all the life cycle status above, their supported transitions are described in a generic diagram
applying to all objects (see Figure 1). For further transition alternatives that may be applied to all
objects, see 5.3 for command-dependent LCS transitions. Other commands applicable to the objects in
these states, including for the discoverability of their related state, are determined by the application.
Examples of life cycle status handling are provided for information on Annex B.
5.2 Generic life cycle status
Figure 1 provides a generic representation of life cycle status and transitions applying to files, data
objects or any further object of which the card management is according to this document. The
transitions on Figure 1 are performed upon successful completion of card management commands that
are listed in Table 1. The condition of execution of those commands is according to ISO/IEC 7816-4.
Figure 1 — Generic diagram for life cycle status
NOTE ISO/IEC 7816-4 allows proprietary values for life cycle status that are addressed by this document.
4 © ISO/IEC 2017 – All rights reserved

Table 1 — Commands entailing explicit life cycle status transition
Transition Object
From To File Other objects
Creation state CREATE FILE CREATE
Initialization state CREATE FILE CREATE
a a
Proprietary command Proprietary command
Operational state CREATE FILE CREATE
Object not
(activated)
existing
Operational state CREATE FILE CREATE
(deactivated)
Card termination TERMINATE CARD USAGE TERMINATE CARD USAGE
state
b
Operational state ACTIVATE (FILE) ACTIVATE
(activated) MANAGE DATA
b
Operational state DEACTIVATE (FILE) DEACTIVATE
(deactivated) MANAGE DATA
a
Initialization state Proprietary command MANAGE DATA
a
Proprietary command
Creation state
b
Termination state TERMINATE EF TERMINATE
TERMINATE (DF) MANAGE DATA
b
Object not existing DELETE (FILE) DELETE
DELETE DATA
Card termination TERMINATE CARD USAGE TERMINATE CARD USAGE
state
b
Operational state ACTIVATE (FILE) ACTIVATE
(activated) MANAGE DATA
b
Operational state DEACTIVATE (FILE) DEACTIVATE
(deactivated) MANAGE DATA
b
Initialization Termination state TERMINATE EF TERMINATE
state TERMINATE (DF) MANAGE DATA
b
Object not existing DELETE (FILE) DELETE
DELETE DATA
Card termination TERMINATE CARD USAGE TERMINATE CARD USAGE
state
Operational state DEACTIVATE (FILE) MANAGE DATA
b
(deactivated) DEACTIVATE
b
Termination state TERMINATE EF TERMINATE
Operational
TERMINATE (DF) MANAGE DATA
state
b
Object not existing DELETE (FILE) DELETE
(activated)
DELETE DATA
Card termination TERMINATE CARD USAGE TERMINATE CARD USAGE
state
a
For legacy reasons, proprietary commands can be used for this transition.
b
Transition applicable to objects other than files referenced as described in 6.1.
© ISO/IEC 2017 – All rights reserved 5

Table 1 (continued)
Transition Object
From To File Other objects
Operational state ACTIVATE (FILE) MANAGE DATA
b
(activated) ACTIVATE
b
Termination state TERMINATE EF TERMINATE
Operational
TERMINATE (DF) MANAGE DATA
state
b
Object not existing DELETE( FILE) DELETE
(deactivated)
DELETE DATA
Card termination TERMINATE CARD USAGE TERMINATE CARD USAGE
state
b
Object not existing DELETE (FILE) DELETE
DELETE DATA
Termination
state
Card termination TERMINATE CARD USAGE TERMINATE CARD USAGE
state
a
For legacy reasons, proprietary commands can be used for this transition.
b
Transition applicable to objects other than files referenced as described in 6.1.
5.3 Command-dependent life cycle status transition
A command-dependent LCS transition for an object is an LCS transition triggered by a command
according to the execution rules applicable for the object.
The security handling or operation commands general authenticate, generate asymmetric key
pair, reset retry counter and change reference data, and commands initiating the modification
of the current template contents as put/put next/update data may have a command-dependent
LCS transition effect of initiating an LCS transition. Unlike the rest of the transitions initiated by
other commands and that are said explicit (see Table 1), these transitions are provided as optional
functionality.
In the last step of command processing onto an object featuring CP, the assigned CP shall be evaluated
to check for the requirement to perform a command-dependent LCS transition.
To be applicable, command-dependent LCS transition functionality shall conform to the following rules:
— for an existing object, all transitions from Figure 1 could be triggered by a command-dependent LCS
transition;
— the command-dependent LCS transition applicable for the object shall be executed after successful
execution of the command, i.e. the response trailer indicates “normal processing” (see ISO/IEC 7816-
4:2013, Table 5);
— such a transition shall be declared during object creation phase with the use of create command
only; the use of any other command to achieve the same goal is out of scope of this document;
— the payload of create shall contain within CP template (DO‘62’) a data object ‘AE’ nesting one
or more context-specific configuration DO‘A1’, each of which features a value field describing the
conditions for a command-dependent LCS transition and is comprised of:
— an LCS DO‘8A’ according to ISO/IEC 7816-4:2013, Table 14 denoting the starting LCS for the
transition;
— one or more access mode DO from ‘81’ to ‘8F’ according to ISO/IEC 7816-4:2013, Tables 31 and
32, optionally followed by security condition data objects according to ISO/IEC 7816-4:2013,
Table 33; access mode and security condition compose an access rule; the LCS transition occurs
if and only if this access rule is fulfilled;
— an LCS DO‘8A’ denoting the targeted LCS for the transition.
6 © ISO/IEC 2017 – All rights reserved

Whenever it occurs under create (INS code ‘E1’), the template ‘AE’ nested in CP DO‘62’ is meant for
command-dependent transition configuration. See DO‘AE’ application examples in Annex A.
5.4 Life cycle status inheritance and evaluation
5.4.1 General
This subclause describes the general rules for life cycle status inheritance and evaluation applicable to
objects.
Life cycle status are defined herein either as directly assigned LCS or effective LCS.
The life cycle status of a file, a data object or a further object is said to be
— directly assigned LCS when it is configured in the object’s CP as the explicit value of DO‘8A’, or
— effective LCS when it results from the evaluation rules set in Table 2 (see 5.4.2) and it derives from
the effective life cycle status of its parent structure.
The effective LCS of an object shall match one among the LCSs of LCS-dependent security attributes for
those attributes to be applicable; as a general rule, for LCS-dependent security attributes, the effective
LCS shall apply (see ISO/IEC 7816-4:2013, 7.4.12.2). As a general rule, a command can be performed
only if the security status satisfies the security attributes defined for the function.
5.4.2 General rules for life cycle status evaluation
Table 2 reads as follows: when a child’s directly assigned LCS valuates to a row’s value from Table 2,
it is assigned the effective LCS as r
...