ISO/IEC TS 23465-2:2023 個人識別用のカードとセキュリティ デバイス — セキ​​ュリティ デバイス用のプログラミング インターフェイス — Part 2: API 定義 | ページ 2

※一部、英文及び仏文を自動翻訳した日本語訳を使用しています。

序文

ISO (国際標準化機構) と IEC (国際電気標準会議) は、世界標準化のための専門システムを形成しています。 ISO または IEC のメンバーである国家機関は、技術活動の特定の分野を扱うために、それぞれの組織によって設立された技術委員会を通じて、国際規格の開発に参加しています。 ISO と IEC の技術委員会は、相互に関心のある分野で協力しています。 ISO および IEC と連携して、政府および非政府の他の国際機関もこの作業に参加しています。

この文書の作成に使用された手順と、今後の維持のために意図された手順は、ISO/IEC 指令のPart 1 で説明されています。特に、さまざまな種類の文書に必要なさまざまな承認基準に注意する必要があります。この文書は、ISO/IEC 指令、 Part 2 の編集規則に従って作成されました ( www.iso.org/directives or www.iec.ch/members_experts/refdocs を参照)

このドキュメントの要素の一部が特許権の対象となる可能性があることに注意してください。 ISO および IEC は、そのような特許権の一部またはすべてを特定する責任を負わないものとします。ドキュメントの開発中に特定された特許権の詳細は、序論および/または受信した特許宣言の ISO リスト ( www.iso.org/patents を参照) または受信した特許宣言の IEC リスト ( https://patents.iec.ch )

このドキュメントで使用されている商号は、ユーザーの便宜のために提供された情報であり、保証を構成するものではありません。

規格の自主的な性質の説明、適合性評価に関連する ISO 固有の用語と表現の意味、および技術的貿易障壁 (TBT) における世界貿易機関 (WTO) の原則に対する ISO の遵守に関する情報については、 www を参照してください。 .iso.org/iso/foreword.html . IEC については、 www.iec.ch/understanding-standards を参照してください。

この文書は、合同技術委員会 ISO/IEC JTC 1, 情報技術、小委員会 SC 17, 個人識別用のカードおよびセキュリティ デバイスによって作成されました。

ISO/IEC 23465 シリーズのすべての部品のリストは、ISO および IEC の Web サイトにあります。

序章

統合チップ カード (ICC) テクノロジとソリューションは世界中で広く展開されていますが、ID トークンと資格情報のシステムは急速に変化しています。これに関連して、ISO/IEC 7816 シリーズで概説されているアプリケーション プロトコル データ ユニット (APDU) プロトコルは、場合によっては、携帯電話、ハンドヘルド デバイス、コネクテッド デバイス (M2M, IoT ) またはセキュリティ デバイスを使用するその他のアプリケーション。

さらに、一部の利害関係者は、その複雑さのために APDU プロトコルに慣れていないか、あまり好きではありません。彼らは、データ構造やセキュリティ ポリシーの複雑さなどの IC の詳細を隠す抽象化レイヤーを要求することで、その制約を回避します。

ソフトウェア開発でこの目標を達成するための一般的な方法は、デバイス内の IC にアクセスするためのアプリケーション プログラミング インターフェイス (API) 機能の定義と適用です。 ADPU プロトコルと IC 実装の詳細に関する特定の知識は、もはや必要ありません。また、セキュリティ モデルとセキュリティ ポリシーの実装の複雑さと詳細は、純粋なアプリケーション開発から ID 管理全体のシステム設計に移行できます。

ただし、この種のミドルウェアに基づくソリューションでさえ、一部のシステムでは扱いにくいと認識されています。市場は、ミドルウェアのメモリ フットプリントが可能な限り小さく、そのようなシステムの受け入れ、使用、および保守がより簡単になることを求めています。

このドキュメントは、ICC 機​​能を保持し、新しいシステムへのシームレスな ICC 移植性を可能にする新しいアプローチを提案することによって、これらの問題を克服または軽減することを目的としています。

ISO/IEC 23465 シリーズは、次の特性を持つ API とシステムを設計することによるソリューションに焦点を当てています。

  • 他の ICC 関連規格の ISO/IEC 7816 シリーズから派生した、マルチセクター ICC 機​​能に関連する一連の API 呼び出しを提供します。
  • これは、API 関数から「プロキシ」と呼ばれるセキュリティ デバイスのインターフェイス (APDU インターフェイスなど) への変換を実行するサブシステムを定義します。
  • これにより、ミドルウェアがない、またはミドルウェアのメモリ フットプリントが非常に少ない (つまり、単純化されたドライバー) ソリューションの説明が得られます。
  • これは、簡素化された ICC 機​​能、発見可能性の説明 (つまり、ISO/IEC 24727 よりも大幅に複雑でない) を定義し、使用例を提供します。

現在のモデルは静的であり、将来の改訂ではライブ サイクル機能が追加される予定です。

1 スコープ

このドキュメントでは、ISO/IEC 23465-1 で概説されているフレームワークに基づいて、セキュリティ デバイスとプロキシを扱うクライアント アプリケーション間のプログラミング インターフェイスの次の側面について説明します。

  • 汎用 API 定義。
  • ユース ケースの状態およびセキュリティ モデル。
  • ISO/IEC 7816 シリーズなど、他の標準で定義されている機能のクラスおよび API 定義。

2 参考文献

以下のドキュメントは、その内容の一部またはすべてがこのドキュメントの要件を構成するように、本文で参照されています。日付のある参考文献については、引用された版のみが適用されます。日付のない参照については、参照文書の最新版 (修正を含む) が適用されます。

  • ISO/IEC 23465-1:2023, 個人識別用のカードおよびセキュリティ デバイス — セキ​​ュリティ デバイスのプログラミング インターフェイス — Part 1: 概要とアーキテクチャの説明

3 用語と定義

このドキュメントの目的のために、ISO/IEC 23465-1 および以下に記載されている用語と定義が適用されます。

ISO および IEC は、次のアドレスで標準化に使用する用語データベースを維持しています。

3.1

配列

メンバー数が既知の任意のデータ型のインデックス付きリスト

3.2

ブール値

TRUE と FALSE のいずれかの値のみを取ることができるデータ項目を示すために使用されるデータ型

3.3

チャー

0 から 255 までの数値を持つ任意のバイト指向コード セットから 1 バイト文字をエンコードする 8 ビット量を含むデータ型

3.4

資格

主張または主張された身元および/または資格の証拠として提示される一連のデータ

例:

真正性の証明として発行者によって署名されたユーザー属性 (ISO/IEC 19286 を参照) は、サービス プロバイダーが電子署名を検証することによって検証できる資格情報です。

[SOURCE:ISO/IEC 29115:2013, 3.8, modified — エントリの注 1 が削除されました。実施例を追加しました。 ]

3.5

整数

基数から取得した一連の数字を含むデータ型

注記 1:プログラミング言語は、整数値をさまざまなフレーバーのデータ型としてサポートします。たとえば、符号付き整数または符号なし整数、および短形式または長形式の形式です。プログラミング言語にとらわれないようにするために、このドキュメントではこれらの異なる定義を指定せず、さまざまな型に一般的な整数型を使用しています。このアプローチは、使用されるインターフェイス記述言語 (IDL) とは異なります。 [ 6] 関数の必要性と使用するプログラミング言語に従って、関連する API 関数呼び出しで整数型を定義するのは、アプリケーション プログラマの責任です。

例:

0, 1, 2, 3, 4, 5, 6, 7, 8, 9 で構成される基数 10 (10 進数) の数字。

3.6

オクテット

8 ビット量のデータ型

3.7

一定の長さの一連の文字を含むデータ型

参考文献

1Global Platform Technology, Open Mobile API 仕様、バージョン 3.3, 2018 年 7 月
2ISO/IEC 781, 識別カード — 集積回路カード
3https://www.oracle.com/technetwork/java/javase/documentation/codeconventions-135099.html
4Google命名規則.docx: https://google.github.io/styleguide/javaguide.html
5PKCS #11 暗号トークン インターフェイス、基本仕様バージョン 2.40, OASIS 標準、2015 年 4 月 14 日
6オブジェクト管理グループ、OMG インターフェイス定義言語、バージョン 4.2, 2018 年 1 月 5 日、 2
7BSI TR-03110,テクニカル ガイドライン Advanced Security Mechanisms for Machine Readable Travel Documents and eIDAS Token – Part 2: Protocols for electronic IDentification, Authentication and Trust Service, バージョン 2.21, 2016 年 12 月 21 日
8グローバル プラットフォーム テクノロジー、カード仕様、バージョン 2.3.1, 2018 年 3 月
9ISO/IEC/IEEE 24765:2017, システムおよびソフトウェア工学 - 語彙
10ISO/IEC 29115:2013, 情報技術 - セキュリティ技術 - エンティティ認証保証フレームワーク
11ISO/IEC 19286, ID カード — 集積回路カード — プライバシー強化プロトコルおよびサービス
12GlobalPlatform Technology, TEE システム アーキテクチャ、バージョン 1.2, 2018 年 11 月、1.4, セキュア エレメント (SE)
13ISO 12812-1:2017, コア バンキング — モバイル金融サービス — Part 1: 一般的な枠組み
14ISO/IEC TS 23465-3, 個人識別用のカードおよびセキュリティ デバイス — セキ​​ュリティ デバイスのプログラミング インターフェイス — Part 3: プロキシ3

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.

Introduction

Integrated chip card (ICC) technologies and solutions are widely deployed around the world, but the system for identity tokens and credentials is 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 ICs in environments such as mobile phones, handheld devices, connected devices (e.g. M2M, IoT) or other applications using security devices.

In addition, several stakeholders are not familiar with, or not very fond of the APDU protocol because of its complexity. They would circumvent its constraints by requesting an abstraction layer hiding IC specifics such as data structures and complexity of the security policies.

A common way to reach this goal in the software development is the definition and application of application programming interface (API) functions to access the IC within the devices. Specific knowledge of ADPU 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 the pure application development into the system design of the whole ID management.

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 and the acceptance, usage and maintenance of such a system can be simpler.

This document aims to overcome or mitigate those issues by proposing a new approach that preserves ICC functionality and allows a seamless ICC portability onto new systems.

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 of 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 simplified ICC capabilities, description of the discoverability (i.e. with significantly less complexity than ISO/IEC 24727) and provides examples of usages.

The present model is static and future revisions are expected to add live cycle functionality.

1 Scope

This document describes the following aspects of the programming interface between the client application dealing with the security device and the proxy, based on the framework outlined in ISO/IEC 23465-1:

  • the generic API definition;
  • state and security models for use cases;
  • class and API definitions of functionality, defined in other standards, e.g. the ISO/IEC 7816 series.

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:2023, 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:

3.1

array

indexed list of any data types with a well-known number of members

3.2

boolean

data type used to denote a data item that can only take one of the values TRUE and FALSE

3.3

char

data type containing an 8-bit quantity that encodes a single-byte character from any byte-oriented code set with a numerical value between 0 and 255

3.4

credential

set of data presented as evidence of a claimed or asserted identity and/or entitlements

EXAMPLE:

A user attribute (see ISO/IEC 19286) signed by the issuer as proof of authenticity is a credential that can be verified by the service provider by validating the electronic signature.

[SOURCE:ISO/IEC 29115:2013, 3.8, modified — Note 1 to entry was deleted. An EXAMPLE was added.]

3.5

integer

data type containing a sequence of digits taken from a number base

Note 1 to entry: Programming languages support integer values as a data type in different flavours, e.g. as signed integer or unsigned integer and in short or long format. To be programming language agnostic this document does not specify any of these different definitions and uses the general type integer for different types. This approach is different to the used interface description language (IDL).[6] It is the responsibility of the application programmer to define the type of integer in a relevant API function call according to the need of the function and the programming language used.

EXAMPLE:

Digits from the number base 10 (decimal) consisting of 0, 1, 2, 3, 4, 5, 6, 7, 8, 9.

3.6

octet

data type with 8-bit quantity

3.7

string

data type containing a sequence of characters with a definite length

Bibliography

1GlobalPlatform Technology, Open Mobile API Specification, Version 3.3, July 2018
2ISO/IEC 7816 (all parts), Identification cards — Integrated circuit cards
3https://www.oracle.com/technetwork/java/javase/documentation/codeconventions-135099.html
4Google Naming convention.docx: https://google.github.io/styleguide/javaguide.html
5PKCS #11 Cryptographic Token Interface, Base Specification Version 2.40, OASIS Standard, 14 April 2015
6Object Management Group, OMG Interface Definition Language, Version 4.2, 05 January 2018, 2
7BSI TR-03110 Technical Guideline Advanced Security Mechanisms for Machine Readable Travel Documents and eIDAS Token – Part 2: Protocols for electronic IDentification, Authentication and trust Services (eIDAS), Version 2.21, 21. December 2016
8GlobalPlatform Technology, Card Specification, Version 2.3.1, March 2018
9ISO/IEC/IEEE 24765:2017, Systems and software engineering — Vocabulary
10ISO/IEC 29115:2013, Information technology — Security techniques — Entity authentication assurance framework
11ISO/IEC 19286, Identification cards — Integrated circuit cards — Privacy-enhancing protocols and services
12GlobalPlatform Technology, TEE System Architecture, Version 1.2, November 2018, 1.4, Secure Element (SE)
13ISO 12812-1:2017, Core banking — Mobile financial services — Part 1: General framework
14ISO/IEC TS 23465-3, Card and security devices for personal identification — Programming interface for security devices — Part 3: Proxy3