Identification cards -- Transport layer topologies -- Configuration for HCI/HCP interchange

Cartes d'identification -- Topologies de la couche transport -- Configuration pour les échanges HCI/HCP

General Information

Status
Published
Publication Date
26-May-2021
Current Stage
5060 - Close of voting Proof returned by Secretariat
Start Date
20-Apr-2021
Completion Date
20-Apr-2021
Ref Project

Buy Standard

Draft
ISO/IEC PRF TS 22924 - Identification cards -- Transport layer topologies -- Configurations for HCI/HCP interchange
English language
26 pages
sale 15% off
Preview
sale 15% off
Preview

Standards Content (sample)

TECHNICAL ISO/IEC TS
SPECIFICATION 22924
First edition
Identification cards — Transport layer
topologies — Configurations for HCI/
HCP interchange
PROOF/ÉPREUVE
Reference number
ISO/IEC TS 22924:2021(E)
ISO/IEC 2021
---------------------- Page: 1 ----------------------
ISO/IEC TS 22924:2021(E)
COPYRIGHT PROTECTED DOCUMENT
© ISO/IEC 2021

All rights reserved. Unless otherwise specified, or required in the context of its implementation, 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
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: +41 22 749 01 11
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
ii PROOF/ÉPREUVE © ISO/IEC 2021 – All rights reserved
---------------------- Page: 2 ----------------------
ISO/IEC TS 22924:2021(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

5 Architecture ...............................................................................................................................................................................................................4

5.1 System architecture view ............................................................................................................................................................... 4

5.1.1 General...................................................................................................................................................................................... 4

5.1.2 Hosts ........................................................................................................................................................................................... 5

5.1.3 Gates ........................................................................................................................................................................................... 5

5.1.4 Pipes ........................................................................................................................................................................................... 6

5.1.5 Host controller ................................................................................................................................................................... 7

5.1.6 General aspects on APDU gate ............................................................................................................................. 7

5.2 System architecture with legacy COS ................................................................................................................................... 8

6 Configuration requirements.....................................................................................................................................................................9

6.1 General ........................................................................................................................................................................................................... 9

6.2 Logical components of an APDU-enabled host ........................................................................................................... 9

6.3 Gates registry ........................................................................................................................................................................................... 9

6.3.1 General...................................................................................................................................................................................... 9

6.3.2 Administration gate registry ..............................................................................................................................10

6.3.3 Link management gate ............................................................................................................................................11

6.3.4 Identity management gate .................. ..................................................................................................................12

6.3.5 Loop back gate ................................................................................................................................................................12

6.3.6 APDU gate ...........................................................................................................................................................................13

6.3.7 APDU application gate registry ........................................................................................................................13

6.4 Example of exchanging APDU via HCI/HCP ................................................................................................................13

6.5 APDU transport versus HCP frames ..................................................................................................................................14

6.5.1 General...................................................................................................................................................................................14

6.5.2 Chaining of T=1 message blocks wrapping HCP packets ...........................................................15

6.5.3 Handling of error recovery with T=1 features ....................................................................................15

6.6 APDU fragmentation .......................................................................................................................................................................15

6.7 Supported set of commands and events ........................................................................................................................15

Annex A (informative) Examples of architecture variants ..........................................................................................................16

Annex B (informative) Background information ..................................................................................................................................21

Bibliography .............................................................................................................................................................................................................................26

© ISO/IEC 2021 – All rights reserved PROOF/ÉPREUVE iii
---------------------- Page: 3 ----------------------
ISO/IEC TS 22924:2021(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.

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 or www .iec .ch/ members

_experts/ refdocs).

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) or the IEC

list of patent declarations received (see patents.iec.ch).

Any trade name used in this document is information given for the convenience of users and does not

constitute an endorsement.

For an explanation of 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 www .iso .org/

iso/ foreword .html. In the IEC, see www .iec .ch/ understanding -standards.

This document was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology,

Subcommittee SC 17, Cards and security devices for personal identification.

Any feedback or questions on this document should be directed to the user’s national standards body. A

complete listing of these bodies can be found at www .iso .org/ members .html and www .iec .ch/ national

