ISO/IEC 7816-9:2000

Identification cards - Integrated circuit(s) cards with contacts - Part 9: Additional interindustry commands and security attributes

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

General Information

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

Relations

• Consolidated By: ISO 6433:2012 - Technical product documentation - Part references
• Effective Date: 06-Jun-2022
• Revised: SIST ISO/IEC 7816-5:2005 - Identification cards -- Integrated circuit cards -- Part 5: Registration of application providers
• Effective Date: 12-May-2008
• Revised: SIST ISO/IEC 7816-4:2005 - Identification cards -- Integrated circuit cards -- Part 4: Organization, security and commands for interchange
• Effective Date: 12-May-2008
• Revised: ISO/IEC 7816-5:2004 - Identification cards - Integrated circuit cards - Part 5: Registration of application providers
• Effective Date: 15-Apr-2008
• Revised: ISO/IEC 7816-8:2004 - Identification cards - Integrated circuit cards - Part 8: Commands for security operations
• Effective Date: 15-Apr-2008
• Revised: ISO/IEC 7816-9:2004 - Identification cards - Integrated circuit cards - Part 9: Commands for card management
• Effective Date: 15-Apr-2008
• Revised: ISO/IEC 7816-4:2005 - Identification cards - Integrated circuit cards - Part 4: Organization, security and commands for interchange
• Effective Date: 15-Apr-2008

Standards Content (Sample)

INTERNATIONAL ISO/IEC
STANDARD 7816-9
First edition
2000-09-01
Identification cards — Integrated circuit(s)
cards with contacts —
Part 9:
Additional interindustry commands and
security attributes
Cartes d'identification — Cartes à circuit(s) intégré(s) à contacts —
Partie 9: Commandes intersectorielles additionnelles et attributs de
sécurité
Reference number
©
ISO/IEC 2000
PDF disclaimer
This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but shall not
be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In downloading this
file, parties accept therein the responsibility of not infringing Adobe's licensing policy. The ISO Central Secretariat accepts no liability in this
area.
Adobe is a trademark of Adobe Systems Incorporated.
Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation parameters
were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In the unlikely event
that a problem relating to it is found, please inform the Central Secretariat at the address given below.
© ISO/IEC 2000
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 either ISO at the address below or ISO's member body
in the country of the requester.
ISO copyright office
Case postale 56 � CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail [e-mail]
Web www.iso.ch
Printed in Switzerland
ii © ISO/IEC 2000 – All rights reserved

Contents                                                       Page
Foreword.v
1 Scope.1
2 Normative references .1
3 Terms and definitions.1
4 Symbols (and abbreviated terms) .2
5 File control parameters .3
6 Life cycle status .4
6.1 Definition and purpose.4
6.2 Principles of use .4
6.3 Life cycle rules .4
6.4 LCS Integer encoding.5
7 Security attributes - general principles .5
7.1 Definition and purpose.5
7.2 Principles of use .5
7.3 Security environments used for access control.6
7.4 Access authorisation coded in certificates.7
8 Security attributes - mechanisms and coding .7
8.1 Coding.7
8.2 Referencing .7
8.2.1 Referencing in the FCI.7
8.2.2 Referencing in SCQL .7
8.2.3 Referencing for data objects .7
8.3 Security attributes for different interface modes .7
8.4 Compact format.8
8.4.1 Introduction .8
8.4.2 Conditions of use.8
8.4.3 Access mode byte.8
8.4.4 Security condition byte .10
8.5 Expanded format.11
8.5.1 Introduction .11
8.5.2 Access Mode data object (AM_DO).11
8.5.3 Security condition data objects (SC_DO).12
8.5.4 Access rule references.12
9 Commands.13
9.1 Definition and scope.13
9.2 CREATE FILE command.13
9.2.1 Definition and Scope .13
9.2.2 Conditional usage and security.14
9.2.3 Command message .14
9.2.4 Response message.14
9.2.5 Status conditions.15
9.3 DELETE FILE command .15
9.3.1 Definition and Scope .15
9.3.2 Conditional usage and security.15
9.3.3 Command message .15
9.3.4 Response message.16
9.3.5 Status conditions.16
9.4 DEACTIVATE FILE command .16
9.4.1 Definition and Scope .16
© ISO/IEC 2000 – All rights reserved iii

