ISO/IEC DIS 18013-3:2026(en)

ISO/IEC JTC 1/SC 17

Secretariat: BSI

Date: 2025-12-29

Personal identification — ISO-compliant driving licence — Part 3: Access control, authentication and integrity validation

Identification des personnes — Permis de conduire conforme à l’ISO — Partie 3: Contrôle d’accès, authentification et validation d’intégrité

© ISO/IEC 2026

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

Contents

Foreword vii

Introduction viii

1 Scope 1

2 Normative references 1

3 Terms and definitions 2

4 Abbreviated terms 6

5 Conformance 7

6 Functional requirements 7

6.1 Access control 7

6.2 Document authentication 7

6.3 Data integrity validation 8

7 Mapping of mechanisms to requirements and technologies 10

8 Mechanism 11

8.1 Passive authentication 11

8.1.1 Purpose 11

8.1.2 Applicability 11

8.1.3 Description 12

8.1.4 Hash function 12

8.1.5 Signing method 13

8.2 Active authentication 17

8.2.1 Purpose 17

8.2.2 Applicability 17

8.2.3 Description 17

8.2.4 Mechanism 17

8.3 Scanning area identifier 18

8.3.1 Applicability 18

8.3.2 Description 18

8.4 Non-match alert 29

8.4.1 Purpose 29

8.4.2 Applicability 29

8.4.3 Description 29

8.4.4 Mechanism 30

8.5 Basic access protection 31

8.5.1 Purpose 31

8.5.2 Applicability 31

8.5.3 Description 31

8.5.4 Mechanism 32

8.6 Extended Access Control v1 33

8.6.1 Purpose 33

8.6.2 Applicability 33

8.6.3 Description and mechanism 33

8.7 PACE 34

8.7.1 Purpose 34

8.7.2 Applicability 34

8.7.3 Description and Mechanism 34

8.7.4 PACE relative to BAP 34

9 Security mechanism indicator 35

10 SIC LDS 36

10.1 General 36

10.2 EF.SOD – Document security object (short EF identifier = ‘1D’, Tag = ‘77’) 38

10.3 EF.DG12 Non-match alert (short EF identifier= ‘0C’, Tag = ‘71’) 38

10.4 EF.DG13 Active authentication (short EF identifier = ‘0D’, Tag = ‘6F’) 38

10.5 EF.DG14 EACv1 (short EF identifier = ‘0E’, Tag = ‘6E’) 39

10.6 EF.CardAccess if PACE is supported (short EF identifier = ‘1C’) 39

Annex A (informative) Public key infrastructure (PKI) 40

A.1 General 40

A.2 PKI design principles 40

A.3 General description 41

A.4 Implementation 43

A.4.1 Publication mechanism 43

A.4.2 Information published 44

A.5 Certificate content 44

A.5.1 Verification processes 44

A.5.2 Document key 45

A.5.3 Root key 46

A.6 Key revocation 46

A.6.1 Root key compromise 46

A.6.2 Document key compromise 47

A.7 Trust model weak points 47

A.7.1 Overview 47

A.7.2 General 47

A.7.3 Attacks 47

Annex B (normative) Basic Access Protection 49

B.1 General 49

B.2 Parameters 49

B.3 Protocol 49

B.4 Key derivation mechanism 49

B.5 Authentication and key establishment 50

B.6 Secure messaging 51

B.6.1 Message structure of SM APDUs 51

B.6.2 SM errors 53

B.6.3 Other errors 53

B.7 Mode of operations 53

B.7.1 Encryption 53

B.7.2 Message authentication 54

B.8 Basic access protection configuration 54

B.9 Card commands 55

B.9.1 GET CHALLANGE 55

B.9.2 MUTUAL AUTHENTICATE 55

B.10 Worked example (informative) 56

Annex C (Normative) 64

PACE 64

C.1 General 64

C.2 Changes to ICAO Doc 9303 Part 11 64

C.2.1 General 64

C.2.2 Key derivation function 64

C.3 Worked example (informative) 64

C.3.1 Read PACEInfo 64

C.3.2 Generate Password key Kπ 67

C.3.3 Application flow of the ECDH-based example 67

Annex D (Normative) 75

Extended Access Control v1 75

D.1 General 75

D.2 Changes to TR-03110-1 v2.10 75

D.2.1 Overview 75

D.2.2 General 75

D.2.3 Clauses not applicable to IDL 76

D.2.4 Clause 2.1: Driving Licence Application 76

D.2.5 Clause 2.2: Inspection System 76

D.2.6 Clause 2.4: Inspection Procedures 77

D.2.7 Clause 3.5: Terminal Authentication Version 1 77

D.3 Changes to TR-03110-3 v2.10 77

D.3.1 Overview 77

D.3.2 General 77

D.3.3 Clause B.8: Reading Data Groups 77

D.3.4 Clause C.4.1: Inspection Systems 77

D.4 Security mechanism indicator 78

Annex E (normative) 79

SIC Command set 79

E.1 Class byte 79

E.2 Command set 79

Annex F (Normative) 81

List of tags used 81

Annex G (informative) 82

Passive authentication (Version 01) 82

G.1 General 82

G.2 Purpose 82

G.3 Applicability 82

G.4 Description 82

G.5 Hash function 83

G.5.1 Standard encording 83

G.5.2 Compact encoding 83

G.6 Signing method 83

G.6.1 Standard encoding 83

G.6.2 Compact encoding 85

Bibliography 87

Foreword

ISO (the International Organization for Standardization) is a worldwide federation of national standards bodies (ISO member bodies). The work of preparing International Standards is normally carried out through ISO technical committees. Each member body interested in a subject for which a technical committee has been established has the right to be represented on that committee. International organizations, governmental and non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely with the International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization.

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 ISO documents 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).

ISO draws attention to the possibility that the implementation of this document may involve the use of (a) patent(s). ISO takes no position concerning the evidence, validity or applicability of any claimed patent rights in respect thereof. As of the date of publication of this document, ISO [had/had not] received notice of (a) patent(s) which may be required to implement this document. However, implementers are cautioned that this may not represent the latest information, which may be obtained from the patent database available at www.iso.org/patents. ISO shall not be held responsible for identifying any or all such patent rights.

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.

This document was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology, Subcommittee SC 17, Cards and security devices for personal identification.

This third edition cancels and replaces the second edition (ISO/IEC 18013-3:2017), which has been technically revised.

The main changes are as follows:

— Update ICAO references,

— Incorporate all published amendments

A list of all parts in the ISO/IEC 18013 series can be found on the ISO website.

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.

Introduction

This document prescribes requirements for the implementation of mechanisms to control access to data recorded in the machine-readable technology on an ISO-compliant driving licence (IDL), verifying the origin of an IDL, and confirming data integrity.

One of the functions of an IDL is to facilitate international interchange. While storing data in machine-readable form on the IDL supports this function by speeding up data input and eliminating transcription errors, certain machine-readable technologies are vulnerable to being read without the knowledge of the card holder and to other means of unauthorized access by unintended persons that is other than driving licence or law enforcement authorities. Controlling access to IDL data stored in machine- readable form protects the data on the card from being read remotely by electronic means without the knowledge of the card holder.

Identifying falsified driving licences or an alteration to the human-readable data on authentic driving licences present a major problem for driving licence and law enforcement authorities, both domestically and in the context of international interchange. Verifying the authenticity of an IDL and confirming the integrity of the data recorded on an IDL provide driving licence and law enforcement authorities with a means to identify an authentic IDL from a falsified or altered one in the interests of traffic law enforcement and other traffic safety processes.

Personal identification — ISO-compliant driving licence — Part 3: Access control, authentication and integrity validation

ISO/IEC 18013 establishes guidelines for the design format and data content of an ISO-compliant driving licence (IDL) with regard to human-readable features (ISO/IEC 18013-1), machine-readable technologies (ISO/IEC 18013-2), and access control, authentication and integrity validation (ISO/IEC 18013-3). It creates a common basis for international use and mutual recognition of the IDL without impeding individual countries/states to apply their privacy rules and national/community/regional motor vehicle authorities in taking care of their specific needs.

This document

— is based on the machine-readable data content specified in ISO/IEC 18013-2;

— specifies mechanisms and rules available to issuing authorities (IAs) for:

— access control (i.e. limiting access to the machine-readable data recorded on the IDL),

— document authentication (i.e. confirming that the document was issued by the claimed IA), and

— data integrity validation (i.e. confirming that the data has not been changed since issuing).

This document does not address issues related to the subsequent use of data obtained from the IDL, e.g. privacy issues.

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 1831, Printing specifications for optical character recognition

ISO/IEC 7816‑4, Identification cards — Integrated circuit cards — Part 4: Organization, security and commands for interchange

ISO/IEC 8859‑1, Information technology — 8-bit single-byte coded graphic character sets — Part 1: Latin alphabet No. 1

ISO 9796‑2, Information technology — Security techniques — Digital signature schemes giving message recovery — Part 2: Integer factorization based mechanisms

ISO/IEC 9797‑1, Information technology — Security techniques — Message Authentication Codes (MACs) — Part 1: Mechanisms using a block cipher

ISO/IEC 10118‑3, Information technology — Security techniques — Hash-functions — Part 3: Dedicated hash-functions

ISO/IEC 11770‑2:1996, Information technology — Security techniques — Key management — Part 2: Mechanisms using symmetric techniques

ISO/IEC 11770‑2:1996/Cor.1:2005, Information technology — Security techniques — Key management — Part 2: Mechanisms using symmetric techniques — Technical Corrigendum 1

ISO/IEC 18013‑1, Personal identification — ISO-compliant driving licence — Part 1: Physical characteristics and basic data set

ISO/IEC 18013‑2:2020, Personal identification — ISO-compliant driving licence — Part 2: Machine-readable technologies

ISO/IEC 18033‑3:2010, Information technology — Security techniques — Encryption algorithms — Part 3: Block ciphers

ANSI X9.62:2005, Public Key Cryptography for the Financial Services Industry: The Elliptic Curve Digital Signature Algorithm (ECDSA)

BSI Technical Guideline TR-03110-1: Advanced Security Mechanisms for Machine Readable Travel Documents — Part 1 — eMRTDs with BAC/PACEv2 and EACv1 — Version 2.10 — 2012-03-20

BSI Technical Guideline TR-03110-3: Advanced Security Mechanisms for Machine Readable Travel Documents — Part 3 — Common Specifications — Version 2.10 — 2012-03-20

FIPS 186-4 (including Change Notice), Digital Signature Standard (DSS), Federal Information Processing Standards Publication, National Institute of Standards and Technology, July 2013

ICAO Doc 9303 – Machine Readable Travel Documents, Eighth Edition, 2021, Part 10: Logical Data Structure (LDS) for Storage of Biometrics and Other Data in the Contactless Integrated Circuit (IC) [Doc 9303-10]

ICAO Doc 9303 – Machine Readable Travel Documents, Eighth Edition, 2021, Part 11: Security Mechanisms for MRTDs [Doc 9303-11]"

NIST/SP 800-38B, Recommendation for Block Cipher Modes of Operation: The CMAC Mode for Authentication, May 2005

RFC 2631, E. Rescorla, Diffie-Hellman Key Agreement Method, June 1999

RFC 3279, W. Polk et al., Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, April 2002

RFC 3280, R. Housley et al., Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, April 2002

RFC 3369, R. Housley, Cryptographic Message Syntax, August 2002

RFC 4055, J. Schaad, B. Kaliski, R. Housley, Additional Algorithms and Identifiers for RSA Cryptography for use in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, June 2005

RFC 5639, M. Lochter, J. Merkle, Elliptic Curve Cryptography (ECC) Brainpool Standard Curves and Curve Generation, March 2010

RFC 8422, Y. Nir, S. Josefsson, M. Pegourie-Gonnard, Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier, August 2018

For the purposes of this document, the terms and definitions given in ISO/IEC 18013-1, ISO/IEC 18013-2 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

active authentication

mechanism that uses information stored in a secure area of a secure integrated circuit (SIC) (3.17) to confirm that the SIC and the other machine-readable data were issued together

Note 1 to entry: See 8.2.

3.2

basic access protection

BAP

mechanism to confirm that an inspection system (IS) has physical access to a proximity integrated circuit card (PICC) before the IS is allowed access to the data stored on the PICC and to ensure that communication between the IS and the PICC (once access is authorized) is protected

Note 1 to entry: See 8.5 and Annex B.

3.3

chip authentication

ephemeral-static key agreement protocol that provides authentication of the secure integrated circuit (3.17) and strong secure messaging

Note 1 to entry: See 8.6.

3.4

clone

unauthorized exact copy of a document that has the same security characteristics as the original document and that cannot be distinguished from the legitimate one

3.5

eavesdropping

unauthorized interception and interpretation of information-bearing emanations

[SOURCE: ISO/IEC 2382‑8:2015, 08.05.25, modified]

3.6

extended access control v1

EACv1

protocol used to limit access to optional signature and biometric data groups

Note 1 to entry: See 8.6 and Annex D.

3.7

input string

string of characters printed on an ISO-compliant driving licence [as human-readable text, optionally (or by specification) accompanied by or consisting of a machine-readable rendering thereof] used as input (either manually or automatically through the use of suitable equipment) for the non-match alert and BAP (3.2) or PACE (3.10) mechanisms

3.8

issuing authority

IA

licensing authority (or issuing country if separate licensing authorities have not been authorized) which applies a digital signature to an ISO-compliant driving licence and is responsible for the associated key management

[SOURCE: ISO/IEC 18013‑1]

3.9

non-match alert

mechanism to detect any differences between the machine-readable information and (some of) the human-readable information on an ISO-compliant driving licence

Note 1 to entry: See 8.4.

3.10

PACE

alternative mechanism to BAP to confirm that an inspection system (IS) has physical access to a secure integrated circuit (SIC) (3.17) on a driving licence card before the IS is allowed to access to the data stored on the SIC and to establish a secure communication channel between the IS and SIC once access is authorised

Note 1 to entry: See 8.7 and Annex C.

3.11

passive authentication