-committees.
iv PROOF/ÉPREUVE © ISO/IEC 2021 – All rights reserved
---------------------- Page: 4 ----------------------
ISO/IEC TS 22924:2021(E)
Introduction

This document is laid on the ground of ISO/IEC 7816 (all parts) specifying integrated circuit cards and

the use of such cards for interchange, and on ETSI TS 102 622 defining the HCI core that is an application

independent logical interface.

ETSI TS 102 622 is referenced in this document as a well-known HCI specification, however it should

be noted ETSI TS 102 622 describes another host network with the host controller implemented by

the CLF/NFC controller and with hosts residing on UICCs/SEs all connected to the host controller.

ETSI TS 102 622 allows for other interfaces than SWP for data link layer of HCI, and does not mandate

using the SWP but just describes the condition if the SWP is used.
© ISO/IEC 2021 – All rights reserved PROOF/ÉPREUVE v
---------------------- Page: 5 ----------------------
TECHNICAL SPECIFICATION ISO/IEC TS 22924:2021(E)
Identification cards — Transport layer topologies —
Configurations for HCI/HCP interchange
1 Scope

This document specifies the requirements for a protocol derived from HCI/HCP (see ETSI TS 102 622)

enabling communication for devices regardless of data link and physical layers. This document covers

the following:
a) outline of a system comprised of one or more hosts and one controller;

b) extension of connection topology between hosts and host controller (i.e. star topology and

additional other topologies);

c) segregation between existing system using ETSI TS 102 613 and new system compliant to this

document (this document refers ETSI TS 102 613, but does not change its specification and does not

use RFU).

For ETSI TS 102 622, data link layer and physical layer like SWP specified in ETSI TS 102 613 is out of

the scope.

Albeit questioned in this document, the duplication of OSI transport layer by e.g. enforcing encapsulation

of HCP into T=1 or the reverse, is out of the scope.
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-3, Identification cards — Integrated circuit cards — Part 3: Cards with contacts — Electrical

interface and transmission protocols

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:

— ISO Online browsing platform: available at https:// www .iso .org/ obp
— IEC Electropedia: available at http:// www .electropedia .org/
3.1
APDU gate

entry point to a service processing command APDU inside a host (3.6) or returning response APDU

3.2
APDU application gate

entry point to a service sending command APDU and retrieving correspondent response APDU

© ISO/IEC 2021 – All rights reserved PROOF/ÉPREUVE 1
---------------------- Page: 6 ----------------------
ISO/IEC TS 22924:2021(E)
3.3
gate
entry point to a service that is operated inside a host (3.6)
[SOURCE: ETSI TS 102 622]
3.4
HCI network

star-topology network comprised of a host network (3.8) where hosts (3.6) are interconnected with a

host controller (3.7) through HCI
3.5
HCP stack

layout comprised of a routing layer, a messaging layer and a collection of gates (3.3)

3.6
host
logical entity that operates one or more service(s)
[SOURCE: ETSI TS 102 622]
3.7
host controller
host (3.6) that is also responsible for managing a host network (3.8)
[SOURCE: ETSI TS 102 622]
3.8
host network
network of two or more hosts (3.6)
[SOURCE: ETSI TS 102 622]
3.9
managing host

host (3.6) which is in charge of resolving conflicts and interoperability issues between different

contactless applications provided by different hosts
[SOURCE: ETSI TS 102 622]
3.10
pipe
logical communication channel between two gates (3.3) from different hosts (3.6)
[SOURCE: ETSI TS 102 622]
3.11
terminal host
host (3.6) allocated a static identifier HID '01'
4 Symbols and abbreviated terms

ADM_x arbitrary command for administration gate, see ETSI TS 102 622 clause 6.1, e.g. ADM_CRE-

ATE_PIPE
APDU application protocol data unit
API application programming interface
2 PROOF/ÉPREUVE © ISO/IEC 2021 – All rights reserved
---------------------- Page: 7 ----------------------
ISO/IEC TS 22924:2021(E)

ANY_x a rbit ra r y comma nd for a ll g ates, see ETSI TS 102 622 clause 6 .1, e.g.