9.4.2 Conditional usage and security. 16
9.4.3 Command message . 16
9.4.4 Response message. 17
9.4.5 Status conditions . 17
9.5 ACTIVATE FILE command . 17
9.5.1 Definition and Scope . 17
9.5.2 Conditional usage and security. 17
9.5.3 Command message . 18
9.5.4 Response message. 18
9.5.5 Status conditions . 18
9.6 TERMINATE DF command . 18
9.6.1 Definition and Scope . 18
9.6.2 Conditional usage and security. 19
9.6.3 Command message . 19
9.6.4 Response message. 19
9.6.5 Status conditions . 19
9.7 TERMINATE EF command. 19
9.7.1 Definition and Scope . 19
9.7.2 Conditional usage and security. 19
9.7.3 Command message . 20
9.7.4 Response message. 20
9.7.5 Status conditions . 20
9.8 TERMINATE CARD USAGE command. 20
9.8.1 Definition and Scope . 20
9.8.2 Conditional usage and security. 20
9.8.3 Command message . 21
9.8.4 Response message. 21
9.8.5 Status conditions . 21
9.9 SEARCH BINARY command . 21
9.9.1 Definition and Scope . 21
9.9.2 Conditional usage and security. 21
9.9.3 Command message . 22
9.9.4 Response message. 22
9.9.5 Status conditions . 22
9.10 SEARCH RECORD command . 22
9.10.1 Definition and Scope . 22
9.10.2 Conditional usage and security. 23
9.10.3 Command message . 23
9.10.4 Response message. 25
9.10.5 Status conditions . 25
10 Card originated messages . 25
10.1 Definition. 25
10.2 Triggering by the card . 25
10.3 Message retrieval and reply. 26
10.4 Message and reply formats. 26
10.5 Conditions of use. 26
Annex A (normative) File life cycle states . 27
A.1 Commands. 27
Annex B (informative) Usage example of security attributes for download. 28
B.1 Introduction . 28
B.2 Assumptions. 28
B.3 Secure downloading . 28
B.4 Compact format coding for security attributes of EF 1. 29
B.5 Expanded format coding for security attributes of EF 1. 30
B.6 Coding of the corresponding Secure Environments (SEs) . 31
iv © ISO/IEC 2000 – All rights reserved

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.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 3.
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.
Attention is drawn to the possibility that some of the elements of this part of ISO/IEC 7816 may be the subject of
patent rights. ISO and IEC shall not be held responsible for identifying any or all such patent rights.
International Standard ISO/IEC 7816-9 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
Annex A forms a normative part of this part of ISO/IEC 7816. Annex B is for information only.
© ISO/IEC 2000 – All rights reserved v

INTERNATIONAL STANDARD ISO/IEC 7816-9:2000(E)
Identification cards — Integrated circuit(s) cards with contacts —
Part 9:
Additional interindustry commands and security attributes
1 Scope
This part of ISO/IEC 7816 specifies
 a description and coding of the life cycle of cards and related objects;
 a description and coding of security attributes of card related objects;
 functions and syntax of additional interindustry commands;
 data elements associated with these commands;
 a mechanism for initiating card-originated messages.
This part of ISO/IEC 7816 does not cover the internal implementation within the card and / or the outside world.
2 Normative references
The following normative documents contain provisions which, through reference in this text, constitute provisions of
this part of ISO/IEC 7816. For dated references, subsequent amendments to, or revisions of, any of these
publications do not apply. However, parties to agreements based on this part of ISO/IEC 7816 are encouraged to
investigate the possibility of applying the most recent editions of the normative documents indicated below. For
undated references, the latest edition of the normative document referred to applies. Members of ISO and IEC
maintain registers of currently valid International Standards.
ISO/IEC 7816-4:1995, Information technology — Identification cards — Integrated circuit(s) cards with contacts —
Part 4: Interindustry commands for interchange.
ISO/IEC 7816-7:1999, Information technology — Identification cards — Integrated circuit(s) cards with contacts —
Part 7: Interindustry commands for Structured Card Query Language (SCQL).
ISO/IEC 7816-8:1999, Information technology — Identification cards — Integrated circuit(s) cards with contacts —
Part 8: Security related interindustry commands.
ISO/IEC TR 9577:1996, Information technology — Protocol identification in the network layer.
3 Terms and definitions
For the purposes of this part of ISO/IEC 7816, the following terms and definitions apply.
3.1
AND Template
template containing security conditions of which all have to be fulfilled
© ISO/IEC 2000 – All rights reserved 1

