ISO/IEC 18328-3:2016
(Main)Identification cards — ICC-managed devices — Part 3: Organization, security and commands for interchange
Identification cards — ICC-managed devices — Part 3: Organization, security and commands for interchange
ISO/IEC 18328-3:2016 specifies the logical interface of an application supporting the necessary security features in a card-IC which communicates with the external world by a physical interface supporting APDUs. This application supports the usage of electronic devices. This involves the design of commands, data structures and security mechanisms which are required to handle the data and handling the additional devices itself. The handling of the additional devices is always controlled by the card-IC. External inputs or outputs shall be managed by the existing interfaces. This document deals not with physical characteristics of the card and interface technology, but only with the logical aspects. Management of data for additional devices that is not subdued by the COS or application control is out of the scope of this document. Definitions of coding requirement for "trust assessment" of the managed data like warning, font, colour etc. is in the scope of this document. A description of the logical internal interface functionality used by the COS or by device drivers, if any, is also part of this document. Due to the fact that relevant technologies may evolve or be adopted very fast, this document defines commands and structures supporting extensions and adaptations.
Cartes d'identification — Dispositifs contrôlés par carte — Partie 3: Organisation, sécurité et commandes pour les échanges
General Information
Standards Content (Sample)
INTERNATIONAL ISO/IEC
STANDARD 18328-3
First edition
2016-10-15
Identification cards — ICC-managed
devices —
Part 3:
Organization, security and commands
for interchange
Cartes d’identification — Dispositifs contrôlés par carte —
Partie 3: Organisation, sécurité et commandes pour les échanges
Reference number
©
ISO/IEC 2016
© ISO/IEC 2016, 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 2016 – All rights reserved
Contents Page
Foreword .v
Introduction .vi
1 Scope .1
2 Normative references .1
3 Terms and definitions .1
4 Symbols and abbreviated terms .4
5 Architectural aspects .5
5.1 General architecture . 5
5.2 Operational conditions. 6
5.2.1 Interfaces . 6
5.2.2 Identification of additional devices . 7
5.2.3 Device discovery mechanism . 7
5.2.4 Logical activation of additional devices . 8
5.2.5 Activation sequence . 8
5.2.6 Activity states of additional devices . 8
5.2.7 Exclusive usage attribute .10
5.2.8 General functionality .11
5.2.9 Timer control .12
5.3 Energy depending activation .12
5.4 Addressing of an additional device .12
5.4.1 General.12
5.4.2 Device identifier .12
5.4.3 Device handle.13
5.5 Device control information .13
5.5.1 Administration of additional devices .13
5.5.2 Device control parameter DVCP .13
5.5.3 General device information template .15
6 Functions of the additional device management command .17
6.1 General .17
6.2 Specific status bytes for additional device management .18
6.3 Functions of additional device management command .18
6.3.1 General command handling .18
6.3.2 general device reset function .18
6.3.3 logical device reset function .19
6.3.4 open device function . . .19
6.3.5 deactivate device function .20
6.3.6 reactivate device function .20
6.3.7 exclusive device usage function .20
6.3.8 general device usage function .21
6.3.9 get from device function .21
6.3.10 put to device function .22
6.3.11 get device information function .23
6.3.12 erase device content function .23
6.3.13 manage device configuration function .24
7 Usage of off-card devices .24
7.1 General .24
7.2 Transmission mechanism .26
7.3 Device handle .27
7.4 Secure channel .27
8 Command structures with adm functions in applications .28
9 Security aspects .28
© ISO/IEC 2016 – All rights reserved iii
9.1 Security attributes .28
9.1.1 Access mode field for adm command .28
9.1.2 Security conditions .29
9.2 Data integrity and confidentiality.29
9.3 Security with off-card-devices .30
9.4 Trust assessment .30
10 Device configuration template .30
10.1 Configuration template .30
10.2 Usage of device configuration templates .31
Annex A (informative) Activity sequences .32
Annex B (informative) Examples for information templates .34
Annex C (informative) Example of command sequences with additional devices .38
Annex D (informative) General system description .41
Bibliography .42
iv © ISO/IEC 2016 – 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. 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 document 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 and IEC 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 meaning of ISO specific terms and expressions related to conformity
assessment, as well as information about ISO’s adherence to the WTO principles in the Technical
Barriers to Trade (TBT) see the following URL: Foreword - Supplementary information
The committee responsible for this document is ISO/IEC JTC 1, Information technology, Subcommittee
SC 17, Cards and personal identification.
A list of all parts in the ISO 18328-series can be found on the ISO website.
© ISO/IEC 2016 – All rights reserved v
Introduction
The purpose of this document is to establish a normative basis for ICCs with at least an additional device.
Many new developments of electronic displays and keypads offer the technical opportunity to integrate
such devices on an ICC. First products are already available and the technical progress driven by mobile
devices also enforces the definition of basic standards for these technologies. Upcoming projects
require several different standardized aspects.
These different aspects are in the focus of the standardization related to electronic devices on ICC,
primarily the physical and electrical aspects, but also in addition the logical, organizational and
security definitions.
Physical characteristics for devices on an ICC are handled in ISO/IEC 18328-2. ISO/IEC 18328-3 deals
with the logical and security aspects and covers all relevant definitions and mechanisms to logical
interfaces, command sets, data structures and security aspects.
Many aspects in this document refer to ISO/IEC 7816 (all parts).
ISO and IEC draw attention to the fact that it is claimed that compliance with this document may involve
the usage of the following patents and the foreign counterparts:
— FR99/09818: Smart card architecture incorporating peripherals;
— PCT/EP2011/058914: Bank card with display screen;
— PCT/EP2011/059021: Bank card with display screen;
— EP2001949522A: Contact-free display peripheral device for contact-free portable object;
— WO2009077398, US20100263034, EP2225703, JP2010-538574, KR10-1162443: A method for
authorizing a communication with a portable electronic device, such as an access to an electronic
memory zone corresponding device and system.
ISO and IEC take no position concerning the evidence, validity and scope of these patent rights.
The holder of this patent right has assured the ISO and IEC that he/she is willing to negotiate licenses
under reasonable and non-discriminatory terms and conditions with applicants throughout the
world. In this respect, the statement of the holder of this patent right is registered with ISO and IEC.
Information may be obtained from:
Gemalto
Intellectual Property and Licensing Department
6, Rue de la Verrerie
92197 Meudon Cedex, France
Gemplus
Avenue Pic de Bertagne
Parc d’Activités de Gémenos BP 100
FR-13881 Gémenos Cedex
vi © ISO/IEC 2016 – All rights reserved
ASK SA
Les Boullides
15, Traverse des Brucs, Sophia Antipolis
06560 Valbonne, France
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights other than those identified above. ISO and IEC shall not be held responsible for identifying
any or all such patent rights.
© ISO/IEC 2016 – All rights reserved vii
INTERNATIONAL STANDARD ISO/IEC 18328-3:2016(E)
Identification cards — ICC-managed devices —
Part 3:
Organization, security and commands for interchange
1 Scope
This document specifies the logical interface of an application supporting the necessary security
features in a card-IC which communicates with the external world by a physical interface supporting
APDUs. This application supports the usage of electronic devices.
This involves the design of commands, data structures and security mechanisms which are required
to handle the data and handling the additional devices itself. The handling of the additional devices is
always controlled by the card-IC. External inputs or outputs shall be managed by the existing interfaces.
This document deals not with physical characteristics of the card and interface technology, but only
with the logical aspects. Management of data for additional devices that is not subdued by the COS or
application control is out of the scope of this document.
Definitions of coding requirement for “trust assessment” of the managed data like warning, font, colour
etc. is in the scope of this document. A description of the logical internal interface functionality used by
the COS or by device drivers, if any, is also part of this document.
Due to the fact that relevant technologies may evolve or be adopted very fast, this document defines
commands and structures supporting extensions and adaptations.
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, 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 http://www.iso.org/obp
3.1
access rule
data element containing an access mode referring to an action and security conditions to fulfil
before acting
3.2
application
structures, data elements and program modules needed for performing a specific functionality
© ISO/IEC 2016 – All rights reserved 1
3.3
button
tactile device used for a singular input
3.4
card-IC
integrated circuit with COS
3.5
command-response pair
set of two messages at the interface
EXAMPLE A command APDU followed by a response APDU in the opposite direction.
3.6
data element
item of information seen at the interface for which are specified a name, a description of logical content,
a format and a coding
3.7
data object
information seen at the interface consisting of the concatenation of a mandatory tag field, a mandatory
length field and a conditional value field
3.8
device
additional electronic feature used as an extension of the ICC
3.9
device driver
part of the operating system which provides the required functionality and interfaces to the additional
devices on ICC
3.10
device identifier
data element used to reference a device
3.11
device handle
logic data element used to work with a selected device
3.12
device manager
entity in an ICC which controls the device operation
3.13
device unit
electronic system providing all relevant entities to work with the device on the card
EXAMPLE Connections, driver-microcontroller, etc.
3.14
EF.ATR/INFO
optional EF indicating operating characteristics of the card, also known as Information file
3.15
electronic display
electronic device transporting optical information
3.16
file
structure for application and/or data in the card, as seen at the interface when processing commands
2 © ISO/IEC 2016 – All rights reserved
3.17
identification card
card identifying its holder and issuer, which may carry data required as input for the intended use of
the card and for transactions based thereon
3.18
interindustry
occurring, existing or using between two or more industries
3.19
key
sequence of symbols controlling a cryptographic operation
EXAMPLE Encipherment, decipherment, a private or a public operation in a dynamic authentication,
signature generation production, signature verification.
3.20
keypad
array of several buttons organized as one entity
3.21
payload
data of arbitrary length, to be sent to the card or by the card, in order to be processed together
3.22
record
string of bytes stored within EF, referenced and handled as a unit
3.23
secure messaging
set of means for cryptographic protection of (parts of) command-response pairs
3.24
security attribute
condition of use of objects in the card including stored data and data processing functions, expressed as
a data element containing one or more access rules
3.25
secure element
tamper-resistant ICC in a different form factor securely hosting applications and their confidential and
cryptographic data
3.26
security environment
set of components required by an application in the card for secure messaging or for security operations
3.27
structure
DF, EF, record, Data String or DO
3.28
template
concatenation of BER-TLV data objects, forming the value field of a constructed BER-TLV data object
© ISO/IEC 2016 – All rights reserved 3
4 Symbols and abbreviated terms
ACD application capability description
ADM additional device management
APDU application protocol data unit
ATR answer-to-reset
ATS answer-to-select
BER basic encoding rules of ASN.1 (see ISO/IEC 8825-1)
CCD card capability description
CLA class byte
COS card operating system
NOTE COS is a logical element for implementation of functionalities defined in ISO/IEC 7816-4.
CRT control reference template
C-RP command-response-pair
DF dedicated file
DHN device handle number
DO BER-TLV data object
DO’.’ BER-TLV data object, the tag of which is a hexadecimal value given between
simple quotes
DVCP device control parameter
EF elementary file
EF.ATR/INFO answer-to-reset file, or information file
FMD file management data
FCI file control information
IC integrated circuit
ICC integrated circuit card
IFD interface device
INS instruction byte
I²C inter-integrated circuit
LCD liquid crystal display
LED light emitting diode
Le field length field for coding the number N
e
N number of bytes in the command data field
c
4 © ISO/IEC 2016 – All rights reserved
N maximum number of bytes expected in the response data field
e
Nr number of bytes in the response data field
OID object identifier, as defined by ISO/IEC 8825-1
OLED organic light emitting diode
RF radio frequency
RFU reserved for future use by ISO/IEC JTC 1/SC 17
SPT security parameter template
SW1-SW2 status bytes (inserted for clarity, the dash is not significant)
TEE trusted execution environment
TLV tag length value
UTF universal character set transformation format
5 Architectural aspects
5.1 General architecture
An ICC comprising additional devices connected to the card IC extends the functionality of existing
implementations and applications. The new components require different new physical aspects to the
card and the electronic system as well as some new approaches in logical perspective. Architecture,
activities, commands and security are aspects which have to be covered in addition to existing
standards. The definitions shall be easily extensible for new developments in the future.
An ICC with additional devices consists of an ICC with
— an interface to the external world, e.g. a contact module or an antenna,
— at least an electronic device connected physically to the card IC, or
— logically linked additional off-card devices.
The COS may support the usage of an additional device with an extension or an internal interface to an
additional driver which may allow unidirectional or bi-directional information flow.
NOTE Devices referred in this document may consist of additional electronic equipment which allows
delivering activity state information or internal device information even in the case of an output device. The
ability is defined in the administration data of such devices.
This document deals with the interfaces between the external world and the ICC, and the ICC with the
electronic device. A physical interface between the ICC and any input/output device on the card may
use different technologies and transmission protocols. This is out of scope of this document. The COS
should always enable communication via the implemented interfaces with any device.
An ICC with input/output devices is controlled by means of the COS. The general principle is kept, that
the card is the slave, steered by commands of the IFD as the master. The initiative of any operation
performed with an additional device shall be caused by the external world or IFD, by the COS or the
active ICC application. A direct connection of the outside world to any input/output device on the card
is not covered by this document and is finally forbidden.
The principles of access control to any additional devices shall be compliant with the access control
syntax to files and data objects defined and described in ISO/IEC 7816-4.
© ISO/IEC 2016 – All rights reserved 5
The communication of the external world with the ICC dealing with an additional device consists of
APDUs with C-RP according to the definition in ISO/IEC 7816-4. The handling of the APDU is always in
the responsibility of the COS and uses the security means defined in ISO/IEC 7816-4.
The physical interfaces to different additional electronical input/output devices use a large variety
of electronic protocols, e.g. I²C, SPI, etc. The definition of a physical interface and related security
requirements, e.g. integrity and confidentiality of transferred data to any input/output device and vice
versa, is not in the scope of this document. Nevertheless, it is recommended to define generic abstract
activities/instructions on a logical level to these interfaces to ease the description of any required
activities.
This concept considers additional devices on a card, but also sets a general framework applicable to
card or secure element implementing interchanges according to this document and using interfaces to
off-card devices, e.g. display, LED and/or button in a handset.
For an informative description of the general system, see D.1.
Figure 1 — Schematic ICC system with electronic devices
5.2 Operational conditions
5.2.1 Interfaces
Any transport protocols and interfaces are possible (e.g. according ISO/IEC 7816-3, ISO/IEC 7816-12,
ISO/IEC 14443) as far as they allow the transmission of APDU-command-response pairs as defined in
ISO/IEC 7816-4.
6 © ISO/IEC 2016 – All rights reserved
5.2.2 Identification of additional devices
The external world is able to get the information about the card capabilities. The external world may
use different ways to retrieve this information, for example, with the following:
— an analysis of the General Feature Management DO’7F74’ in EF.ATR/INFO;
— analysis of the FCI of a selected application to retrieve a general feature management DO’7F74’;
— an OID referring the data set of capability description out of the general device information template
(see Table 10);
— other identification means of the card, e.g. information according to ISO/IEC 24727 (ACD, CCD, card
info file).
5.2.3 Device discovery mechanism
If used for device identification, the general feature management DO’7F74’ (see ISO/IEC 7816-4) in
EF.ATR/INFO or in the FCI of the selected application shall contain the on-card service DO’81’. This
data object contains a bitmap defining the on-card services. An additional DO’83’ may denote a device
identifiers list in the same order as denoted in the bitmap of on-card services. Multi-occurrences of the
same type of devices are represented with a prefixed occurrence number (one byte) followed by the
concatenation of device identifier (two bytes each). Each entry of occurrence number and concatenated
list of device identifier corresponds to the related bit in the bitmap of DO’81’ of the on-card services.
Table 1 — Device identifier list DO’83’
Tag Length Value
Occurrence number byte n of on-card service type A || Device identifier A1 || … || Device
‘83’ var.
identifier An
Occurrence number byte m of on-card service type B || Device identifier B1 || … || Device
identifier Bm
…
Table 2 defines further entries in the DO’81’ of the General Feature Management DO’7F74’. If there is a
need to add new devices, the feature list has to be extended.
Table 2 — Extension of feature-list-entries in general feature management DO’7F74’
Tag Length Meaning
‘81’ var. Sub-template identifier for on-card services
Feature-List [0.n], expandable
Byte 1 Byte 2
b8 b7 b6 b5 b4 b3 b2 b1 b8 b7 b6 b5 b4 b3 b2 b1 Meaning of bits
Display (defined by
1 — — — — — — — — — — — — — — —
ISO/IEC 7816-4)
Biometric input sensor
— 1 — — — — — — — — — — — — — —
(defined by ISO/IEC 7816-4)
— — 1 - — — — — — — — — — — — — Button
— — — 1 — — — — — — — — — — — — Keypad
— — — — 1 — — — — — — — — — — — LED
— — — — — 1 — — — — — — — — — — Loudspeaker
— — — — — — 1 — — — — — — — — — Microphone
— — — — — — — 1 — — — — — — — — Touchscreen
— — — — — — — — 1 — — — — — — — Battery
© ISO/IEC 2016 – All rights reserved 7
5.2.4 Logical activation of additional devices
After retrieval of the information about the capabilities of the card, a logical activation of an additional
device starts with the opening process by an adm command (see Clause 6). The identification of the
device is achieved by application of the device identifier (see 5.4.2) in the command.
The COS/device management returns a device handle number (see 5.4.3). With the positive
acknowledgement in the response by the card, the device is ready for further usage in the course of the
application. Table 3 denotes the states of the activation of a device.
5.2.5 Activation sequence
After enabling the physical interface between the ICC and the external world, all devices on the card
which are covered by this document are selectable with an adm command. The IFD activates a device in
IDLE/WAIT state with the following steps:
— retrieval of the device identifier by the device discovery mechanisms, e.g. described in 5.2.3 or
device identifier is implicitly known;
— application of the relevant device identifier in an adm open device command;
— the successful selection of the device returns a device handle number;
— all subsequent activities are applicable with this device handle number (see Clause 6).
Logical channels other than the basic channel shall start an activation sequence independently if
support of additional devices is requested. Annex A describes activation sequences.
5.2.6 Activity states of additional devices
The activity states of an additional device depend on the characteristics of the device itself. Table 3
defines the general activity states of additional devices. Possible actions within the states are listed and
may be performed by the COS, the devices driver or the external world. These actions may take place
even the device is in DEVICE OPERATION state.
8 © ISO/IEC 2016 – All rights reserved
Table 3 — Logical device states
State Definition Possible actions (or functions for adm command)
INACTIVE Device is not available, e.g. power power-on/off
is off
IDLE/WAIT open device,
Device is selectable
power-off
READY reactivate/deactivate device,
general/exclusive device usage,
get device information,
Device is selected device input/output,
general/logical reset device,
physical device reset,
power-off
DEVICE OPERA- deactivate device,
TION
get device information,
Device is actively in usage, e.g.
erase device content,
wait
for input on a button, visible device input/output,
information on a display, lighting
general/logical reset device,
instruction to an LED
physical device reset,
power-off
DEACTIVATED activate device,
Device is temporarily not in usage get device information, general/logical reset device,
physical device reset, power-off
The state DEACTIVATED can be achieved with an adm deactivation function at any state after an open
device function.
Transitions between the states of an additional device and their entailing activities are described in
Figure 2.
When in its activity state READY, DEVICE OPERATION or DEACTIVATED, an additional device is said in
OPERATIONAL state.
NOTE The support of physical or logical power-on/off depends on each device. After power-on and enabling
of the interfaces to the ICC, an additional device shall be in the activity state IDLE/WAIT waiting for the
activation sequence. The activation starts with a selection of the device by the function adm open device and
passes the state into READY. The active usage of the device switches this state into DEVICE OPERATION. In this
state, an input device requests actively for the input data, e.g. a button is waiting to be pressed, an output device
offers the information to the external world, e.g. a LED emits light. Most of these activities may be controlled by
timer (see 5.2.9). Two conditions may occur by this timer control. The first is an end of time frame for successful
input/output execution and the activity status of a device returns from DEVICE OPERATION to READY. The
second is a timeout for unsuccessful input/output execution, a state transition of device activity does not occur
and SW1-SW2 = ’6483’ is provided for this process. Defect devices are outside of the scope, handled by the
application and are not reflected in the diagram.
© ISO/IEC 2016 – All rights reserved 9
Figure 2 — State diagram of electronic device activities
The external world may get the current activity state of any additional device by applying an adm get
device information command (see 6.3.11).
Table 4 shows meanings of this byte.
Table 4 — Activity status byte
b8 b7 b6 b5 b4 b3 b2 b1 Meaning
— — — — — x x x Activity State
— — — — — 0 0 0 No information given
— — — — — 0 0 1 IDLE/WAIT
— — — — — 0 1 0 READY
— — — — — 0 1 1 DEVICE OPERATION
— — — — — 1 0 0 DEACTIVATED
— — — — — x x x any other values are RFU
— x x x x — — — 0000, any other values are RFU
x — — — — — — — Usage Attribute
1 — — — — — — — EXCLUSIVE DEVICE USAGE
0 — — — — — — — GENERAL DEVICE USAGE
5.2.7 Exclusive usage attribute
Beside the activity states a specific usage attribute shall be applicable. This attribute reserves in case
of EXCLUSIVE DEVICE USAGE the usage of the device for a single application only. The attribute can be
set by a specific operation for all those devices which are allowed to be used by all applications (see
10 © ISO/IEC 2016 – All rights reserved
6.3.7). The general shareability of a device is denoted in the DVCP of the device (see 5.5.2.1). The usage
attribute can be unset by an opposite operation to allow an unreserved usage again (see 6.3.8).
NOTE The unreserved mechanisms may be activated in some critical situations by COS or device
management. This is outside of scope and depends on the policy for such situation. The process is responsible to
restore the original settings.
5.2.8 General functionality
Independent from implemented internal interfaces between card IC and any input/out device, the COS
shall be able to establish a stable physical and logical connection to the additional device. The COS serves
and administrates the device handling internally or as an extension by specific driver functionality.
The set of functions of the adm command (see Clause 6) allows the external world to have also access to
the device handling functionality.
To fulfil all required activities to an additional device, a set of internal abstract instructions or
functionality shall be available in the COS to support the basic device handling. The following list
describes the minimal set of functionality which may have a corresponding function in the adm
command. These functions may be used by the application internally whenever necessary, regardless of
any adm command.
— Logical device reset
The device is logically set to the state IDLE/WAIT. All internal data structures are cleared, a device
handle is released. See also 6.3.3.
— Logical device selection
The device is opened and registered by assignment of a device handle. The state is switched to
READY. See also 6.3.4.
— Logical device activation
The device is switched from DEACTIVATED to READY or DEVICE OPERATION. See also 6.3.6.
— Logical device deactivation
The device is switched from READY or DEVICE OPERATION to DEACTIVATED. The device is
temporarily un-usable. See also 6.3.5.
— Output of data on the device
The process to handover to a device can be only achieved in the state DEVICE OPERATION. A
functionality performing such device output has to switch the internal state (temporarily) from
READY to DEVICE OPERATION. Output data is handed on to the device. See also 6.3.10.
— Input of data from the device
The process to receive data from a device can only be achieved in the state DEVICE OPERATION.
A functionality performing such device input has to switch the internal state (temporarily) from
READY to DEVICE OPERATION. Input data is requested from the device. See also 6.3.9.
— Get state of activity of additional device
The internal status of the device is requested. This functionality is available at any state after open
device operation. See also 6.3.11.
— Set state of activity of additional device
The internal status of the device is set by the application. This internal functionality may be
available at any state after open device operation.
© ISO/IEC 2016 – All rights reserved 11
— Reserve device
The device is exclusively usable by a single application. See also 6.3.7.
— Un-reserve device
The exclusive usage of a device is unset. See also 6.3.8.
— Get device information
General device information is requested and returned. This functionality is available at any state
after OPEN device operation. See also 6.3.11.
— Erase device content
The content of the device is deleted or overwritten with a pattern. This functionality may be
available in all states after OPEN device operation. See also 6.3.12.
— Manage device configuration
The predefined configuration values for a device are changed or set. See also 6.3.13.
This general functionality can be provided either by the COS or additional device control methods.
5.2.9 Timer control
In the course of the usage of an additional device on an ICC, the active conveyance of information to and
from the device switches the device state from READY to DEVICE OPERATION. The process to output
the data information or waiting for input depends on the system configuration and can be controlled by
timer. Device configuration templates (see 10.1) enable a device management to use timer control for
handling the input/output process. At the end of time frame, the process is stopped, the state switches
from DEVICE OPERATION to READY and the result of the function is available.
5.3 Energy depending activation
Additional electronic devices on an ICC show specific power consumption requirements. Depending on
the interface and the ability of the IFD, it may occur that not enough energy for additional devices on an
ICC is available.
If this is the reason for a failure of an activation of such additional device, the ICC shall return a specific
error code. Table 14 shows the additional device related SW1-SW2 values.
In case of energy deficits, an application dealing normally with additional devices may work without
device usage in the course of the application.
5.4 Addressing of an additional device
5.4.1 General
The different entities managing or having access to any additional device administrated by the ICC shall
address or reference these devices on a logical level. The physical mapping and access to a dedicated
additional device is internally known by the COS or the additional device control methods.
5.4.2 Device identifier
The device identifier is the logical identifier to address an additional device on the card. It is the internal
reference which is reserved for device oriented commands and is used by the COS to address the device
unambiguously (see 5.2.3). The device identifier shall be a two-byte value.
12 © ISO/IEC 2016 – All rights reserved
5.4.3 Device handle
The device handle is a logical structure identified by a unique number which is defined by the COS for
each additional device within a session. This number may be static or dynamic and shall be available or
usable after the selection/open of the additional device.
Device identifiers are static values and internal references to the card and do not correlate directly to
the device handle number (DHN). The COS shall maintain a logical link between uniquely attributed
device identifier value and corresponding device handle number. A given DHN generated by the COS or
statically assigned shall relate to a unique additional device identified by its unique device identifier.
Once a DHN is available, it shall be employed by the external world instead of the device identifier from
the device identifier list.
The device handles are used in the device related commands (see Clause 6). The DHN shall be returned
by the card in the response to device selection. When a device turns INACTIVE, its current DHN shall
be released. Table 5 shows the predefined static device handle numbers, which shall be used to address
the related additional device.
Table 5 — Interindustry device handle numbers
Device handle number Additional device
‘01’ Electronic display (static)
‘02’ Keypad (static)
‘03’-’7F
...








Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...