ANY_OPEN_PIPE
CB chaining bit
CLF contactless front end
COS card operating system
CPU central processing unit
CRC cyclic redundancy code
DF dedicated file
EVT_x arbitrary event, see ETSI TS 102 622 clause 6.3, e.g. EVT_HOT_PLUG
GID gate identifier
HCI host controller interface
HCP host controller protocol
HID host identifier
I C inter-integrated circuit
ICC integrated circuit card
IFD interface device
IRQ interrupt request
LRC longitudinal redundancy code
NAD node address
NFC near field communication
N(S) send sequence number
OSI Open System Interconnection
PCB protocol control byte
PID pipe identifier
PPS protocol and parameter selection
RF radio frequency
RFU reserved for future use
SCL smart secure platform common layer
SE secure element
SS SPI slave select wire
SSP smart secure platform
SWP single wired protocol
© ISO/IEC 2021 – All rights reserved PROOF/ÉPREUVE 3
---------------------- Page: 8 ----------------------
ISO/IEC TS 22924:2021(E)
TPDU transmission protocol data unit
UART universal asynchronous receiver and transmitter
UICC Universal Integrated Circuit Card
USB universal serial bus
eSE (embedded) secure element
5 Architecture
5.1 System architecture view
5.1.1 General

This subclause describes the reference use case architecture where APDU gate fits. This architecture is

based on a star topology where one or more hosts (e.g. secure element, ICC-managed device) physically

connect to a component (e.g. IFD, device controller, contactless frontend) acting as a host controller. In

this topology, the HCI defines the interface between hosts.
Figure 1 — System architecture for reference use case

ICC-managed devices may also make use of off-card devices (see ISO/IEC 18328-1 for use cases and

ISO/IEC 18328-3:2016, Clause 7, for architecture description). The usage of ICC-managed off-card

devices needs a communication with an ICC (or a secure element) through an IFD. The prerequisite for

such communication is a COS or application which can handle additional devices and a host controller

providing the suitable bi-directional communication means. Figure 1 describes this architecture.

NOTE For simplification, drivers and interfaces are not represented on Figure 1.

The reference use case on Figure 1 is deployed on Figure 2 over a general HCP stack. The route conveying

instructions over a pipe created between the two gates is represented.
4 PROOF/ÉPREUVE © ISO/IEC 2021 – All rights reserved
---------------------- Page: 9 ----------------------
ISO/IEC TS 22924:2021(E)
Figure 2 — HCI general stack representation
5.1.2 Hosts

This subclause contains a subset of information from ETSI TS 102 622 about hosts.

The identity of a host is coded in a byte named HID. Table 1 lists the reserved values for the HID.

Table 1 — Host identifiers
host HID
host controller '00'
terminal host '01'
RFU '02' to ''7F'
dynamically allocated '80' to 'BF'
proprietary 'C0' to 'FE'
not allowed 'FF'

In this table the value '02' is RFU whereas in ETSI TS 102 622 it is used for UICC host.

In this table the value 'FF' is not allowed whereas in ETSI TS 102 622 it is proprietary.

The generic term "host" is used to refer to any host (e.g. terminal host, UICC host) excluding the host

controller.

The dynamically allocated range of values shall be used by the host controller to assign a HID to any host

not identified in Table 1. The host controller shall always assign the same HID to a given host throughout

different sessions as long as there is no modification in the hardware configuration of the device.

NOTE 1 In ETSI TS 102 622, there is no statement that a HID has to be unique.

NOTE 2 ETSI TS 102 622 does not describe how a host controller assigns an HID to a host.

5.1.3 Gates

This subclause contains a subset of information from ETSI TS 102 622 about gates.

A gate provides an entry point to a service that is operated inside a host. The HCP enables gates from

different hosts to exchange messages. There are two types of gates:
— management gates that are needed for the management of the host network;
— generic gates that are not related to the management of the host network.
© ISO/IEC 2021 – All rights reserved PROOF/ÉPREUVE 5
---------------------- Page: 10 ----------------------
ISO/IEC TS 22924:2021(E)

The type of a gate is identified by a GID. GIDs are listed in Table 2 and are either unique within the scope

of a host ('10' to 'FF'), or their values refer to the same gate type for every host ('00' to '0F').