3.2
access rule
a data element containing an access mode (a reference to an action) and security conditions (to be fulfilled before
an action is allowed)
3.3
application
the data structure, data elements and program modules needed for a specific functionality to be satisfied
3.4
OR Template
template containing security conditions of which at least one has to be fulfilled
3.5
security attributes
conditions of use of various resources in the card including stored data and data processing functions, expressed
as a data element containing one or several access rules
4 Symbols (and abbreviated terms)
For the purposes of this part of ISO/IEC 7816, the following abbreviations apply:

AM access mode
AM_DO access mode data object
APDU application protocol data unit
ARR access rule references
AT auth entication template
BER basic encoding rules (of ASN.1)
CRT control reference template
DE data element
DF dedicated file
DO data object
EF elem entary file
FCP f ile control parameters
File ID f ile identifier
IFD inter face device
LCS life cycle status
LCSI life cycle status integer
MF m aster file
RF radio frequency
RFU reserved for future use
SC security condition
SC_DO security condition data object
SE s ecurity environment
SE # s ecurity environment number
SM secure messaging
SW1-SW2 s tatus words
TLV tag, len gth, value
2 © ISO/IEC 2000 – All rights reserved

5 File control parameters
Table 1 gives the file control parameters (FCP, tag ‘62’) as used in this part of ISO/IEC 7816.
Table 1 - File control parameters
7816 Tag L Value Applies to
Part-
4 ‘80’ 2 Number of data bytes in the file, excluding structural information Transparent EFs
4 ‘81' 2 Number of data bytes in the file, including structural information if any. Any file
4 ‘82' 1 File descriptor byte Any file
2 File descriptor byte followed by data coding byte Any file
3 File descriptor byte followed by data coding byte and maximum record length, EFs with record structure
coded on 1 byte
4 File descriptor byte followed by data coding byte and maximum record length, EFs with record structure
coded on 2 bytes
9 5 or 6 File descriptor byte followed by data coding byte and maximum record length, EFs with record structure
coded on 2 bytes, and number of records coded on 1 or 2 bytes
4 ‘83' 2 File identifier Any file
4 ‘84' 1 to 16 DF name DFs
4 ‘85' var Proprietary information Any file
4 ‘86' var Security attributes, proprietary format Any file
4 ‘87' 2 Identifier of an EF containing an extension of the FCI Any file
9 ‘88' 0 or 1 Short EF identifier, coded from bits b8 to b4. Bits b3, b2, b1 = 000 EFs
9 ‘8A' 1 Life Cycle Status Integer (LCSI) Any file
9 ‘8B’ var Security attributes, reference to expanded format Any file
9 ‘8C’ var Security attributes, compact format Any file
9 ‘8D’ 2 File identifier of file containing SE templates DFs
9 ‘A0’ var Security attribute template for DOs Any file
9 ‘A1’ var Security attribute template for interface mode (see 8.3) Any file
9 ‘A2’ var Short EF identifier / path mapping template, i.e. short EF identifier (tag ‘88’) || path DFs
(tag ‘51’) see ISO/IEC 7816-6 || … See note 2
9 ‘A5’ var Proprietary information, constructed Any file
9 'AB' var Security attributes, expanded format Any file
NOTE 1  The meaning of tag ‘82' has been extended in this part of ISO/IEC 7816. Further DOs have been defined.
NOTE 2  The path to the EF, which can be selected with the short EF identifier, may be an absolute or a relative path.

If selection by short EF identifier is supported but tag ‘88’ is not present, then the 5 least significant bits of the file
identifier (tag ‘83’) shall code the short file identifier. If the card supports the short EF identifier mechanism, an
empty DO with tag '88' in the FCP indicates that the corresponding EF has no short EF identifier.
© ISO/IEC 2000 – All rights reserved 3