mechanism to confirm that machine-readable data on an ISO-compliant driving licence (IDL) has not been changed since the IDL was issued

Note 1 to entry: See 8.1 and Annex G (informative)..

3.12

pseudo issuing authority

PIA

authority that does not issue ISO-compliant driving licences [but that is similar to an issuing authority (IA) (3.8) in all other respects] and which does not issue document keys, but which does have a root key pair with which it can sign documents of other IAs or PIAs that it trusts

3.13

public key infrastructure

PKI

technologies and products using public key (asymmetric) cryptography

Note 1 to entry: Both passive authentication (3.11) and extended access protection use this technology.

3.14

reading authority

RA

authorized entity reading the machine-readable data on an ISO-compliant driving licence (IDL)

Note 1 to entry: Driving licence authorities other than the authority that issued the IDL and law enforcement authorities are examples of reading authorities.

3.15

reference string

string of characters used as a reference against which to compare the input string (3.7) when using the non-match alert (3.9) mechanism, and used for session key calculation purposes by the secure integrated circuit (3.17) during execution of the basic access protection (3.2) mechanism

3.16

scanning area identifier

SAI

one or more graphical elements that demarcate an input string (3.7)

3.17

secure integrated circuit

SIC

integrated circuit that includes both a security feature (or security features), and memory and/or a central processing unit

Note 1 to entry: An integrated circuit card with contacts and a proximity integrated circuit card (PICC) are examples of a SIC.

Note 2 to entry: A SIC can be embedded in different solutions, for example in ID-1 sized cards (as used for the ISO-compliant driving licence) and in a booklet (as found in passports).

3.18

secure memory

integrated circuit (IC) memory of which the content [once populated by an issuing authority (3.8) during the personalization process] is accessible only by the IC operating system for internal use, and cannot be made available by the operating system to any reading device

3.19

skimming

reading data from a proximity integrated circuit card (PICC) without the card holder’s awareness

3.20

trust chain

sequential set of trust points (3.23) that a verifying authority (3.26) references to verify a specific issuing authority’s (3.8) public root key

3.21

trust model

description of the functional and logical aspects of a traditional public key infrastructure (3.13), specifically excluding technical implementation details

3.22

trust network

component of a trust model (3.21) that describes the trust relationships and chains between issuing authorities

3.23

trust point

issuing authority (3.8) or pseudo issuing authority (3.12) that publishes a trust list (and the related public root keys) that verifying entities can reference

3.24

twinning

copying the data and/or integrated circuit of a physically and/or biometrically similar driver to the attacker’s integrated circuit or ISO-compliant driving licence

3.25

unpacked BCD

binary coding of a sequence of integers using 4 bits for each integer (where the bit weights are 8421) and encoding one integer in the least significant bits of each byte

Note 1 to entry: Only unsigned BCD is used in this document.

3.26

verifying authority

VA

verifying entity (3.27) that is part of a trust network (3.22), i.e. that also is an issuing authority (3.8) or a pseudo issuing authority (3.12)

Note 1 to entry: Not all verifying entities are VAs. A car rental company can be a verifying entity, but is not a VA as it is not part of the trust network.

Note 2 to entry: VAs can be divided into immediate VAs (3.26.1) and non-immediate VAs (3.26.2).

3.26.1

immediate VA

VA (3.26) that acquired the public root key of the issuing authority (3.8) via out-of-band means

3.26.2

non-immediate VA

VA (3.26) that acquired the public root key of the issuing authority (3.8) from another VA

3.27

verifying entity

entity that tries to determine if a digital signature is valid (i.e. if the data to which a certificate has been applied has not been changed, and if the signature was generated by the issuing authority (3.8) the verifying entity expects)

A driving licence is in conformance with this document if it meets all mandatory requirements specified directly or by reference herein. Compliance with ISO/IEC 18013-2 is required for compliance with this document.

Compliance with ISO/IEC 18013-1 is not required for compliance with this document. Conversely, the incorporation of a machine-readable technology which is not compliant with this document does not render the IDL non-compliant with ISO/IEC 18013-1.

Access control can be broken down into the following functional requirements:

a) prevent skimming of machine-readable data on a PICC by ensuring that physical access to the IDL is acquired prior to reading;

b) prevent unnoticed alteration of communication between a reader and a SIC;

c) prevent eavesdropping between a reader and a SIC;

d) selectively restrict access to specific optional machine-readable data groups for specific reading authorities.

Document authentication can functionally be established by allowing for verification of the origin of an IDL.

Data integrity validation can be broken down into the following functional requirements:

a) Verify that the IDL (including the machine-readable data) is not a clone of another IDL. A cloning attempt can schematically be illustrated as shown in Figure 1.

Figure 1 — Data integrity validation: IDL cloning

b) Protect against the exchange of machine-readable data carriers between otherwise authentic IDLs.This type of attack can schematically be illustrated as shown in Figure 2.

NOTE This guards (among others) against an IC “twinning” attack. This type of attack is of particular concern in inspection environments where machine-readable data and human-readable data is not compared (or only cursorily compared by an operator using, for example, a portrait image). Finding a biometrically similar driver is possible by skimming the data of a few thousand IDL PICs.

Figure 2 — Data integrity validation: Data carrier exchange or twinning

c) Verify that the physical IDL and the machine-readable data thereon were issued (belong) together. This type of attack can schematically be illustrated as shown in Figure 3.

Figure 3 — Data integrity validation: Machine-readable data exchange

d) Validate the integrity of the human readable data (i.e. confirm that the human-readable data has not changed since issuing). This type of attack can schematically be illustrated as shown in Figure 4.

Figure 4 — Data integrity validation: Human-readable data alteration

e) Validate the integrity of the machine-readable data (i.e. confirm that the machine-readable data has not changed since issuing). This can schematically be illustrated as shown in Figure 5.

Figure 5 — Data integrity validation: Machine-readable data alteration

Mechanisms that, when used individually, can address specific functional requirements are specified in Clause 8. Mechanisms can also be used together to address a broader range of functional requirements. Not all machine-readable technologies have the same functional requirements, and some mechanisms are applicable only to specific machine-readable technologies. Table 1 specifies the relationships between the mechanisms, machine-readable technologies, and functional requirements.

Table 1 — Applicable mechanisms

IA’s may selectively implement the mechanisms identified above, subject to any dependencies noted in Clause 8.

The purpose of passive authentication is to confirm that machine-readable data has not been changed since the IDL was issued.

This version 02 of passive authentication supersedes the deprecated version 01 included in Annex G (informative) for the information of manufacturers of readers that must be able to read IDL cards issued in accordance with this version that have not yet expired.

Passive authentication is applicable to all machine-readable technologies.

Passive authentication is implemented by way of a digital signature over specified machine-readable data on the IDL, using a public-private (asymmetric) key pair.

In the case of standard encoding, a separate message digest is calculated for each data group and included in the machine-readable data. The collection of message digests is then digitally signed (using a private key that is kept secret by the IA) and the digital signature is added to the machine-readable data.

In the case of compact encoding, no message digests are calculated separately. The contents of the data groups present is directly signed (using a private key that is kept secret by the IA) and the digital signature is added to the machine-readable data.

NOTE A message digest has the following properties:

a) It is very small in size compared to the IDL data.

b) The probability of finding any two (different) IDL data sets that lead to the same message digest is negligible. This has the following implications:

1) The probability of finding an IDL data set A that produces the same message digest as a given IDL data set B is negligible.

2) The probability that a message digest (for the data on an IDL) remains the same upon a change in the data is negligible.

When the IDL is presented to a RA, the RA uses the IA’s public key to verify the digital signature. The RA also computes the message digests of each of the data groups that it is interested in and compares them to the corresponding message digests stored in the machine-readable data. If the following conditions are met, the RA can consider the data groups that it is interested in to be authentic:

a) the digital signature verifies;

b) the calculated message digests are the same as the message digests stored in the machine-readable data;

c) the RA is confident that the public key used to verify the digital signature belongs to the claimed IA.

If the digital signature does not verify, either an incorrect public key was used or the data on the IDL has been changed. Depending on the digital signature method used, it can be possible to further narrow down the cause of the non-verification.

This document does not prescribe methods to obtain and/or to establish trust in public keys. It is the responsibility of each RA to obtain and/or to establish trust in the public keys used to verify a digital signature on an IDL. However, informative methods and approaches to establish such trust are provided in Annex A, which describes the principles for a PKI that may be used for public key distribution in the absence of one global certification authority.

This document does not prescribe methods for the generation, administration and safekeeping of key pairs. It is the responsibility of each issuing jurisdiction to ensure that keys are generated, administered and protected as necessary.

Standard encoding

For standard encoding, IA’s shall choose the SHA-256, SHA-384 or the SHA-512 hash function. SHA-256 is recommended.

A message digest is calculated separately for each data group present and stored in the machine-readable data (see 8.1.5.1). The same hash function is used for all data groups. A message digest for a data group is calculated on the concatenation of those data elements present in the data group in the order specified in ISO/IEC 18013-2.

NOTE This approach allows reading authorities to read only those data groups it is interested in.

Compact encoding

For compact encoding, IA’s shall not calculate separate message digests for each data group. Therefore, no hash function is specified for compact encoding (except as required as part of any digital signature mechanism; see 8.1.5.2).

Standard encoding

An IDL digital signature is generated over the concatenation of the message digests of the data groups present.

IA’s may use either ECDSA or RSA as digital signature methods for standard encoding.

IA’s using RSA shall use RFC 4055. RFC 4055 specifies two signature mechanisms, RSASSA-PSS and RSASSA-PKCS1-v1_5. It is recommended to generate signatures according to RSASSA-PSS, but reading authorities shall also be prepared to verify signatures according to RSASSA-PKCS1-v1_5. The minimum size of the modulus, n, shall be 1024 bits.

IA’s implementing ECDSA shall use ANSI X9.62. The elliptic curve domain parameters used to generate the ECDSA key pair shall be encoded as namedCurve as specified in RFC 8422 or brainpool domain parameter as specified in RFC 5639. If brainpool domain parameter is used, it shall be one from brainpoolP256r1, brainpoolP320r1, brainpoolP384r1 or brainpoolP512r1.

In addition to EF.COM and the data groups specified in ISO/IEC 18013-2, IA’s shall add the SOD to accommodate the hashes of the individual data groups (see 8.1.4.1) and the digital signature of the data on the IDL. The SOD is implemented as a SignedData Type, as specified in RFC 3369 (including processing rules). The SOD shall be produced in DER format.

Table 2 — SignedData Type

ISO/IEC 18013-3:2017 specifies EF.SOD V0 for LDS v1.7 as below.

ASN.1 sequence

LDSSecurityObject { joint-iso-itu-t(2) international-organizations(23) icao(136) mrtd(1)

security(1) ldsSecurityObject(1)}

DEFINITIONS IMPLICIT TAGS ::=

BEGIN

-- Imports from RFC 3280 [PROFILE], Appendix A.1

AlgorithmIdentifier FROM

PKIX1Explicit88 { iso(1) identified-organization(3) dod(6)

internet(1) security(5) mechanisms(5) pkix(7)

id-mod(0) id-pkix1-explicit(18) }

-- Constants

ub-DataGroups INTEGER ::= 16

-- Object Identifiers

id-icao OBJECT IDENTIFIER ::= {2.23.136}

id-icao-mrtd OBJECT IDENTIFIER ::= {id-icao 1}

id-icao-mrtd-security OBJECT IDENTIFIER ::= {id-icao-mrtd 1}

id-icao-ldsSecurityObject OBJECT IDENTIFIER ::= {id-icao-mrtd-security 1}

-- LDS Security Object

LDSSecurityObjectVersion ::= INTEGER {V0(0)}

DigestAlgorithmIdentifier ::= AlgorithmIdentifier

LDSSecurityObject ::= SEQUENCE {

   version LDSSecurityObjectVersion,

   hashAlgorithm DigestAlgorithmIdentifier,

   dataGroupHashValues SEQUENCE SIZE (2..ub-DataGroups) OF DataGroupHash }

DataGroupHash ::= SEQUENCE {

dataGroupNumber DataGroupNumber,

dataGroupHashValue OCTET STRING }

DataGroupNumber ::= INTEGER {

dataGroup1 (1),

dataGroup2 (2),

dataGroup3 (3),

dataGroup4 (4),

dataGroup5 (5),

dataGroup6 (6),

dataGroup7 (7),

dataGroup8 (8),

dataGroup9 (9),

dataGroup10 (10),

dataGroup11 (11),

dataGroup12 (12),

dataGroup13 (13),

dataGroup14 (14),

dataGroup15 (15),

dataGroup16 (16)}

END

NOTE 1 The field dataGroupHashValue contains the calculated hash over the complete contents of the Data Group EF, specified by dataGroupNumber.

NOTE 2 Data Groups 15 and 16 can be defined in future.

In addition, this document specifies EF.SOD V1 for LDS v1.8 extended with a signed attribute, containing the LDS and Unicode version information as below. The new project should use LDS v1.8. If LDS v1.8 is supported, Document Signer certificate shall be supported in LDS. Only one EF.SOD is REQUIRED and allowed.

LDSSecurityObject ::= SEQUENCE {

version LDSSecurityObjectVersion,

hashAlgorithm DigestAlgorithmIdentifier,

dataGroupHashValues SEQUENCE SIZE (2..ub-DataGroups) OF

DataGroupHash,

ldsVersionInfo LDSVersionInfo OPTIONAL

-- If present, version MUST be V1

}

LDSVersionInfo ::= SEQUENCE {

ldsVersion PrintableString,

unicodeVersion PrintableString }

Compact encoding

An IDL digital signature is generated over the full data stream from the start of DG1 (including the data group delimiter between DG1 and the header) to the end of DG12 (including the data group delimiter that terminates DG12, but excluding DG.SOD, if present). The digital signature is stored in DG.SOD.

NOTE 1 The header is not included in the information to be signed as the length information in the header pertains to DG.SOD.1 and DG.SOD.H. as well.

IA’s shall use ECDSA (as defined in ANSI X9.62) as a signing method for compact encoding, and in order to reduce the storage requirements for the domain parameters, shall use one of the curves specified in Table 3.