Table 2 — Gate identifiers
gate GID
reserved for proprietary use '00' to '03'
loop back gate '04'
identity management gate '05'
RFU '06' to '0F'
host specific '10' to 'EF'
reserved for proprietary use 'F0' to 'FF'

The GID for the application gates are dynamically assigned by the host running the application gate.

The following rules apply to hosts and gates.
a) All hosts and the host controller shall have one administration gate.

b) All hosts may have one link management gate and the host controller shall have one link

management gate.
c) All hosts and the host controller shall have one identity management gate.
d) All hosts and the host controller shall have one loop back gate.
e) All hosts and the host controller may have one or more generic gates.
5.1.4 Pipes

This subclause contains a subset of information from ETSI TS 102 622 about pipes.

A pipe is a logical communication channel between two gates. There are two types of pipes:

— static pipes that are always available, i.e. they do not need to be created and cannot be deleted;

— dynamic pipes that can be created and deleted.

The state of a pipe is either open or closed. The state shall remain persistent if the hosts are powered

down and up again. It shall also remain persistent if a host is temporarily removed from the host

network and is not replaced by a different device in the meantime. The state of a dynamic pipe after

creation and the initial state of a static pipe shall be closed.

The PID is 7 bits long. The value of PID is used in the header of HCP packets as routing information (see

B.6). For static pipes the PIDs are predefined with values as defined in Table 3. For dynamic pipes, PIDs

are dynamically allocated by the host controller.
Table 3 — Pipe identifiers
PID pipe ending at: pipe type
'00' link management gate
static
'01' administration gate
'02' to '6F' other gate dynamic
'70' to '7F' RFU
The following rules apply to gates and pipes.

a) A static pipe always connects a gate of a host to a gate of the host controller.

6 PROOF/ÉPREUVE © ISO/IEC 2021 – All rights reserved
---------------------- Page: 11 ----------------------
ISO/IEC TS 22924:2021(E)
b) A dynamic pipe connects two gates from different hosts.

c) Static and dynamic gates connect to different types of gates; see Table 3 for the mapping.

d) Dynamic PIDs shall be unique in the host network.
5.1.5 Host controller

The host controller can be a dedicated physical device or a software component on a device exposing

the host controller and zero, one or more hosts in the HCI network. The host controller can provide

more than one physical interface. The host controller allocates dynamic HIDs and PIDs as applicable.

A host can request the host controller to create a new dynamic pipe between two gates. The host

requesting the pipe is the source host. If successful, then a pipe is created between the source host and

a destination host. The host controller uses the WHITELIST defined by the destination host in order to

verify that the source host is authorized to create a pipe.

Once a pipe is open between the gates of two hosts, the host controller handles packets of data between

the two hosts based on the routing information provided by the PID in the network field of the HCP

header. In case a packet length exceeds the physical buffers sizes present on the host and on the host

controller, data are transferred in multiple subsequent fragments of the packet, with fragments in

chaining mode specified by the CHAINING field in the HCP header. As the physical buffer size present on

each host interface may vary with each implementation, the host controller may need to perform data

re-assembly and re-segmentation before forwarding it, according to each interface specification.

Data integrity checking and flow control for communications with each host according to specific data

link layer rules applicable for each physical interface is performed on each connection between a host

and the host controller. The host controller should have the ability to set a host into a power saving mode

and resume a host for access with a sequence specific to each physical interface and host architecture.

These elements of the OSI physical layer and data link layer are not defined in this document.

5.1.6 General aspects on APDU gate

According to ETSI TS 102 622, the host sending the APDU command is called the "client APDU host";

and the host receiving and processing the APDU commands is called the "server APDU host". The server

APDU host has an APDU gate with GID='30'. The client APDU host has an APDU application gate.

APDUs shall be as defined in ISO/IEC 7816-4. Usage of both the basic logical channel and further logical

channel(s) is allowed.

Assume a secure element with a physical interface receives command APDU and sends corresponding

response APDU. Its physical interface has a data link layer and a transport protocol for communication.

If such a secure element acts as a server APDU host in an HCI network, then this secure element also has

an APDU gate. The physical interface of such a secure element acts as a pipe to APDU application gates

of other hosts. The APDU gate within such a secure element is the APDU handler of its COS.