6 Life cycle status
6.1 Definition and purpose
The card, files and other objects in the card each have a life cycle, in principle as shown in Annex A.
States in the life cycle may be manipulated by commands. This part of ISO/IEC 7816 defines such commands.
Annex A gives a list of these commands.
A life cycle status (LCS) may be associated with files as one of the attributes. It may also be associated with other
resources in the card.
To support flexible management of the life cycle as an attribute, a number of life cycle states have been identified,
which are defined in this clause. This clause also defines an encoding of the states in the life cycle.
This clause defines a coding of the LCS that allows the card to identify the states. In addition it allows the
application to define additional life cycle states. Changes are controlled by the card and may be performed in a
pre-defined order, reflecting reversible or irreversible changes in state.
6.2 Principles of use
A card may support a LCS attribute associated with files and, possibly, other objects in the card to indicate the
different logical security states of the use of these objects.
Commands may set the value of the LCS attribute when they execure. However the card shall maintain the
integrity of this value in accordance with this part of ISO/IEC 7816.
If supported, the current LCS of an object, as expressed by its value, shall be used by the card, possibly in
combination with additional security attributes, to determine whether a requested operation with the object is in
accordance with the specified security policy.
This standard defines 4 primary states of the life cycle (see 6.3 and Annex A) in the following order:
 creation state;
 initialisation state;
 operational state;
 termination state.
Transitions between the primary states of the life cycle are irreversible and occur in only a top-to-bottom direction.
Each primary state may have reversible secondary states.
6.3 Life cycle rules
The use of objects is governed by the current LCS according to the following rules:
 when an object is in the creation state, any security attributes for that object shall not apply;
 when an object is in the initialisation state, then security attributes specific to this state may apply;
 when an object is in the operational state, then the associated security attributes shall apply;
 when an object is in the termination state, then it shall not allow a modification of its value but it may be used
as specified by its associated security attributes e.g. it may be deleted.
4 © ISO/IEC 2000 – All rights reserved

