ISO/IEC TS 23465-3:2023
(Main)Card and security devices for personal identification — Programming interface for security devices — Part 3: Proxy
Card and security devices for personal identification — Programming interface for security devices — Part 3: Proxy
This document describes the software (SW) layer called “proxy”. It supports the programming interface to security devices and the application using this API to access the application related security devices defined in ISO/IEC TS 23465-2. This document is applicable to: — proxy requirements, functionality and layers; — resolving mechanisms for API functions; — data structures related to security device handling; — translation for security device communication; — serialization/de-serialization syntax and methods.
Cartes et dispositifs de sécurité pour l’identification personnelle — L'interface du logiciel pour dispositifs de sécurité — Partie 3: Proxy
General Information
Buy Standard
Standards Content (Sample)
TECHNICAL ISO/IEC TS
SPECIFICATION 23465-3
First edition
2023-05
Card and security devices for personal
identification — Programming
interface for security devices —
Part 3:
Proxy
Cartes et dispositifs de sécurité pour l’identification personnelle —
L'interface du logiciel pour dispositifs de sécurité —
Partie 3: Proxy
Reference number
ISO/IEC TS 23465-3:2023(E)
© ISO/IEC 2023
---------------------- Page: 1 ----------------------
ISO/IEC TS 23465-3:2023(E)
COPYRIGHT PROTECTED DOCUMENT
© ISO/IEC 2023
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
© ISO/IEC 2023 – All rights reserved
---------------------- Page: 2 ----------------------
ISO/IEC TS 23465-3:2023(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 Proxy related requirements .2
5.1 Link between client application and security device . 2
5.2 Proxy layers . . 3
5.2.1 Proxy layer model . 3
5.2.2 Resolution layer of ISO/IEC 23465-API calls . 3
5.2.3 Layer representing/resolving class model . 4
5.2.4 Administration layer for security devices . 4
5.2.5 Security related layer . 4
5.2.6 Translation layer . . 4
5.2.7 Exception handler . 5
5.2.8 Connectivity related layer . 5
5.3 Conditional proxy functionality . 5
5.3.1 Multitasking/Multiplexing . 5
5.3.2 Crypto functionality. 5
5.3.3 Discovery functionality . 6
5.3.4 Registration functionality . 6
6 Instantiation of class objects . 6
6.1 Class model . 6
6.2 Process of instantiation . 7
6.3 Life cycle of an instance . 8
7 Services of the proxy . 8
7.1 Security device management. 8
7.1.1 Identification of security device . 8
7.1.2 Retrieval of security device information . . 9
7.1.3 Security device related functionality . 9
7.2 Security related layer . 10
7.2.1 General . 10
7.2.2 Security conditions and fulfilment . 10
7.2.3 Interpretation of ISO/IEC 7816-4 security conditions . 11
7.2.4 Security attributes for complex multistep authentication .12
7.2.5 Security attribute “user verification” .12
7.2.6 Security attribute “authentication” .12
7.2.7 Security attribute “secure messaging” (SM) .12
7.2.8 Implicit fulfilment of security conditions .13
7.3 Connectivity layer. 13
7.4 Multi-client/multi-security device support . 13
7.4.1 Task management . 13
7.4.2 Management of security devices . 13
8 Life cycle model of the proxy.14
8.1 Start-up phase . 14
8.2 Initialization and administration . 14
Annex A (informative) Example of client API call processing with proxy functionality .15
Bibliography .19
iii
© ISO/IEC 2023 – All rights reserved
---------------------- Page: 3 ----------------------
ISO/IEC TS 23465-3:2023(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 https://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.
A list of all parts in the ISO/IEC 23465 series can be found on the ISO and IEC websites.
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
© ISO/IEC 2023 – All rights reserved
---------------------- Page: 4 ----------------------
ISO/IEC TS 23465-3:2023(E)
Introduction
Integrated circuit card (ICC) technologies and solutions are widely deployed around the world, but
systems for identity tokens and credentials are quickly changing. In this context, the application
protocol data unit (APDU) protocol outlined in the ISO/IEC 7816 series is becoming, in some cases,
a hindrance to the integration of integrated circuits (ICs) in environments such as mobile phones,
handheld devices, connected devices (e.g. M2M, IoT) or other application using security devices.
Stakeholders often request an abstraction layer hiding IC specifics to avoid the complexity of APDU
protocols. However, even solutions based on those kinds of middleware are perceived as cumbersome
in some systems. The market looks for a middleware memory footprint to be as low as possible. This
document aims to overcome or mitigate those issues by proposing a new approach that would preserve
ICC functionality and allow for a seamless ICC portability onto new systems.
The ISO/IEC 23465 series focuses on a solution by designing an application programming interface
(API) and a system with these characteristics:
— It offers a subset, from the ISO/IEC 7816 series, of mostly used multi-sectorial ICC functions.
— It results in no further middleware or very little middleware memory footprint (i.e. simplified
drivers).
— It requires a simplified ICC capability discoverability (i.e. with significantly less complexity than
[3]
ISO/IEC 24727-1).
The ISO/IEC 23465 series is comprised of three parts, each focusing on a specific topic:
— ISO/IEC 23465-1: provides an introduction to the series and a short overview of the architecture;
— ISO/IEC TS 23465-2: defines the API for client applications allowing incorporation and usage of
security devices;
— ISO/IEC TS 23465-3 (this document): describes the software (SW) called "proxy" which provides
different services, e.g. to convert the API calls into serialized messages to be sent to the security
device.
The ISO/IEC 23465 series is intended to be used by any sector relying on the interchange defined, but
not limited to, the ISO/IEC 7816 series.
v
© ISO/IEC 2023 – All rights reserved
---------------------- Page: 5 ----------------------
TECHNICAL SPECIFICATION ISO/IEC TS 23465-3:2023(E)
Card and security devices for personal identification —
Programming interface for security devices —
Part 3:
Proxy
1 Scope
This document describes the software (SW) layer called “proxy”. It supports the programming interface
to security devices and the application using this API to access the application related security devices
defined in ISO/IEC TS 23465-2.
This document is applicable to:
— proxy requirements, functionality and layers;
— resolving mechanisms for API functions;
— data structures related to security device handling;
— translation for security device communication;
— serialization/de-serialization syntax and methods.
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 23465-1, Card and security devices for personal identification — Programming interface for
security devices — Part 1: Introduction and architecture description
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO/IEC 23465-1 and the following
apply.
ISO and IEC maintain terminology databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https:// www .iso .org/ obp
— IEC Electropedia: available at https:// www .electropedia .org/
3.1
access rule
data element containing an access mode referring to an action and security conditions to be fulfilled
before acting
3.2
client application
implemented application using the ISO/IEC 23465-API requesting services from a security device
1
© ISO/IEC 2023 – All rights reserved
---------------------- Page: 6 ----------------------
ISO/IEC TS 23465-3:2023(E)
3.3
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.1)
4 Symbols and abbreviated terms
APDU application protocol data unit
API application programming interface
ATR answer to reset
CBOR consise binary object representation
DO data object
ICC integrated circuit card
JSON JavaScript open notation
MSE manage security environment
OMAPI open mobile API
OSI open systems interconnection
PACE password authenticated connection establishment
SM secure messaging
SW software
SD security device, see terms and definitions
5 Proxy related requirements
5.1 Link between client application and security device
The proxy is the piece of software (SW) between the programming interface used by a client application
dealing with security devices and the related security device(s). The functionality of the proxy and its
APIs deal with communication, connectivity, provisioning of confidentiality and authenticity of the
connection to the security device and its security device applications.
The general concept of client applications dealing with a set of security device is outlined in
ISO/IEC 23465-1 and is depicted in Figure 1 (see also ISO/IEC 23465-1:2023, Figure. 2). The applications
or clients use abstractions of access methods to the security devices, which are outlined as the
ISO/IEC 23465-API in ISO/IEC TS 23465-2. Details of low-level security device addressing and accessing
methods are kept hidden to these clients. The translation of the abstract API-functions into low-level
commands and protocols shall be performed by the proxy, possibly supported by additional libraries
and internal APIs.
The clients only have access to the physical security devices by the proxy which acts as a dispatcher for
the direct access to the security devices and the related security device applications. In some use cases
the proxy may handle as a multiplexer, especially in multitasking environments with parallel running
clients.
2
© ISO/IEC 2023 – All rights reserved
---------------------- Page: 7 ----------------------
ISO/IEC TS 23465-3:2023(E)
Figure 1 — Components of the system with distributing proxy
5.2 Proxy layers
5.2.1 Proxy layer model
Figure 2 depicts the layers and components of the proxy to perform the client application requests by the
defined API. The proxy as a SW component requires some additional SW parts in a real implementation.
These are not outlined here, but are mentioned separately.
Figure 2 — Components of a proxy
5.2.2 Resolution layer of ISO/IEC 23465-API calls
Any API call needs a piece of programming code, called glue code, which has no functional relevance
but is essentially to adhere to the different code parts. Any real implementation resolves, with this
additional glue SW, the requirements of the applied programming language.
When several client applications are allowed to act in parallel, this layer shall be able to handle several
tasks independently.
3
© ISO/IEC 2023 – All rights reserved
---------------------- Page: 8 ----------------------
ISO/IEC TS 23465-3:2023(E)
5.2.3 Layer representing/resolving class model
The class model, outlined in ISO/IEC TS 23465-2, represents the view of the client and part of the proxy
to the object-oriented definition of a security device and its components. The client uses the references
and methods of the classes provided by the instantiated objects. The instantiation of the objects is
done in this layer. The proxy provides the object references to the client, administrates the objects
in accordance to the resources of the systems, e.g. the available or addressed security devices and its
related data.
5.2.4 Administration layer for security devices
All relevant data of the administrated and addressable security devices are handled in this layer. The
layer tallies the security devices, identifies the access methods, administrates the security device
individually and stores all relevant information of the available security devices.
Means for such administration is an internal registry holding all the information of available security
devices. In case of removable security devices, this layer shall register when mounting and de-
register when detaching the security devices. The registry entries for such devices has to be updated
accordingly.
NOTE The entries of such a registry are used to inform the client about the details of the requested security
devices.
5.2.5 Security related layer
This layer provides the means to perform all the security mechanisms related to the security devices.
Any security device supports or requires security features, directly or indirectly. Depending on the
security attributes of the security device application, these security-related activities have to be
provided or performed, sometimes in cooperation with the client application, sometimes hidden to the
client application. In the latter case the security activities shall be performed by this proxy layer.
Relevant information of fulfilled security features shall be stored, in case this information is required
for further security device access.
A security device requires sometimes an authentication procedure according to external specifications,
to set-up a secure channel, which are be completely hidden to the client application. In this case a
session management has to be considered in the security related layer.
5.2.6 Translation layer
The most important abstraction of the access methods to security devices is the concealment of the
direct communication, offered by the API. As outlined in ISO/IEC 23465-1, the evolution of security
device technologies can require different protocols and data formats than those currently being used.
The conversion into protocols understood by the used security device shall be done in this layer.
The translation layer provides the means to perform the translation of the client application’s initiated
activity into security device related protocols and formats. An abstract API call from the client
application finally results in at least one command understood by the addressed security device.
In contrast, responses of the security device after processing of the command(s) are returned in the
format of the used security device protocol. This layer re-translates the replied data into the formats
defined by the API which are finally expected and understood by the client application.
The translation process is understood as a serialisation/marshalling and de-serialisation/unmarshalling
technique, which is well-known in SW technology and used by many computer languages.
NOTE The actual protocol dealing with security devices based on ICC technology uses APDU, defined by
ISO/IEC 7816-4. Upcoming application specifications use, e.g. CBOR, JSON or other coded protocols which can be
relevant in the future.
4
© ISO/IEC 2023 – All rights reserved
---------------------- Page: 9 ----------------------
ISO/IEC TS 23465-3:2023(E)
5.2.7 Exception handler
Most of the API functions defined in ISO/IEC TS 23465-2 expect exception messages. Dedicated return
values of the security devices, e.g. defined in ISO/IEC 7816-4, shall be translated by the translation
layer. In case of errors or unforeseeable situations, the program flow is interrupted by throwing an
exception This is managed by this exception layer.
The service can be used in conjunction with the translation layer since a response of a security device
can require exception handling.
5.2.8 Connectivity related layer
The physical connection of the security device in the system has to be used by the proxy. Depending
on the runtime environment of the used system, security device/reader-related device drivers or
middlewares are available. This layer uses existing APIs which may be manufacturer dependent and
requires a system related implementation. Some systems offer standardized APIs which can facilitate
[6]
the interaction between proxy and security devices, e.g. the Global Platform Open Mobile API .
5.3 Conditional proxy functionality
5.3.1 Multitasking/Multiplexing
ISO/IEC 23465-1 outlined different runtime environments in which client applications can use the
ISO/IEC 23465-API. The behaviour of a proxy varies from either supporting only one security device by
one client, or one client with access to several security devices (in a single task), or several clients with
access to several security devices in parallel in a multitasking runtime environment.
According to the needs of the latter situation, the proxy shall be designed as a SW running in a
multitasking environment. When several clients interact with one security device simultaneously, the
proxy shall obey the ability of the security device. An existing solution for such simultaneous access on
a single security device is possible today when logical channels are supported. The approach of multiple
logical interfaces in addition to logical channels also allows the parallel processing of security device
applications in a single physical security device.
The security device’s behaviour shall be managed by the proxy. Logical channel or multiple logical
interface support can be part of a discovery mechanism of the proxy or a specific information in the
proxy’s registry of security devices.
5.3.2 Crypto functionality
Many API functions defined in ISO/IEC TS 23465-2 deal with crypto-functionality related to the
security device. Addressing means used by the client application and the internal management within
the security device usually differs. The knowledge about the behaviour, the needs of crypto protocols
and the translation into security device related formats is provided by this service.
The proposed API methods for crypto operations cover all algorithms and mechanisms which are
currently in common usage. Since the calculation is performed on the security device, the proxy shall
adopt and structure the data in a way that the addressed security device can use the data.
Some crypto API calls are separated into calls for initialization of the method followed by one or more
subsequent calls of the crypto API for processing. The sequence of APIs shall be controlled by the proxy.
Existing crypto protocols performed on security devices need additional commands to set-up a crypto-
functionality. ISO/IEC 7816-4 defines concepts and commands which are used to set-up the security
environment (MSE command) with essential information, expected by the security devices in advance.
These activities should be completely hidden to the client application. The application of such security
device related commands shall be performed by the proxy.
5
© ISO/IEC 2023 – All rights reserved
---------------------- Page: 10 ----------------------
ISO/IEC TS 23465-3:2023(E)
5.3.3 Discovery functionality
ISO/IEC TS 23465-2 offers the API call isoIec23465_getSDList which provides the security device
attributes of the accessible security devices. This set of information shall be collected and distributed
by the proxy. The discovery service is responsible for the collection and distribution of the relevant
attributes.
This can be performed by specific discovery mechanisms related to the security devices known by
additional interfaces, middlewares or other means. A possible registration service (see 5.3.4) with a
persistent registry can be an additional source of information to be filled in the list of security device
attributes.
5.3.4 Registration functionality
This service may be established to administrate the connected security devices. It allows the storage
of security device related information in a registry of the proxy. The service periodically polls the
existence and the identification of security devices in the system and updates the registry accordingly.
This behaviour is also important for removable devices.
The registration and discovery functionality services are normally handled in conjunction with each
other.
6 Instantiation of class objects
6.1 Class model
The class model for the API was introduced in ISO/IEC TS 23465-2, together with the object handling
and the resolution of the instances. Figure 3 (see also ISO/IEC 23465-1:2023, Figure 7) depicts the
proposed way to handle the API calls in the proxy.
6
© ISO/IEC 2023 – All rights reserved
---------------------- Page: 11 ----------------------
ISO/IEC TS 23465-3:2023(E)
Figure 3 — Class model in context of the API and the security device
The client applications use the ISO/IEC 23465-API to handle the user functionality. The application
refers to the class definitions and establishes the access to the objects defined in the class model via
the API calls to the proxy. The calls are handled in the proxy’s resolving layer (see 5.2.2). Based on the
references of the instantiated objects, subsequent API calls on these objects are app
...
Deleted: TC /SC N ¶
ISO/IEC DTS 23465-3
Date: ¶
¶
ISO/IEC JTC 1/SC 17
/SC /WG
Secretariat: BSI
Date: 2022-12-21
Deleted: ¶
Copyright notice¶
This ISO document is a working draft
Card and security devices for personal identification —
Programming interface for security devices —
Part 3:
Proxy
Cartes et dispositifs de sécurité pour l’identification personnelle — L'interface du logiciel pour dispositifs
de sécurité —
Partie 3: Proxy
FDIS stage
---------------------- Page: 1 ----------------------
ISO/IEC DTS 23465-3:(E)
ii © ISO/IEC 2022 – All rights reserved
---------------------- Page: 2 ----------------------
ISO/IEC DTS 23465-3:(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. Deleted: 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 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 https://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 Deleted: on
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.
Deleted: following URL:
Field Code Changed
This document was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology,
Deleted: iso.org/iso/foreword.html
Subcommittee SC 17, Cards and security devices for personal identification.
Deleted: The committee responsible for
A list of all parts in the ISO/IEC 23465 series can be found on the ISO and IEC websites.
Deleted: is
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. Deleted: ISO/IEC 23465 consists of the following parts,
under the general title Card and security devices for
personal identification — Programming interface for
security devices¶
¶
— Part 1:
© ISO/IEC 2022 – All rights reserved iii
---------------------- Page: 3 ----------------------
ISO/IEC DTS 23465-3:(E)
Deleted: and architecture description
Introduction
Integrated circuit card (ICC) technologies and solutions are widely deployed around the world, but
Deleted: — Part 2: API definition¶
— Part 3: Proxy¶
systems for identity tokens and credentials are quickly changing. In this context, the application protocol
¶
data unit (APDU) protocol outlined in the ISO/IEC 7816 series is becoming, in some cases, a hindrance to
Introduction¶
the integration of integrated circuits (ICs) in environments such as mobile phones, handheld devices,
Deleted: the system
connected devices (e.g. M2M, IoT) or other application using security devices.
Deleted: is
Several stakeholders are not familiar with, or not very fond of APDU protocol because of its complexity.
Deleted: like
They will often circumvent its constraints by requesting an abstraction layer hiding IC specifics.
Deleted: secure elements
However, even solutions based on those kinds of middleware are perceived as cumbersome in some
Deleted: for
systems. The market looks for a middleware memory footprint to be as low as possible. This document
aims to overcome or mitigate those issues by proposing a new approach that would preserve ICC
Deleted: would
functionality and allow for a seamless ICC portability onto new systems.
Deleted: ¶
But
The ISO/IEC 23465 series focuses on a solution by designing an application programming interface (API)
and a system with these characteristics: Deleted: standard
Deleted: allows
— It offers a subset, from the ISO/IEC 7816 series, of mostly used multi-sectorial ICC functions.
Deleted: ¶
— It results in no further middleware or very little middleware memory footprint (i.e. simplified This
drivers).
Deleted: of standards
Deleted: ¶
— It requires a simplified ICC capability discoverability (i.e. with significantly less complexity than
[3]
ISO/IEC 24727-1 ).
Deleted:
The ISO/IEC 23465 series is comprised of three parts, each focusing on a specific topic:
Deleted: finally
1
— ISO/IEC 23465-1 : provides an introduction to the series and a short overview of the architecture; Deleted:
Deleted: capabilities
2
— ISO/IEC TS 23465-2 : defines the API for client applications allowing incorporation and usage of
Deleted: ).
security devices;
Deleted: — Part 1 (IS):
— ISO/IEC TS 23465-3 (this document): describes the software (SW) called "proxy" which provides
Deleted: — Part 2 (
different services, e.g. to convert the API calls into serialized messages to be sent to the security
Deleted: ):
device.
Deleted: — Part
The ISO/IEC 23465 series is intended to be used by any sector relying on the interchange defined, but not
Deleted: Proxy
limited to, the ISO/IEC 7816 series.
—
1
Under preparation. Stage at the time of publication: ISO/IEC PRF 23465-1.
2
Under preparation. Stage at the time of publication: ISO/IEC PRF TS 23465-2.
iv © ISO/IEC 2022 – All rights reserved
---------------------- Page: 4 ----------------------
ISO/IEC DTS 23465-3:(E)
Card and security devices for personal identification —
Programming interface for security devices —
Part 3:
Proxy
1 Scope Deleted: (Part3)
This document describes the software (SW) layer called “proxy”. It supports the programming interface Deleted: part of ISO/IEC 23465
to security devices and the application using this API to access the application related security devices
Deleted: ” supporting
defined in ISO/IEC TS 23465-2.
Deleted: ,
This document is applicable to:
Deleted: part
— proxy requirements, functionality and layers;
Deleted: of this series of standards
Deleted: This series of standards is intended to be used
— resolving mechanisms for API functions;
by any sectors relying on the interchange defined by the
ISO/IEC 7816 series but no limited.¶
— data structures related to security device handling; ¶
This is the third part of the series dealing with ¶
— translation for security device communication;
Deleted: ,
Deleted: ,
— serialization/de-serialization syntax and methods.
Deleted: ,
2 Normative references
There are no normative references in this document.
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
ISO and IEC maintain terminology databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https://www.iso.org/obp
Deleted: —
— IEC Electropedia: available at https://www.electropedia.org/
Deleted: —
3.1 Deleted: .
access rule
data element containing an access mode referring to an action and security conditions to be fulfilled
before acting
3.2 Deleted: .
bus
communication system transferring data between electronic components
[SOURCE: ISO/IEC/IEEE 24765:2017, 3.441]
3.3
Deleted: .
client
any type of entity requesting services from a security device (3.9)
Deleted: (3.9)
3.4 Deleted: .
client application
implemented application using the ISO/IEC 23465-API (3.5) requesting services from a security device Deleted: (3.5)
(3.9)
Deleted: (3.9)
© ISO/IEC 2022 – All rights reserved 1
---------------------- Page: 5 ----------------------
ISO/IEC DTS 23465-3:(E)
3.5 Deleted: .
ISO/IEC 23465-API
[5]
software (SW) interface defined in ISO/IEC TS 23465-2 Deleted: [5]
3.6
Deleted: .
middleware
software (SW) component allowing two systems from different or similar open systems interconnection
(OSI) layers to communicate with each other
3.7 Deleted: .
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.1) Deleted: (3.1)
3.8 Deleted: .
proxy
sub-system to perform conversion from the application programming interface (API) function to the
interface of the security device (3.9)
Deleted: (3.9)
3.9 Deleted: .
security device
tamper-resistant secure hardware component which is used in a device to provide the security,
confidentiality and multiple application environment required to support various business models
Deleted: ,
Note 1 to entry: Can exist in any form factor, e.g. universal integrated circuit card (UICC), embedded SE, smartSD,
Deleted: ¶
smart microSD.
[SOURCE: Global Platform Inc.: "GlobalPlatform Device
Technology - TEE System Architecture", Version¶
EXAMPLE A SIM, an UICC, an eSIM, an eSE or a secure memory card.
Deleted: .2, Public Release, December 2018]¶
¶
[8]
[SOURCE: GlobalPlatform Device Technology]
NOTE
Deleted: such as
3.10
Deleted: ,
serialization
Deleted: serve as security device
process of translating data structures or object states into a format that can be transmitted
Deleted: .
3.11
Deleted: .
use case
list of actions or event steps typically defining the interactions between a role (known in the Unified
Deleted: a
Modeling Language as an actor) and a system to achieve a goal
Note 1 to entry: A role is known as an actor in the Unified Modelling Language.
4 Symbols and abbreviated terms
APDU application protocol data unit
API application programming interface
ATR answer to reset
CBOR consise binary object representation
DO data object
ICC integrated circuit card
JSON JavaScript open notation
MSE manage security environment
OMAPI open mobile API
OSI open systems interconnection
2 © ISO/IEC 2022 – All rights reserved
---------------------- Page: 6 ----------------------
ISO/IEC DTS 23465-3:(E)
PACE password authenticated connection establishment
SW Software
SD security device, see terms and definitions
5 Proxy related requirements
5.1 Link between client application and security device
The proxy is the piece of software (SW) between the programming interface used by a client application
dealing with security devices and the related security device(s). The functionality of the proxy and its
APIs deal with communication, connectivity, provisioning of confidentiality and authenticity of the
connection to the security device and its security device applications.
The general concept of client applications dealing with a set of security device is outlined in ISO/IEC
23465-1 and is depicted in Figure 1 (see also ISO/IEC 23465-1:20—, Figure. 2). The applications or Deleted: , Fig.
clients use abstractions of access methods to the security devices, which are outlined as the ISO/IEC
23465-API in ISO/IEC TS 23465-2. Details of low-level security device addressing and accessing methods Deleted: device’s
are kept hidden to these clients. The translation of the abstract API-functions into low-level commands
and protocols have to be performed by the proxy, possibly supported by additional libraries and internal
APIs.
The clients only have access to the physical security devices by the proxy which acts as a dispatcher for Deleted: only
the direct access to the security devices and the related security device pplications. In some use cases the
Deleted: an
proxy may handle as a multiplexer, especially in multitasking environments with parallel running clients.
Figure 1 — Components of the system with distributing proxy
5.2 Proxy layers
5.2.1 Proxy layer model
Figure 2 depicts the layers and components of the proxy to perform the client application requests by the
Deleted: Figure 2
defined API. The proxy as a SW component requires some additional SW parts in a real implementation.
Deleted: software
These are not outlined here, but are mentioned separately.
Deleted: ,
© ISO/IEC 2022 – All rights reserved 3
---------------------- Page: 7 ----------------------
ISO/IEC DTS 23465-3:(E)
Deleted: ¶
Resolution Layer of ISO/IEC 23465 API calls
Layer representing/resolving class model
Security device related layer
not re
Security related layer
Translation layer
Exception handler
Connectivity related layer
PROXY
Figure 2 — Components of a proxy
5.2.2 Resolution layer of ISO/IEC 23465-API calls
Any API call needs a piece of programming code, called glue code, which has no functional relevance but
is essentially to adhere the different code parts. Any real implementation resolves, with this additional
glue SW, the requirements of the applied programming language.
Deleted: software
When several client applications are allowed to act in parallel, this layer shall be able to handle several
tasks independently.
5.2.3 Layer representing/resolving class model
The class model, outlined in ISO/IEC TS 23465-2, represents the view of the client and part of the proxy
to the object-oriented definition of a security device and its components. The client uses the references
and methods of the classes provided by the instantiated objects. The instantiation of the objects is done
in this layer. The proxy provides the object references to the client, administrates the objects in
accordance to the ressources of the systems, e.g. the available or addressed security devices and its
related data.
5.2.4 Administration layer for security devices
All relevant data of the administrated and addressable security devices are handled in this layer. The
layer tallies the security devices, identifies the access methods, administrates the security device
individually and stores all relevant information of the available security devices. Deleted: indivually
Means for such administration is an internal registry holding all the information of available security
devices. In case of removable security devices, this layer has to register when mounting and de-register
when detaching the security devices. The registry entries for such devices has to be updated accordingly.
NOTE The entries of such a registry are used to inform the client about the details of the requested security
devices.
5.2.5 Security related layer
This layer provides the means to perform all the security mechanisms related to the security devices.
Any security device supports or requires security features, directly or indirectly. Depending on the
security attributes of the security device application, these security-related activities have to be provided
Deleted: has
or performed, sometimes in cooperation with the client application, sometimes hidden to the client
application. In the latter case the security activities have to be performed by this proxy layer.
Deleted: has
Relevant information of fulfilled security features has to be stored, in case this information is required
for further security device access.
A security device requires sometimes an authentication procedure according to external specifications,
to set-up a secure channel, which are be completely hidden to the client application. In this case a session
management has to be considered in the security related layer.
4 © ISO/IEC 2022 – All rights reserved
---------------------- Page: 8 ----------------------
ISO/IEC DTS 23465-3:(E)
5.2.6 Translation layer
The most important abstraction of the access methods to security devices is the concealment of the direct
communication, offered by the API. As outlined in ISO/IEC 23465-1, the evolution of security device
technologies can require different protocols and data formats than those currently being used. The Deleted: may
conversion into protocols understood by the used security device has to be done in this layer.
Deleted: as
The translation layer provides the means to perform the translation of the client application’s initiated Deleted: be
activity into security device related protocols and formats. An abstract API call from the client application
finally results in at least one command understood by the addressed security device. Deleted: finally
In contrast, responses of the security device after processing of the command(s) are returned in the
Deleted: Vice versa
format of the used security device protocol. This layer re-translates the replied data into the formats
defined by the API which are finally expected and understood by the client application.
The translation process is understood as a serialisation/marshalling and de-serialisation/unmarshalling
technique, which is well-known in SW technology and used by many computer languages. Deleted: the software
Deleted: is
NOTE The actual protocol dealing with security devices based on ICC technology uses APDU, defined by
ISO/IEC 7816-4. Upcoming application specifications use, e.g. CBOR, JSON or other coded protocols which can be
Deleted: might
relevant in the future.
5.2.7 Exception handler
Most of the API functions defined in ISO/IEC TS 23465-2 expect exception messages. Dedicated return
values of the security devices, e.g. defined in ISO/IEC 7816-4, have to be translated by the translation
layer. In case of errors or unforeseeable situations, the program flow is interrupted by throwing an
exception This is managed by this exception layer.
The service can be used in conjunction with the translation layer since a response of a security device can
Deleted: might
require exception handling.
Deleted: may
5.2.8 Connectivity related layer
The physical connection of the security device in the system has to be used by the proxy. Depending on
the runtime environment of the used system, security device/reader-related device drivers or Deleted: devices/readers
middlewares are available. This layer uses existing APIs which may be manufacturer dependent and
requires a system related implementation. Some systems offer standardized APIs which can facilitate the Deleted: could
[7]
interaction between proxy and security devices, e.g. the Global Platform Open Mobile API .
Deleted: .
5.3 Conditional proxy functionality
5.3.1 Multitasking/Multiplexing
ISO/IEC 23465-1 outlined different runtime environments in which client applications can use the
ISO/IEC 23465-API. The behaviour of a proxy varies from either supporting only one security device by Deleted: behavior
one client, or one client with access to several security devices (in a single task), or several clients with
access to several security devices in parallel in a multitasking runtime environment.
According to the needs of the latter situation, the proxy has to be designed as a SW running in a Deleted: software
multitasking environment. When several clients interact with one security device simultaneously, the
proxy has to obey the ability of the security devices. An existing solution for such simultaneous access on
a single security device is possible today when logical channels are supported. The approach of multiple
Deleted: today
logical interfaces in addition to logical channels also allows the parallel processing of security device
Deleted: also
applications in a single physical security device.
The security device’s behaviour has to be managed by the proxy. Logical channel or multiple logical
interface support can be part of a discovery mechanism of the proxy or a specific information in the Deleted: could
proxy’s registry of security devices.
5.3.2 Crypto functionality
Many API functions defined in ISO/IEC 23465-2 deal with crypto-functionality related to the security
Deleted: A lot ot
device. Addressing means used by the client application and the internal management within the security
Deleted: part
Deleted: of this series of standard are dealing
© ISO/IEC 2022 – All rights reserved 5
---------------------- Page: 9 ----------------------
ISO/IEC DTS 23465-3:(E)
device usually differs. The knowledge about the behaviour, the needs of crypto protocols and the Deleted: usually
translation into security device related formats is provided by this service.
The proposed API calls for crypto operations to cover algorithms and mechanisms which are in common
usage. Since the calculation is performed on the security device, the proxy shall adopt and structure the
data in a way that the addressed security device can use the data.
Some crypto API calls are separated into calls for initialization of the method followed by one or more
subsequent calls of the crypto API for processing. The sequene of APIs has to be controlled by the proxy.
Existing crypto protocols performed on security devices need additional commands to set-up a crypto-
functionality. ISO/IEC 7816-4 defines concepts and commands which are used to set-up the security
environment (MSE) with essential information, expected by the security devices in advance. These
activities should be completely hidden to the client application. The application of such security device
related commands has to be done by the proxy.
5.3.3 Discovery functionality
ISO/IEC TS 23465-2 offers the API call isoIec23465_getSDList which provides the security device
attributes of the accessible security devices. This set of information shall be collected and distributed by
the proxy. The discovery service is responsible for the collection and distribution of the relevant
attributes.
This can be performed by specific discovery mechanisms related to the security devices known by
additional interfaces, middlewares or other means. A possible registration service (see 5.3.4) with a Deleted: clause
persistent registry can be an additional source of information to be filled in the list of security device
Deleted: could
attributes.
5.3.4 Registration functionality
This service may be established to administrate the connected security devices. It allows the storage of
security device related information in a registry of the proxy. The service periodically polls the existence
and the identification of security devices in the system and updates the registry accordingly. This Deleted: periodically
behaviour is also important for removable devices.
The registration and discovery functionality services are normally handled in conjunction with each
Deleted: service is
other.
6 Instantiation of class objects
6.1 Class model
The class model for the API was introduced in ISO/IEC TS 23465-2, together with the object handling and
the resolution of the instances. Figure 3 (see also ISO/IEC 23465-1:20—, Figure 7) depicts the proposed Deleted: , Fig.
way to handle the API calls in the proxy.
6 © ISO/IEC 2022 – All rights reserved
---------------------- Page: 10 ----------------------
ISO/IEC DTS 23465-3:(E)
Figure 3 — Class model in context of the API and the security device
The client applications use the ISO/IEC 23465-API to handle the user functionality. The application refers
to the class definitions and establishes the access to the objects defined in the class model via the API calls Deleted: establish
to the proxy. The calls are handled in the proxy’s resolving layer (see 5.2.2). Based on the references of
the instantiated objects, subsequent API calls on these objects are applicable.
The proposed class model and its possible usage reflects the structure and the content on the security
device. Any client application can only use objects and methods which are supported by the underlaying Deleted: uses
security device. The proxy is the entity which conveys the application request, e.g. addressing of
Deleted: ,
objects/methods and finally transforming into adequate format to the security device.
Deleted: finally
The real objects on the security device have their counterparts in the proxy as objects defined in the class
model. Usable methods reflect the set of commands of the security device. The proxy resolves the usage
of methods into sequences of security device commands, at least into one command.
An example is provided in Annex A.
6.2 Process of instantiation
After identifying the corresponding security device (in case more than one are available) the client
application starts to interact with the security device by instantiating the SdApplication related to the
client application. The link and binding of the instance of this object to its physical counterpart on the
security device shall be established by the proxy.
The underlaying resolution layer detects the application on the security device by the selection
mechanism of ISO/IEC 7816-4. The proxy generates the reference of this object and links its methods to
the command set of the client related application on the security device.
According to the results of this process the proxy collects all relevant information:
— The object reference becomes valid, when the security device application exists.
— Additionally, available information, e.g. data objects of the FCI, application related access conditions,
are collected and assigned to the object/reference.
© ISO/IEC 2022 – All rights reserved 7
---------------------- Page: 11 ----------------------
ISO/IEC DTS 23465-3:(E)
— The client application retrieves the reference of the instance.
— The client application addresses any further calls/methods via the instance reference.
NOTE The logical and physical interaction with the security device through a communication layer (e.g. APDU)
is handled by the proxy and its subsequent layers. The usage of other APIs providing connection to the security
device (e.g. Open Mobile API) is possible.
The proxy handles the memory requirements and its allocation related to its services autonomously,
completely hidden to the client applications. The client application only takes care of its own memory Deleted: only for
requirements.
6.3 Life cycle of an instance
Objects of a client application instantiated according to 6.2 are directly linked to the physical content of
the security device. A request of instantiation by the client application in the first hand generates the Deleted: firstly
reference to this object.
In general, a reference and the instance to such object shall be usable by the client application until the Deleted: till
session of the client application is closed or the object and its ressources are released. A destruction of
the object as a method is not part of this document. Deleted: standard
In complex system architectures the proxy has to administrate the list of objects and its references for Deleted: object
each security device instantiated by each client application separately. Closing a client application, in case
of multi-tasking environments, shall release all the references related to that client application.
NOTE In case of a simple system architecture with only one client application and one security device, the life
cycle of all instantiated objects is terminated at the latest by ending the session.
Deleted: with
Deleted: of
7 Services of the proxy
7.1 Security device management
7.1.1 Identification of security device
One of the main functions of the proxy is to manage and administrate the security devices within the
Deleted: function
system.
In a system with fixed installed security devices a proxy may get the information by install parameters
offered by the system directly or by additional APIs (e.g. OMAPI) from an underlaying operation system
(e.g. Realtime OS, mobile phone operating systems) conveying the relevant information.
The ISO/IEC 7816 series defines the ATR as a first identification means for an ICC or the EF.ATR to Deleted: with provides
provide additional information. Since a security device in a running system may be not reset (e.g. in a
mobile device) not all information is available in all cases. ISO/IEC 7812 defines additional identification
means, e.g. issuer identification number, which can be used for identification of a security device. All this
Deleted: could
information may be used in closed systems.
ISO/IEC 23465-2 defines a set of information collected in a table of security device attributes which
Deleted: Part 2 of this series of standard
describes the ability and content of the security device in a flexible and detailed way. This information
shall be used internally by the proxy and delivered to the external world/client applications via the API
call. Any security device should store a describing data object which offers the required information. This
identification means has to be initialized and personalized by the provider of the system. The following
requirements should be considered:
— The proxy stores the security device attribute persistently for each controlled security device.
— Each security device stores the DO “security device attribute” and the proxy initiates the retrieval of
the information autonomous
...
FINAL
TECHNICAL ISO/IEC DTS
DRAFT
SPECIFICATION 23465-3
ISO/IEC JTC 1/SC 17
Card and security devices for personal
Secretariat: BSI
identification — Programming
Voting begins on:
2023-01-25 interface for security devices —
Voting terminates on:
Part 3:
2023-03-22
Proxy
Cartes et dispositifs de sécurité pour l’identification personnelle —
L'interface du logiciel pour dispositifs de sécurité —
Partie 3: Proxy
RECIPIENTS OF THIS DRAFT ARE INVITED TO
SUBMIT, WITH THEIR COMMENTS, NOTIFICATION
OF ANY RELEVANT PATENT RIGHTS OF WHICH
THEY ARE AWARE AND TO PROVIDE SUPPOR TING
DOCUMENTATION.
IN ADDITION TO THEIR EVALUATION AS
Reference number
BEING ACCEPTABLE FOR INDUSTRIAL, TECHNO-
ISO/IEC DTS 23465-3:2023(E)
LOGICAL, COMMERCIAL AND USER PURPOSES,
DRAFT INTERNATIONAL STANDARDS MAY ON
OCCASION HAVE TO BE CONSIDERED IN THE
LIGHT OF THEIR POTENTIAL TO BECOME STAN-
DARDS TO WHICH REFERENCE MAY BE MADE IN
NATIONAL REGULATIONS. © ISO/IEC TS 2023
---------------------- Page: 1 ----------------------
ISO/IEC DTS 23465-3:2023(E)
FINAL
TECHNICAL ISO/IEC DTS
DRAFT
SPECIFICATION 23465-3
ISO/IEC JTC 1/SC 17
Card and security devices for personal
Secretariat: BSI
identification — Programming
Voting begins on:
interface for security devices —
Voting terminates on:
Part 3:
Proxy
Cartes et dispositifs de sécurité pour l’identification personnelle —
L'interface du logiciel pour dispositifs de sécurité —
Partie 3: Proxy
COPYRIGHT PROTECTED DOCUMENT
© ISO/IEC 2023
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.
RECIPIENTS OF THIS DRAFT ARE INVITED TO
ISO copyright office
SUBMIT, WITH THEIR COMMENTS, NOTIFICATION
OF ANY RELEVANT PATENT RIGHTS OF WHICH
CP 401 • Ch. de Blandonnet 8
THEY ARE AWARE AND TO PROVIDE SUPPOR TING
CH-1214 Vernier, Geneva
DOCUMENTATION.
Phone: +41 22 749 01 11
IN ADDITION TO THEIR EVALUATION AS
Reference number
Email: copyright@iso.org
BEING ACCEPTABLE FOR INDUSTRIAL, TECHNO-
ISO/IEC DTS 23465-3:2023(E)
Website: www.iso.org
LOGICAL, COMMERCIAL AND USER PURPOSES,
DRAFT INTERNATIONAL STANDARDS MAY ON
Published in Switzerland
OCCASION HAVE TO BE CONSIDERED IN THE
LIGHT OF THEIR POTENTIAL TO BECOME STAN-
DARDS TO WHICH REFERENCE MAY BE MADE IN
ii
© ISO/IEC 2023 – All rights reserved
NATIONAL REGULATIONS. © ISO/IEC 2023
---------------------- Page: 2 ----------------------
ISO/IEC DTS 23465-3:2023(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 Proxy related requirements .2
5.1 Link between client application and security device . 2
5.2 Proxy layers . . 3
5.2.1 Proxy layer model . 3
5.2.2 Resolution layer of ISO/IEC 23465-API calls . 3
5.2.3 Layer representing/resolving class model . 4
5.2.4 Administration layer for security devices . 4
5.2.5 Security related layer . 4
5.2.6 Translation layer . . 4
5.2.7 Exception handler . 5
5.2.8 Connectivity related layer . 5
5.3 Conditional proxy functionality . 5
5.3.1 Multitasking/Multiplexing . 5
5.3.2 Crypto functionality. 5
5.3.3 Discovery functionality . 6
5.3.4 Registration functionality . 6
6 Instantiation of class objects . 6
6.1 Class model . 6
6.2 Process of instantiation . 7
6.3 Life cycle of an instance . 8
7 Services of the proxy . 8
7.1 Security device management. 8
7.1.1 Identification of security device . 8
7.1.2 Retrieval of security device information . . 9
7.1.3 Security device related functionality . 9
7.2 Security related layer . 10
7.2.1 General . 10
7.2.2 Security conditions and fulfilment . 10
7.2.3 Interpretation of ISO/IEC 7816-4 security conditions . 11
7.2.4 Security attributes for complex multistep authentication .12
7.2.5 Security attribute “user verification” .12
7.2.6 Security attribute “authentication” .12
7.2.7 Security attribute “secure messaging” (SM) .12
7.2.8 Implicit fulfilment of security conditions .13
7.3 Connectivity layer. 13
7.4 Multi-client/multi-security device support . 13
7.4.1 Task management . 13
7.4.2 Management of security devices . 13
8 Life cycle model of the proxy.14
8.1 Start-up phase . 14
8.2 Initialization and administration . 14
Annex A (informative) Example of client API call processing with proxy functionality .15
Bibliography .19
iii
© ISO/IEC 2023 – All rights reserved
---------------------- Page: 3 ----------------------
ISO/IEC DTS 23465-3:2023(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 https://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.
A list of all parts in the ISO/IEC 23465 series can be found on the ISO and IEC websites.
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
© ISO/IEC 2023 – All rights reserved
---------------------- Page: 4 ----------------------
ISO/IEC DTS 23465-3:2023(E)
Introduction
Integrated circuit card (ICC) technologies and solutions are widely deployed around the world, but
systems for identity tokens and credentials are quickly changing. In this context, the application
protocol data unit (APDU) protocol outlined in the ISO/IEC 7816 series is becoming, in some cases,
a hindrance to the integration of integrated circuits (ICs) in environments such as mobile phones,
handheld devices, connected devices (e.g. M2M, IoT) or other application using security devices.
Several stakeholders are not familiar with, or not very fond of APDU protocol because of its complexity.
They will often circumvent its constraints by requesting an abstraction layer hiding IC specifics.
However, even solutions based on those kinds of middleware are perceived as cumbersome in some
systems. The market looks for a middleware memory footprint to be as low as possible. This document
aims to overcome or mitigate those issues by proposing a new approach that would preserve ICC
functionality and allow for a seamless ICC portability onto new systems.
The ISO/IEC 23465 series focuses on a solution by designing an application programming interface
(API) and a system with these characteristics:
— It offers a subset, from the ISO/IEC 7816 series, of mostly used multi-sectorial ICC functions.
— It results in no further middleware or very little middleware memory footprint (i.e. simplified
drivers).
— It requires a simplified ICC capability discoverability (i.e. with significantly less complexity than
[3]
ISO/IEC 24727-1).
The ISO/IEC 23465 series is comprised of three parts, each focusing on a specific topic:
1)
— ISO/IEC 23465-1 : provides an introduction to the series and a short overview of the architecture;
2)
— ISO/IEC TS 23465-2 : defines the API for client applications allowing incorporation and usage of
security devices;
— ISO/IEC TS 23465-3 (this document): describes the software (SW) called "proxy" which provides
different services, e.g. to convert the API calls into serialized messages to be sent to the security
device.
The ISO/IEC 23465 series is intended to be used by any sector relying on the interchange defined, but
not limited to, the ISO/IEC 7816 series.
1) Under preparation. Stage at the time of publication: ISO/IEC PRF 23465-1.
2) Under preparation. Stage at the time of publication: ISO/IEC PRF TS 23465-2.
v
© ISO/IEC 2023 – All rights reserved
---------------------- Page: 5 ----------------------
TECHNICAL SPECIFICATION ISO/IEC DTS 23465-3:2023(E)
Card and security devices for personal identification —
Programming interface for security devices —
Part 3:
Proxy
1 Scope
This document describes the software (SW) layer called “proxy”. It supports the programming interface
to security devices and the application using this API to access the application related security devices
defined in ISO/IEC TS 23465-2.
This document is applicable to:
— proxy requirements, functionality and layers;
— resolving mechanisms for API functions;
— data structures related to security device handling;
— translation for security device communication;
— serialization/de-serialization syntax and methods.
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 23465-1, Card and security devices for personal identification — Programming interface for
security devices — Part 1: Introduction and architecture description
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO/IEC 23465-1 and the
following apply.
ISO and IEC maintain terminology databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https:// www .iso .org/ obp
— IEC Electropedia: available at https:// www .electropedia .org/
3.1
access rule
data element containing an access mode referring to an action and security conditions to be fulfilled
before acting
3.2
client application
implemented application using the ISO/IEC 23465-API requesting services from a security device
1
© ISO/IEC 2023 – All rights reserved
---------------------- Page: 6 ----------------------
ISO/IEC DTS 23465-3:2023(E)
3.3
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.1)
4 Symbols and abbreviated terms
APDU application protocol data unit
API application programming interface
ATR answer to reset
CBOR consise binary object representation
DO data object
ICC integrated circuit card
JSON JavaScript open notation
MSE manage security environment
OMAPI open mobile API
OSI open systems interconnection
PACE password authenticated connection establishment
SM secure messaging
SW software
SD security device, see terms and definitions
5 Proxy related requirements
5.1 Link between client application and security device
The proxy is the piece of software (SW) between the programming interface used by a client application
dealing with security devices and the related security device(s). The functionality of the proxy and its
APIs deal with communication, connectivity, provisioning of confidentiality and authenticity of the
connection to the security device and its security device applications.
The general concept of client applications dealing with a set of security device is outlined in
ISO/IEC 23465-1 and is depicted in Figure 1 (see also ISO/IEC 23465-1:20—, Figure. 2). The applications
or clients use abstractions of access methods to the security devices, which are outlined as the
ISO/IEC 23465-API in ISO/IEC TS 23465-2. Details of low-level security device addressing and accessing
methods are kept hidden to these clients. The translation of the abstract API-functions into low-level
commands and protocols shall be performed by the proxy, possibly supported by additional libraries
and internal APIs.
The clients only have access to the physical security devices by the proxy which acts as a dispatcher for
the direct access to the security devices and the related security device pplications. In some use cases
the proxy may handle as a multiplexer, especially in multitasking environments with parallel running
clients.
2
© ISO/IEC 2023 – All rights reserved
---------------------- Page: 7 ----------------------
ISO/IEC DTS 23465-3:2023(E)
Figure 1 — Components of the system with distributing proxy
5.2 Proxy layers
5.2.1 Proxy layer model
Figure 2 depicts the layers and components of the proxy to perform the client application requests by the
defined API. The proxy as a SW component requires some additional SW parts in a real implementation.
These are not outlined here, but are mentioned separately.
Figure 2 — Components of a proxy
5.2.2 Resolution layer of ISO/IEC 23465-API calls
Any API call needs a piece of programming code, called glue code, which has no functional relevance
but is essentially to adhere to the different code parts. Any real implementation resolves, with this
additional glue SW, the requirements of the applied programming language.
When several client applications are allowed to act in parallel, this layer shall be able to handle several
tasks independently.
3
© ISO/IEC 2023 – All rights reserved
---------------------- Page: 8 ----------------------
ISO/IEC DTS 23465-3:2023(E)
5.2.3 Layer representing/resolving class model
The class model, outlined in ISO/IEC TS 23465-2, represents the view of the client and part of the proxy
to the object-oriented definition of a security device and its components. The client uses the references
and methods of the classes provided by the instantiated objects. The instantiation of the objects is
done in this layer. The proxy provides the object references to the client, administrates the objects
in accordance to the resources of the systems, e.g. the available or addressed security devices and its
related data.
5.2.4 Administration layer for security devices
All relevant data of the administrated and addressable security devices are handled in this layer. The
layer tallies the security devices, identifies the access methods, administrates the security device
individually and stores all relevant information of the available security devices.
Means for such administration is an internal registry holding all the information of available security
devices. In case of removable security devices, this layer shall register when mounting and de-
register when detaching the security devices. The registry entries for such devices has to be updated
accordingly.
NOTE The entries of such a registry are used to inform the client about the details of the requested security
devices.
5.2.5 Security related layer
This layer provides the means to perform all the security mechanisms related to the security devices.
Any security device supports or requires security features, directly or indirectly. Depending on the
security attributes of the security device application, these security-related activities have to be
provided or performed, sometimes in cooperation with the client application, sometimes hidden to the
client application. In the latter case the security activities shall be performed by this proxy layer.
Relevant information of fulfilled security features shall be stored, in case this information is required
for further security device access.
A security device requires sometimes an authentication procedure according to external specifications,
to set-up a secure channel, which are be completely hidden to the client application. In this case a
session management has to be considered in the security related layer.
5.2.6 Translation layer
The most important abstraction of the access methods to security devices is the concealment of the
direct communication, offered by the API. As outlined in ISO/IEC 23465-1, the evolution of security
device technologies can require different protocols and data formats than those currently being used.
The conversion into protocols understood by the used security device shall be done in this layer.
The translation layer provides the means to perform the translation of the client application’s initiated
activity into security device related protocols and formats. An abstract API call from the client
application finally results in at least one command understood by the addressed security device.
In contrast, responses of the security device after processing of the command(s) are returned in the
format of the used security device protocol. This layer re-translates the replied data into the formats
defined by the API which are finally expected and understood by the client application.
The translation process is understood as a serialisation/marshalling and de-serialisation/unmarshalling
technique, which is well-known in SW technology and used by many computer languages.
NOTE The actual protocol dealing with security devices based on ICC technology uses APDU, defined by
ISO/IEC 7816-4. Upcoming application specifications use, e.g. CBOR, JSON or other coded protocols which can be
relevant in the future.
4
© ISO/IEC 2023 – All rights reserved
---------------------- Page: 9 ----------------------
ISO/IEC DTS 23465-3:2023(E)
5.2.7 Exception handler
Most of the API functions defined in ISO/IEC TS 23465-2 expect exception messages. Dedicated return
values of the security devices, e.g. defined in ISO/IEC 7816-4, shall be translated by the translation
layer. In case of errors or unforeseeable situations, the program flow is interrupted by throwing an
exception This is managed by this exception layer.
The service can be used in conjunction with the translation layer since a response of a security device
can require exception handling.
5.2.8 Connectivity related layer
The physical connection of the security device in the system has to be used by the proxy. Depending
on the runtime environment of the used system, security device/reader-related device drivers or
middlewares are available. This layer uses existing APIs which may be manufacturer dependent and
requires a system related implementation. Some systems offer standardized APIs which can facilitate
[6]
the interaction between proxy and security devices, e.g. the Global Platform Open Mobile API .
5.3 Conditional proxy functionality
5.3.1 Multitasking/Multiplexing
ISO/IEC 23465-1 outlined different runtime environments in which client applications can use the
ISO/IEC 23465-API. The behaviour of a proxy varies from either supporting only one security device by
one client, or one client with access to several security devices (in a single task), or several clients with
access to several security devices in parallel in a multitasking runtime environment.
According to the needs of the latter situation, the proxy shall be designed as a SW running in a
multitasking environment. When several clients interact with one security device simultaneously, the
proxy shall obey the ability of the security device. An existing solution for such simultaneous access on
a single security device is possible today when logical channels are supported. The approach of multiple
logical interfaces in addition to logical channels also allows the parallel processing of security device
applications in a single physical security device.
The security device’s behaviour shall be managed by the proxy. Logical channel or multiple logical
interface support can be part of a discovery mechanism of the proxy or a specific information in the
proxy’s registry of security devices.
5.3.2 Crypto functionality
Many API functions defined in ISO/IEC 23465-2 deal with crypto-functionality related to the security
device. Addressing means used by the client application and the internal management within the
security device usually differs. The knowledge about the behaviour, the needs of crypto protocols and
the translation into security device related formats is provided by this service.
The proposed API methods for crypto operations cover all algorithms and mechanisms which are
currently in common usage. Since the calculation is performed on the security device, the proxy shall
adopt and structure the data in a way that the addressed security device can use the data.
Some crypto API calls are separated into calls for initialization of the method followed by one or more
subsequent calls of the crypto API for processing. The sequene of APIs shall be controlled by the proxy.
Existing crypto protocols performed on security devices need additional commands to set-up a crypto-
functionality. ISO/IEC 7816-4 defines concepts and commands which are used to set-up the security
environment (MSE command) with essential information, expected by the security devices in advance.
These activities should be completely hidden to the client application. The application of such security
device related commands shall be performed by the proxy.
5
© ISO/IEC 2023 – All rights reserved
---------------------- Page: 10 ----------------------
ISO/IEC DTS 23465-3:2023(E)
5.3.3 Discovery functionality
ISO/IEC TS 23465-2 offers the API call isoIec23465_getSDList which provides the security device
attributes of the accessible security devices. This set of information shall be collected and distributed
by the proxy. The discovery service is responsible for the coll
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.