A client APDU host shall not create more than one pipe to the APDU gate of a server APDU host. The

APDU gate may accept only an implementation specific maximum concurrent number of pipes from

other client APDU hosts.
The general rules are as follows.
a) A pipe bridges between two gates from two hosts.

b) A pipe identifier in a host shall address a unique gate within the other host.

c) A gate shall only accept a command or an event on a pipe when the state of that pipe is open unless

determined otherwise by the application.

d) A gate shall not send a command or event on a pipe when it is waiting for a response to a previous

command on that pipe.
© ISO/IEC 2021 – All rights reserved PROOF/ÉPREUVE 7
---------------------- Page: 12 ----------------------
ISO/IEC TS 22924:2021(E)

HCI interface operates as an abstraction layer regardless of the underlying data link and physical layers,

which leaves to the implementation a wide range of possibilities fitting the eSE with the context.

Interface activation, presence of power saving modes, entering and exiting a power saving mode,

electrical parameters for a certain interface and handling of communication errors are outside the

scope of this document and dedicated to physical layer and data link layer.

The underlying data link layer may vary depending on the ecosystem. As a general rule it is expected

that a data link layer definition should meet the following properties.

— The data link layer ensures data is error free and the order of the received/sent data is respected.

— The data link layer provides its own data flow control.

— The data link layer delivers packets of the upper layer up to a maximum size specific to the data

link layer.

— The data link layer reports the size of each received packet to its upper layer.

5.2 System architecture with legacy COS

In this subclause it is assumed that an eSE is connected to an HCI network, but the physical interface

of the eSE is not compatible with the HCI (legacy COS). In that case the implementation of the server

APDU host (host A in Figure 3) connects to the eSE using a specific driver. Figure 3 shows the complete

communication path from a client APDU host (host B in Figure 3), via the host controller, through host A

and driver to the eSE. Please note, that the communication path between host A and host B in Figure 3

is identical to Figure 2, although Figure 3 does not show any detail from Figure 2.

Figure 3 shows how HCI is an abstraction layer to the eSE, and how the route through an HCI pipe

stretches from the APDU application gate to the legacy COS of the eSE. This pipe is logical and does not

require necessarily a wired connection.

NOTE 1 Host A in Figure 3 can run on the same hardware as the host controller e.g. as an embedded software

that emulates the eSE.

NOTE 2 Host B can run on the same hardware as the host controller e.g. a mobile controller.

Key
legacy route
HCP route
Figure 3 — HCI stack representation with legacy COS support

Further architecture variants with legacy secure element are described in Annex A.

8 PROOF/ÉPREUVE © ISO/IEC 2021 – All rights reserved
---------------------- Page: 13 ----------------------
ISO/IEC TS 22924:2021(E)
6 Configuration requirements
6.1 General

This clause describes the required configuration for a host providing APDU gate service.

6.2 Logical components of an APDU-enabled host

A host supporting the present HCI/HCP specification and able to handle APDUs shall be implemented

with, in addition to the APDU gate, the following other gates:
a) one (mandatory)administration gate allowing:

1) to create and delete dynamic pipes (access to services that manage the network of pipes in HCI);

2) the management of permissions through WHITELISTS (each host informs the host controller

with its WHITELIST about which other hosts are allowed to communicate with it);

3) the discovery of hosts at the first start-up or when configuration has changed;

4) the management of sessions (session ID changes whenever the host configuration changes);

b) one link management gate allowing:

1) the management of the underlying transport layer (i.e. number of invalid or lost frames due to

communication error);

2) EVT_HCI_END_OF_OPERATION to be sent by a host to the host controller over the pipe

connecting the host and host controller link management gate to announce host entry into

a power saving mode and requiring a resume sequence before a next access (the resume

sequence is expected to be defined in other specifications describing the lower OSI layers).

c) one (mandatory) loopback gate allowing to verify pipe connectivity (for tests purposes);

d) one (mandatory) identity management gate allowing the discovery of software and hardware

information about the APDU-enabled host;
e) generic (optional) gate(s) allowing various service(s) supported by the host.
6.3 Gates registry
6.3.1 General
This subclause describes the required entries of the registry respective to each
...

Questions, Comments and Discussion

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