See Annex A for an example of the transitions between file life cycle states and associated commands.
The card life cycle status (as defined in ISO/IEC 7816-4) may be present in the historical bytes, in which case the
coding shown in Table 2 shall be used.
When the card has a Master file (MF, see ISO/IEC 7816-4), then it is in, at least, the creation state.
6.4 LCS Integer encoding
The LCS Integer (LCSI - tag ‘8A') encodes the current LCS over one byte. The coding is shown in Table 2.
Table 2 - Coding of the LCSI - tag ‘8A'
b8.b5 b4 b3 b2 b1 Meaning
‘0’ 0 0 0 0 no information given
‘0’ 0 0 0 1 creation state
‘0’ 0 0 1 1 initialisation state
‘0’ 0 1 - 1 operational state – activated
‘0’ 0 1 - 0 operational state – deactivated
‘0’ 1 1 - - termination state
≠ ‘0’ x x x x proprietary
7 Security attributes - general principles
7.1 Definition and purpose
The security attributes define the allowed actions, and procedures to be performed to complete such actions (see
ISO/IEC 7816-4). In particular, security attributes may:
 specify the security status of the card to be in force before access to data is allowed;
 restrict access to data to certain functions if the card has a particular status;
 define which security functions shall be performed to obtain a specific security status.
Card resources that may be protected with security attributes include:
 files;
 commands;
 tables and views;
 data objects.
7.2 Principles of use
This part of the standard describes the possible content of security attributes as data elements and objects, and the
means to retrieve them from the card.
Security attribute definitions may be expressed in a collection of data elements.
A specific resource may be associated with more than one security attribute definition.
© ISO/IEC 2000 – All rights reserved 5

A card resource such as an EF or DF may contain in its descriptive data a reference to the security attribute
definitions pertaining to it.
Other card resources (e.g. commands and data objects) may be associated with a security attribute definition by a
reference contained in the security attribute definition data.
The definition of security attributes shall be specified by use of the following descriptive data elements:
 the set of access rules bound explicitly or implicitly to a resource;
 an access rule combining access modes with security conditions;
 an access mode logically containing a specification of the type of access operation, e.g. read or update.
Optionally it specifies the internal function or external command that invokes the appropriate access rule
definition;
 a security condition specifying which security mechanisms are necessary to conform to the access rule
definition.
See clause 8 for the encoding of these data elements.
7.3 Security environments used for access control
Security environments (SEs, see ISO/IEC 7816-8) used for access control may be stored in the card within a SE
Template DO (tag ‘7B’) or in a file (or both).
The SE template DO contains, for every included SE, a SE# DO (tag ‘80’), an optional LCSI DO (tag ‘8A’) and the
corresponding CRTs. The value of the LCSI indicates for which life cycle state the SE is valid. If the SE is used for
access control e.g. to a file, then the LCSI of the file and of the SE have to match. If the LCSI is not present, the
SE is valid for the operational activated state.
If several DOs with the same tag are present inside a CRT (e.g. DOs specifying a key reference) then only one of
the DOs has to be fulfilled (OR condition).
The default SE is always available and is coded under a reserved SE# (#1).
For specifying the usage of a CRT in compliance with the MANAGE SECURITY ENVIRONMENT command, a CRT
usage qualifier (tag ‘95’) may be contained in the CRT, see table 3.
Table 3 - Coding of the value of the CRT usage qualifier DO
b8 b7 b6 b5 b4 b3 b2 b1 Meaning
1    - verification (DST, CCT)
- encipherment (CT)
- external authentication (AT)
1   - computation (DST, CCT)
- decipherment (CT)
- internal authentication (AT)
1   - S M response (CCT, CT, DST)
1   - S M command (CCT, CT, DST)
1  - Us er authentication, knowledge based (AT)
1  - Us er authentication, biometric based (AT)
x x - RFU (default = 00)
6 © ISO/IEC 2000 – All rights reserved

7.4 Access authorisation coded in certificates
In public key based authentication procedures, card verifiable certificates may be applied. In such a certificate, a
certificate holder authorisation (e.g. a role identifier) may be contained coded in a DE or DO with tag ‘5F4B’. If this
certificate holder authorisation is used in the security conditions to be fulfilled for access to data or functions, then
the DO, tag ‘5F4B’, shall be present in the related authentication template (AT) describing the public key oriented
authentication procedure.
8 Security attributes - mechanisms and coding
8.1 Coding
The coding structure presented here aims to provide a tiered approach to binding objects and their respective
security attributes. Two codings are defined:
 a compact coding based on bitmaps (see 8.4);
 an expanded coding which is an extension of the compact coding with intermediate scope containing bitmaps
and TLV list management (see 8.5).
8.2 Referencing
8.2.1 Referencing in the FCI
The File Control Information (FCI, see ISO/IEC 7816-4) may contain security attributes.
Relevant data objects are listed in table 1.
8.2.2 Referencing in SCQL
In an SCQL environment (see ISO/IEC 7816-7), security attributes can be specified in SCQL operations e.g.
CREATE TABLE and CREATE VIEW.
If security attributes based on this part of ISO/IEC 7816 are used, then they shall be conveyed in a DO with tag
‘8C', ‘8B’ or ‘AB' in the security attribute parameters of an SCQL operation.
8.2.3 Referencing for data objects
Security attributes for data objects may be stored in the FCI of the corresponding DF (see table 1). The security
attribute template for DOs, tag ‘A0’, is the concatenation of a security attribute DO and a taglist DO (giving the
relevant DOs).
8.3 Security attributes for different interface modes
If the security attribute template for interface mode (tag ‘A1’) is present, it is used for indicating access conditions
for radio frequency (RF) interface and / or contact interface.
The template contains one or more pairs consisting of an interface mode DO (see tables 4 and 5) followed by any
of the DOs ‘86’, ‘8B’, ‘8C’, ‘A0’ or ‘AB’, containing the corresponding security attributes.
Table 4 — Interface mode DO
Tag L Value
‘91’ 1 Interface mode DE
© ISO/IEC 2000 – All rights reserved 7

Table 5 — Interface mode DE
b8.b3 b2.b1 Meaning
000000 RFU (0 is default value)
Access is restricted to interface mode:
00 - RFU
01 - contacts (default in ICC with contact interface)
10 - RF (default in ICC with RF interface)
11 - contacts and RF (default in ICC with dual interface)
8.4 Compact format
8.4.1 Introduction
Access control to an object in this coding is managed by binding the access rules to the related object.
An access rule is encoded with:
 an Access Mode (AM) byte, as defined in table 6 to table 9;
 one or more Security Condition (SC) bytes, as defined in table 10.
8.4.2 Conditions of use
The AM byte is followed by a number of SC bytes equal to the number of bits set to 1 in the AM byte (excluding
b8). Each SC byte codes the conditions relevant to a (set of) command(s), in the same order (b7 to b1) as in the
AM byte.
When several access rules are present in the value field of the DO, tag ‘8C' (see table 1), they represent an OR
condition.
8.4.3 Access mode byte
Table 6 to table 9 define an AM byte for:
 DFs;
 EFs;
 Tables and views;
 DOs.
If, in an AM byte, a ‘1’ is set within the range b7.b1, then an SC byte applies. If a ‘0’ is set within the same range,
then no SC byte applies.
8 © ISO/IEC 2000 – All rights reserved

Table 6 - AM byte for DFs
b8 b7 b6 b5 b4 b3 b2 b1 Meaning
0 - - - - - - - b7.b1 according to this table
1 - - - - - - - b3.b1 according to this table;
b7.b4 proprietary
- 1 - - - - - - DELETE FILE (self)
- - 1 - - - - - TERMINATE CARD USAGE (MF), TERMINATE DF
- - - 1 - - - - ACTIVATE FILE
- - - - 1 - - - DEACTIVATE FILE
- - - - - 1 - - CREATE FILE – DF creation
- - - - - - 1 - CREATE FILE – EF creation
- - - - - - - 1 DELETE FILE (child)

Table 7 - AM byte for EFs
b8 b7 b6 b5 b4 b3 b2 b1 Meaning
0 - - - - - - - b7.b1 according to this table
1 - - - - - - - b3.b1 according to this table;
b7.b4 proprietary
- 1 - - - - - - DELETE FILE
- - 1 - - - - - TERMINATE EF
- - - 1 - - - - ACTIVATE FILE
- - - - 1 - - - DEACTIVATE FILE
- - - - - 1 - - WRITE BINARY, WRITE RECORD, APPEND RECORD
- - - - - - 1 - UPDATE BINARY, UPDATE RECORD, ERASE BINARY
- - - - - - - 1 READ BINARY, READ RECORD, SEARCH BINARY, SEARCH RECORD

Table 8 - AM byte for Tables & Views
b8 b7 b6 b5 b4 b3 b2 b1 Meaning
0 - - - - - - - b7.b1 according to this table
1 - - - - - - - b3.b1 according to this table;
b7.b4 proprietary
- 1 - - - - - - CREATE USER, DELETE USER
- - 1 - - - - - GRANT, REVOKE
- - - 1 - - - - CREATE TABLE, CREATE VIEW, CREATE DICTIONARY
- - - - 1 - - - DROP TABLE, DROP VIEW
- - - - - 1 - - INSERT
- - - - - - 1 - UPDATE, DELETE
- - - - - - - 1 FETCH
© ISO/IEC 2000 – All rights reserved 9

Table 9 - AM byte for DOs
b8 b7 b6 b5 b4 b3 b2 b1 Meaning
0 - - - - - - - b7.b1 according to this table
1 - - - - - - - b3.b1 according to this table;
b7.b4 proprietary
- x - - - - - - 0 (1 = RFU)
- - x - - - - - 0 (1 = RFU)
- - - x - - - - 0 (1 = RFU)
- - - - x - - - 0 (1 = RFU)
- - - - - 1 - - MANAGE SECURITY ENVIRONMENT
- - - - - - 1 - PUT DATA
- - - - - - - 1 GET DATA
Additional commands e.g. application specific commands may be added to the grouping of the commands
presented in tables 6 to 9.
8.4.4 Security condition byte
The SC byte specifies which security mechanisms are necessary to conform to the access rules.
The 4 most significant bits indicate the required security conditions.
A SE may be specified in bits b4.b1. If a SE is specified, the mechanisms that may be defined in it for external
authentication, user authentication and command protection shall be used, if indicated by bits b8.b5.
The coding of the SC byte is given in table 10.
Table 10 - Security condition byte
b8 b7 b6 b5 b4.b1 Meaning
0 0 0 0 0000 No condition
1 1 1 1 1111 Never
- - - - 0000 No reference to SE
- - - - 0001.1110 SE#
- - - - 1111 RFU
0 - - - - At least one condition
1 - - - - All conditions
- 1 - - - Secure messaging
- - 1 - - External authentication
- - - 1 - User authentication (e.g. password presentation)
If bit b8 = 1, all conditions set in bits b7.b5 shall be satisfied.
If bit b8 = 0, at least one of the conditions set in bits b7.b5 shall be satisfied.
10 © ISO/IEC 2000 – All rights reserved

If b7 =1, the CRT of the SE indicated in bits b4.b1 describes whether SM shall apply to the command APDU, the
response APDU or both (see table 3).
8.5 Expanded format
8.5.1 Introduction
Access control to an object in this format is managed by referencing the access rules from the related object.
An access rule consists of:
 an AM_DO, as defined in table 11, followed by a sequence of
 SC_DOs, as defined in table 13.
Access rules with this encoding may be present in the value field of the DO with tag ‘AB' (see table 1).
8.5.2 Access Mode data object (AM_DO)
An AM_DO contains either:
 an AM byte (see table 6 to table ) or
 a list of command descriptions or
 a proprietary state machine description.
Subsequent SC_DOs are relevant for all commands indicated in the AM_DO. Table 11 shows the coding of
AM_DOs.
Table 11 - AM_DOs
Ta g L Value Meaning
'80' 1 AM byte See table 6 to table 9
'81'.'8F' x Command description (e.g. INS-P2 || INS-P2) List of CLA-INS-P1-P2, the existence of which in the list is

determined by the bits b4.b1 of the tag byte according to table 12
'9C' x Proprietary state machine description

If the tag ranges from ‘81' to ‘8F' then the value field of the AM_DO represents a list of possible combinations of
CLA-INS-P1-P2 to be compared to the command header. Depending on b4.b1 of the tag the list contains only the
indicated reference values as described in table 12. The existing byte groups may appear repeatedly in order to
define a set of commands being protected.
Table 12 - Coding of b4.b1 of the AM_DO tag byte
b4 b3 b2 b1 Meaning
1 x x x CLA exists in definition list
x 1 x x INS exists in definition list
x x 1 x P1 exists in definition list
x x x 1 P2 exists in definition list
© ISO/IEC 2000 – All rights reserved 11

In the CLA byte, if used in the command description, the logical channel number shall be set to 0 with the meaning
that the description is independent from the particular logical channel being applied.
8.5.3 Security condition data objects (SC_DO)
The SC_DO defines the required security actions in order to access an object being protected through the
particular AM_DO:
 to be performed before accessing an object (e.g. authentication);
 to protect commands or responses by secure messaging.
Table 13 shows the coding of SC_DOs.
Table 13 - SC_DOs
Tag L Value Description of access condition
T
SC_DO
'90' ‘00’ - Always
'97' ‘00' - Never
‘A4’ x CRT value Authentication (external
authentication or user
authentication) depending on the
CRT usage
'B4' x CRT value CRTs for command and/or
response with SM depending on
‘B6’
CRT usage
‘B8’
'9E' x SC byte according to table 10 Security Condition byte
'A0' x SC_DOs OR template
‘AF’ x SC_DOs AND template
Several SC_DOs may be attached to a particular operation:
 if the SC_DOs are encapsulated in an OR template, then only one of the security conditions has to be fulfilled
for the operation to be allowed;
 if the SC_DOs are not to be encapsulated in an OR template or if the SC_DOs are encapsulated in an AND
template, then all security conditions shall be fulfilled before the operation is allowed.
8.5.4 Access rule references
Access rules in expanded format (AM_DOs and SC_DOs) may be stored in a linear variable EF, each record
containing one or more rules (see table 14). The access rule file may be an internal file, referenced implicitly, or
may be referenced explicitly, e.g. by a File ID
...