DG.SOD shall consist of a concatenation of two Type 2 data groups, storing the following information:

a) DG.SOD.1: digital signature, shall be the DER encoded ASN.1 sequence of two integers, r and s: SEQUENCE ::= { r INTEGER, s INTEGER };

b) DG.SOD.H: SHA-256 hash of IA public key certificate that contains the public key for the verification of the DG.SOD.1 signature; the hash value shall be calculated over the entire DER-encoded certificate (including the signature).

DG.SOD shall be added after DG12, as follows:

[header] × [Data Group 1] × [Data Group 2] × [Data Group 3] × [Data Group 4] × [Data Group 7] × [Data Group 11] × [Data Group 12] × [DG.SOD.1 length] [digital signature] × [DG.SOD.H length] [hash value]

DG.SOD.1 and DG.SOD.H shall be included. Length information is encoded using ASN.1 rules.

NOTE 2 Reading authorities should be able to verify (or obtain) a public key (and domain parameters) from the IA using the data in other data groups (specifically the ISO issuer ID number and document discriminator in DG3 and the licence number and date of issue in DG1).

The curve identifier shall consist of one byte, as shown in Table 3.

Table 3 — Curve identifiers

Active authentication uses information stored in a secure area of an SIC to confirm that the SIC and the other machine-readable data were issued together.

This mechanism is limited to SICs.

A challenge-response protocol matches the private and public keys of an SIC-individual key pair. The private key is stored in the SIC’s secure memory and cannot be copied. The public key is stored as part of the signed data on the SIC (the challenge-response protocol thus has to be preceded by passive authentication). The SIC (or more specifically, the SIC operating system) can prove knowledge of the SIC-individual private key in a challenge-response protocol. In this protocol, the SIC digitally signs a challenge randomly chosen by the IS. The IS is convinced that the SIC is genuine if and only if the returned signature is correct.

NOTE Active authentication using a challenge-response protocol is open to a “traceability” attack. The challenge-response protocol does not place any limitation on the format or content of the challenge. If the challenge includes time, date, location, and a secret key, a log of challenge responses can be used to track IDLs and to prove presence (due to the inclusion of the secret key). The counterargument is that basic access protection would safeguard against unknown read attempts and that a driver’s location is known in any case in those instances where an IDL is handed over for inspection.

General

The SIC-individual public key shall be stored in DG13, an additional data group specifically intended for use with the active authentication mechanism. The format of the structure (SubjectPublicKeyInfo) is specified in RFC 3280. SubjectPublicKeyInfo shall be produced in DER format as follows:

ActiveAuthenticationPublicKeyInfo ::= SubjectPublicKeyInfo

SubjectPublicKeyInfo ::= SEQUENCE {

algorithm AlgorithmIdentifier,

subjectPublicKey BIT STRING }

AlgorithmIdentifier ::= SEQUENCE {

algorithm OBJECT IDENTIFIER,

parameters ANY DEFINED BY algorithm OPTIONAL }

Allowed algorithm object identifiers and parameters are specified in RFC 3279.

Active authentication shall be performed using the ISO/IEC 7816 INTERNAL AUTHENTICATE command as defined by ISO/IEC 7816-4. The input shall be a terminal-generated nonce (RND.IFD) that shall be 8 bytes in length. The SIC computes a signature which shall be sent back to the IS. The IS shall check the response and verify the signature.

Signature generation using RSA

The signature shall be computed according to ISO/IEC 9796-2 Digital Signature Scheme 1. M shall consist of M1 and M2, where M1 is an SIC-generated nonce of c-4 bits and M2 is RND.IFD. The result of the signature generation shall be the signature Σ without the recoverable message part M2.

Signature generation using ECC

An IDL supporting ECDSA shall use a prime curve with uncompressed points for this computation. In this case the output of the computation shall be the concatenation of the values r and s (r||s). The input for this computation shall be computation shall be compressed with a hash algorithm with an output length shorter or equal to the length of the signature key.

NOTE The plain signature format (r||s) for the ECDSA is according to TR-03111^[6].

If ECDSA based signature algorithm is used for Active Authentication by the SIC, the SecurityInfos in LDS Data Group 14 of the IDL application shall contain following SecurityInfo entry:

ActiveAuthenticationInfo ::= SEQUENCE {

      protocol id-icao-mrtd-security-aaProtocolObject,

      version INTEGER, -- MUST be 1

      signatureAlgorithm OBJECT IDENTIFIER

}

id-icao-mrtd-security-aaProtocolObject OBJECT IDENTIFIER ::=

                                         { id-icao-mrtd-security 5 }

The object identifiers for signatureAlgorithm are defined in TR-03111.^[6] ecdsa-plain-SHA1 and ecdsa-plain-RIPEMD160 shall not be used.

NOTE 1 See 8.1.5.1 for the definition of the Object Identifier id-icao-mrtd-security.

NOTE 2 SecurityInfos can contain entries for other protocols, e.g. Chip Authentication, Terminal Authentication, PACE.

Security mechanism indicator

SICs which implement active authentication may optionally indicate this in the security mechanism indicator (see Clause 9). The object identifier shall be id-sm-AA.

id-sm-AA OBJECT IDENTIFIER ::= {

iso(1) standard(0) driving-licence(18013) part-3(3)

security-mechanisms(2) 3}

The parameters are mandatory and shall be of type param-AA.

param-AA ::= SEQUENCE {

version INTEGER,

publicKeyDG INTEGER}

The version shall be set to v1(0) for this version of active authentication. The publicKeyDG field shall be set to the number of the data group of the active authentication public key, i.e. 13.

This mechanism is used with the non-match alert, BAP or PACE mechanisms, which collectively are applicable to SICs and 2D barcode (see 8.4 and 8.5).

General

The primary purpose of this mechanism is to facilitate machine assisted automatic or interactive verification procedures that match machine-readable data to human-readable data. This mechanism is not a solution on its own, but is intended for use as a component of either of the following mechanisms:

a) non-match alert (see 8.4), which checks if the machine-readable and human-readable data belong together;

b) BAP (see 8.5) or PACE (see 8.7), which ensures that a PICC cannot be read without physical access to the IDL.

NOTE The BAP mechanism also performs the function of the non-match alert mechanism, but potentially at a different level of security.

The SAI demarcates the input string. The input string can be entered manually by an operator or can be read automatically using machine-readable technologies.

The SAI and any machine-readable information demarcated by it shall be adapted for reading in the B900 infrared band defined in ISO 1831. Under such illumination, the printing background and any overlays within the SAI will backscatter light in a homogeneous way (i.e. the SAI shall contain no optically variable device, local deviations in properties, security features, or surface gloss exceeding natural transparent overlay gloss, which will interfere with readability). In addition, machine-readable printed information (e.g. bar codes and OCR characters) shall comply with the associated standards. The brightness of the printing background (including the effects of overlays) will not be less than 40 % compared to an ideal white surface under the same illumination. Human-readable information inside the SAI shall be rendered such that it can be read without difficulty.

The contrast ratio between character lines and the background shall be a minimum of 4:1. Any reflective layer covering the SAI area shall not further deteriorate this contrast value when illuminated under angles of incidence up to 45° and looked at under angles more than 10° outside of the nominal glance angle.

The presence of the SAI is identified as follows:

a) If PICC access is required and the access conditions are unsatisfied (i.e. BAP or PACE is in place), the reader searches for a SAI on the IDL.

b) If access to DG12 is available, BAP or PACE is not applicable and the non-match alert mechanism is present. DG12 may indicate the location of the SAI, alternatively, the reader searches for a SAI on the IDL.

Not more than one SAI shall be present on a single IDL.

The reference string (and the input string, when stored in a barcode) shall be encoded in accordance with ISO/IEC 8859-1.

The content of the SAI can follow one of three standards, i.e. based on an existing text field, containing a dedicated text field, or containing a barcode.

SAI content based on existing text field

The SAI may be constructed around an existing field on an IDL In this case, the SAI shall consist of a double lined rectangle as illustrated by the example in Figure 6.

Figure 6 — SAI around an existing field (not to scale)

Each line shall have a thickness of 0,2 mm ± 0,1 mm, and the distance between the centre of each line shall be 0,6 mm ± 0,1 mm. The lines shall be black in colour. The clear distance between the inside line and the extremities of the input string shall be at least 1 mm.

The input string shall be printed using OCR-B size 1 or a character set with the same symbols and character shapes but using a reduced size of either 25 % or 50 % reduction of all linear dimensions compared to OCR-B size 1.

To prevent confusion about the input sequence of the characters, text within the rectangle shall be limited to one line. The data element name (if reflected on the IDL) and/or the data field reference code shall not be included within the rectangle.

In order to facilitate manual entry of the input string when needed, the input string may contain only Latin capital letters (hexadecimal range 41 to 5A of ISO/IEC 8859-1:1998), Latin small letters (hexadecimal range 61 to 7A of ISO/IEC 8859-1), N characters, and the S characters shown in Table 4.

Latin capital letters (hexadecimal range 41 to 5A of ISO/IEC 8859-1) are recommended.

NOTE 2 References to ISO/IEC 8859-1 are only for purposes of identifying the characters. Encoding methods are specified elsewhere.

Table 4 — S characters allowed for SAI content based on existing field

The reference string shall not contain any space characters (i.e. hexadecimal character ‘20’ of ISO/IEC 8859-1). Thus, the IS shall delete all space characters (hexadecimal code 20 of ISO/IEC 8859-1) from the input string before further processing.

IA’s should carefully consider the level of entropy of existing fields before use within the SAI. Any rules followed in the construction of the field will decrease the entropy.

IA’s considering the use of an SAI based on an existing field should keep in mind that a check digit is not provided for in this case.

EXAMPLE See Figure 7.

Figure 7 — Existing data field on portrait side of IDL designated as input string (not to scale)

SAI content consisting of a dedicated text field

A dedicated field (i.e. a field designed specifically for this purpose) may be used within a SAI. In this case, the SAI shall consist of a rectangle constructed by a black single line with a thickness of 0,65 mm ± 0,1 mm. The clear distance between the line and the extremities of the printed input string shall be at least 1 mm.

EXAMPLE See Figure 8.

Figure 8 — SAI around a dedicated field (not to scale)

The content of the SAI shall comply with the following requirements:

a) the text shall be limited to the set of ICAO MRZ characters, i.e. 0 1 2 3 4 5 6 7 8 9 A B C D E F G H I J K L M N O P Q R S T U V W X Y Z <;

b) an odd number of characters per line shall be used;

c) if characters are printed in more than one line, each line shall have the same number of characters;

d) a line shall not have more than seven characters;

e) no more than three lines shall be used;

f) the text shall be printed using OCR-B font at 100 % of OCR-B size 1;

g) the middle character of each line shall be reserved for a check digit. Before adding the check digit(s), the input string may have the following lengths:

1) for one line only, string lengths of 4 or 6 characters are permitted;

2) for two lines, string lengths of 8 or 12 characters are permitted;

3) for three lines 12 or 18 characters are permitted.

To construct an input string (with check digits) consisting of i lines, the input string (before check digits are added) is parsed into i parts of equal length. The leftmost part is used to form line 1, the following parts each to form an additional line. Each part is split in the middle into a left and a right subsection. The left subsection forms the leftmost part of the corresponding line, the right subsection forms the rightmost part of the line. An additional character position is inserted in the middle of each line (for the check digit). The value of the check digit of each line will be calculated as explained further below.

For the purpose of check digit calculation, each character in the input string (before the check digits are added) represents a numerical value V_C defined by the formula V_C=E_C, where E_C is a unique number allotted to each character value, as defined in Table 5.

Table 5 — Character numerical equivalents

If line 1 is the only line, then the unique check digit will be calculated as follows:

a) A check sum S is calculated as S = ΣV_Ci, where i runs from 0 to n−1 and V_Ci indicates the respective value V_C for the character in the i-th position in the input string of length n, counted from right to left, starting with position 0 for the rightmost character.

b) From S, the corresponding check digit c is calculated as c = S modulo 37; (integer remainder when dividing S by 37).

If there are two or three lines, then the check digits c₁ for line one and c₂ for line two will be calculated as follows:

a) A check sum S_V is calculated over the entire input string (before it is split into lines and before adding the check digits) as S_V=ΣV_Ci, where i runs from 0 to n−1 and indicates the character in the i-th position in the input string of length n, counted from right to left, starting with position 0 for the rightmost character.

b) A check sum S_P is calculated over the entire input string (before it is split into lines, and before adding the check digits) as S_P = Σ(V_Ci*i), where i runs from 0 to n−1 and i indicates the i-th position number in the input string of length n, counted from right to left, starting with position 0 for the rightmost character, and V_Ci indicates the respective value for the character in the i-th position.

c) Check digits c₁ and c₂ are calculated as c₁ = (S_V modulo 37) and c₂ = (S_P modulo 37), respectively.

In the case of exactly three lines, the inserted character c₃ in the centre of line three will represent the version number and will be set to “1” for this version of the standard. Version numbers are not supported for less than three lines.

When printed on an IDL, lines are numbered from top to bottom, as shown in Figure 9.

Figure 9 — Line configuration (not to scale)

EXAMPLE Input string for Figure 9 is EDHTULVXCDGBZ4G8HF.

S_V = 335

S_P = 3082

c₃ = 1

The input string submitted as input to the non-match alert or BAP mechanisms is the input string inclusive of the check digit, i.e. the concatenation s₁+s₂+s₃ where s_i is the string in line i of the corresponding input string, including the respective check digit and read from the left to the right, with i ranging from 1 to a maximum of 3.

NOTE Mathematically, the check digit scheme allows identifying any single digit reading error in the case of a one-line input string and to correct any single digit reading error, as well as identifying any double error in the case of a two-line or three-line input string. Less than 3 % of any other statistical reading error may pass inadvertently. This is only true if adequate measures are taken on the side of the reading equipment to make use of the information offered by the check digit scheme.

It is recommended that the minimum entropy of the input string be 40 bits or more (before addition of the check digits). The use of random data is recommended.

