Projet de PNM ISO/IEC 7816-9

IC 17.1.115
Norme Marocaine 2022

ICS : 35.240.15

Identification cards

ne
Integrated circuit cards
Part 9 : Commands for card management

ai
oc
Cartes d’identification

ar
Cartes à circuit intégré m
Partie 9: Commandes pour la gestion des cartes
e
r m
no

Norme Marocaine homologuée

de

Par décision du Directeur de l’Institut Marocain de Normalisation N°........... du ............ 2022,

publiée au B.O. N° ............ du ............ .
et

Correspondance
oj

La présente norme est identique à l’ISO/IEC 7816-9:2017.

pr

Droits d'auteur
Droit de reproduction réservés sauf prescription différente aucune partie de cette publication ne peut
être reproduite ni utilisée sous quelque forme que ce soit et par aucun procédé électronique ou
mécanique y compris la photocopie et les microfilms sans accord formel. Ce document est à usage
exclusif et non collectif des clients de l'IMANOR, Toute mise en réseau, reproduction et rediffusion, sous
quelque forme que ce soit, même partielle, sont strictement interdites.

Institut Marocain de Normalisation (IMANOR) © IMANOR 2022 – Tous droits réservés

Angle Avenue Kamal Zebdi et Rue Dadi Secteur 21 Hay Riad - Rabat
Tél : 05 37 57 19 48/49/51/52 - Fax : 05 37 71 17 73
Email : imanor@imanor.gov.ma
PNM ISO/IEC7816-9:2022

Avant-Propos National

L’Institut Marocain de Normalisation (IMANOR) est l’Organisme National de Normalisation. Il a été

créé par la Loi N° 12-06 relative à la normalisation, à la certification et à l’accréditation sous forme
d’un Etablissement Public sous tutelle du Ministère chargé de l’Industrie et du Commerce.

Les normes marocaines sont élaborées et homologuées conformément aux dispositions de la Loi

ne
N° 12-06 susmentionnée.

La présente norme marocaine NM ISO/IEC 7816-9 a été examinée et adoptée par la

ai
commission de normalisation des technologies de l’information et de la communication (51).

oc
ar
m
e
r m
no
de
et
oj
pr
 ISO/IEC 7816-9:2017(E)


Contents Page

Foreword......................................................................................................................................................................................................................................... iv
Introduction...................................................................................................................................................................................................................................v
1 Scope.................................................................................................................................................................................................................................. 1
2 Normative references....................................................................................................................................................................................... 1
3 Terms and definitions...................................................................................................................................................................................... 1
4 Symbols and abbreviated terms............................................................................................................................................................ 2

ne
5 Life cycle......................................................................................................................................................................................................................... 3
5.1 General properties................................................................................................................................................................................ 3
5.2 Generic life cycle status.................................................................................................................................................................... 4

ai
5.3 Command-dependent life cycle status transition...................................................................................................... 6
5.4 Life cycle status inheritance and evaluation.................................................................................................................. 7

oc
5.4.1 General...................................................................................................................................................................................... 7
5.4.2 General rules for life cycle status evaluation............................................................................................ 7
5.4.3 Behaviour for effective LCS...................................................................................................................................... 8

ar
6 Commands for card management........................................................................................................................................................ 8
6.1 General............................................................................................................................................................................................................ 8
6.2  create file command...................................................................................................................................................................... 9
m
6.3  delete command.............................................................................................................................................................................. 10
6.4  deactivate command................................................................................................................................................................... 10
6.5  activate command.......................................................................................................................................................................... 11
e
6.6  terminate command..................................................................................................................................................................... 11
6.7  terminate ef command............................................................................................................................................................. 12
rm

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
no

Annex A (informative) Command-dependent LCS transition examples........................................................................16

Annex B (informative) Life cycle status handling examples......................................................................................................18
de

Bibliography.............................................................................................................................................................................................................................. 21
et
oj
pr

© ISO/IEC 2017 – All rights reserved  iii

ISO/IEC 7816-9:2017(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.

ne
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

ai
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

oc
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).

ar
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement. m
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
e
URL: www.iso.org/iso/foreword.html.
rm

This document was prepared by ISO/IEC JTC 1, Information technology, Subcommittee SC 17, Cards and
security devices for personal identification.
no

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:
de

— 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;
et

— 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
oj

describes generic or legacy command options and Table 3 describes the bitmap of P1 and P2 for
legacy commands and extended command (generic ones);
pr

— 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

 ISO/IEC 7816-9:2017(E)


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.

ne
— ISO/IEC 7816-1 specifies physical characteristics for cards with contacts.
— ISO/IEC 7816-2 specifies dimensions and location of the contacts.

