この規格 プレビューページの目次
※一部、英文及び仏文を自動翻訳した日本語訳を使用しています。
序章
このドキュメントは、データ構造を指定するために使用される「言語」を指定します。 1 つまたは複数の AIDC からデータ構造を読み取る方法。また、そのようなデータをデコードして検証する方法。
このドキュメントは、自動識別サービスの ISO/IEC 9594-8 (公開鍵インフラストラクチャ: デジタル署名および証明書) アプリケーション仕様です。自動識別データキャリアのデータ容量および/またはデータ転送容量には制限があります。これにより、自動識別サービス内での ISO/IEC 9594-8 で指定されているデジタル署名の通常の使用が制限されます。
このドキュメントは、リアルタイムのリモート制御から独立して、自動識別データ キャリアに格納されたデータを指定、読み取り、デコード、および検証するための効果的で相互運用可能な方法を指定します。デジタル証明書に含まれるメタ パラメータを使用して、
- データ ソースとデータの独創性のオフラインの整合性検証、
- 展開、ドメイン権限、および自動識別データキャリアの相互運用性を可能にする検証可能なデータ構造の説明、
- データに制約のある自動識別データキャリアに保存されるコンパクトなデータを実現するための検証可能なデータエンコード方法 (JSON データ形式は、エンコーダーとデコーダーの入力と出力の両方に使用されます)、
- 検証可能な自動識別データキャリアの読み取り方法の記述により、読み取りイベントのデータを、同じ技術および異なる技術の複数のキャリアに分散させることができます。
- 暗号化が有効な自動識別データ キャリアのキー管理をサポートする検証可能な方法。
このドキュメントのユーザーは、任意の適切なハッシングおよび非対称暗号方式を使用できます。暗号化方式の選択は慎重に検討する必要があり、FIPS PUB 186-4 や IEEE P1363 など、国際的に認められた、または標準化された方式のみを使用することをお勧めします。
このドキュメントは、ユース ケースと環境の標準的なリスク評価と併せて使用する必要があります。
注多くの輸送アプリケーションは、データがタグおよび/または車両にバインドされていることを確認するために、安全で譲渡不可能な一意の識別子に依存しています。このような機能については、ISO/IEC 29167 を参照してください。この仕様は、改ざんやシステムへの誤ったデータの挿入から保護するために、データ自体の完全性と信頼性を保証するメカニズムを提供します。防御する手段は提供しません。リプレイ攻撃対策。タグの安全で譲渡不可能な一意の識別子を署名付きデータとして含めることで、タグとデータの間の反論の余地のないリンクが可能になり、データがタグから読み取られたかどうかを判断する手段が提供されます。リーダーは、読み取りトランザクションに効果的に署名することで、読み取り DigSig を別の DigSig に配置できます。第三者は、データの読み取りだけでなく、読み取りトランザクションが特定の場所と時間に発生したことを確認できます。
Introduction
This document specifies a “language” which is used to specify data constructs with; how the data constructs can be read from one or more AIDC; and how to decode and verify such data.
This document is an ISO/IEC 9594-8 (Public Key Infrastructure: digital signatures and certificates) application specification for automated identification services. Data capacity and/or data transfer capacity of Automated Identification Data Carriers are limited. This restricts the normal use of a digital signature as specified in ISO/IEC 9594-8 within automated identification services.
This document specifies an effective and interoperable method to specify, read, decode and verify data stored in automated identification data carriers, independent from real-time remote control. Meta parameters included in a digital certificate are used to achieve
- offline integrity verification of the data source and data originality,
- a verifiable data structure description to enable interoperability of deployment, domain authority and automated identification data carriers,
- a verifiable data encoding method to achieve compact data to be stored in data constrained automated identification data carriers (the JSON data format is used for both input and output of the encoder and decoder),
- a verifiable automated identification data carrier read method description allowing for the data of a read event to be distributed over more than one carrier of the same and of different technologies, and
- a verifiable method to support key management of cryptographically enabled automated identification data carriers.
The user of this document may use any suitable hashing and asymmetric cryptography method. The choice of cryptography method should be considered carefully and it is advised that only internationally recognized or standardized methods, for example FIPS PUB 186-4 and IEEE P1363, be used.
This document should be used in conjunction with standard risk assessments of the use case and environment.
NOTE Many transport applications rely on a secure non-transferable unique identifier to ensure that the data are bound to the tag and/or the vehicle. For such functionality, please refer to ISO/IEC 29167. This specification provides a mechanism to ensure the integrity and authenticity of the data themselves in order to protect against alterations or insertion of false data into the system. It does not provide any means to defend against replay attacks. Including the secure non-transferable unique identifier of a tag, as signed data, allows for the unrefutable link between the tag and the data and provides a means to determine if the data were read from the tag. The reader can place the read DigSig in another DigSig, effectively signing the read transaction. A third party can then verify that the read transaction happened at a given place and time, as well as the data read.