NOTE IA’s may consider imposing restrictions on allowable content of input strings to meet local requirements, e.g. to address the “nasty word” problem, or to limit the value range of practically existing check digits (i.e. numerical characters only). Methods exist that allow enforcement of such restrictions without violation of the rules set out above. The use of such methods is left to the discretion of the IA’s. Attention is drawn to the fact that such restrictions will reduce the entropy of the input string.

EXAMPLE See Figure 10.

Figure 10 — Dedicated data field on non-portrait side of IDL designated as input string (not to scale)

SAI content consisting of a barcode

A barcode may be used within a SAI as the primary means of input. The SAI’s corners shall be clearly shown. Each corner indicator shall be constructed of two perpendicular lines joined at the end points, with each line having a thickness of 0,5 mm ± 0,3 mm, and a length of 4 mm ± 2 mm.

EXAMPLE See Figure 11.

Figure 11 — SAI around a dedicated field (not to scale)

The input string may contain any A, N or S characters, and is not limited in length. However, it is recommended that the input string be limited to the characters specified in 8.3.2.3 to facilitate manual entry when required. The barcode may be accompanied by a human-readable version of the input string (in accordance with ISO/IEC 8859-1), printed in a font not smaller than 6pt.

EXAMPLE See Figure 12.

The one of the following symbologies shall be used:

— PDF417

— Code 39 as specified in ISO/IEC 16388

— Code 128 as specified in ISO/IEC 15417

— data matrix as specified in ISO/IEC 16022)

— QR code as specified in ISO/IEC 18004

NOTE ISO/IEC 18013-3:2017 did not mandate these symbologies.

Figure 12 — Barcode on non-portrait side of IDL designated as input string (not to scale)

SAI consisting of an IDL MRZ

General

This mechanism is a 1 line MRZ and is used with the non-match alert, BAP or PACE mechanisms, which collectively are applicable to SICs and 2D barcode (see 8.4 and 8.5).

The IDL MRZ differs from the manner in which an input string is identified in 8.3, in that, its position is fixed and consequently does not require one or more graphical elements that demarcate the input string as an SAI.

The data elements shall be printed in machine readable form, in the MRZ, beginning with the leftmost character position in each field in the sequence indicated in the data structure specifications for the IDL MRZ.

NOTE The content of the IDL MRZ is not to be confused with data elements in the passport MRZ.

Check digits are used within the machine readable zone to provide verification that the entered data are correctly interpreted.

The presence of the IDL MRZ is identified as follows:

a) If SIC access is required and the access conditions are unsatisfied (i.e. BAP or PACE is in place), the reader searches for the IDL MRZ on the IDL.

b) If access to DG12 is available, BAP or PACE is not applicable and the non-match alert mechanism is present, DG12 may confirm the existence of the IDL MRZ, alternatively, the reader searches for the IDL MRZ on the IDL.

Not more than one IDL MRZ shall be present on a single IDL.

The reference string shall be encoded in accordance with ISO/IEC 8859-1.

The IDL MRZ may be located on the portrait side or the non-portrait side of the IDL, except for the case where the reference string for the non-match alert is stored in a bar code. In such cases, the IDL MRZ shall not be located on the same side as the barcode.

Figure 13 shows the location of the 1 line MRZ at the bottom of the IDL, the nominal dimensions and position of the IDL MRZ data.

Dimensions in millimetres (inches)

Key

1 machine reading zone

2 reference centre line

3 printing zone

Figure 13 — Location of 1 line MRZ at the bottom of the IDL (not to scale)

Printing

The position of the left edge of the first character of the OCR line shall be 4,0 mm ± 1,0 mm (0.16 in ± 0.04 in) from the left edge of the IDL. The reference centre line for the OCR line shall be 7,27 mm ± 1,0 mm (0.29 in ± 0.04 in) from the bottom edge of the IDL. The OCR line shall not exceed the printing zone length of 77,7 mm ± 1,0 mm (3.06 in ± 0.04 in). No other printing in the B900 infrared band defined in ISO 1831 may appear in the machine reading zone within 12,12 mm ± 1,0 mm (0.48 in ± 0.04 in) from the bottom edge of the IDL.

Machine readable data shall be printed in OCR-B type font, size 1, constant stroke width. The MRZ shall be printed with a horizontal printing density of nominally 10 characters per 25,4 mm.

The text shall be limited to the set of ICAO MRZ characters, i.e. 0 1 2 3 4 5 6 7 8 9 A B C D E F G H I J K L M N O P Q R S T U V W X Y Z <, excluding the space character.

The IDL MRZ shall be adapted for reading in the B900 infrared band defined in ISO 1831. Under such illumination, the printing background and any overlays will backscatter light in a homogeneous way (i.e. the IDL MRZ shall not be obstructed by an optically variable device, local deviations in properties, security features, or surface gloss exceeding natural transparent overlay gloss that will interfere with readability). The brightness of the printing background (including the effects of overlays) will not be less than 40 % compared to an ideal white surface under the same illumination.

The contrast ratio between character lines and the background shall be a minimum of 4:1. Any reflective layer covering the SAI area shall not further deteriorate this contrast value when illuminated under angles of incidence up to 45° and looked at under angles more than 10° outside of the nominal glance angle.

Use of the IDL MRZ as a BAP or PACE input string

The IDL MRZ can be used for establishing BAP as specified in 8.5 or PACE as specified in 8.7. The input string shall be composed of characters 2 to 29 of the IDL MRZ.

The IDL MRZ shall contain the elements given in Table 6.

Table 6 — IDL MRZ data elements

Check digit calculation

The IDL MRZ check digit shall be calculated on modulus 10 with a continuously repetitive weighting of 731 731 ..., as follows:

— Step 1: Going from left to right, multiply each digit of the pertinent numerical data element by the weighting figure appearing in the corresponding sequential position.

— Step 2: Add the products of each multiplication.

— Step 3: Divide the sum by 10 (the modulus).

— Step 4: The remainder shall be the check digit.

For data elements in which not all available character positions are occupied, the symbol < shall be used to complete vacant positions and shall be given the value of zero for the purpose of calculating the check digit.

When the check digit calculation is applied to data elements containing alphabetic characters, the characters A to Z shall have the values 10 to 35 consecutively, as shown in Table 7.

Table 7 — Check digit calculation

EXAMPLE Using an IDL with the following elements in the IDL MRZ, as shown in Table 8.

Table 8 — Example IDL MRZ data elements

Check digit is to be calculated over the following data: D123T09PJ3Y8478FSD<<<<<<<<<<<

Step 1: Multiplication:

Step 2: Sum of products:

1 +3 +2 +21 +87 +0 +63 +75 +19 +21 +102 +8 +28 +21 +8 +105 +84 +13 +0 +0 +0 +0 +0 +0 +0 +0 +0 +0 +0 = 751

Step 3: Division by modulus: = 75, remainder 1.

Step 4: Check digit is the remainder, 1. The resulting MRZ including check digit shall be written as: D123T09PJ3Y8478FSD<<<<<<<<<<<1

Table 9 — Example IDL MRZ data elements and check digit

The corresponding hex value of the above input string (Configuration and Discretionary data) given in Table 9 encoded in accordance with ISO/IEC 8859-1 is:

‘31 32 33 54 30 39 50 4A 33 59 38 34 37 38 46 53 44 3C 3C 3C 3C 3C 3C 3C 3C 3C 3C 3C’

Use of IDL MRZ for non-match alert

The IDL MRZ can be used with the non-match alert mechanism as described in 8.4.

In order to describe such use in DG12, byte 1 of the SAI_inputmethod field shall be assigned a value of ‘41’. The four most significant bits (upper nibble) of this byte identifies the IDL MRZ as the input method. The four least significant bits (lower nibble) of byte 1 is assigned in accordance with Table 10.

If byte 2 of the SAI_inputmethod is present, it shall have the value ‘FF’.

If the presence of the non-match alert mechanism is indicated in the EF.COM file and if the optional parameters are provided, the version field shall be set to v1(1) for this version of the non-match alert mechanism.

EXAMPLE See Figure 14.

Figure 14 — IDL MRZ on portrait side of IDL designated as input string (not to scale)

EXAMPLE See Figure 15.

Figure 15 — IDL MRZ on non-portrait side of IDL designated as input string (not to scale)

This mechanism allows detection of any differences between the machine-readable information and (some of) the human-readable information (printed on an IDL). This mechanism may be of value in the presence of machine-readable technologies with data content not accessible to visual inspection and on data carriers or physical support that may be transferred completely from one IDL to another without strong visual evidence of alteration.

This mechanism is applicable to SICs and 2D barcode.

Conceptually, the reference string is verified via a digital signature, after which the reference string is compared to the input string. If the comparison is not successful, it means that the machine-readable data and the (human-readable) printed data are not consistent.

NOTE 1 It is assumed that the RA trusts the public key used to verify the digital signature.

NOTE 2 If the comparison is successful, the RA may conclude that the machine-readable data and the physical document are consistent if it can be assumed that alteration to any part of the printed data (i.e. not just the area that contains the input string) would be visually apparent.

The reference string is not separately verified with a dedicated digital signature, but is verified during passive authentication (the digital signature used for passive authentication already covers the reference string).

NOTE 3 The function provided by the non-match alert mechanism can also be achieved by performing passive authentication followed by a visual comparison of the human-readable data printed on the document with the authenticated machine-readable data.

General

The manner in which the non-match alert mechanism is implemented is specified in DG12, using the parameters and values as shown in Table 10.

Table 10 — Non-match alert parameters

Compact encoding

When used with compact encoding, DG12 shall be constructed as a Type 1 data group as follows:

… × [SAI_referencestring] ÷ [SAI_inputmethod] × …

Standard encoding

When used with standard encoding, the parameters shall be stored in DG12 as shown in Table 11.

Table 11 — Non-match alert parameters for standard encoding

IA’s may optionally indicate the presence of the non-match alert mechanism in the EF.COM file using the security mechanism indicator as specified in Clause 9.

The object identifier for non-match alert shall be id-sm-NMA.

id-sm-NMA OBJECT IDENTIFIER ::= {

iso(1) standard(0) driving-licence(18013) part-3(3)

security-mechanisms(2) 4

}

The parameters are optional and shall be of type param-NMA.

param-NMA ::= SEQUENCE {

version INTEGER, SAI_inputmethod OCTET STRING

}

The version field shall be set to v1(0) for this version of the non-match alert mechanism.

The SAI_inputmethod field shall be set to the corresponding value in DG12. If the SAI_inputmethod field is not present in DG12, the field shall also not be included in EF.COM.

BAP confirms that an IS has physical access to a PICC before the IS is allowed access to the data stored on the PICC. In addition, BAP ensures that communication between the IS and the PICC (once access is authorized) is protected.

NOTE Although BAP was designed for PICCs, it can also be used to satisfy a variety of functional requirements for ICs with contacts as listed in Table 1.

This mechanism is limited to PICCs and ICs with contacts.

For a SIC that is accessed via a contactless interface and protected by the BAP, mechanism shall deny access to its content by the contactless interface unless the IS can prove that it is authorized to access the SIC. This proof shall be given in a challenge-response protocol, where the IS proves knowledge of the PICC-individual document basic access keys (KENC and KMAC) that are derived from the input string.

After the IS has been authenticated successfully, the SIC shall enforce encryption and message authentication of the communication channel between the IS and the SIC by Secure Messaging techniques.

The document basic access keys are stored in the internal elementary file (see ISO/IEC 7816-4).

A SIC that supports BAP shall respond to unauthenticated read attempts (including selection of files in the logical data structure) with ‘Security status not satisfied’ (0x6982). The presence of BAP thus is determined by an IS from the response to read attempts (see below) and the subsequent success in locating the SAI.

BAP is specified in Annex B. The following shall be used in the application of Annex B:

a) the reference string shall be used as the document keying material (Kdoc);

b) the IS can automatically read the input string or can allow an operator to manually enter the input string (if present) into the IS;

c) the first byte of the input string shall identify the BAP configuration used.

NOTE BAP is intended mainly as an anti-skimming mechanism. However, provided that the entropy of the reference string is commensurate with the IA’s assessment of the threat, this mechanism can also serve as protection against eavesdropping.

IA’s may optionally add the BAP logo to an IDL to indicate that the SAI contains a BAP input string.

Figure 16 shows the BAP logo while Figure 17 shows the BAP logo on IDL. The minimum dimensions of the A-dimension of the logo shall be 5 mm, and the B-dimension shall be scaled proportionally in a ratio of 5:3. It is recommended that the BAP logo be placed in close proximity to the associated SAI.

Key

1 B-dimension

2 A-dimension

Figure 16 — Basic access protection logo (not to scale)

Figure 17 — Basic access protection logo on IDL (not to scale)

EXAMPLE Suppose the following barcode is printed on the IDL:

This barcode encodes the string “1462483345434115654434034118361284817041”, whose hexadecimal rendering is ‘31 34 36 32 34 38 33 33 34 35 34 33 34 31 31 35 36 35 34 34 33 34 30 33 34 31 31 38 33 36 31 32 38 34 38 31 37 30 34 31’

The first byte (‘31’) of the input string indicates BAP configuration 1. The entire input string is used as K_doc. The resulting derived document access keys are:

— K_enc: ‘E4 80 0E 99 54 FF 39 EB F6 09 15 FD 46 C4 3F DD’

— K_mac: ‘E7 EA 15 4F ED 39 38 77 A1 12 9D CB 7A 54 93 50’

The barcode in this example contains 40 numeric digits. As the first byte conveys predictable information, only the following 39 bytes may contribute entropy. Assuming they were generated randomly, the resulting K_doc contains log2(10³⁹)≈129 bits of entropy.

EACv1 consists of:

a) chip authentication, which provides for authentication of the SIC and strong secure messaging, and

b) terminal authentication, which provides for conditional authenticated access to data groups.

This mechanism is applicable only to SICs.

EACv1 is defined in Annex D.

This document only supports EACv1 Chip Authentication with the ECDH mechanism.

This document only supports EACv1 Terminal Authentication with the ECDSA mechanism.

The following rules shall be used in the application of EACv1 for an IDL:

a) The SIC’s key agreement public key(s) shall be stored in DG14, formatted in accordance with BSI/TR 03110-3.

b) If BAP is performed before EACv1, the driving licence number, as it appears in DG1, shall be used as SIC identifier (IDSIC). If PACE is performed before EACv1, the SIC identifier (IDSIC) is computed from the SIC’s ephemeral PACE public key, i.e. IDSIC=Comp(PKSIC).

c) Strong secure messaging (established using chip authentication as described in BSI/TR 03110) shall be active before terminal authentication can take place.

d) DG14 shall be accessible without terminal authentication.

The PACE protocol confirms that an IS has physical access to a SIC before the IS is allowed to access to the data stored on the chip. Once access is authorized, PACE protects the subsequent communication by a secure channel between SIC and IS. The PACE protocol can be used as an alternative to BAP and allows various implementation options (mappings, input strings, algorithms).

This mechanism is applicable only to SICs.

PACE is defined in Annex C. This document only supports PACE with ECDH generic mapping. The first byte of the input string shall be ‘50’ (“P”) if PACE is used as a stand-alone protocol, i.e. not used in conjunction with BAP configuration 1.

If PACE is used to gain access to the SIC, the SIC shall deny access to the content of the IDL application by its interface unless the IS can prove that it is authorized to access the SIC. This proof is given in a password authenticated Elliptic Curve Diffie Hellman key agreement protocol where the IS proves its knowledge of a SIC-specific key K_π, which is derived from the input string.

After the IS has been authenticated successfully, the SIC shall enforce encryption and message authentication of the communication channel between the SIC and the IS by Secure Messaging techniques.

PACE shall be performed in the master file (MF) of the SIC. The SIC provides the relevant SecurityInfos in a transparent EF.CardAccess contained in the MF (and additionally in DG14 contained in the IDL application). Due to the execution on MF level, PACE provides an application independent authentication between IS and SIC that may also be used to get access to potential other domestic applications on the SIC.

The chip access procedure shall be in accordance with ICAO Doc 9303-11:2021, 4.2. The SecurityInfos shall be in accordance with ICAO Doc 9303-10:2021, 3.11.3 and ICAO Doc 9303-11:2021, 9.2.11.

PACE differs from BAP in the following respects:

a) PACE introduces a mandatory master file (MF) structure.

b) PACE requires an EF.CardAccess file within the MF.

c) Security conditions are established at MF level for PACE.

d) The IDL application is selected by secure messaging using session keys derived in accordance with the PACE procedure.

In relation to BAP, the PACE protocol has the following advantages:

a) Strong session keys are provided independent of the strength of the input string.

b) The entropy of the input string(s) used to authenticate the IS can be very low (e.g. 6 digits are sufficient in general).

c) The binding between PACE and a Terminal Authentication is universal and does not depend on the input string.

The BAP logo in 8.5 may be used to denote the presence of an input string for PACE.

The security mechanism(s) deployed on an IDL with an SIC can be identified to reading authorities by the addition of tag ‘86’ to EF.COM. Tag ‘86’ identifies the data groups subject to each mechanism used.

NOTE Use of the security mechanism indicator is optional unless a mechanism mandates the security mechanism to be used.

Tag ‘86’ shall have the following DER-encoded ASN.1 TLV structure:

SecurityMechanisms ::= SET OF SecurityMechanism

SecurityMechanism ::= SEQUENCE {

mechanism MechanismIdentifier,

datagroups SET OF INTEGER}

MechanismIdentifier ::= SEQUENCE {

mechanism OBJECT IDENTIFIER,

parameters ANY DEFINED BY mechanism OPTIONAL}

EXAMPLE Assume an implementation using LDS version 1.0 having the following data content – mandatory data (DG 1), optional licence holder data (DG 2), and optional finger biometric template (DG7). The optional finger biometric template is protected using EACv1 (see Annex D). The implementation makes use of the file identifier ’55 66’ for EF.CVCA and does not specify a short EF identifier.

EF.COM would be encoded as follows (in order to improve clarity, tags are printed in ITALIC, lengths are UNDERLINED and values are printed in normal text):

where ‘31 28 30 21 … 01 07’ is the following DER-encoded ASN.1 structure:

SET

SEQUENCE

SEQUENCE

OBJECT IDENTIFIER: 0.4.0.127.0.7.2.2.2

SEQUENCE

OBJECT IDENTIFIER: 0.4.0.127.0.7.2.2.2

INTEGER: 01

SEQUENCE

OCTET STRING:55 66

SET

INTEGER: 07

In addition to the data groups identified in ISO/IEC 18013-2:2020, Figure C.1, this document defines the data groups shown in Table 12 and Figure 18. The file structure for an IDL which supports PACE is shown in Figure 19. All tags used are listed in Annex F.

Table 12 — Assignment of file identifiers and Data Group Tags

Figure 18 — Data groups

NOTE This EF can contain software functions supporting especially command chaining and extended Lc/Le field.

Figure 19 — File structure for an IDL supporting PACE

EF.SOD is defined in 8.1.5.1.

DG12 is defined in 8.4.4.

DG13 is defined in 8.2.4.1.

NOTE '6F' is nested within DO '7E' when used as file control information template for ISO/IEC 18013 (all parts).

DG14 is defined in Annex D for EACv1.

If PACE is supported, additional DG14 content is defined in Annex C.

NOTE See ICAO Doc 9303-11:2021, 9.2.11.

EF.CardAccess is defined in Annex C for PACE.

NOTE See ICAO Doc 9303-10:2021, 5.3.1.

1. 
   (informative)
   
   Public key infrastructure (PKI)
   1. General

This annex suggests a structure for a public key infrastructure specifically in respect of IDLs that are used internationally. Such a use environment poses unique challenges, primarily the infeasibility of any one issuing jurisdiction to conclude, implement and maintain key sharing agreements and infrastructures with all other issuing jurisdictions (given the assumption that a “super certification authority” that controls and issues keys globally is not available).

The concepts in this annex were developed from first principles, and explore the functional and logical aspects of a PKI. Standardisation of technical aspects relating to implementation (e.g. certificate formats) are outside the scope of this annex, although some issues that would need standardisation are pointed out. Consequently, this annex describes the mechanisms to establish a “trust model” more than it describes a traditional PKI.

The trust model described in this annex is based on a “trust by proxy” principle, i.e. A trusts C because A trusts B and B trusts C. Consequently, the ultimate responsibility to establish trust in a public key remains with the RA (also see Annex B dealing with trust establishment). The trust model should not be seen as infallible confirmation of the origin and integrity of a public key.

• 1. PKI design principles

In addition to the principle stated in A.1, the trust model was designed to comply with the following principles:

a) No central CA is available.

b) The trust model should exploit existing trust relationships.

c) The rules for setting up and maintaining the trust network should not require any one entity to manage the trust network, but should allow for the trust network to essentially manage itself.

d) Use a two-level key approach, consisting of a root key-pair and a document key pair. The document key pair is used to sign and verify an IDL, and the root key pair is used to sign and verify the document key and other information as described below. Public root keys are to be exchanged by out-of-band means.

NOTE 1 A one-level key approach is possible but less appropriate given that keys used to sign IDLs are replaced periodically.

NOTE 2 In this context, “sign” means that a private key is used to create a digital signature for a certificate that contains a public key and/or other information.

NOTE 3 Given the autonomy of each country, and the political sensitivities that exist between some, a trust model that uses one global certification authority is considered infeasible.

NOTE 4 Existing trust relationships are an ideal starting point to build a trust network. For example, the American Association of Motor Vehicle Administrators (AAMVA) already has trust relationships established with most IA’s in North America. In Southern Africa, the Southern Africa Development Community (SADC) has relationships set up with all the countries in Southern Africa, with a similar function performed by the Economic Community of West African States (ECOWAS) in West Africa, and the Common Market for Eastern and Southern Africa (COMESA) in Eastern and Southern Africa. In Europe, the European Commission has relationships with numerous IA’s.

• 1. General description

NOTE 1 The trust model is somewhat similar to the user-centric trust model employed by PGP, and as discussed in Reference [4].

Each IA generates two sets of key pairs, a root key pair, and a document key pair. The IA signs its own public root key using its private root key. This means that the IA certifies that the public root key is associated with the IA. In a more traditional environment, a CA would sign e.g. IA A’s public root key, thus certifying the association between the public root key and IA A. If IA B trusts the CA, IA B would then also trust the association between IA A and its public root key. If IA A self-signs its public root key, and IA B trusts IA A, a CA becomes superfluous (at least for the purpose of associating IA A with its public root key). The public root key is distributed out-of-band only. The public document key is also signed with the private root key. For standard encoding, the public document key may optionally be distributed with the IDL.

NOTE 2 The root key as used in this document is similar to the Country Signing CA Key in the ICAO PKI Specification (see Reference [9]).

NOTE 3 The document key as used in this document is similar to the Document Signer Key in the ICAO PKI Specification (see Reference [9]).

NOTE 4 ICAO’s PKI Specification (see Reference [9]) mentions the out-of-band confirmation of a root public key, thus inferring that the actual distribution of such keys may take place separately from the out-of-band confirmation, possibly using “in-band” communication.

As noted above, it is infeasible to expect each IA’s public root key to be distributed (out of band) to every other IA. Consequently, if IA A trusts IA B, then IA A would also like to know who else IA B trusts. IA B thus needs to publish (see A.4.1 for a discussion of the term “publish”.) a list (signed with IA B’s private root key) of the IAs (including IA A, if applicable) that it trusts. IA B also signs the public root key of each IA in IA B’s trust list, and publishes all the signed public root keys. B thus publishes the documents (or certificates) shown in Figure A.1.

NOTE 5 IA B would presumably (but not necessarily) only directly trust those IAs for which it has received the public root key in an out-of-band fashion.

NOTE 6 In addition, IA B would also publish information on IA B’s public keys used to sign IDLs. This however does not directly pertain to the trust network, and is only discussed later.

Figure A.1 — Certificates published by an IA

If every IA publishes the same items that IA B publishes (i.e. a signed trust list, and signed public root keys of each authority on the trust list), it enables IA A to construct a diagram of the complete trust network. For example, if IA B trusts IA C, IA A uses IA C’s public root key (signed by IA B), to verify IA C’s trust list. If IA C trusts IA D, IA A uses IA C’s public root key to verify IA D’s public root key, and then verifies IA D’s trust list, and so on. IA A thus compiles a trust network diagram which can be used to verify any IDL presented.

NOTE 7 The trust network diagram includes all the public keys, lists and other information required to verify an IDL in an off-line manner. Typically, the trust network diagram is updated periodically (e.g. daily), and used as reference for all internal verification actions.

The above allows IA A to verify the public root key of each IA (in the trust network). The public root key then is used to verify the public document keys published by each IA.

Public root keys distributed between IAs in an out-of-band fashion essentially become trust anchors, and should be stored, protected and used in an appropriately secure manner.

NOTE 8 The proposed trust model requires the unrestricted availability of the public root key. The ICAO PKI Specification (see Reference [9]) however appears to discourage such availability of ICAO’s equivalent of the public root key.

It is anticipated that the global trust network will eventually consist of a collection of “local” trust networks, with the different local trust networks connected by a limited number of trust “links”. For example, in the Southern Africa Development Community (SADC), South Africa may act as an aggregator for the SADC countries. That is, each SADC country exchanges public root keys (out-of-band) only with South Africa, and vice versa. South Africa then signs each public root key, and publishes same along with the list of all SADC countries. In the European Union (EU), the European Parliament may decide to act as a central trust broker, or PIA. That is, the EU obtains the public root key for each IA in the EU, signs it with the EU private root key, and publishes same. The American Association of Motor Vehicle Administrators (AAMVA) may fulfil a similar function in North America. Figure A.2 illustrates an example of a trust network.

Figure A.2 — Trust network example

• 1. Implementation
     1. Publication mechanism

It is suggested that the information to be published, be published (as signed certificates) in a location that is easily accessible by all verifying entities. Consequently, each IA’s identifying details should include directions on how and where published information can be accessed.

NOTE The Internet would be a location that complies with the above accessibility requirements. However, security concerns have been expressed about using the Internet. If the Internet is used, a requirement to use server side authenticated SSL (similar to the ICAO requirement) for all communication can be added to enhance security. This implies that each IA will have to obtain a single server key from a commercial party. The disadvantage of alternative publication locations in general is that they may not be readily accessible to all verifying entities (with the potential for consequential difficulties for the IA’s card holders). In the end, it remains the responsibility of the IA to select a suitable publication location.

The security of the publication location is the responsibility of each IA. However, the authenticity of all published information can be verified using the IA’s public root key, thus adding an additional layer of security to published information.

It follows that in cases where an IA may not have the necessary infrastructure or expertise or may not want to publish and/or maintain published information in-house, such publication may be performed (under agreement) by other IAs or trusted third parties.

The availability of published information is crucial. If published information is not available, a verifying entity cannot update its trust network diagram, and thus will be unaware of any changes in the trust network diagram such as new document keys issued, document keys revoked, or IAs removed from the trust network. Thus, this approach is vulnerable to a denial of service attack (see A.7.3).

• • 1. Information published

As discussed in A.3, each IA (in its role as VA) publishes a trust list and the public root key of each IA on the trust list. Each of these documents is signed with the publishing VA’s private root key.

Each VA may optionally also publish the network trust diagram that it has constructed. Such a published network trust diagram can potentially be referenced by local industry (e.g. airlines and car hire companies) as a primary source to verify foreign driving licences.

NOTE In a sense, a published trust network diagram is similar to the public key directory defined in the ICAO PKI Specification (see Reference [9]), with the difference that it is intended for local use only. However, nothing prevents a company in e.g. Australia to use (because it trusts) a network trust diagram published by e.g. Germany.

The VA (if it is also an IA) also publishes its own public document keys.

A standard format for each of the above documents (or certificates) has to be specified.

• 1. Certificate content
     1. General