ai
— ISO/IEC 7816-3 specifies electrical interface and transmission protocols for asynchronous cards.

oc
— 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.

ar
— 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.
m
— ISO/IEC 7816-4 specifies organization, security and commands for interchange.
— ISO/IEC 7816-5 specifies registration of application providers.
e
— ISO/IEC 7816-6 specifies interindustry data elements for interchange.
rm

— ISO/IEC 7816-7 specifies commands for structured card query language.

— ISO/IEC 7816-8 specifies commands for security operations.
no

— 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
de

environment.
— ISO/IEC 7816-15 specifies cryptographic information application.
et

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.
oj
pr

© 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

ne
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

ai
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.

oc
It is not applicable to the internal implementation within the card and/or the outside world.

2 Normative references

ar
The following documents are referred to in the text in such a way that some or all of their content
m
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
e
commands for interchange
rm

3 Terms and definitions

no

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/
de

— ISO Online browsing platform: available at https://www.iso.org/obp

3.1
object
et

structure (according to ISO/IEC 7816-4) or security object (3.3)

3.2
oj

secure messaging
set of means for cryptographic protection of (parts of) command-response pairs
pr

[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

ISO/IEC 7816-9:2017(E)


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

ne
CP control parameter

CP DO control parameter data object (bearing the tag ‘62’)

ai
CRT control reference template

oc
DF dedicated file

DO BER-TLV data object

ar
DST control reference template for digital signature

EF elementary file
m
EF.ATR/INFO Answer-to-Reset file or Information file
e
FCP file control parameter
rm

FID file identifier

GAKP generate asymmetric key pair command

no

ICC integrated circuit card

IFD interface device

de

INS instruction byte

Lc field length field for coding the number of bytes in the command data field

Le field length field for coding maximum number of bytes expected in the response data field
et

LCS life cycle status

oj

MF master file
pr

Nc number of bytes in the command data field

Ne maximum number of bytes expected in the response data field

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

 ISO/IEC 7816-9:2017(E)


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

ne
5 Life cycle

ai
5.1 General properties

oc
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

ar
status determines the use of objects when the card supports life cycle status dependent security
attributes according to the following rules. m
— 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.
e
— If an object is in operational state, then any associated security attribute specific to this state
rm

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.
no

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
de

(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.
et

The object is not active but selectable and may be provisioned with data.
— Operational state comprises two secondary states: operational activated and operational deactivated.
oj

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
pr

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

ISO/IEC 7816-9:2017(E)


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

ne
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.

ai
5.2 Generic life cycle status

oc
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

ar
are listed in Table 1. The condition of execution of those commands is according to ISO/IEC 7816-4.
m
e
rm
no
de
et
oj
pr

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

 ISO/IEC 7816-9:2017(E)


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
Proprietary commanda Proprietary commanda
Operational state CREATE FILE CREATE
Object not
(activated)
existing
Operational state CREATE FILE CREATE

ne
(deactivated)
Card termination TERMINATE CARD USAGE TERMINATE CARD USAGE
state

ai
Operational state ACTIVATE (FILE) ACTIVATEb
(activated) MANAGE DATA
Operational state DEACTIVATE (FILE) DEACTIVATEb

oc
(deactivated) MANAGE DATA
Initialization state Proprietary commanda MANAGE DATA
Proprietary commanda

ar
Creation state
Termination state TERMINATE EF TERMINATEb
TERMINATE (DF) m MANAGE DATA
Object not existing DELETE (FILE) DELETEb
DELETE DATA
Card termination TERMINATE CARD USAGE TERMINATE CARD USAGE
e
state
Operational state ACTIVATE (FILE) ACTIVATEb
rm

(activated) MANAGE DATA

Operational state DEACTIVATE (FILE) DEACTIVATEb
(deactivated) MANAGE DATA
no

Initialization Termination state TERMINATE EF TERMINATEb

state TERMINATE (DF) MANAGE DATA
Object not existing DELETE (FILE) DELETEb
DELETE DATA
de

Card termination TERMINATE CARD USAGE TERMINATE CARD USAGE

state
Operational state DEACTIVATE (FILE) MANAGE DATA
(deactivated) DEACTIVATEb
et

Termination state TERMINATE EF TERMINATEb

Operational TERMINATE (DF) MANAGE DATA
state
oj

(activated) Object not existing DELETE (FILE) DELETEb

DELETE DATA
pr

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

ISO/IEC 7816-9:2017(E)


Table 1 (continued)
Transition Object
From To File Other objects
Operational state ACTIVATE (FILE) MANAGE DATA
(activated) ACTIVATEb
Termination state TERMINATE EF TERMINATEb
Operational TERMINATE (DF) MANAGE DATA
state
(deactivated) Object not existing DELETE( FILE) DELETEb
DELETE DATA

ne
Card termination TERMINATE CARD USAGE TERMINATE CARD USAGE
state
Object not existing DELETE (FILE) DELETEb
Termination DELETE DATA

ai
state Card termination TERMINATE CARD USAGE TERMINATE CARD USAGE
state

oc
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.

ar
5.3 Command-dependent life cycle status transition
m
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
e
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
rm

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.
no

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:
de

— 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
et

execution of the command, i.e. the response trailer indicates “normal processing” (see ISO/IEC 7816-
4:2013, Table 5);
oj

— 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;
pr

— 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

 ISO/IEC 7816-9:2017(E)


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.

ne
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

ai
— 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.

oc
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

ar
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

m
Table 2 reads as follows: when a child’s directly assigned LCS valuates to a row’s value from Table 2,
e
it is assigned the effective LCS as read at the intersection with its parent’s effective LCS. At any point
of time, before an evaluation is made, the child LCS subject to evaluation is either directly assigned or
rm

effective, i.e. resulting from a previous evaluation.

Table 2 — Evaluation matrix for effective LCS of Child in a hierarchy

no

Effective LCS of Parent structure

Creation state Initialization Operational Operational Termination
state state state state
de

(activated) (deactivated)
Creation state Creation state Creation state Creation state Operational Termination
state state
deactivated
et

Initialization Creation state Initialization Initialization Operational Termination

state or state state state state
Initialization (deactivated)
oj

state
Directly Operational Creation state Initialization Operational Operational Termination
pr

assigned state or Operational state or state state state

LCS of (activated) state Operational (activated) (deactivated)
Child (activated) state
object (activated)
Operational Creation state Initialization Operational Operational Termination
state or Operational state or state state state
(deactivated) state Operational (deactivated) (deactivated)
(deactivated) state
(deactivated)
Termination Out of scope Out of scope Termination Termination Termination
state state state state

© ISO/IEC 2017 – All rights reserved  7

ISO/IEC 7816-9:2017(E)


The following principles are consistent with evaluation rules from Table 2.
— When derived effective LCS, i.e. resulting from the evaluation according to Table 2 matrix, is different
from directly assigned LCS, the updating of directly assigned LCS is not required.
— When requested, the LCS DO‘8A’ (included in CP DO) that is returned shall be the directly
assigned one.
— As LCS DO‘8A’ (included in CP DO) is optional, if an object does not have a directly assigned LCS, then
the default value Operational state (activated) is used during the calculation of the effective LCS; see
ISO/IEC 7816-4:2013, 7.4.10.

ne
— If a child object is accessed by an IFD, e.g. through select, get data or get attribute command,
with its effective LCS in Operational state (deactivated) or terminated state, the application shall
either return

ai
— checking or execution error status bytes, or

oc
— a warning processing, for example, SW1-SW2=‘6200’ or ‘6283’ or ‘6285’ or ‘6287’, even though
the security attributes of the object aforementioned are assigned an ALWAYS security condition.

5.4.3 Behaviour for effective LCS

ar
Once its effective LCS is evaluated, a child object is allowed the entire set of transitions determined for
m
this resulting LCS as described in Figure 1; if the CP of this child object includes command-dependent
LCS transition indicator DO‘AE’ (see 5.3), some transition(s) may be forbidden for its effective LCS or
controlled by security rules.
e
6 Commands for card management
rm

6.1 General
no

It shall not be mandatory for all cards complying with this document to support all those commands or
all the options of a supported command.
The commands can be performed only if the security status satisfies the security attributes for the
de

command.
For each command, a non-exhaustive list of status bytes is provided (see also ISO/IEC 7816-4).
When using P1 parameters from Table 3:
et

— bit b5 and bit b6 set to 0, the commands for deletion, activation, deactivation and termination work
on files;
oj

— bit b5 set to 1 and bit b6 set to 0, the commands for deletion, activation, deactivation and termination
work on passwords;
pr

— bit b5 set to 0 and bit b6 set to 1, the commands for deletion, activation, deactivation and termination
work on keys;
— bit b5 and bit b6 set to 1, the commands for deletion, activation, deactivation and termination work
on any other structure.
For parameter P2 values, see Table 3.

8  © ISO/IEC 2017 – All rights reserved

 ISO/IEC 7816-9:2017(E)


Table 3 — Coding of P1 in delete, activate, deactivate, terminate commands

b8 b7 b6 b5 b4 b3 b2 b1 Meaning Command data field
0 0 0 0 x x x x File operations (EF or DF) P2=‘00’a
Target file is the most recently selected file (EF or Absent
0 0 0 0 0 0 0 0
DF)
0 0 0 0 0 0 0 1 Target DF under the current DF FID indicating DF
0 0 0 0 0 0 1 0 Target EF under the current DF FID indicating EF
0 0 0 0 0 1 0 0 Target DF by DF name Full DF name
Target file indicated with path from the MF Path without the MF
0 0 0 0 1 0 0 0

ne
file identifier
Target file indicated with path from the current DF Path without the cur-
0 0 0 0 1 0 0 1
rent DF file identifier

ai
0 0 0 1 x x x x Password operations
0 0 0 1 0 0 0 0 Password reference in P2 Absent

oc
Further DO in command data field, P2=‘00’ Further DO with pass-
0 0 0 1 0 0 0 1
word reference
0 0 1 0 x x x x Key operations

ar
0 0 1 0 0 0 0 0 Key reference in P2 Absent
Further DO in command data field, P2=‘00’ Further DO with key
0 0 1 0 0 0 0 1 m reference
0 0 1 1 x x x x Other structure operations
Structure reference in P2, or current structure Absent
0 0 1 1 0 0 0 0
e
(P2=‘00’)
Further DO in command data field, P2=‘00’ Further DO with other
rm

0 0 1 1 0 0 0 1
structure reference
a P2=‘0C’ may be used for legacy reasons.
no

6.2  create file command

The create file command (see Table 4) initiates the creation of a file (DF or EF) placed immediately
under the current DF. The command may allocate memory to the file it creates. The created file shall be
de

set as the current file, unless otherwise specified. MF generation is out of scope of this command.
When a short EF identifier is given that already exists in the current DF, the behaviour of the card is not
defined in this document.
et

The command can be performed only if the security status satisfies the security attributes for the
current DF.
oj

The file descriptor byte is mandatory. It indicates whether a DF or an EF is to be created.

pr

— If a DF is created, then a DF name and/or a file identifier shall be specified.

— If an EF is created, then a file identifier and/or a short EF identifier shall be specified.

© ISO/IEC 2017 – All rights reserved  9

ISO/IEC 7816-9:2017(E)


Table 4 — create file command-response pair

CLA As defined in ISO/IEC 7816-4:2013, 5.4.1
INS ‘E0’
P1-P2 ‘0000’ File identifier and file parameters, i.e. file descriptor byte, encoded in the command data
field
P1 not equal to ‘00’: File descriptor byte as defined in ISO/IEC 7816-4:2013, Table 11
P2 short EF identifier on bits b8 to b4; bits b3 to b1 proprietary
Lc field Absent for encoding Nca = 0, present for encoding Nc > 0
Data field FCP template (DO‘62’) and possible further DO, or absent

ne
Le field Absent for encoding Ne = 0

Data field Absent

ai
SW1-SW2 See ISO/IEC 7816-4:2013, Tables 5 and 6 where relevant, e.g. ‘6982’, ‘6A84’, ‘6A86’, ‘6A89’, ‘6A8A’
a If number Nc is zero, then the file control parameters of the created file are out of scope of this document.

oc
6.3  delete command

ar
The delete command (see Table 5) initiates the deletion of a referenced object. In case the referenced
object is a DF, it is deleted with its complete sub-tree. After successful completion of this command, the
deleted object can no longer be selected, referenced or used. If a file is referenced by this command, the
m
following rule applies in general: if the current file is deleted, its parent becomes the current file. If a file
is deleted which is not the current file, the current file may remain the same. Current DF deletion for DF
without parent is out of scope of this document.
e
The deletion of the object may additionally depend on the object LCS. The deletion of MF is out of scope
rm

of this document.
NOTE 1 delete data command with INS=‘EE’ was reserved by ISO/IEC 7816-4; however, the complete
functionality is fulfilled by generic delete command.
no

NOTE 2 See 6.1 for generic or legacy command options.

Table 5 — delete command-response pair

de

CLA As defined in ISO/IEC 7816-4:2013, 5.4.1

INS ‘E4’
P1-P2 See Table 3, other value is RFU
et

Lc field Absent for encoding Nc = 0, present for encoding Nc > 0

Data field See Table 3
oj

Le field Absent for encoding Ne = 0

pr

Data field Absent

SW1-SW2 See ISO/IEC 7816-4:2013, Tables 5 and 6 where relevant, e.g. ‘9000’, ‘6982’, ‘6985’

6.4  deactivate command

The deactivate command (see Table 6) initiates the transition to the Operational state (deactivated)
of an object referenced by P1, P2 or by further information in command data field, according to Table 3.
When applied to a deactivated file, the select command will select the file and return SW1-SW2 = ‘6283’
as a warning processing status for selected file deactivated.
The command shall only apply to the referenced object (see Table 3).

10  © ISO/IEC 2017 – All rights reserved

 ISO/IEC 7816-9:2017(E)


The successful execution of the command shall not change the VA.
NOTE See 6.1 for generic or legacy command options.

Table 6 — deactivate command-response pair

CLA As defined in ISO/IEC 7816-4:2013, 5.4.1
INS ‘04’
P1-P2 See Table 3, other value is RFU
Lc field Absent for encoding Nc = 0, present for encoding Nc > 0

ne
Data field See Table 3
Le field Absent for encoding Ne = 0

ai
Data field Absent
SW1-SW2 See ISO/IEC 7816-4:2013, Tables 5 and 6 where relevant, e.g. ‘6982’, ‘6A80’

oc
6.5  activate command

ar
The activate command (see Table 7) initiates the transition to the Operational state (activated) of an
object referenced by P1, P2 or by further information in command data field, according to Table 3.
m
The successful execution of the command shall not change the VA.
NOTE See 6.1 for generic or legacy command options.
e
Table 7 — activate command-response pair
rm

CLA As defined in ISO/IEC 7816-4:2013, 5.4.1

INS ‘44’
P1-P2 See Table 3, other value is RFU
no

Lc field Absent for encoding Nc = 0, present for encoding Nc > 0

Data field See Table 3
Le field Absent for encoding Ne = 0
de

Data field Absent

SW1-SW2 See ISO/IEC 7816-4:2013, Tables 5 and 6 where relevant, e.g. ‘6400’, ‘6982’
et

6.6  terminate command

oj

The terminate command (see Table 8) initiates the irreversible transition to the termination state of
an object referenced by P1, P2 or by further information in data field, according to Table 3. In case of a
pr

terminated DF, the DF shall be selectable and if selected, the warning status SW1-SW2 = ‘6285’ (selected
file in termination state) shall be returned. Further possible actions are not defined in ISO/IEC 7816
(all parts).
The successful execution of the command shall not change the VA.
NOTE 1 The intent of DF termination is generally to make the application unusable by the cardholder.

NOTE 2 See 6.1 for generic or legacy command options.

© ISO/IEC 2017 – All rights reserved  11

ISO/IEC 7816-9:2017(E)


Table 8 — terminate command-response pair

CLA As defined in ISO/IEC 7816-4:2013, 5.4.1
INS ‘E6’
P1-P2 See Table 3, other value is RFU
Lc field Absent for encoding Nc = 0, present for encoding Nc > 0
Data field See Table 3
Le field Absent for encoding Ne = 0

Data field Absent

ne
SW1-SW2 See ISO/IEC 7816-4:2013, Tables 5 and 6 where relevant, e.g. ‘6982’, ‘6985’

6.7  terminate ef command

ai
The terminate ef command (see Table 9) initiates the irreversible transition to the termination state

oc
of an EF referenced by P1, P2 or by further information in command data field, according to Table 3.
The successful execution of the command shall not change the VA.

ar
Table 9 — terminate ef command-response pair
CLA
INS
As defined in ISO/IEC 7816-4:2013, 5.4.1
‘E8’
m
P1-P2 See Table 3, other value is RFU
e
Lc field Absent for encoding Nc = 0, present for encoding Nc > 0
rm

Data field See Table 3

Le field Absent for encoding Ne = 0
no

Data field Absent

SW1-SW2 See ISO/IEC 7816-4:2013, Tables 5 and 6 where relevant, e.g. ‘6982’, ‘6985’

6.8  manage data command

de

The manage data command (see Table 10) initiates LCS transition of the indicated DO according to
direction indicated in Figure 1. P2 indicates the target LCS for the transition. Coding of P1 is the same
as that of select data command (see ISO/IEC 7816-4). Command data field is either absent or features
et

the general reference DO‘60’ (see ISO/IEC 7816-4). For manage data command, DO‘60’ includes one DO
only such as tag list DO‘5C’, extended header DO‘4D’ or DO‘5F61’. If several DOs correspond to general
reference DO’s indication, P1=‘01’ to ‘EF’ denotes occurrence number of target DO.
oj

— If several instances of a DO fit the target definition, P1= ‘00’ to ‘EF’ denotes occurrence number of
pr

instance and allows for successive management of all instances.

— When executed with empty command data field, manage data does not select the DO to be managed,
i.e. it does not modify the current VA; when selecting the DO, the effect of this command on the
current VA is according to ISO/IEC 7816-4.

12  © ISO/IEC 2017 – All rights reserved

 ISO/IEC 7816-9:2017(E)


Table 10 — manage data command-response pair

CLA As defined in ISO/IEC 7816-4:2013, 5.4.1
INS ‘CF’
‘00’ to ‘EF’ for occurrence number of instance (numbered in Data Field)
P1 ‘F0’ parent of curConstructedDO if it exists.
>‘F0’ RFU
P2 See Table 11
Lc field Absent for encoding Nc = 0, present for encoding Nc > 0

ne
Data field Absent or general reference DO‘60’ (see ISO/IEC 7816-4:2013, Table 86)
Le field Absent for encoding Ne = 0

ai
Data field Absent
See ISO/IEC 7816-4:2013, Table 5 and Table 6 where relevant, e.g. ‘6202’ to ‘6280’, ‘6281’, ‘6700’,
SW1-SW2

oc
‘6981’, ‘6982’, ‘6985’, ‘6A81’, ‘6A88’ (DOs not found, i.e. referenced data not found)

Table 11 — Coding of P2 in manage data command

ar
Value Meaning
‘03’ Initialize DO
m
‘04’ Deactivate DO
‘05’ Activate DO
e
‘0C’ Terminate DO
rm

6.9  create command

The create command (see Table 12) generates a new object in the logical context defined by the
object related VA references. The command data field may comprise a CP DO‘62’ including a command-
no

dependent LCS transition indicator DO‘AE’ (see 5.3), along with further DO. The created object shall be
set as the current object unless otherwise specified.

Table 12 — create command-response pair

de

CLA As defined in ISO/IEC 7816-4:2013, 5.4.1

INS ‘E1’a
P1-P2 See Table 13
et

L c field Present for coding Nc > 0

CP DO‘62’ when needed, optionally including command-dependent LCS management template
oj

Data field
DO‘AE’ (see 5.3) and/or further DO
L e field Absent
pr

Data field Absent

SW1-SW2 See ISO/IEC 7816-4:2013, Table 5 and Table 6 where relevant, e.g. ‘6981’, ‘6982’, ‘6986’, ‘6A82’, ‘6A83’
a The INS code of this command is not defined in ISO/IEC 7816-4.

© ISO/IEC 2017 – All rights reserved  13

ISO/IEC 7816-9:2017(E)


Table 13 — Coding of P1 for generic create command

b8 b7 b6 b5 b4 b3 b2 b1 Meaning
P2=‘00’, no information given, creation of an object
0 0 0 0 0 0 0 0
of arbitrary type
0 0 0 x Creation of a password
0 0 0 1 0 0 0 0 Password reference in P2
0 0 0 1 P2=‘00’, further DO in command data field
0 0 0 x Creation of a key
0 0 1 0 0 0 0 0 Key reference in P2

ne
0 0 0 1 P2=‘00’, further DO in command data field
0 0 1 1 0 0 0 x Creation of other structures
0 0 0 0 Structure reference in P2

ai
0 0 0 1 P2=‘00’, further reference DO in command data field

oc
Any other value is RFU.

6.10  terminate card usage command

ar
The terminate card usage command (see Table 14) initiates the irreversible transition of the card
into the termination state. Use of this command gives an implicit selection of the MF.
m
For cards supporting this command, the termination state should be indicated in the Answer-to-Reset.
NOTE The intent of terminating card usage is to make the card unusable by the cardholder.
e
Table 14 — terminate card usage command-response pair
rm

CLA As defined in ISO/IEC 7816-4:2013, 5.4.1

INS ‘FE’
no

P1-P2 ‘0000’
Lc field Absent for encoding Nc = 0
Data field Absent
de

Le field Absent for encoding Ne = 0

Data field Absent

SW1-SW2 See ISO/IEC 7816-4:2013, Tables 5 and 6 where relevant, e.g. ‘6982’, ‘6985’
et

6.11  import card secret command

oj

The import card secret command (see Table 15) initiates the import of card secret data related to a
key or password or biometric reference object placed under the current DF.
pr

The relevant security object is referred by P1, P2 or by further information in the data field, according
Table 3. The card secret data are transmitted using a DO or template depending on the type of the card
secret data.
The command can be performed only if the security status satisfies the security attributes for the
security object.

14  © ISO/IEC 2017 – All rights reserved

 ISO/IEC 7816-9:2017(E)


Table 15 — import card secret command-response pair

CLA As defined in ISO/IEC 7816-4:2013, 5.4.1
INS ‘48’a
P1-P2 See Table 3, other value is RFU
Lc field Present for encoding Nc > 0
Data field DO with reference to the security object according Table 3 (conditional), followed by a data
object transmitting the secret data.
‘5F48’ or ‘7F48’: private key
‘5F49’ or ‘7F49’: public key

ne
‘53’ or ‘73’: secret key
‘53’: password reference data

ai
‘5F2E’ or ‘7F2E’: biometric reference data
‘7F61’ or ‘7F60’: biometric information template(s)

oc
Le field Absent for encoding Ne = 0

ar
Data field Absent
SW1-SW2 See ISO/IEC 7816-4:2013, Table 5 and Table 6 where relevant, e.g. ‘6982’, ‘6A80’, ‘6A88’
a The INS code of this command is not defined in ISO/IEC 7816-4.
m
e
rm
no
de
et
oj
pr

© ISO/IEC 2017 – All rights reserved  15

ISO/IEC 7816-9:2017(E)


Annex A
(informative)

Command-dependent LCS transition examples

A.1 General

ne
The combination allowed by DO‘AE’ may achieve a variety of use cases as described in the following
examples.

ai
A.2 Example of key generation or update

oc
The newly created object’s LCS may be respectively changed into Operational state (activated) or
Operational state (deactivated) upon successful execution of either generate asymmetric key pair or
general authenticate command, e.g. an object hosting a key is deactivated every time its content is

ar
renewed through generate asymmetric key pair command, then an administrator has to authorize
the activation of this key object with activate command to allow its use by the cardholder.
m
A.3 Example of provision of content
e
Once an object is created with its LCS set at Creation state, this LCS may transit to initialization state
by provisioning its content, e.g. by nesting further data or by generating DO of further generation upon
rm

successful execution of put data, put next data or update data command.

A.4 Example of a password administration

no

Every time the value of a password/PIN or its attribute of authorized tries is changed (e.g. with change
reference data or reset retry counter), the object hosting this password/PIN, or the password/PIN
itself, is deactivated, i.e. its LCS becomes Operational state (deactivated), e.g. this process may be
de

employed to require from an administrator to confirm the authorization of use to the cardholder, e.g. by
an activate command.

A.5 Example of key initialization

et

Once an object is created and its LCS set at either Creation state, Operational state (activated) or
oj

Operational state (deactivated), this LCS may transit upon successful execution of either generate
asymmetric key pair or general authenticate command, e.g. an object intended to host a key pair
is created as an empty container, and once provisioned with keys through generate asymmetric key
pr

pair, its LCS moves from its Creation state to its Initialization state.

A.6 Example of digital signature control

An ICC featuring digital signature functionality may be set up by an administrator with a password
object and assigned attributes but no content (i.e. no password value set) and LCS state Operational
state (deactivated). A user applies the change reference data command according to the access rules
to set an initial password value. The command triggers the LCS transition of the password object into
Operational state (activated), which saves the user one command.

16  © ISO/IEC 2017 – All rights reserved

 ISO/IEC 7816-9:2017(E)


A.7 Example of object behaviour after LCS evaluation

When its effective LCS is evaluated for a child object (see 5.4.2), the transition(s) from this resulting
LCS may be controlled by the application. In case that such object includes command-dependent LCS
transition indicator DO‘AE’ within its CP DO (see 5.3), some transition(s) may be forbidden.

ne
ai
oc
ar
m
e
rm
no
de
et
oj
pr

© ISO/IEC 2017 – All rights reserved  17

ISO/IEC 7816-9:2017(E)


Annex B
(informative)

Life cycle status handling examples

B.1 General

ne
This annex provides further clarifications on file or data object life cycle status handling.

ai
B.2 LCS interdependencies issue
If the security parameter template DO‘AD’ is expanded with an additional DO‘7B’ encapsulating

oc
a Security Environment template, i.e. set of control reference templates (CRT), and featuring an
LCS (DO‘8A’), this LCS, if any, shall match LCS DO occurring immediately under interface and LCS
dependent security attribute template DO(DO‘A3’); otherwise, the Security Environment is not

ar
applicable (see Table B.1).
m
Table B.1 — Interdependencies between Physical interface, LCS, security attributes and SE
DO generation Value
1st 2nd 3rd 4th
e
‘62’ CP DO
rm

‘8A’ LCS (Life Cycle Status), optional

‘A3’ Interface and LCS dependent security attribute template
‘91’ Physical interface (contact/contactless, etc.)
no

‘8A’ LCS
‘9C’ AMF || SCB (ref#n) Alternatively Tag ‘9D’ under
tag ‘AB’ when using expanded
format
de

‘5C’ Tag list

‘AD’ Security parameters template #n
‘80’ AD sequence number (AD #n)
et

‘AX’ Security attributes extension (X from 0 to 4)

‘7B’ Security Environment template
oj

‘80’ SEID
‘8A’ LCS, optional
pr

‘AC’ Cryptographic mechanism identifier template, optional

‘A4’, ‘A6’, CRTs
‘AA’, ‘B4’,
‘B6’, ‘B8’
‘B3’ OID related information, optional
‘63’ Wrapper pointing, e.g. to the security object involved in AX,
optional

18  © ISO/IEC 2017 – All rights reserved

 ISO/IEC 7816-9:2017(E)


B.3 Retrieval of LCS value

The directly assigned life cycle status of a file or a DO may be retrieved by either (non-exhaustive list)
of the following.
— compare command (see ISO/IEC 7816-4:2013, 11.6.1) may be applied to check whether a data object
LCS belongs to a set of input LCS values, i.e. it may be necessary to ask the card whether the LCS of
a given DO is either Operational state (activated) or Operational state (deactivated); accordingly,
the response to such a question (compare command) may be either YES (SW1-SW2=‘90 00’) or NO
(SW1-SW2=‘63 40’).
For this purpose, two values of parameter P2 are possible:

ne
— ‘07’ which means that the reference value shall belong to the set of finite values defined by the
command;

ai
— ‘08’ which means that the reference value shall not belong to the set of finite values defined by
the command.

oc
The target of such compare command shall be the value of the primitive DO‘8A’ standing for
reference data.

ar
— get attribute command (see ISO/IEC 7816-4:2013, 11.6.2).
— select, select data, or get data command with a parameter specifying to return CP DOs, then
m
DO‘8A’ immediately under DO‘62’ in the response data field is extracted by IFD.
When required by bit b5 set to 1 in parameter P2 of select data command, this command returns a tag
e
list DO‘5C’ nesting the same concatenation of tags as in the DIR function but, according to its needs, an
application may exclude the tags that do not fulfil some conditions; unless specified otherwise by the
rm

application, the default condition that applies on DO, security objects and files for the VIEW function is
LCS valuating to Operational state (activated).
no

B.4 Life cycle status handling for DO with same tag in same generation
For DO(s) with same tag in the same template (thus in the same generation), the handling of one among
those DOs for the purpose of reading or setting or updating its LCS may use DO ordering within this
de

template; a proper selection of the targeted DO is required, e.g. select data, get next data with odd
INS code or put data, put next data, or update data using a pointer set by the command and not by
the template allowing pointing the DO before to set its LCS.
et

B.5 Life cycle status of tagged wrapper extension

oj

Primary DO LCS influences the view on extensions possibly targeted by the primary DO, i.e. wrapper
extension. The LCS of a tagged wrapper does not impact any property of the referenced object if any,
but may impact the view on the targeted object. Besides, when the outside world sets the LCS of a DO
pr

belonging to the parent template, it does not impact the LCS of the template extension, e.g. even in
case the LCS of the parent template becomes terminated, the DO belonging to the extension template
remains in its former state with its life cycle unchanged.

B.6 Life cycle status handling for DO hosted in files

When not featuring their CP DO, data objects nested in files may have their related security attributes
encoded within the file header under security attribute template DO‘A0’ as described on Table B.2; such
implementation complies with ISO/IEC 7816-4 rules.

© ISO/IEC 2017 – All rights reserved  19

ISO/IEC 7816-9:2017(E)


Table B.2 — Example of CP DO contents for DOs nested in File

DO generation Value
1st 2nd 3rd 4th
‘62’ CP DO
‘8A’ LCS (Life Cycle status)
‘A3’ Interface and LCS dependent security attribute template
‘91’ Physical interface
‘8A’ LCS
‘A0’ Security attributes template for DOs

ne
‘8C’ AMF associated to DO handling Alternatively Tag ‘9C’ or ‘9D’ with SPT
commands oriented security attributes
‘5C’ Tag list

ai
‘A3’ Interface and LCS dependent security attribute template
Physical interface

oc
‘91’
‘8A’ LCS
‘8C’ AMF associated to Application DF/ Alternatively Tag ‘9C’ or ‘9D’ with SPT

ar
DF/EF handling commands oriented security attributes

m
e
rm
no
de
et
oj
pr

20  © ISO/IEC 2017 – All rights reserved

 ISO/IEC 7816-9:2017(E)


Bibliography

[1] ISO/IEC 7816 (all parts), Identification cards — Integrated circuit cards
[2] ISO/IEC 10536 (all parts), Identification cards — Contactless integrated circuit(s) cards — Close-
coupled cards
[3] ISO/IEC 14443 (all parts), Identification cards — Contactless integrated circuit cards —
Proximity cards

ne
[4] ISO/IEC 15693 (all parts), Identification cards — Contactless integrated circuit cards —
Vicinity cards

ai
oc
ar
m
e
rm
no
de
et
oj
pr

© ISO/IEC 2017 – All rights reserved  21