ISO/IEC 23465-1:2023

Card and security devices for personal identification — Programming interface for security devices — Part 1: Introduction and architecture description

This document introduces and describes the concept of the application programming interface (API) to security devices with the intention to simplify the usage of commands and mechanisms defined by the ISO/IEC 7816 series. This document gives guidelines on: — the system overview and description of the system of the programming interface; — the architecture description; — the data model in general, used by the API; — the use cases and the usage model of the API.

Cartes et dispositifs de sécurité pour l’identification personnelle — Interface de programmation pour dispositifs de sécurité — Partie 1: Introduction et description de l’architecture

General Information

• Status: Published
• Publication Date: 14-Feb-2023
• ICS: 35.240.15 - Identification cards. Chip cards. Biometrics
• Technical Committee: ISO/IEC JTC 1/SC 17 - Cards and security devices for personal identification
• Drafting Committee: ISO/IEC JTC 1/SC 17/WG 4 - Generic interfaces and protocols for security devices
• Current Stage: 6060 - International Standard published
• Start Date: 15-Feb-2023
• Due Date: 26-Feb-2023
• Completion Date: 15-Feb-2023

Standards Content (Sample)

INTERNATIONAL ISO/IEC
STANDARD 23465-1
First edition
2023-02
Card and security devices for personal
identification — Programming
interface for security devices —
Part 1:
Introduction and architecture
description
Cartes et dispositifs de sécurité pour l’identification personnelle —
Interface de programmation pour dispositifs de sécurité —
Partie 1: Introduction et description de l’architecture
Reference number
ISO/IEC 23465-1:2023(E)
© ISO/IEC 2023

---------------------- Page: 1 ----------------------
ISO/IEC 23465-1: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: [phone]
Email: [e-mail]
Website: www.iso.org
Published in Switzerland
ii
  © ISO/IEC 2023 – All rights reserved

---------------------- Page: 2 ----------------------
ISO/IEC 23465-1: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  System overview . 3
5.1 Conditions of use. 3
5.2 Simple system configuration . 4
5.3 Complex system configuration . 4
5.4 Generic examples using the different configurations . . 5
5.4.1 SoC — Example of simple system configuration . 5
5.4.2 ID-systems . 5
5.4.3 Mobile devices with multiple security devices . 6
5.4.4 Mobile devices with a single security device . 7
5.4.5 Use cases . 8
6  Architecture model .8
6.1 Components . 8
6.1.1 Client application . 8
6.1.2 Proxy . 8
6.1.3 Security device . 8
6.2 System using the API . 8
6.3 Data model of client application . 9
6.4 Data management . 10
6.5 Security architecture. 11
7  API .12
7.1 General .12
7.2 Requirements for a programming interface .12
7.3 API Implementation . 12
8  Proxy .12
8.1 General .12
8.2 Proxy characteristics .13
9 Evolution of security device types .13
Annex A (informative) Design rules .14
Annex B (informative) Use cases .15
Annex C (informative) Variants of security device interfaces .20
Annex D (informative) Usage and co-existence of additional APIs .21
Bibliography .22
iii
© ISO/IEC 2023 – All rights reserved