In considering certificate content, cognizance was taken of industry experts’ recommendations that X.509 certificates should only be used if absolutely necessary (see Reference [5] BSI Technical Guideline TR-03110-1 and BSI Technical Guideline TR-03110-3). Consequently, and in keeping with the intent of this annex (see A.1), the certificate content proposed below is based solely on the functional requirements pertaining to the IDL environment and the proposed trust model. The actual certificate profile eventually specified may or may not be X.509 compliant.

NOTE X.509 compliancy has advantages and disadvantages, which need to be carefully considered by an IA prior to implementation. The disadvantages are discussed in the noted references, and in essence involve unneeded complexity and questionable “fitness for purpose”. The disadvantage to using a non-X.509 certificate is that IAs’ existing environments may already be set up to accommodate only X.509 certificates.

• • 1. Verification processes

As mentioned above, the functional processes drive the certificate contents. This clause discusses the processes involved.

When a public document key certificate needs to be verified, the following steps are executed:

a) Identify the IA that signed the certificate. Primary identification is based on the ISO Issuer Number in Data Group (DG) 3 (this field thus becomes mandatory if a digital signature is used). Additional identification information includes directions on how and where information published by the IA can be accessed.

b) Using a trust network diagram, identify the IA’s public root key(s). If the IA has published more than one root key, identify the public root key used associated with the public document key certificate.

NOTE If the IA does not appear on the VA’s trust network diagram, the public document key certificate cannot be verified. The IA first has to be added to the VA’s trust network diagram via the out-of-band exchange of the IA’s public root key with any of the existing IAs on the VA’s trust network diagram.

c) Use the IA’s public root key to check the public document key certificate’s digital signature. This requires knowledge of the digital signature algorithm (and accompanying parameters) used. The algorithm and parameters are specified in the public document key certificate.

d) Verify that the public document key is still valid, that is, that the document key has not been revoked yet. This can be set up in either of the following ways:

1) Use certificate revocation lists.

2) Use a “Revoked Y/N” field in the public document key certificate (this field would always be “N” for a public key certificate included on the IDL; only public keys published by the IA can have a“Y” value for this field.). This is unusual in that it implies that a certificate for the same key can be issued twice. However, it also negates the need for certificate revocation lists (refer to A.6.2 for more information), thus reducing the complexity of the overall solution.

When an IDL needs to be verified, the following actions are involved.

a) Identify the IA. The same identification process as for the public document key certificate verification is followed.

b) Obtain the correct public document key. Regardless of whether or not the public document key is included on the IDL, an attempt should be made to obtain the public document key from the appropriate public document key certificate on the IA’s publication area (or alternatively as included in the VA’s most recent trust network diagram).

c) For compact encoding, the appropriate public document key can be identified using the hash value of the signer certificate. For standard encoding, the appropriate public document key can be identified using a key identifier.

d) Verify the public document key certificate, as described above.

e) Check the digital signature on the IDL using the public document key. This requires knowledge of the digital signature algorithm and parameters used to sign the IDL. This information is stored in DG.SOD (for both compact encoding and standard encoding).

• • 1. Document key

Based on the discussion in A.5.1, a public document key certificate should contain the following information:

a) IA identifying details;

b) public document key;

c) public document key identifier (if dates are not used to identify the public document key);

d) identifier of the public root key used to sign the document public key certificate (if dates are not used to identify the public root key);

e) beginning (and ending) issuing dates for which the key is valid (at the time of signing the certificate) (if dates are used to identify the public document key);

f) digital signature algorithm and parameter information;

g) revocation indicator (Yes/No);

h) revocation date (mandatory if revocation indicator is Yes) (if dates are used to identify the public document key);

i) notes (optional), which can be used to add additional information regarding the revocation, in English, French or Spanish if required;

j) date of signing (if dates are used to identify the public root key), which is used to identify the private key that was used to sign the certificate; this is optional if the public key is included on the IDL, as it can be assumed that the date of signing is the same as the IDL issue date; digital signature (assuming a digital signature with appendix scheme).

k) digital signature (assuming a digital signature with appendix scheme).

• • 1. Root key

Based on the discussion in A.5.1, a root key certificate should consist of the following information:

a) IA identifying details;

b) public root key;

c) public root key identifier (if dates are not used to identify the public root key);

d) beginning (and ending) signing dates for which the key is valid (at the time of signing the certificate);

e) date of signing (optional);

f) digital signature (assuming a digital signature with appendix scheme).

Note that whenever a private document key is compromised, all the documents signed with the private key become suspect (and not only those documents signed prior to the compromise).

• • 1. Certificate profiles
       1. Overview

The certificate profiles defined in this clause are mandatory for IDLs and IDL readers.

The IACA root certificate is the root certificate used to issue all end-entity certificates. The allowed usage of the end- entity certificates is defined using the extended key usage extension. All end-entity certificates signed by an IACA root certificate shall contain the same country code as the IACA certificate. An IACA certificate may contain the stateOrProvinceName element to indicate that this IACA certificate only issues IDLs within a particular state or province. If the element is present in an IACA certificate, it shall also be present and have the same value in the end-entity certificates signed by that IACA certificate.

The IACA root certificate shall use the IACA root certificate profile as defined in ISO/IEC 18013-5:2021, B.1.2.

If an IACA link certificate is created, it shall use the IACA link certificate profile as defined in ISO/IEC 18013-5:2021, B.1.3.

For EF.SOD (see 10.2), the issuing authority shall use the document signer certificate profile as defined in A.5.5.2.

The CRL indicated in an IACA root certificate, an IACA link certificate and any certificate signed by and IACA root certificate shall comply with the requirements in ISO/IEC 18013-5:2021, Clause B.2. All certificates shall be DER encoded.

For each certificate profile, the presence column indicates whether an element is mandatory (M), optional (O) or conditional (C). The criticality column indicates whether an element is critical (C) or non-critical (NC).

The following extensions shall not be used:

— PolicyMappings,

— NameConstraints,

— PolicyConstraints,

— InhibitAnyPolicy,

— FreshestCRL.

Certificates in this clause use OIDs for extended key usage extension. The OIDs have the following definition:

— id-idl OBJECT IDENTIFIER ::= { iso(1) standard(0) 18013 3 },

— id-idl-kp OBJECT IDENTIFIER ::= { id-idl 1 } - - arc for extended key purposes,

— id-idl-kp-idlDS OBJECT IDENTIFIER ::= { id-idl-kp 2 } - - arc for IDL DS,

— id-idl-kp-idlReaderAuth OBJECT IDENTIFIER ::= { id-idl-kp 6 } - - arc for IDL reader authentication used by mDL readers,

— id-idl-kp-idlIACALink OBJECT IDENTIFIER ::= { id-idl-kp 4 } - - arc for iDL IACA Link, — id-idl-kp-idlIACA OBJECT IDENTIFIER ::= { id-idl-kp 7} – arc for IDL IACA.

The issuing authority that provided both IDL and mDL can use OIDs specifies in ISO/IEC 18013-5.

• • • 1. IACA root certificate

The certificate profile for IACA root certificate is as specified in ISO/IEC 18013-5:2021. B.1.2.

• • • 1. IACA link certificate

The certificate profile for IACA link certificate is as specified in ISO/IEC 18013-5:2021. B.1.3.

• • • 1. Document signer certificate

This certificate is used to sign the document security object which is included in EF.SOD.

Table A.1 — Document signer certificate

• 1. Key revocation
     1. Root key compromise

A private root key compromise has the following far-reaching consequences:

a) none of the documents signed with the private root key can be considered “safe” anymore;

b) the IA (whose private root key has been compromised) is effectively deleted from the trust network.

Due to the above, notification via publication (as defined in A.4.1) is infeasible. The fact that the private root key has been compromised can be published, but technically no VA will be able to verify such information, since there is no way in which the compromised IA can sign such publication.

In case of a compromise, the compromised IA thus has to notify all the immediate VAs of the compromise in an out-of-band fashion. Following such notification, the immediate VAs have to immediately remove the compromised IA from their trust lists (and their trust network diagrams). The compromised IA now has to create a new root key pair and distribute the new public root key to the immediate VAs. At the same time, the compromised IA has to resign all other information that it wishes to publish, e.g. the trust list, public root keys for the IAs on the trust list, and the compromised IA’s existing public document keys.

It thus is in each IA’s best interest to communicate any compromise as expediently as possible to all immediate VAs. To this end, each IA should keep a list of all its immediate VAs. It is also recommended that the compromised IA re-obtain (out-of-band) the public root keys of the IAs in the compromised IA’s trust list, to ensure that the public keys re-signed and re-published by the compromised IA (with the IA’s new root private key) are in fact the correct keys.

NOTE The list of an IA’s immediate VAs is not necessarily the same as the IA’s trust list. An IA may not trust all the VAs to which it provided a copy of its public root key (by out-of-band means).

For non-immediate VAs, the compromised IA’s public root key is essentially revoked when the compromised IA is removed from the immediate VAs’ trust lists. Each VA thus needs to carefully consider the frequency with which it updates its trust network diagram.

• • 1. Document key compromise

The compromise of a private document key is easier to communicate and process than in the case of a private root key. When a private document key is compromised, the compromised IA (i.e. the IA whose private document key was compromised) simply re-publishes the public document key associated with the compromised private document key with the value of the “Revocation indicator” field set to “Y”, and (if necessary) the value of the ending issuing date associated with the compromised public key set to the date the private document key was last used to issue an IDL.

This approach does away with the need to maintain certificate revocation lists. The compromised key is noted as such by any other VA the moment the VA updates its trust network diagram.

• 1. Trust model weak points
     1. Overview

The trust model presented in this annex is to a large extent predetermined by the design principles and constraints stated in A.2. However, since no trust model is perfect, it is important to also take note of the weak points of the model, so that these can be adequately addressed. This subclause points out some of the weak points of the trust model. Weak points concerning other areas (e.g. testing, issuing, document security) are not discussed here.

• • 1. General

One of the inherent weaknesses of the “trust by proxy” approach is that VAs may not all have the same criteria for measuring trustworthiness. If IA A trusts IA B and IA B trusts IA C, but IA A and IA B do not use the same criteria to determine trustworthiness then IA C does not necessarily comply with IA A’s trustworthiness criteria, even though the “trust by proxy” approach would imply that IA A can trust IA C.

The trust chain can also become rather long, introducing ever more opportunity for a trust breakdown. A solution to this conundrum is for a VA to adapt its trust network (within the constraints imposed by cost and logistical considerations) so that higher volume IDL verifications “flow” over shorter trust chains. That is, a VA could establish direct trust relationships in such a manner that it minimizes the sum of chain lengths for all IDLs verified.

NOTE This approach does not guarantee the lowest probability of letting a problematic IDL slip through. Knowing about the above approach, criminals can specifically target the end points of long trust chains in a VA’s trust network in their attempts to circumvent the system.

If a breakdown in trust occurs or is suspected (i.e. it is determined or suspected that an IDL is verified when it shouldn’t have been, or vice versa), the point where it is discovered may be several trust points removed from the IA. The longer the trust chain involved, the more cumbersome it becomes to confirm a trust breakdown and to identify the point of compromise. As described above, minimizing the sum of chain lengths for all IDLs verified can minimize this problem.

A VA may include an IA in a trust list for political reasons, even if the VA does not trust the IA internally. Even though such conduct would effectively sabotage the trust model, it cannot be ruled out. Consequently, it is important that VAs augment the trust model with other methods of establishing trust in an IDL issued by an IA.

• • 1. Attacks

In general terms, (at least) the following attacks are possible against any two-level PKI:

a) obtain private root key;

b) replace private root key;

c) replace trusted root key;

d) obtain private document key;

e) replace private document key;

f) replace trusted document key;

g) denial of service attack.

The above attacks can take many shapes and forms, some of which are unique to the trust model used, and others that would be applicable regardless of the trust model. The paragraphs that follow discuss some of the attacks that are specific to the proposed trust model.

The distributed nature of the proposed trust model requires each IA to take responsibility for the safekeeping of its own private keys. The general level of security which an IA is capable of or willing to employ, or the conscientiousness with which it follows its security procedures, may be less than would have been the case with one central (or even more than one) commercial certification authority. This can create a weak spot in the proposed trust model.

Trust in a public root key is established by exchanging such keys by out-of-band means. The main attack on such an exchange would be to replace the public key somewhere in the process. IAs should be aware of this risk, and implement appropriate procedures to secure their out-of-band key exchanges.

Several attacks against published information (e.g. trust lists, public root and document keys) are possible. The appeal of some of these attacks, and the expected duration before the attacks are uncovered, are related to the frequency with which a trusted root public key is used to verify certificates that were supposed to be signed by the trusted root public key (essentially the frequency with which the trust network diagram is verified). Other attacks (on published information) are not influenced by the frequency of trust network verification. These attacks are however likely to be uncovered over time, when it is realized that IDLs that do not verify is due to incorrect public keys being used to try and verify authentic IDLs.

A variant on the published information attack is to try and sneak the details of a fictitious IA into the trust list and public keys published by an existing IA. Although this would require some inside help (as the information has to be signed using the existing IA’s private root key), this subterfuge can potentially remain undetected.

Denial of service attacks could be used on their own or in conjunction with some of the attacks mentioned above. A denial of service attack will prevent a VA from updating its trust network diagram, creating opportunities for many other attacks.

The ultimate decision on which IAs to trust and which IAs not to trust lies with the VA. Setting up and maintaining a trust network diagram thus requires active involvement from the VA. Any VA that does not take this responsibility seriously or does not allocate sufficient resources can become a liability for the whole trust network.

The bigger and more complex a trust network diagram becomes, the more opportunity there is for situations arising that require manual decision-making.

EXAMPLE 1 IA A has immediate VAs B and C. VA D’s trust network diagram has paths to both VA B and VA C. For some reason, VA B removes IA A from its trust list. Does VA D now also remove IA A from its trust network diagram?

EXAMPLE 2 After investigating IA B’s security procedures and practices, VA A decides not to include IA B in its trust list. However, VA A does include IA C in its trust list, and IA C includes IA B in its trust list. VA A thus has to manually ensure that IA B is not included in its trust network diagram.

1. 
   (normative)
   
   Basic access protection
   1. General

BAP is a mechanism and protocol to protect identity documents with a SIC against skimming attacks. This protection is achieved by requiring the establishment of a secure channel using pre-defined key material which should only be revealed by closer physical inspection of the document, before access is granted to information stored in the SIC.

The secure channel protects the integrity and authenticity of authorized communication between an IS and an identity document. If the entropy of the key material is high enough, a certain amount of protection against eavesdropping attacks is also achieved.

NOTE 1 Because the same pre-defined key material is used for all communication sessions with a given document, this protocol does not give forward-secrecy. This means that, if knowledge about the keying material is gained, it can be used to decrypt any past sessions. However, knowledge of a particular session’s session keys does not enable the decryption of past or future sessions.

NOTE 2 This protocol is based on ICAO’s Basic Access Control.

It is not recommended to use BAP configuration 1 for new projects.

• 1. Parameters

Referring specifications shall specify the following when referencing BAP:

a) the source of K_doc;

b) the method(s) by which K_doc is entered into the IS.

NOTE This document uses information printed on the IDL in machine and/or human-readable form as K_doc. The SAI demarcates the information used. The first byte of the input string indicates the use of BAP and has the value “1”. For further details, see 8.3 and 8.5.

• 1. Protocol

BAP comprises the following steps:

a) Document basic access keys are established using the key derivation mechanism described in B.4.

b) The IS and the SIC mutually authenticate and derive session keys. The authentication and key establishment protocol described in B.5 is used.

c) After successful authentication, subsequent communication is protected by Secure Messaging as described in B.6. Access shall only be granted as long as secure messaging is active.

• 1. Key derivation mechanism

The following key derivation mechanism is used to derive keys from a key seed (K_seed) for both the establishment of the document basic access keys and the establishment of the session keys for secure messaging.

A 32-bit counter c is used to allow for deriving multiple keys from a single seed. Depending on whether a key is used for encryption or MAC computation, the following values shall be used:

— c = 1 (i.e. ‘00 00 00 01’) for encryption;

— c = 2 (i.e. ‘00 00 00 02’) for MAC computation.

The following steps are performed to derive a key K from the seed K_seed and c using the cryptographic hash function h:

a) Let D be the concatenation of K_seed and c (D = K_seed || c).

b) Using h, calculate the hash H of D (H = h(D)).

c) The k leftmost bits of H form the key K.

The document basic access keys K_enc and K_mac are derived using the mechanism described above, with c = 1 and 2, respectively. In addition, the most significant 16 bytes of the h(K_doc) is used as the value for K_seed . h is the selected cryptographic hash function defined the BAP configuration.

K_doc should be different for every document and care should be taken to ensure that K_doc is sufficiently random for the intended application.

NOTE The entropy of K_doc is the upper bound on available entropy for the secure messaging keys. For example, if K_doc only provides 30 bits of entropy, the derived keys cannot contain more – even if the key size is larger.

• 1. Authentication and key establishment

Authentication and key establishment is provided by a three pass challenge-response protocol according to ISO/IEC 11770-2 key establishment mechanism 6 using the selected block cipher. A cryptographic checksum according to the selected MAC algorithm m is calculated over and appended to the cipher texts. The modes of operation described in B.7 shall be used. Exchanged nonces shall have a size of 64 bits, exchanged keying material shall be k bits long. Distinguishing identifiers shall not be used.

In more detail, the IS and SIC perform the following steps.

NOTE The abbreviations IS and SIC used here are equivalent to IFD and ICC, respectively as used in ISO/IEC 7501-1 (ICAO Doc 9303-1).

a) The IS requests a challenge RND.ICC by sending the GET CHALLENGE command.

b) The SIC generates and responds with a random nonce RND.ICC.

c) The IS performs the following operations:

1) Generate a random nonce RND.IFD and random keying material K.IFD.

2) Generate the concatenation S = RND.IFD || RND.ICC || K.IFD.

3) Compute the cryptogram E_IFD = e[Kenc](S).

4) Compute the checksum M_IFD = m[Kmac](E_IFD).

5) Send a MUTUAL AUTHENTICATE command using the data E_IFD || M_IFD.

d) The SIC performs the following operations:

1) Check the checksum M_IFD of the cryptogram E_IFD.

2) Decrypt the cryptogram E_IFD.

3) Extract RND.ICC from S and check if the IS returned the correct value.

4) Generate random keying material K.ICC.

5) Generate the concatenation R = RND.ICC || RND.IFD || K.ICC

6) Compute the cryptogram E_ICC = e[Kenc](R).

7) Compute the checksum M_ICC = m[Kmac](E_ICC).

8) Send the response using the data E_ICC || M_ICC.

e) The IS performs the following operations:

1) Check the checksum M_ICC of the cryptogram E_ICC.

2) Decrypt the cryptogram E_ICC.

3) Extract RND.IFD from R and check if the SIC returned the correct value.

• 1. Secure messaging
     1. General

After a successful execution of the authentication protocol, both the IS and the SIC compute session keys KS_enc and KS_mac using the key derivation mechanism described in B.4 with (K.ICC ⊕ K.IFD) as key seed. All further communication shall be protected by secure messaging (SM) as described in ISO/IEC 7816- 4 according to the requirements below. The modes of operation described in B.7 shall be used.

• • 1. Message structure of SM APDUs

The SM data objects shall be used according to Table B.1 in the following order:

— command APDU: [DO‘87’] [DO‘97’] DO‘8E’;

— response APDU: [DO‘87’] DO‘99’ DO‘8E’.

All SM data objects shall be encoded in BER-TLV as specified in ISO/IEC 7816-4:2013. The command header shall be included in the MAC calculation, therefore the class byte CLA shall be ‘0C’.

The actual value of Lc will be modified to Lc’ after application of secure messaging. In the protected command APDU, the new Le byte shall be set to ‘00’, while the value of the original Le byte may be conveyed in the appropriate data object.

Table A.2 — Usage of SM Data Objects

Figure B.1 shows the transformation of an unprotected command APDU to a protected command APDU in the case that data and Le are available (case 4). If no data is available (case 1 and 2), leave building DO‘87’ out. If Le is not available (case 1 and 3), leave building DO‘97’ out.

Figure B.1 — Computation of a SM command APDU

Figure B.2 shows the transformation of an unprotected response APDU to a protected response APDU in case data is available. If no data is available, leave building DO‘87’ out.

Figure B.2 — Computation of a SM response APDU

• • 1. SM errors

When the integrated circuit in the document recognizes an SM error while interpreting a command, then the secure messaging session shall be aborted and the status words returned in plain. ISO/IEC 7816-4 defines the following status bytes to indicate SM errors:

a) ‘6987’ Expected SM data objects missing

b) ‘6988’ SM data objects incorrect

• • 1. Other errors

In the application context, other errors (i.e. status words other than ’90 00’) may occur that are protected under SM. Under these conditions SM shall not be aborted.

• 1. Modes of operation
     1. Encryption

During encryption, the selected block cipher shall operate in cipher block chaining (CBC) mode with an initialization vector (IV) of n ‘0’ bits.

During authentication, the data to be encrypted shall only be padded if it is not a multiple of the block cipher’s block length n. During the computation of SM APDUs, data shall always be padded.

Padding according to ISO/IEC 9797-1 padding method 2 shall be used.

• • 1. Message authentication

Cryptographic checksums are calculated using the selected MAC algorithm with an initialization vector (IV) of n ‘0’ bits. The MAC length shall be 8 bytes.

After a successful authentication, the datagram to be MACed shall be prepended with an 8 byte send sequence counter (SSC). If the block length n is larger than 64 bits, the SSC shall be prepended by n-64 zero bits to form a full block. The SSC is incremented every time before a MAC is calculated, i.e. if the starting value is x, in the first command the value of SSC is x+1. The value of SSC for the first response is then x+2. The initial value of the SSC is computed by concatenating the four least significant bytes of RND.ICC and RND.IFD, respectively:

SSC = RND.ICC (4 least significant bytes) || RND.IFD (4 least significant bytes)

• 1. Basic access protection configuration

When selecting h, e, n, k and m, IA’s shall pick a valid combination, herein called “configuration”, from the choices in this subclause.

This document supports one configuration, which uses the following algorithms:

— SHA-1 according to ISO/IEC 10118-3;

— TDEA according to ISO/IEC 18033-3:2010 (“Triple DES”);

— ISO/IEC 9797-1 MAC algorithm 3.

NOTE The first edition of ISO/IEC 18013-3:2005 supported multiple BAP configurations. This edition supports BAP configuration 1 only. See Table B.2.

Table A.3 — BAP configuration 1

BAP configuration 1 is equivalent to Basic Access Control (BAC) as described in ICAO Doc 9303-11.

The following ASN.1 object identifier is used to refer to the BAP configuration 1:

bap-config-1 OBJECT IDENTIFIER ::= {

iso(1) standard(0) driving-licence(18013) part-3(3) security-mechanisms(2) id-sm-BAP(1) 1

}

• 1. Card commands
     1. GET CHALLENGE

The GET CHALLENGE command in Table B.3 receives a (true) random challenge from the card for authentication in the subsequent MUTUAL AUTHENTICATE command in Table B.4.

Table A.4 — Command APDU: GET CHALLENGE

Table A.5 — Response APDU: GET CHALLENGE

• • 1. MUTUAL AUTHENTICATE

The MUTUAL AUTHENTICATE command in Table B.5 is used to submit the host cryptogram to the card and receive the card cryptogram in the Response MUTUAL AUTHENTICATE in Table B.6.

Table A.6 — Command APDU: MUTUAL AUTHENTICATE

Table A.7 — Response APDU: MUTUAL AUTHENTICATION

• 1. Worked example (informative)

This subclause provides a worked example for BAP configuration 1. Note that not all steps are explicitly shown.

Static document keying material:

K_doc = ‘31239AB9CB282DAF66231DC5A4DF6BFBAE’

Computation of basic access keys:

Authentication and Establishment of Session Keys:

Command APDU:

Response APDU:

Secure Messaging:

IS

1. SELECT EF.COM (file identifier = ’01 1E’):

Unprotected command APDU:

a) Mask class byte and pad command header:

cmd_header = ’0CA4020C80000000’

b) Pad data:

p_data = ’011E800000000000’

c) Encrypt p_data using TDEA with KS_enc:

enc_data = ’6375432908C044F6’

d) Build DO‘87’:

DO87 = ’8709016375432908C044F6’

e) Concatenate cmd_header and DO87:

M = ’0CA4020C800000008709016375432908

C044F6’

f) Compute “Retail MAC” of M with KSmac:

g) Build DO‘8E’:

DO8E=’8E08BF8B92D635FF24F8’

h) Construct command data:

cmd_data = ’

‘8709016375432908C044F68E08BF8B92D635FF24F8’

Protected command APDU:

Document SIC:

1. Set EF.COM as the currently selected file and send affirmative response to IS:

Unprotected response APDU:

a) Build DO‘99’:

DO99=’99029000’

b) Compute “Retail MAC” of DO99 with KS_mac:

c) Build DO‘8E’:

DO8E = ‘8E08FA855A5D4C50A8ED’

d) Construct response data:

resp_data = ‘990290008E08FA855A5D4C50A8ED’

Protected response APDU:

IS:

2. READ BINARY of the first 4 bytes:

Unprotected command APDU:

a) Mask class byte and pad command header:

cmd_header = ‘0CB0000080000000’

b) Build DO ‘97’:

DO97 = ‘970104’

c) Concatenate cmd_header and DO97:

M = ‘0CB0000080000000970104’

d) Compute “Retail MAC” of M with KS_mac:

e) Build DO‘8E’:

DO8E = ‘8E08ED6705417E96BA55’

f) Construct command data:

cmd_data = ‘9701048E08ED6705417E96BA55’

Protected command APDU:

Document SIC:

3. Return 4 bytes of EF.COM starting at offset 0:

data = ’600D5F01’

Unprotected response APDU:

a) Pad data:

p_data = ‘600D5F0180000000’

b) Encrypt p_data using TDEA with KS_enc:

enc_data = ‘F9435D056E27C52E’

c) Build DO‘87’:

DO87 = ‘870901F9435D056E27C52E’

d) Build DO‘99’:

DO99 = ‘99029000’

e) Concatenate DO‘87’ and DO‘99’:

M = ‘870901F9435D056E27C52E99029000’

f) Compute “Retail MAC” of M with KS_mac:

g) Build DO‘8E’:

DO8E = ‘8E080C15238078E0A4C9’

h) Construct response data:

resp_data = ‘870901F9435D056E27C52E990290008E

080C15238078E0A4C9’

Protected response APDU:

IS:

4. READ BINARY of the remaining 11 bytes:

Unprotected command APDU:

a) Mask class byte and pad command header:

cmd_header = ‘0CB0000480000000’

b) Build DO ‘97’:

DO97 = ‘97010B’

c) Concatenate cmd_header and DO97:

M = ‘0CB000048000000097010B’

d) Compute “Retail MAC” of M with KSmac:

e) Build DO‘8E’:

DO8E = ‘8E0840900A27C4C390D6’

f) Construct command data:

cmd_data = ‘97010B8E0840900A27C4C390D6’

Protected command APDU:

Document SIC:

5. Return 11 bytes of EF.COM starting at offset 4:

data = ‘04303130305C04616B6567’

Unprotected response APDU:

a) Pad data:

p_data = ’04303130305C04616B65678000000000’

b) Encrypt p_data using TDEA with KS_enc:

enc_data = ‘B3CD0334417393661AA9B39206EC89CC’

c) Build DO‘87’:

DO87 = ‘871101B3CD0334417393661AA9B39206

EC89CC’

d) Build DO‘99’:

DO99 = ‘99029000’

e) Concatenate DO‘87’ and DO‘99’:

M =’871101B3CD0334417393661AA9B39206

EC89CC99029000’

f) Compute “Retail MAC” of M with KS_mac:

g) Build DO‘8E’:

DO8E = ‘8E080747E8CEC180EB48’

h) Construct response data:

resp_data = ‘871101B3CD0334417393661AA9B39206