---------------------- Page: 3 ----------------------
ISO/IEC 23465-1: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 23465-1: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 defined in the ISO/IEC 7816 series is becoming, in some cases, a
hindrance to the integration of integrated circuits (ICs) (as security devices) in environments such as
mobile phones, handheld devices, connected devices (e.g. M2M, IoT) or other applications using security
devices.
Several stakeholders are not familiar with, or not very fond of the APDU protocol because of its
complexity. They will often circumvent its constraints by requesting an abstraction layer hiding IC
specifics. Although the security mechanisms of security devices are well defined in ISO/IEC 7816-4
their implementation and application differ from vendor to vendor and the complexity overstrains most
of the application developers.
In software development, a common way to simplify the usage of complex systems is the definition and
application of application programming interface (API) functions to access the IC within the devices.
Specific knowledge of APDU protocols and details of the IC implementation is not necessary anymore.
Also, the complexity and details of the implementation of the security model and the security policy can
be shifted from pure application development into system design of the electronic device and its related
software.
Therefore, this document is geared towards software (SW)-architects, application programmers or
specification developers developing software applications using and addressing ICs as security devices
within operating systems or their components.
The projected applications can run on different software and hardware environments. Generalisation
of the API definition is key and the dependencies on specific runtime environments and equipment are
kept out in principle.
Existing runtime environments already support the access to IC as security devices using different
[10] [12]
specific APIs, e.g. OpenMobileAPI, PKCS#11, but they always implement a proprietary interface
and middleware, which is not commonly applicable. 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 also aims to overcome or mitigate those
issues by proposing a new approach that would preserve ICC functionality and allows for a seamless
ICC portability onto new systems.
Since the system is designed for easy support by mobile operation systems, mobile operating system
(OS) designers/ implementers are encouraged to support these standardized APIs to access any
embedded secure element (eSE) within the mobile device.
In the context of mobile devices, there is a necessity for trusted computing, e.g. by dedicated security
hardware. The proposed API helps the application implementer with a standardized common interface
to such trusted IC.
The ISO/IEC 23465 series focuses on a solution by designing an API and a system with the following
characteristics.
— It offers a set of API calls related to multi-sectorial ICC functionality, derived from the ISO/IEC 7816
series and other ICC related standards.
— It defines the sub-system to perform the conversion from the API function to the interface of the
security device (e.g. APDU-interface), called Proxy.
— It results in a description of solutions with no middleware or very little middleware memory
footprint (i.e. simplified drivers).
— It defines the simplified ICC capabilities, the discoverability (i.e. with significantly less complexity
than ISO/IEC 24727) and examples of usages.
v
© ISO/IEC 2023 – All rights reserved

---------------------- Page: 5 ----------------------
ISO/IEC 23465-1:2023(E)
The ISO/IEC 23465 series is comprised of three parts each focusing on a specific topic:
— ISO/IEC 23465-1 (this document): 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;
1)
— ISO/IEC TS 23465-3 : describes the software called Proxy which provides different services e.g. to
convert the API calls into serialized messages to be sent to the security device.
1) Under preparation. Stage at the time of publication: ISO/IEC DTS 23465-3.
vi
  © ISO/IEC 2023 – All rights reserved

---------------------- Page: 6 ----------------------
INTERNATIONAL STANDARD ISO/IEC 23465-1:2023(E)
Card and security devices for personal identification —
Programming interface for security devices —
Part 1:
Introduction and architecture description
1 Scope
This document introduces and describes the concept of the application programming interface (API) to
security devices with the intention to simplify the usage of commands and mechanisms defined by the
ISO/IEC 7816 series.
This document gives guidelines on:
— the system overview and description of the system of the programming interface;
— the architecture description;
— the data model in general, used by the API;
— the use cases and the usage model of the API.
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
— IEC Electropedia: available at https:// www .electropedia .org/
3.1
client
any type of entity requesting services from a security device (3.7)
3.2
ISO/IEC 23465 API
software interface defined in ISO/IEC TS 23465-2
3.3
middleware
software (SW) component allowing two systems from different or similar operating systems
interconnection (OSI) layers to communicate with each other
3.4
operating systems interconnection model
OSI model
conceptual model that characterizes and standardizes the communication functions of a network or
computing system without regard to its underlying internal structure and technology
1
© ISO/IEC 2023 – All rights reserved

---------------------- Page: 7 ----------------------
ISO/IEC 23465-1:2023(E)
3.5
secure digital memory card
SD-card
secure storage media using non-volatile memory
3.6
proxy
sub-system to perform conversion from the application programming interface (API) function to the
interface of the security device (3.7)
3.7
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
Note 1 to entry: It may exist in any form factor, e.g. embedded or integrated SE, SIM/UICC, smart card, SD-card.
3.8
serialization
translation of data structures or object state into an octet string for transmitting or storing
3.9
trusted execution environment
TEE
aspect of the mobile device comprising hardware and/or software which provides security services to
the mobile device computing environment, protects data against general software attacks and isolates
hardware and software security resources from the operating system
[SOURCE: ISO 12812-1:2017, 3.60]
3.10
use case
list of actions or event steps typically defining the interactions between a role 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
BLE bluetooth low energy
CBOR concise binary object representation
DF dedicated files
eSE embedded secure element
eSIM embedded subscriber identity module
IC integrated circuit
ICC integrated circuit card
IDL interface description language
iSIM integrated subscriber identity module
2
I C inter-integrated circuit
JSON java script object notation
NFC near field communication
PCB printed circuit board
2
  © ISO/IEC 2023 – All rights reserved

---------------------- Page: 8 ----------------------
ISO/IEC 23465-1:2023(E)
PC/SC personal computer/smart card
OSI open systems interconnection
OTA over the air
SD secure digital (memory card)
SE secure element
SIM subscriber identity module
SoC system on chip
SPI serial peripheral interface
SW software
TEE trusted execution environment
UICC universal integrated circuit card
USB universal serial bus
WIFI wireless communication technology, defined by the Wifi consortium
5  System overview
5.1 Conditions of use
The utilisation of an API for security devices defined in the ISO/IEC 23465 series of standards is useful
in any client application software which needs services of a security device. The application software
may run on any electronic devices, e.g. personal computers, terminals or mobile devices. The electronic
device contains or is connected to a security device and allows its access by client applications. It is
assumed that any software running on the electronic device is separated into several logical or
functional layers. Such layers may be designed as a middleware between the client application software
and the related security device or may be provided by the device’s operating system. API is herein
defined as generalised function calls from the client application software to the additional layers in the
system.
The API allows the logical access to any available security device, independent from the physical
form factor, the technology, the used connectivity and the applied transmission protocol. It hides the
physical layer, the data link layer and the network layers of OSI model to the application. The API offers
standardized methods and functions to security device services and builds either an abstraction or a
subset of the underlying security device interface, e.g. the APDU interface defined by ISO/IEC 7816-4,
or both. In this way, the transport, session and presentation layers are also hidden from the client
application.
The API is a representation of the application layer to a security device. The application implementer
does not need further details to contact, address, select and use a connected security device. But the
set of the API functions still allows the application to work with the security device by retrieving all
relevant information, functionality and services.
Systems implementing this API facilitate the access to the security device. Dedicated function calls
and specific knowledge about the structure and architecture of the security device’s application is not
needed by the client application programmer. The API generalises function calls, offers less complexity
and reduces the need of knowledge about details of the security device.
The API functions are resolved within an additional software, which handles the access to security
devices. These additional software components are provided by the manufacturer of the electronic
device. Since the number of security devices in a system is not limited, the additional software
components have to be enabled to handle the different involved security devices.
Conversely, several client applications can use a single security device. It is possible for each client
application to use a different application inside the security device. Furthermore, applications inside a
security device are separated from each other from a security point of view.
3
© ISO/IEC 2023 – All rights reserved

---------------------- Page: 9 ----------------------
ISO/IEC 23465-1:2023(E)
5.2  Simple system configuration
The simplest possible configuration is outlined Figure 1. This kind of system consists (possibly among
other components) of just one software environment running any application and incorporates the
security device. Such configuration is, e.g. a SoC device proposed for mobile devices. In this case, the
mobile device environment contains the complete client application and the security device for which
the implementation is running on the same system and within the same runtime environment as the
client application itself.
API calls from the client application directly lead to function calls in the security device. The security
device implements the resolution of the API and handles the processing of the requested operation on
the security device. Thus, from a client application programmer's point of view, the API calls from the
client application just call the corresponding method implementation of the security device.
In this simple situation, there is neither any other layer in between nor is there any kind of message
serialization. The API calls and the resolution of the API calls are done in the common system. To
achieve this, the security device programmer normally provides a library to the system manufacturer
or application.
Figure 1 — Simple system configuration
5.3  Complex system configuration
Compared to the simple configuration in Figure 1, the API defined in the ISO/IEC 23465 series of
standards applies also to configurations where a system contains more than one client application
or more than one security device, as outlined in Figure 2. The API supports the possibility that more
than one security device is available. It contains methods to select a specific security device among the
available ones. This kind of selection requires another component, called Proxy, mediating between
client applications and security devices. The client application calls API methods which trigger the
Proxy and address the appropriate requested functionality in the selected security device.
4
  © ISO/IEC 2023 – All rights reserved