EC89CC990290008E080747E8CEC180EB

48’

Protected response APDU:

1. 
   (Normative)
   
   PACE
   1. General

This annex defines an optional protocol for conditional access to an application that stores data in data groups according to a LDS. PACE may be used as a stand-alone protocol or in conjunction with BAP configuration 1.

PACE is specified in ICAO Doc 9303-11:2021, 4.4.1 to 4.4.5. Specification defined in ICAO Doc 9303-11:2021, 9.1, 9.2 and 9.4 to 9.8 applicable to PACE also apply for IDL in respect of the limitations defined in C.2.1.

After PACE, AES and 3DES shall be applied in Secure Messaging as specified in ICAO Doc 9303-11:2021, 9.8.

It is not recommended to use PACE with 3DES for new projects.

NOTE 1 The Secure Messaging syntax is specified in B.6.

NOTE 2 According to ICAO Doc 9303-11, padding is always performed by the secure messaging layer, so that the underlying message authentication code need not perform any internal padding.

• 1. Changes to ICAO Doc 9303 Part 11
     1. General

This subclause describes the changes that apply to ICAO Doc 9303-11:2021, 4.4.1 to 4.4.5 to support access to the IDL application using PACE.

Only ECDH generic mapping shall be used.

For eMRTD Application, read Driving Licence Application.

For eMRTD, read IDL.

For eMRTD chip or MRTD chip, read SIC.

For MRZ, read input string.

For password, read input string.

• • 1. Key derivation function

The key derivation function for PACE is specified in ICAO Doc 9303-11:2021, 9.7.3. This standard replaces the encoding of passwords with "f (π) = input string".

• 1. Worked example
     1. General

This subclause provides a worked example for PACE. Not all steps are explicitly shown. As a precondition, the MF is selected.

• • 1. Read PACEInfo

1. Select EF.CardAccess (file identifier = '01 1C')

Unprotected command APDU

Unprotected response APDU

2. Read EF.CardAccess

Read the first 8 bytes of EF.CardAccess.

Unprotected command APDU

Unprotected response APDU

resp_data = '31 14 30 12 06 0A 04 00'

Read the rest of EF.CardAccess.

Unprotected command APDU

Unprotected response APDU

resp_data = '7F 00 07 02 02 04 02 02 02 01 02 02 01 0C'

Hex string of EF.CardAccess is '31 14 30 12 06 0A 04 00 7F 00 07 02 02 04 02 02 02 01 02 02 01 0C'

Content of EF.CardAccess in this worked example is described in Table C.1.

Table C.1 — Example content of EF.CardAccess

The BER-TLV structure of public key data object is specified in ICAO Doc 9303-11:2015, 9.4. For convenience, an ASN.1 encoding of the NIST P-256 standard domain parameters is given in Table C.2.

Table C.2 — NIST P-256 standard domain parameters

• • 1. Generate password key K_π

In this worked example, IDL MRZ is used for input string.

IDL MRZ (See Table 9) = D123T09PJ3Y8478FSD<<<<<<<<<<<1

1. Generate an input string from IDL MRZ:

Input string = 123T09PJ3Y8478FSD<<<<<<<<<<<

2. Computation of a shared secret K:

K = '31 32 33 54 30 39 50 4A 33 59 38 34 37 38 46 53 44 3C 3C 3C 3C 3C 3C 3C 3C 3C 3C 3C'

3. Derivation of an encryption key(K_π) from a shared secret K:

Concatenate K and c (c = 3):

D= '31 32 33 54 30 39 50 4A 33 59 38 34 37 38 46 53 44 3C 3C 3C 3C 3C 3C 3C 3C 3C 3C 3C 00 00 00 03'

Calculate Hash of D:

keydata = H_SHA-1(K || c) = '77 E1 7B 6D 08 48 9C B3 5A CC A1 49 E4 50 CA A5 A1 FF 11 1A'

Use octets 1 to 16 of keydata as 128-bit AES key:

K_π = '77 E1 7B 6D 08 48 9C B3 5A CC A1 49 E4 50 CA A5'

• • 1. Application flow of the ECDH-based example

1. MSE Set:AT

The command MSE:Set AT is used to select and initialise the PACE protocol.

2. Encrypted nonce

The SIC randomly generates the nonce s:

Nonce s = " C9 8C FC B4 4F 55 80 1D F5 A6 22 1C 21 CE 1A 61"

The SIC encrypts the nonce s by means of K_π:

Encrypted nonce z = "99 08 FD A7 35 74 0C DE B4 6F 53 AF 8D 87 CF 90"

IS requests encrypted nonce to SIC and SIC responds to IS with encrypted nonce. The encoding of the command APDU and the corresponding response can be found in the following:

The IS decrypts the encrypted nonce z by means of K_π and then gets nonce s.

3. Map the nonce

The nonce is mapped to an ephemeral group generator via generic mapping. Both SIC and IS randomly generate ephemeral key pairs. An ephemeral key pairs example is shown in Table C.3.

Table C.3 — List of randomly chosen ephemeral key pairs (examples)

IS and SIC exchange ephemeral public keys. The encoding of the command APDU and the corresponding response can be found in the following:

SIC and IS compute shared secret H and mapped generator Ĝ as shown in Table C.4.

Table C.4 — Shared secret H and mapped generator (examples)

4. Perform key agreement

In the third step, SIC and IS perform an anonymous ECDH key agreement using the new domain parameters determined by the mapped generator of the previous step. SIC and IS anonymous key pairs are shown in Table C.5.

Table C.5 — List of anonymous key pairs (examples)

The encoding of the key agreement is examined in the following:

SIC and IS calculate the shared secret. Only the x-coordinate of the shared secret is required since the KDF uses only the first coordinate to derive the session keys. The x-coordinate of the shared secret is denoted as K.

Shared secret = '3A DA 9B CA C6 C0 52 14 81 E6 EA C6 FE A2 A0 BD C7 68 E7 25 C0 E5 CD 5D 45 95 C9 1B 46 A4 53 F5 64 74 2F 40 B9 69 15 7A 0F 93 1A 55 79 48 83 D1 8D F5 DA D1 AD 0D 11 2B C6 C8 3E 62 A4 22 4E 90'

K = '3A DA 9B CA C6 C0 52 14 81 E6 EA C6 FE A2 A0 BD C7 68 E7 25 C0 E5 CD 5D 45 95 C9 1B 46 A4 53 F5'

By means of the KDF, the AES 128 session keys KS_ENC and KS_MAC are derived from the shared secret.

Calculate KS_ENC:

keydata = H_SHA-1(K | c) with c = '00 00 00 01'

Use octets 1 to 16 of keydata as 128-bit AES key:

KS_ENC = 'AB FE 8A 37 36 79 80 27 5F 24 8B 74 83 EA 2D 91'

Calculate KS_MAC:

keydata = H_SHA-1(K | c) with c = '00 00 00 02'

Use octets 1 to 16 of keydata as 128-bit AES key:

KS_MAC = 'DE BA B9 8F 2A 3F B7 AF EF 11 1F 16 E7 8D 75 BD'

5. Mutual authentication

The authentication tokens are derived by means of KS_MAC using the input data to calculate T_IS and T_SIC that is shown in Table C.6. Details of these input data are shown in Tables C.7 and C.8.

Table C.6 — Input data for calculating authentication token

Table C.7 — Input data for IS authentication token

Table C.8 — Input data for SIC authentication token

The computed authentication tokens are:

T_IS = '9B A7 F4 9D 3D 54 99 22'

T_SIC = 'B9 F9 B3 63 63 34 6B 34'

Finally, these tokens are exchanged and verified as follows:

1. 
   (Normative)
   
   Extended Access Control v1
   1. General

This annex defines an optional protocol for conditional access to an application that stores data in data groups according to a LDS.

EACv1 is specified by the BSI in the Technical Guidelines TR-03110-1 v2.10 and in TR-03110-3 v2.10. The support of EACv1 requires a BAP configuration 1 or PACE configuration for the IDL.

After EACv1 Chip Authentication, AES and 3DES shall be applied in Secure Messaging as specified in ICAO Doc 9303-11:2021, 9.8.

It is not recommended to use BAP configuration 1 and Chip Authentication with 3DES for new projects.

NOTE 1 The Secure Messaging syntax is specified in B.6.

NOTE 2 Padding is always performed by the secure messaging layer, so that the underlying message authentication code need not perform any internal padding.

• 1. Changes to TR-03110-1 v2.10
     1. Overview

This subclause defines the changes that apply to TR-03110-1 v2.10 to support the IDL.

• • 1. General

For BAC, read BAP.

For DG2, read DG6.

For DG3, read DG7.

For DG4, read DG8.

For DG15, read DG13.

For ePassport, read Driving Licence.

For ePassport Application, read Driving Licence Application.

For ICAO compliant ePassport Application, read Driving Licence Application.

For ICAO/EAC1-compliant ePassport Application, read Driving Licence Application.

For ICAO Active Authentication, read Active Authentication.

For MRTD, read IDL.

For MRTD chip, read SIC.

For MRZ, read input string.

For PCD, read IS/IFD.

For PICC, read SIC.

• • 1. Clauses not applicable to IDL

The following clauses of TR-03110-1 v2.10 are not applicable to the IDL:

a) Clause 1: Introduction, with the exception of clause 1.5 (Requirements for IDL Chips and Terminals) and clause 1.6 (Terminology) that are applicable to the IDL.

b) Clause 2.4.2: Standard Inspection Procedure

c) Clause 3.2: BAC

d) Annex A: Basic Access Control (Informative)

• • 1. Clause 2.1: Driving Licence Application

The Driving Licence Application is defined by ISO/IEC 18013.

• • 1. Clause 2.2: Inspection System

For the entire clause, read:

The Standard Inspection Procedure is not applicable to the IDL and only one inspection procedure is supported, namely the Advanced Inspection Procedure. Consequently, the Basic Inspection System is not applicable to the IDL, only the Extended Inspection System is supported.

For Table 3, read the following table:

Table 3 — Data Groups of the Driving Licence Application

• • 1. Clause 2.4: Inspection Procedures

The Standard Inspection Procedure is not applicable to the IDL and only one inspection procedure is supported, namely the Advanced Inspection Procedure.

• • 1. Clause 3.5: Terminal Authentication Version 1

For the MRTD chip’s Document Number as contained in the MRZ, read the input string.

When EACv1 is used in combination with BAP, the input string of the IDL is used as the ID_PICC.

• 1. Changes to TR-03110-3 v2.10
     1. Overview

TR-03110-3 v2.10 is a “toolbox” similar to ISO/IEC 7816 from which only the “tools” applicable to the application in hand is used. Hence, the “tools” in TR-03110-3 v2.10 that are not applicable to EACv1 are not listed for exclusion in this section.

This subclause describes the changes that apply to TR-03110-3 v2.10 to support EACv1 for the IDL.

• • 1. General

For BAC, read BAP.

For DG2, read DG6.

For DG3, read DG7.

For DG4, read DG8.

For DG15, read DG13.

For ePassport, read Driving Licence.

For ePassport Application, read Driving Licence Application.

For MRTD, read IDL.

For MRTD chip, read SIC.

For MRZ, read input string.

For PCD, read IS/IFD.

For PICC, read SIC.

• • 1. Clause B.8: Reading Data Groups

Replace the content of this clause with the following:

In accordance with ISO/IEC 18013-3 any unauthorized access to EACv1 protected data groups SHALL be denied and the SIC MUST respond with status bytes 0x6982 (“Security status not satisfied”).

• • 1. Clause C.4.1: Inspection Systems

Successful Terminal Authentication shall grant access to all data groups protected by EACv1 with the exception of DG7 and DG8, each of which requires effective authorisation.

For Table 20, read the following table:

Table 20 — Authorization of Inspection Systems

• 1. Security mechanism indicator

SICs that implement EACv1 shall indicate such implementation in the EF.COM file using the security mechanism indicator as specified in Clause 9.

The object identifier for EACv1 shall be id-TA.

The parameters are mandatory and shall be of type param-EAC (same definition as the TerminalAuthenticationInfo in clause A.1.1.3 of TR-03110-3).

param-EAC ::= SEQUENCE {

protocol id-TA,

version INTEGER, -- MUST be 1

efCVCA FileID OPTIONAL

}

id-TA OBJECT IDENTIFIER ::= {

bsi-de protocols(2) smartcard(2) 2

}

FileID ::= SEQUENCE {

fid OCTET STRING (SIZE(2)),

sfid OCTET STRING (SIZE(1)) OPTIONAL

}

The set of data groups shall only contain data groups as specified in D.2.4. Other data groups cannot be protected with EACv1.

When the structure TerminalAuthenticationInfo is present in DG14 as specified in TR-03110-3, it shall contain the same data as param-EAC.

NOTE Unless specified in efCVCA (in param-EAC or TerminalAuthenticationInfo), the EFID/SFI of the EF.CVCA is the one indicated in TR 03110.

1. 
   (normative)
   
   SIC Command set
   1. Class byte

The value for CLA shall be as specified in Table E.1;

— command chaining is supported when both the SIC and the terminal supports command chaining;

— secure messaging is supported;

— logical channel at least channel ‘0’ is supported.

Table E.1 — Class byte

• 1. Command set

The command set shall be as follows:

— SELECT Command (see ISO/IEC 18013-2);

— READ BINARY Command (see ISO/IEC 18013-2);

— GENERAL AUTHENTICATE Command;

— GET CHALLENGE Command;

— EXTERNAL AUTHENTICATE Command;

— INTERNAL AUTHENTICATE Command;

— MUTUAL AUTHENTICATE Command;

— PERFORM SECURITY OPERATION Command (VERIFY CERTIFICATE);

— MANAGE SECURITY ENVIRONMENT Command (SET AT);

— MANAGE SECURITY ENVIRONMENT Command (SET DST);

— MANAGE SECURITY ENVIRONMENT Command (SET KAT).

The details of the commands specified in this document are shown in Table E.2. For reference purposes, the commands specified in ISO/IEC 18013-2 are provided as well.

Table E.2 — Command details

1. 
   (Normative)
   
   List of tags used