---------------------- Page: 10 ----------------------
ISO/IEC 23465-1:2023(E)
Figure 2 — Complex system configuration
Even in complex system client applications, security devices and the Proxy may run in the same runtime
environment. Typically, a security device is deployed as dedicated hardware. If so, client applications
and (part of) the Proxy on one hand runs in a runtime environment which differs from the security
device.
5.4  Generic examples using the different configurations
5.4.1  SoC — Example of simple system configuration
The simplest configuration of a system using security devices is a system running client applications and
security devices in the same runtime environment (see 5.3). A library within the runtime environment
is supposed to act as the Proxy between the client application and the security device. This library
performs the API call resolution and the security device access.
5.4.2  ID-systems
A slightly more complex system runs client applications and security devices in different runtime
environments with separated software layers. Examples are ID-systems in general (e.g. border control,
banking, health) typically holding a client application as a part of a host connected to a card reader.
Security devices in this configuration are ID-cards temporarily connected to the ID-system. To simplify
the development of such systems, it would be appropriate not only to standardize the interface between
the client applications and the Proxy, but also to standardize the communication between the Proxy
and the security devices.
Figure 3 depicts a generic simple system showing the conditions of usage with an client application
using the API defined in ISO/IEC TS 23465-2 within a single runtime environment. The Proxy can be
outlined as a library or as a module in a more complex reader operating system.
5
© ISO/IEC 2023 – All rights reserved

---------------------- Page: 11 ----------------------
ISO/IEC 23465-1:2023(E)
Figure 3 — ID-system with host and card reader
5.4.3  Mobile devices with multiple security devices
Figure 4 shows an example of a complex system configuration using different security devices within a
mobile device (e.g. mobile phones or tablet computers). The mobile app, downloaded from an app store,
requests, in the course of the client application, functionality from security devices by API function
calls. The software system beneath the mobile app, introduced as Proxy in the ISO/IEC 23465 series,
handles the function calls and transforms or serializes them into a data stream understandable by
the security devices. Depending on the implementation of the security devices, the function calls are
operated by the addressed security device and the results/responses are transferred and transformed
adequately to the calling mobile app. Within mobile devices, usually a fixed number of security devices
are permanently connected, e.g. USIM, ISIM, eSIM, eSE, which can be used by different mobile apps
loaded on the mobile phone.
The Proxy can use additional APIs to achieve the physical access to the security device, e.g. provided by
the mobile operating system. Applications running on personal computers or similar devices can use
additional existing SW drivers, e.g. PC/SC, which can facilitate the access. Security device form factors
of mobile devices beside SIMs are, e.g. soldered ICs on the PCB, connected USB-devices, SD-cards or
connected ID cards via card reader interfaces (NFC, BLE).
ISO/IEC 7816-4 defined APDUs or other representation of messages are transmitted by the lower level
transmission protocols determined by the technology used in the addressed security device. Examples
2
for this protocol types are, e.g. USB, I C, SPI or serial communication according to ISO/IEC 7816-3,
representing the physical layer in the OSI model.
The API hides all these security device details completely from the client applications. ISO/IEC TS 23465-3
gives examples on how a Proxy implements the different layers.
6
  © ISO/IEC 2023 – All rights reserved

---------------------- Page: 12 ----------------------
ISO/IEC 23465-1:2023(E)
Figure 4 — Mobile environment using security devices
5.4.4  Mobile devices with a single security device
If a mobile device contains just one security device, which is used by several mobile apps, then the
security device can be configured such that each mobile app uses a different application in the security
device. Furthermore, the security device can be configured such that its applications are physically
and logically separated from each other such that no interference occurs. The security device controls
access to the assets in its applications. The Proxy controls
...