INTERNATIONAL ISO/IEC

STANDARD 1 801 3 -3

Second edition
2017-04

Information technology — Personal

identification — ISO-compliant driving
licence —

Part 3:
Access control, authentication and
integrity validation

Technologies de l’information — Identi fication des personnes —

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

Reference number
ISO/IEC 18013-3:2017(E)

I n tern ati o n al Org an i z ati o n fo r S tan d ard i z ati o n

© ISO/IEC 2017
 ISO/IEC 1 801 3 -3 : 2 01 7(E)

Get more FREE standards from Standard Sharing Group and our chats

COPYRIGHT PROTECTED DOCUMENT

© ISO/IEC 2017, Published in Switzerland

All rights reserved. Unless otherwise specified, no part o f 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 o f
the requester.
ISO copyright o ffice
Ch. de Blandonnet 8 • CP 401
CH-1214 Vernier, Geneva, Switzerland
Tel. +41 22 749 01 11
Fax +41 22 749 09 47
copyright@iso.org
www.iso.org

ii
I n tern ati o n al Org an i z ati o n fo r S tan d ard i z ati o n
© ISO/IEC 2017 – All rights reserved
 ISO/IEC 1 801 3 -3 : 2 0 1 7(E)

Contents Page

Foreword .................................................. ................................................... ................................................... ................................................... ............................... v

Introduction .................................................. ................................................... ................................................... ................................................... ..................... vi

1 Scope .................................................. ................................................... ................................................... ................................................... ...................... 1

2 Normative re ferences .................................................. ................................................... ................................................... .............................. 1
3 Terms and definitions .................................................. ................................................... ................................................... ............................. 3
4 Abbreviated terms .................................................. ................................................... ................................................... ...................................... 6
5 Con formance .................................................. ................................................... ................................................... ................................................... .. 8

6 Functional requirements .................................................. ................................................... ................................................... ..................... 8

6.1 Access control .................................................. ................................................... ................................................... .................................. 8
6.2 Document authentication .................................................. ................................................... ................................................... ...... 8
6.3 Data integrity validation .................................................. ................................................... ................................................... ......... 8
7 Mapping o f mechanisms to requirements and technologies .................................................. ............................. 1 1

8 Mechanisms .................................................. ................................................... ................................................... ................................................... . 1 2

8.1 Passive authentication .................................................. ................................................... ................................................... ........... 12
8.1.1 Purpose .................................................. ................................................... ................................................... ......................... 12
8.1.2 Applicability .................................................. ................................................... ................................................... .............. 12
8.1.3 Description ................................................... ................................................... ................................................... ................ 12
8.1.4 Hash function .................................................. ................................................... ................................................... ........... 13
8.1.5 Signing method ................................................... ................................................... ................................................... ..... 14
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 .................................................. ................................................... ................................................... ....... 19
8.3.1 Applicability .................................................. ................................................... ................................................... .............. 19
8.3.2 Description ................................................... ................................................... ................................................... ................ 19
8.4 Non-match alert .................................................. ................................................... ................................................... .......................... 30
8.4.1 Purpose .................................................. ................................................... ................................................... ......................... 30
8.4.2 Applicability .................................................. ................................................... ................................................... .............. 30
8.4.3 Description ................................................... ................................................... ................................................... ................ 30
8.4.4 Mechanism .................................................. ................................................... ................................................... ................. 31
8.5 Basic access protection .................................................. ................................................... ................................................... ......... 32
8.5.1 Purpose .................................................. ................................................... ................................................... ......................... 32
8.5.2 Applicability .................................................. ................................................... ................................................... .............. 32
8.5.3 Description ................................................... ................................................... ................................................... ................ 32
8.5.4 Mechanism .................................................. ................................................... ................................................... ................. 33
8.6 Extended Access Control v1 ................................................... ................................................... ............................................... 34
8.6.1 Purpose .................................................. ................................................... ................................................... ......................... 34
8.6.2 Applicability .................................................. ................................................... ................................................... .............. 34
8.6.3 Description and mechanism .................................................. ................................................... .......................... 34
8.7 PACE .................................................. ................................................... ................................................... ................................................... ... 35
8.7.1 Purpose .................................................. ................................................... ................................................... ......................... 35
8.7.2 Applicability .................................................. ................................................... ................................................... .............. 35
8.7.3 Description and mechanism .................................................. ................................................... .......................... 35
8.7.4 PACE relative to BAP .................................................. ................................................... ............................................. 35
9 Security mechanism indicator .................................................. ................................................... ................................................... .... 3 6
10 SIC LDS .................................................. ................................................... ................................................... ................................................... ............... 3 7
10.1 General .................................................. ................................................... ................................................... ................................................ 37
10.2 EF.SOD – Document security object (short EF identifier = ‘1D’, Tag = ‘77’) ..................................... 39

I n tern ati o n al Org an i z ati o n

© ISO/IEC 2017 – All rights reserved
fo r S tan d ard i z ati o n
iii
 ISO/IEC 1 80 1 3 -3 : 2 01 7(E)

10.3 EF.DG12 Non-match alert (short EF identifier= ‘0C’, Tag = ‘71’) .................................................. ............. 39
10.4 EF.DG13 Active authentication (short EF identifier = ‘0D’, Tag = ‘6F’) ................................................. 39
10.5 EF.DG14 EACv1 (short EF identifier = ‘0E’, Tag = ‘6E’) .................................................. ..................................... 40
10.6 EF.CardAccess i f PACE is supported (short EF identifier = ‘1C’) ................................................... ............ 40
Annex A (informative) Public key in frastructure (PKI) .................................................. ................................................... ............ 41
Annex B (normative) Basic access protection .................................................. ................................................... ..................................... 51
Annex C (normative) PACE ................................................... ................................................... ................................................... .................................. 67

Annex D (normative) Extended Access Control v1 .................................................. ................................................... ......................... 72

Annex E (normative) SIC command set .................................................. ................................................... ................................................... ... 76

Annex F (normative) List o f tags used .................................................. ................................................... ................................................... ...... 78

Bibliography .................................................. ................................................... ................................................... ................................................... .................. 80

Get more FREE standards from Standard Sharing Group and our chats

iv
I n tern ati o n al Org an i z ati o n fo r S tan d ard i z ati o n
© ISO/IEC 2017 – All rights reserved
 ISO/IEC 1 801 3 -3 : 2 01 7(E)

Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that are
members of ISO or IEC participate in the development of International Standards through technical
committees established by the respective organization to deal with particular fields o f technical
activity. ISO and IEC technical committees collaborate in fields o f mutual interest. Other international
organizations, governmental and non-governmental, in liaison with ISO and IEC, also take part in the
work. In the field o f in formation technology, ISO and IEC have established a joint technical committee,
ISO/IEC JTC 1.
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular the different approval criteria needed for
the di fferent types o f document should be noted. This document was dra fted in accordance with the
editorial rules of the ISO/IEC Directives, Part 2 (see www.iso .org/directives ).
Attention is drawn to the possibility that some o f the elements o f this document may be the subject
o f patent rights. ISO and IEC shall not be held responsible for identi fying any or all such patent
rights. Details o f any patent rights identified during the development o f the document will be in the
Introduction and/or on the ISO list of patent declarations received (see www.iso .org/patents ).
Any trade name used in this document is in formation given for the convenience o f users and does not
constitute an endorsement.
For an explanation on the meaning o f ISO specific terms and expressions related to con formity assessment,
as well as information about ISO’s adherence to the World Trade Organization (WTO) principles in the
Technical Barriers to Trade (TBT) see the following URL: www.iso .org/iso/foreword .html .
The committee responsible for this document is ISO/IEC JTC 1, Information technology, SC 17, Cards and
personal identi fication .

This second edition cancels and replaces the first edition (ISO/IEC 18013-3:2009), which has been
technically revised. It also incorporates the Amendments ISO/IEC 18013-3:2009/Amd 1:2012 and
ISO/IEC 18013-3:2009/Amd 2:2014, and the Technical Corrigenda ISO/IEC 18013-3:2009/Cor 1:2011
and ISO/IEC 18013-3:2009/Cor 2:2013.
The most significant changes are the following:
— In the interest o f interoperability o f cards used for personal identification, the authentication
protocols for the IDL are simplified. Active Authentication is harmonised with other ISO standards
and thus BAP configurations 2, 3 and 4, as well as EAP are no longer supported by this document.
— Replacing EAP, the optional EACv1 protocol is defin ed for the IDL, enabling access control to sensitive
biometric data stored on an integrated circuit. EACv1 may be used in conjunction with either BAP
configuration 1 or PACE.
— The optional PACE protocol enables access control to the data stored on an integrated circuit. The
PACE protocol is a password authenticated Di ffie Hellman key agreement protocol based on a (short)
input string that provides secure communication between a secure integrated circuit on an IDL
and a terminal and allows various implementation options (mappings, input strings, algorithms).
The PACE protocol implementation for the IDL is restricted to Elliptic Curve Di ffie Hellman (ECDH)
generic mapping and can be used as a stand-alone protocol or in combination with the EACv1
protocol.
A list of all the parts in the ISO/IEC 18013 series can be found on the ISO website.

I n tern ati o n al Org an i z ati o n

© ISO/IEC 2017 – All rights reserved
fo r S tan d ard i z ati o n
v
 ISO/IEC 1 801 3 -3 : 2 01 7(E)

Introduction

This document prescribes requirements for the implementation of mechanisms to control access to
data re corde d i n the mach i ne -re adable te ch nolo g y on a n I S O - comp l i ant d rivi ng l icence (I D L) , veri fyi ng

the origi n o f a n I DL , and con fi rm i ng d ata i ntegrity.

One of the functions of an IDL is to facilitate international interchange. While storing data in machine-
re adable form on the I DL s upp or ts th i s fu nc tion b y s p e e d i ng up data i nput a nd el i m i nati ng tran s c rip tion

errors, certain machine-readable technologies are vulnerable to being read without the knowledge of
the c a rd holder and to o ther me a n s o f u nauthori ze d acce s s b y u ni ntende d p ers on s th at i s o ther th an

driving licence or law enforcement authorities. Controlling access to IDL data stored in machine-
re adable form pro te c ts the data on the c ard from b ei ng re ad remo tely by ele c tron ic me an s without the

knowledge of the card holder.

I denti fyi ng fa l s i fie d d rivi ng l icence s or an a lteration to the hu man-re adable data on authentic d rivi ng

l icence s pre s ent a maj or problem for d rivi ng l icence and law en forcement authoritie s , b o th dome s tic a l ly

and i n the contex t o f i nternationa l i nterch ange . Veri fyi ng the authenticity o f an I DL a nd con fi rm i ng

the i ntegrity o f the data re corde d on a n I DL provide d rivi ng l icence and l aw en forcement authoritie s

with a me an s to identi fy an authentic I DL from a fa l s i fie d or a ltere d one i n the i ntere s ts o f tra ffic law

en forcement a nd o ther tra ffic s a fe ty pro ce s s e s .

Get more FREE standards from Standard Sharing Group and our chats

vi
I n tern ati o n al Org an i z ati o n fo r S tan d ard i z ati o n
© ISO/IEC 2017 – All rights reserved
 INTERNATIONAL STANDARD ISO/IEC 1 801 3 -3 : 2 01 7(E)

In formation technology — Personal identification — ISO-

compliant driving licence —

Part 3:
Access control, authentication and integrity validation

1 Scope

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 o f 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.

2 Normative re ferences

The following documents are re ferred to in the text in such a way that some or all o f their content
constitutes requirements o f this document. For dated re ferences, only the edition cited applies. For
undated re ferences, the latest edition o f the re ferenced document (including any amendments) applies.
ISO 1831:1980, Printing specifications for optical character recognition
ISO/IEC 7816-4:2013, Identification cards — Integrated circuit cards — Part 4: Organization, security and
commands for interchange
ISO/IEC 8859-1:1998, 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:1999 1) , Information technology — Security techniques — Message Authentication Codes

(MACs) — Part 1: Mechanisms using a block cipher

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

Dedicated hash-functions

1) ISO/IEC 9797-1:1999 is withdrawn and replaced by the 2011 version.

I n tern ati o n al Org an i z ati o n

© ISO/IEC 2017 – All rights reserved
fo r S tan d ard i z ati o n
1
 ISO/IEC 1 801 3 -3 : 2 01 7(E)

ISO/IEC 11770-2:1996 2) , 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, Information technology — Personal identification — ISO-compliant driving licence —
Part 1: Physical characteristics and basic data set
ISO/IEC 18013-2, Information technology — Personal identification — ISO-compliant driving licence —
Part 2: Machine-readable technologies
ISO/IEC 18033-3:2005 3) , Information technology — Security techniques — Encryption algorithms —
Part 3: Block ciphers
ISO/IEC 18033-3:2005/Cor1: 2006, Information technology — Security techniques — Encryption
algorithms — Part 3: Block ciphers — Technical Corrigendum 1
ISO/IEC 18033-3:2005/Cor2: 2007, Information technology — Security techniques — Encryption
algorithms — Part 3: Block ciphers — Technical Corrigendum 2
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-2 (including
Get Change Notice),
more FREE Digital Signature
standards Standard
from Standard (DSS),Group
Sharing Federal
andInformation
our chats Processing
Standards Publication, National Institute of Standards and Technology, 27 January 2000
ICAO Technical Report – Supplemental Access Control for Machine Readable Travel Documents, v1.01, 2010
[TR-PACE ]
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 4)
RFC 3279, W. Polk et al., Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure
Certificate and Certificate Revocation List (CRL) Pro file, April 2002 4
RFC 3280, R. Housley et al., Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation
List (CRL) Pro file, April 2002 1
RFC 3369, R. Housley, Cryptographic Message Syntax, August 2002 1
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) Pro file,
June 2005 1
RFC 5639, M. Lochter, J. Merkle, Elliptic Curve Cryptography (ECC) Brainpool Standard Curves and Curve
Generation, March 2010 1

2) I S O /I E C 1 1 7 7 0 - 2 : 1 9 9 6 is withdrawn and rep laced by the 2 0 0 8 vers io n.

3) I S O /I E C 1 8 0 3 3 - 3 : 2 0 0 5 is withdrawn and rep laced by the 2 0 1 0 vers io n.

4) http://www.ietf.org/rfc.html

2
I n tern ati o n al Org an i z ati o n fo r S tan d ard i z ati o n
© ISO/IEC 2017 – All rights reserved
 ISO/IEC 1 801 3 -3 : 2 0 1 7(E)

3 Terms and definitions

For the pu rp o s e s o f th i s do c ument, the term s and defi n ition s given i n I S O/I E C 1 8 01 3 -1 , I S O/I E C 1 8 01 3 -

2 and the fol lowi ng apply.

ISO and IEC maintain terminological databases for use in standardization at the following addresses:
— IEC Electropedia: available at http://www.electropedia .org/
— ISO Online browsing platform: available at http://www.iso .org/obp
3.1
active authentication
mechanism that uses information stored in a secure area of a secure integrated circuit (SIC) (3.17) to
con fi rm th at the S I C a nd the o ther mach i ne -re adable data were i s s ue d to ge ther

N o te 1 to entr y: S e e 8.2 .

3.2
basic access protection
BAP
me chan i s m to con fi rm that a n i n s p e c tion s ys tem (I S ) h as phys ic a l acce s s to a proxi m ity i nte grate d

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
N o te 1 to entr y: S e e 8.5 and Annex B.

3.3
chip authentication
ephemera l- s tatic key agre ement pro to col that provide s authentic ation o f the secure integrated circuit
(3.17 ) and strong secure messaging
N o te 1 to entr y: S e e 8.6.

3.4
clone
u nauthori ze d e xac t cop y o f a do c u ment that ha s the s ame s e c u rity charac teri s tics as the origi na l

document and that cannot be distinguished from the legitimate one

3.5
eavesdropping
unauthorized interception and interpretation of information-bearing emanations
[S OU RC E : I S O/I E C 2 3 8 2 - 8 : 2 01 5 , 0 8 . 0 5 . 2 5 , mo d i fie d]

3.6
extended access control v1
E AC v1
protocol used to limit access to optional signature and biometric data groups
N o te 1 to entr y: S e e 8.6 and Annex D.

3 .7
input s tring
s tri ng o f charac ters pri nte d on an I S O - compl i ant d ri vi ng l icence [a s hu man-re adable te x t, op tiona l ly (or

b y s p e c i fication) accomp an ie d b y or con s i s ti ng o f a mach i ne -re adable renderi ng there o f ] u s e d a s i nput

(either manua l ly or automatic a l ly th rough the u s e o f s u itable e qu ipment) for the non-match a ler t a nd

BAP (3.2) or PACE (3.10) mechanisms

I n tern ati o n al Org an i z ati o n

© ISO/IEC 2017 – All rights reserved
fo r S tan d ard i z ati o n
3
 ISO/IEC 1 80 1 3 -3 : 2 01 7(E)

3.8
issuing authority
IA
licensing authority (or issuing country i f 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 di fferences between the machine-readable in formation and (some o f) 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: As stated in TR-PACE, PACE re fers to PACE v2.

Note 2 to entry: See 8.7 and Annex C .
3 .11
passive authentication
mechanism to confirm that machine-readable
Get more data Standard
FREE standards from on an ISO-compliant driving
Sharing Group and licence (IDL) has not
our chats
been changed since the IDL was issued

Note 1 to entry: See 8.1 .

3 .1 2
pseudo issuing authority
PI A
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 o f other IAs or PIAs that it trusts
3 .13
public key in fras tructure
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 en forcement
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

4
I n tern ati o n al Org an i z ati o n fo r S tan d ard i z ati o n
© ISO/IEC 2017 – All rights reserved
 ISO/IEC 1 801 3 -3 : 2 0 1 7(E)

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 di fferent 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 o f 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 ) re ferences to veri fy 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
trus t point
issuing authority (3.8) or pseudo issuing authority (3.12) that publishes a trust list (and the related public
root keys) that veri fying entities can re ference
3.24
twinning
copying the data and/or integrated circuit o f a physically and/or biometrically similar driver to the
attacker’s integrated circuit or ISO-compliant driving licence

3 .25
unpacked BCD
binary coding o f a sequence o f integers using 4 bits for each integer (where the bit weights are 8421)
and encoding one integer in the least significant bits o f each byte
Note 1 to entry: Only unsigned BCD is used in this document.

I n tern ati o n al Org an i z ati o n

© ISO/IEC 2017 – All rights reserved
fo r S tan d ard i z ati o n
5
 ISO/IEC 1 80 1 3 -3 : 2 01 7(E)

3.26
veri fying 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 veri fying entities are VAs. A car rental company can be a veri fying 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 . 2 6 .1
immediate VA
VA (3.26 ) that acquired the public root key o f 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 o f the issuing authority (3.8) from another VA
3 .27
veri fying entity
entity that tries to determine i f a digital signature is valid (i.e. i f the data to which a certificate has
been applied has not been changed, and i f the signature was generated by the issuing authority (3.8) the
veri fying entity expects)

4 Abbreviated terms

APDU application protocol data unit

Get more FREE standards from Standard Sharing Group and our chats
BAC basic access control
BAP basic access protection
BCD binary coded decimal
BER-TLV basic encoding rules – tag-length-value (see ISO/IEC 8825-1:2002 a)
CA certification authority
CBC cipher block chaining
DER distinguished encoding rules (see ISO/IEC 8825-1:2002)
DF dedicated file
DG data group
DO data object
DST control reference template for digital signature (see ISO/IEC 7816-4:2013)
EACv1 extended access control v1
EAP extended access protection
EF elementary file
IA issuing authority
IC integrated circuit

6
I n tern ati o n al Org an i z ati o n fo r S tan d ard i z ati o n
© ISO/IEC 2017 – All rights reserved
 ISO/IEC 1 801 3 -3 : 2 01 7(E)

ICC integrated circuit card

IDL ISO-compliant driving licence
IFD interface device
IS i n s p e c tion s ys tem

IV initialization vector
KAT control re ference templ ate for key agre ement (s e e I S O/I E C 78 16 - 4: 2 01 3 )

LDS logical data structure

MAC message authentication code
MF mas ter fi le

MRTD machine readable travel document

MRZ machine readable zone
MSE manage s e c urity envi ronment (s e e I S O/I E C 78 16 - 4: 2 01 3 )

OCR optical character recognition

OID obj e c t identi fier

PACE password authenticated connection establishment

PIA p s eudo i s s u i ng authority

PIC proxi m ity i nte grate d ci rc u it

PICC proxi m ity i nte grate d ci rc u it c a rd

PKI publ ic key i n fra s truc tu re

PSO p er form s e c urity op eration (s e e I S O/I E C 78 16 - 4: 2 01 3 )

RA re ad i ng authority

RFU reserved for future use

SAI s c an n i ng are a identi fier

SIC secure integrated circuit

SM secure messaging
SOD do c u ment s e c u rity obj e c t

SSC send sequence counter

TRCA tr u s t ro o t cer ti fic ate authority

UTC coordinated universal time

I n tern ati o n al Org an i z ati o n

© ISO/IEC 2017 – All rights reserved
fo r S tan d ard i z ati o n
7
 ISO/IEC 1 80 1 3 -3 : 2 01 7(E)

VA veri fying authority

2D two-dimensional

a ISO/IEC 8825-1:2002 is withdrawn and replaced by the 2015 version.

5 Con formance

A driving licence is in con formance with this document i f it meets all mandatory requirements specified
directly or by re ference 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 o f a machine-readable technology which is not compliant with this document does not
render the IDL non-compliant with ISO/IEC 18013-1.

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

a) prevent skimming o f machine-readable data on a PICC by ensuring that physical access to the IDL is
acquired prior to reading;
b) prevent unnoticed alteration o f communication between a reader and a SIC;
c) prevent eavesdropping
Get morebetween a reader and
FREE standards froma SIC;
Standard Sharing Group and our chats
d) selectively restrict access to specific optional machine-readable data groups for specific reading
authorities.

6.2 Document authentication

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

6.3 Data integrity validation

Data integrity validation can be broken down into the following functional requirements:
a) Veri fy that the IDL (including the machine-readable data) is not a clone o f another IDL. A cloning
attempt can schematically be illustrated as shown in Figure 1.

8
I n tern ati o n al Org an i z ati o n fo r S tan d ard i z ati o n
© ISO/IEC 2017 – All rights reserved
 ISO/IEC 1 801 3 -3 : 2 0 1 7(E)

C Legend

D 1 Physical IDL (before personalization)

Human-readable data
B
Data carrier
3

1 D Machine-
readable
blank (no data) data

3
blank
(no data)

Figure 1 — Data integrity validation: I DL cloning

b) Protect against the exchange of machine-readable data carriers between otherwise authentic IDLs.
T h i s typ e o f attack c an s chematic a l ly b e i l lu s trate d as s hown i n Figure 2 .

NO TE T h i s gu a rd s (a mo ng o thers) aga i n s t a n I C “twi n n i ng” attack. T h i s typ e o f attack i s o f p a r tic u l a r

concern in inspection environments where machine-readable data and human-readable data is not compared
(or o n l y c u rs or i l y co mp a re d b y a n o p erator u s i n g , for e xa mp le , a p o r tra it i m age) . Fi nd i ng a b io me tric a l l y

s i m i l a r d r i ver i s p o s s ib le b y s ki m m i n g the d ata o f a few tho u s a nd I D L PI C s .

C Legend

D A Physical IDL (before personalization)

Human-readable data
B
Data carrier
3

1 4 Machine-
readable
2 data

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

c) Veri fy that the phys ic a l I DL and the mach i ne -re adable data there on were i s s ue d ( b elong) to ge ther.

T h i s typ e o f attack c an s chematic a l ly b e i l lu s trate d as s hown i n Figure 3.

I n tern ati o n al Org an i z ati o n

© ISO/IEC 2017 – All rights reserved
fo r S tan d ard i z ati o n
9
 ISO/IEC 1 80 1 3 -3 : 2 01 7(E)

C Legend

D A Physical IDL (before personalization)

Human-readable data
B
Data carrier
C

1 4 Machine-
readable
2 data

Figure 3 — Data integrity validation: M achine-readable data exchange

d) Va l idate the i nte grity o f the hu man re adable data (i . e . con fi rm th at the hu man-re adable data ha s no t

ch ange d s i nce i s s ui ng) . T h i s typ e o f attack c a n s chematic a l ly b e i l lu s trate d a s shown i n Figure 4.

Legend

A A Physical IDL (before personalization)

Get more FREE standards from Standard Sharing Group and our chats
Human-readable data
B B’
Data carrier
C C

D D Machine-
readable
data

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

e) Va l idate the i ntegrity o f the mach i ne -re adable data (i . e . con fi rm th at the mach i ne -re adable data

ha s no t change d s i nce i s s u i ng) . T h i s c an s chematic a l ly b e i l lu s trate d a s shown i n Figure 5 .

Legend

A A Physical IDL (before personalization)

Human-readable data
B B
Data carrier
C C

D D’ Machine-
readable
data

Figure 5 — Data integrity validation: M achine-readable data alteration

10
I n tern ati o n al Org an i z ati o n fo r S tan d ard i z ati o n
© ISO/IEC 201 7 – All rights reserved
 ISO/IEC 1 801 3 -3 : 2 0 1 7(E)

7 Mapping o f mechanisms to requirements and technologies

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

Me chan i s ms

Functional 2 D b ar co de IC C with contacts PI C C

requirement
Prevent skim- Physical access to the IDL is required Physical access to the IDL is required BAP or PACE
ming to read the machine-readable data to read the machine-readable data
Prevent unno- N/A Chip authentication (EACv1) in BAP or PACE
ticed alteration combination with BAP or PACE secure
of communica- messaging Chip authentication (EACv1) in
tion between a combination with BAP or PACE secure
reader and an messaging
IDL
Prevent eaves- N/A Chip authentication (EACv1) in BAP a or PACE
dropping combination with BAP or PACE secure
messaging Chip authentication (EACv1) in
combination with BAP or PACE secure
messaging
Selectively N/A Terminal authentication (EACv1) Terminal authentication (EACv1)
restrict access
to specific
optional ma-
chine-readable
data groups for
specific reading
authorities
Allow for veri- Step 1: Veri fy trustworthiness o f/ob - Step 1: Veri fy trustworthiness o f/ob - Step 1: Veri fy trustworthiness o f/ob -
fication o f the tain a trustworthy asymmetric/public tain a trustworthy asymmetric/public tain a trustworthy asymmetric/public
origin of an IDL key (via a PKI and a protected distri - key (via a PKI and a protected distri - key (via a PKI and a protected distri -
bution communication channel, or via bution communication channel, or via bution communication channel, or via
alternative trust building methods) alternative trust building methods) alternative trust building methods)
Step 2: Use trusted key to per form Step 2: Use trusted key to per form Step 2: Use trusted key to per form
passive authentication, followed by passive authentication; i f the passive passive authentication; i f the passive
use of the non-match alert mechanism, authentication was preceded by BAP authentication was preceded by BAP
or followed by visual comparison o f or PACE, the IDL is authentic while if or PACE, the IDL is authentic while if
the human-readable data printed on BAP or PACE is not implemented, pas- BAP or PACE is not implemented, pas-
the document with the authenticated sive authentication can be followed by sive authentication can be followed by
machine-readable data use of the non-match alert mechanism, use of the non-match alert mechanism,
or followed by visual comparison o f or followed by visual comparison o f
the human-readable data printed on the human-readable data printed on
the document with the authenticated the document with the authenticated
machine-readable data machine-readable data
Veri fy that the 2D bar code: Cannot be verified Active authentication via challenge Active authentication via challenge
IDL (including through available international response response
the ma- standards
chine-readable Chip authentication (EACv1) Chip authentication (EACv1)
data) is not a
clone of another
IDL
Protect against Non-match alert Non-match alert Non-match alert
the exchange of
machine read- Passive authentication followed by a BAP or PACE BAP or PACE
able data car- visual comparison of the human-read-
able data printed on the document Passive authentication followed by a Passive authentication followed by a
riers between
otherwise with the authenticated machine-read- visual comparison of the human-read- visual comparison of the human-read-
able data able data printed on the document able data printed on the document
authentic IDLs with the authenticated machine-read- with the authenticated machine-read-
able data able data

I n tern ati o n al Org an i z ati o n

© ISO/IEC 2017 – All rights reserved
fo r S tan d ard i z ati o n
11
 ISO/IEC 1 80 1 3 -3 : 2 01 7(E)

Table 1 (continued)
M echani s m s

Functional 2 D b ar co de I C C with co ntacts PIC C

requirement
Veri fy that the Non-match alert Non-match alert Non-match alert
physical IDL
and the ma- Passive authentication followed by a BAP or PACE BAP or PACE
chine-readable visual comparison of the human-read-
able data printed on the document Passive authentication followed by a Passive authentication followed by a
data thereon
were issued (be- with the authenticated machine-read- visual comparison of the human-read- visual comparison of the human-read-
able data able data printed on the document able data printed on the document
long) together with the authenticated machine-read- with the authenticated machine-read-
(i.e. that the able data able data
machine-read-
able data has Active authentication via challenge Active authentication via challenge
not been copied response a response a
from another
IDL)
Validate the Non-match alert Non-match alert Non-match alert
integrity o f
the human read- Passive authentication followed by a BAP or PACE BAP or PACE
able data (i.e. visual comparison of the human-read-
Passive authentication followed by a Passive authentication followed by a
confirm that the able data printed on the document visual comparison of the human-read- visual comparison of the human-read-
human-readable with the authenticated machine-read- able data printed on the document able data printed on the document
data has not able data
with the authenticated machine-read- with the authenticated machine-read-
changed since Visual inspection o f the security fea - able data able data
issuing) tures incorporated into the IDL (see
ISO/IEC 18013-1) Visual inspection o f the security fea - Visual inspection o f the security fea -
tures incorporated into the IDL (see tures incorporated into the IDL (see
ISO/IEC 18013-1) ISO/IEC 18013-1)
Validate the Passive authentication Passive authentication Passive authentication
integrity o f the
machine-read-
able data (i.e.
confirm that the
machine-reada-
ble data has not Get more FREE standards from Standard Sharing Group and our chats
changed since
issuing)
NOTE Visual comparison of human-readable information printed on an IDL with machine-readable information obtained from the
same IDL is not formally specified as a mechanism in this document; it is assumed that such comparison can be implemented by any RA in
a manner that meets local needs.
a The entropy o f the re ference string used has to be commensurate with the IA’s assessment o f the threat.

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

8 Mechanisms

8.1 Passive authentication

8.1 .1 Purpose

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

8.1 .2 Applicability

Passive authentication is applicable to all machine-readable technologies.

8.1 .3 Description

Passive authentication is implemented by way o f a digital signature over specified machine-readable

data on the IDL, using a public-private (asymmetric) key pair.

12
I n tern ati o n al Org an i z ati o n fo r S tan d ard i z ati o n
© ISO/IEC 2017 – All rights reserved
 ISO/IEC 1 801 3 -3 : 2 0 1 7(E)

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 o f 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 o f compact encoding, no message digests are calculated separately. The contents o f 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 o f finding any two (di fferent) IDL data sets that lead to the same message digest is negligible.
This has the following implications:

1) The probability o f 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 veri fy 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 veri fy the digital signature belongs to the claimed IA.
I f the digital signature does not veri fy, either an incorrect public key was used or the data on the IDL has
been changed. Depending on the digital signature method used, it may be possible to further narrow
down the cause o f the non-verification.
This document does not prescribe methods to obtain and/or to establish trust in public keys. It is the
responsibility o f each RA to obtain and/or to establish trust in the public keys used to veri fy 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 o f one global certification authority.
This document does not prescribe methods for the generation, administration and sa fekeeping o f key
pairs. It is the responsibility o f each issuing jurisdiction to ensure that keys are generated, administered
and protected as necessary.

8.1 .4 Hash function

8.1 .4.1 Standard encoding

For standard encoding, I A’s shall choose the SH A-1, SHA-224, SHA-256, SH A-384 or the SH A-512 hash
function.

SHA-256 is recommended. SHA-1 remains for compatibility with ICAO Doc 9303-1.
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.

I n tern ati o n al Org an i z ati o n

© ISO/IEC 2017 – All rights reserved
fo r S tan d ard i z ati o n
13
 ISO/IEC 1 80 1 3 -3 : 2 01 7(E)

8.1 .4.2 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 o f any digital signature
mechanism; see 8.1.5.2).

8.1 .5 Signing method

8.1 .5 .1 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 veri fy 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 described explicitly in the parameters o f the public key, i.e. parameters
shall be o f type ECParameters (no named curves, no implicit parameters) and shall include the optional
cofactor. ECPoints shall be in uncompressed format. The minimum size for the base point order shall be
160 bits.
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
GetSOD
moreis FREE
implemented as afrom
standards SignedData
StandardType, as specified
Sharing Group andin our
RFCchats
3369 (including
processing rules). The SOD shall be produced in DER format.

Table 2 — SignedData Type

Value Type Comments

SignedData m
Vers ion m
diges tAlgorithms m
encapContentI nfo m
eContentType m id-icao-lds SecurityObj ect
eContent m The encoded contents of an lds SecurityObj ect
certifcates o
Crls x
s ignerI nfos m
SignerI nfo m
vers ion m
Sid m
is s uerandSerialNumber c It is recommended that IA’s support this field over
subj ectKeyI dentifer .
subj ectKeyI dentifer c
m = mandatory (the field shall be present);
x = do not use (the field shall not be populated);
o = optional (the field may be present);
c = choice (the field contents is a choice from alternatives)

14
I n tern ati o n al Org an i z ati o n fo r S tan d ard i z ati o n
© ISO/IEC 2017 – All rights reserved
 ISO/IEC 18013-3:2017(E)

Table 2 (continued)
Value Type Comments
diges tAlgorithm m The algorithm identifier o f the algorithm used to produce the hash value
over encaps ulatedContent and SignedAttrs .
s ignedAttrs m IA’s may wish to include additional attributes for inclusion in the signa -
ture, however these do not have to be processed by a RA except to veri fy
the signature value.
s ignatureAlgorithm m The algorithm identifier o f the algorithm used to produce the signature
value and any associated parameters.
s ignature m The result of the signature generation process.
uns ignedAttrs o IA’s may wish to use this field, but it is not recommended and reading
authorities may choose to ignore them.
m = mandatory (the field shall be present);
x = do not use (the field shall not be populated);
o = optional (the field may be present);
c = choice (the field contents is a choice from alternatives)

ASN.1 sequence
LDSSecurityObj ect { j oint-is o-itu-t( 2 ) international-organiz ations ( 2 3) icao( 1 36) mrtd( 1 )
s ecurity( 1 ) lds SecurityObj ect( 1 ) }

DEFI NI TI ONS I MPLI CI T TAGS : : =

BEGI N

-- I mports from RFC 32 8 0 [ PROFI LE] , Appendix A. 1

AlgorithmI dentifer FROM
PKI X1 Explicit8 8 { iso( 1 ) identifed-organiz ation( 3) dod( 6)
internet( 1 ) s ecurity( 5) mechanis ms ( 5) pkix( 7 )
id-mod( 0 ) id-pkix1 -explicit( 1 8 ) }

-- Cons tants
ub-DataGroups I NTEGER : : = 1 6

-- Obj ect I dentifers

id-icao OBJECT I DENTI FI ER : : = { 2 . 2 3. 1 36}
id-icao-mrtd OBJECT I DENTI FI ER : : = { id-icao 1 }
id-icao-mrtd-s ecurity OBJECT I DENTI FI ER : : = { id-icao-mrtd 1 }
id-icao-lds SecurityObj ect OBJECT I DENTI FI ER : : = { id-icao-mrtd-s ecurity 1 }

-- LDS Security Obj ect

LDSSecurityObj ectVers ion : : = I NTEGER { V0 ( 0 ) }
DigestAlgorithmI dentifer : : = AlgorithmI dentifer
LDSSecurityObj ect : : = SEQUENCE {
vers ion LDSSecurityObj ectVers ion,
hashAlgorithm DigestAlgorithmI dentifer,
dataGroupHas hValues SEQUENCE SI Z E ( 2 . . ub-DataGroups ) OF DataGroupHas h }

DataGroupHas h : : = SEQUENCE {
dataGroupNumber DataGroupNumber,
dataGroupHas hValue OCTET STRI NG }
DataGroupNumber : : = I NTEGER {
dataGroup1 ( 1 ) ,
dataGroup2 ( 2 ) ,
dataGroup3 ( 3) ,
dataGroup4 ( 4 ) ,
dataGroup5 ( 5) ,
dataGroup6 ( 6) ,
dataGroup7 ( 7 ) ,
dataGroup8 ( 8 ) ,
dataGroup9 ( 9) ,
dataGroup1 0 ( 1 0 ) ,

I n tern ati o n al Org an i z ati o n

© ISO/IEC 2017 – All rights reserved
fo r S tan d ard i z ati o n
15
 ISO/IEC 1 80 1 3 -3 : 2 01 7(E)

dataGroup1 1 (11) ,
dataGroup1 2 (12) ,
dataGroup1 3 ( 1 3) ,
dataGroup1 4 (14) ,
dataGroup1 5 ( 1 5) ,
dataGroup1 6 ( 1 6) }
END
NOTE 1 The field dataGroupHas hValue contains the calculated hash over the complete contents of the
Data Group EF, specified by dataGroupNumber .
NOTE 2 Data Groups 15 and 16 may be defined in future.

8.1 .5 .2 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 The header is not included in the information to be signed as the length information in the header
pertains to DG11 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 o f the curves specified in
FIPS 186-2, Appendix 6.
DG.SOD shall consist o f a concatenation o f two Type 2 data groups and one Type 1 data group, 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 I NTEGER, s I NTEGER } ;
Get more FREE standards from Standard Sharing Group and our chats
b) DG.SOD.2: public key; octet string representation o f the public point in uncompressed form
according to X9.62;
c) DG.SOD.3: curve identifier.
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.2 length] [public key] ×
[DG.SOD.3: named curve]
The inclusion of DG.SOD.2 and DG.SOD.3 (as a pair) is optional. Length information is encoded using
ASN.1 rules.
NOTE Reading authorities should be able to veri fy (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 o f one byte, as shown in Table 3.

Table 3 — Curve identifiers

Curve name in
Curve identi fier Cur ve identifier Curve name in RFC 5 63 9
FI PS 186 -2

’01’ P-192 ’11’ brainpoolP160r1

’02’ P-224 ’12’ brainpoolP160t1
’03’ P-256 ’13’ brainpoolP192r1
’04’ P-384 ’14’ brainpoolP192t1
’05’ P-521 ’15’ brainpoolP224r1
’06’ Reserve for future use ’16’ brainpoolP224t1

16
I n tern ati o n al Org an i z ati o n fo r S tan d ard i z ati o n
© ISO/IEC 2017 – All rights reserved
 ISO/IEC 1 801 3 -3 : 2 0 1 7(E)

Table 3 (continued)

Curve name in
Cur ve identifier Curve identifier Curve name in RFC 5 63 9
F I PS 18 6 -2

’07’ Reserve for future use ’17’ brainpoolP256r1

’08’ Reserve for future use ’18’ brainpoolP256t1
’19’ brainpoolP320r1
’1 A’ brainpoolP320t1
’1B’ brainpoolP384r1
’1C’ brainpoolP384t1
’1D’ brainpoolP512r1
’1E’ brainpoolP512t1

EXAMPLE Suppose that a compact encoded data string contains the following data groups: DG1, DG2,
DG7 and DG.SOD.1. A digital signature is included, but the public key and curve identifier are not included. The
sequence of data groups and data group delimiters will be as follows:
[header] × [DG1] × [DG2] × × × [DG7] × × × [DG.SOD.1] ¶

8.2 Active authentication

8.2 .1 Purpose

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

8.2 .2 Applicability

This mechanism is limited to SICs.

8.2 .3 Description

A challenge-response protocol matches the private and public keys o f 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 o f 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 o f 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 i f and only i f 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 o f the challenge. I f the
challenge includes time, date, location, and a secret key, a log o f challenge responses can be used to track IDLs and
to prove presence (due to the inclusion o f the secret key). The counterargument is that basic access protection
would sa feguard 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.

8.2 .4 Mechanism

8.2 .4.1 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 f ormat of the structure ( Subj ectPublicKeyI nfo )
is specified in RFC 3280. Subj ectPublicKeyI nfo shall be produced in DER format as follows:

I n tern ati o n al Org an i z ati o n

© ISO/IEC 2017 – All rights reserved
fo r S tan d ard i z ati o n
17
 ISO/IEC 1 80 1 3 -3 : 2 01 7(E)

ActiveAuthenticationPublicKeyI nfo : : = Subj ectPublicKeyI nfo

Subj ectPublicKeyI nfo : : = SEQUENCE {

algorithm AlgorithmI dentifer,
s ubj ectPublicKey BI T STRI NG }

AlgorithmI dentifer : : = SEQUENCE {

algorithm OBJECT I DENTI FI ER,
parameters ANY DEFI NED BY algorithm OPTI ONAL }

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:2013. 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 veri fy the signature.

8.2 .4.2 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.

8.2 .4.3 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 compressed with a hash algorithm with an output length shorter or equal
to the length o f the signature key.
NOTE The plainGet
signature
more format
FREE (r|| s) for the from
standards ECDSA is according
Standard Group[6]and
to TR-03111
Sharing . our chats

Based on a suitable algorithm catalogue, the length o f the key for ECDSA should be chosen to provide
the desired security level for the physical li fe o f the IDL .

I f ECDSA based signature algorithm is used for Active Authentication by the SIC, the SecurityIn fos in
LDS Data Group 14 of the IDL application shall contain following SecurityI nfo entry:
ActiveAuthenticationI nfo : : = SEQUENCE {
protocol id-icao-mrtd-s ecurity-aaProtocolObj ect,
vers ion I NTEGER, -- MUST be 1
s ignatureAlgorithm OBJECT I DENTI FI ER
}

id-icao-mrtd-s ecurity-aaProtocolObj ect OBJECT I DENTI FI ER : : =

{ id-icao-mrtd-s ecurity 5 }
The object identifiers for s ignatureAlgorithm are defined in TR-03111 [6] . ecds a-plain-SHA1
and ecds a-plain-RI PEMD1 60 shall not be used.
NOTE 1 See 8.1.5.1 for the definition o f the Object Identifier id-icao-mrtd-s ecurity .

NOTE 2 SecurityI nfos may contain entries for other protocols, e.g. Chip Authentication, Terminal
Authentication, PACE.

8.2 .4.4 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-s m-AA .
id-s m-AA OBJECT I DENTI FI ER : : = {
is o( 1 ) s tandard( 0 ) driving-licence( 1 8 0 1 3) part-3( 3)
s ecurity-mechanis ms ( 2 ) 3}

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

18
I n tern ati o n al Org an i z ati o n fo r S tan d ard i z ati o n
© ISO/IEC 2017 – All rights reserved
 ISO/IEC 1 801 3 -3 : 2 0 1 7(E)

param-AA : : = SEQUENCE {
vers ion I NTEGER,
publicKeyDG I NTEGER}

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

8.3 Scanning area identifier

8.3 .1 Applicability

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

8.3 .2 Description

8.3 .2 .1 General

The primary purpose o f 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 per forms the function o f the non-match alert mechanism, but potentially at
a di fferent level o f 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 in formation demarcated by it shall be adapted for reading in the
B900 in frared band defined in ISO 1831:1980. 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 sur face gloss exceeding
natural transparent overlay gloss, which will inter fere with readability). In addition, machine-readable
printed in formation (e.g. bar codes and OCR characters) shall comply with the associated standards.
The brightness o f the printing background (including the e ffects o f 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 di fficulty.
The contrast ratio between character lines and the background shall be a minimum o f 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 o f the SAI is identified as follows:
a) I f 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 o f 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:1998.

I n tern ati o n al Org an i z ati o n

© ISO/IEC 2017 – All rights reserved
fo r S tan d ard i z ati o n
19
 ISO/IEC 1 80 1 3 -3 : 2 01 7(E)

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.

8.3 .2 .2 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 o f 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 o f either 25 % or 50 % reduction o f 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 (i f reflected on the IDL) and/or the data field re ference code
shall not be included within the rectangle.
In order to facilitate manual entry o f the input string when needed, the input string may contain
only Latin capital letters (hexadecimal range 41 to 5A o f ISO/IEC 8859-1:1998), Latin small letters
(hexadecimal range
Get61more
to 7AFREE
of ISO/IEC 8859-1:1998),
standards N characters,
from Standard and the
Sharing Group S characters
and our chats shown in
Table 4.
NOTE 1 Latin capital letters (hexadecimal range 41 to 5A of ISO/IEC 8859-1:1998) are recommended.

NOTE 2 Re ferences to ISO/IEC 8859-1:1998 are only for purposes o f identi fying the characters. Encoding
methods are specified elsewhere.

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

Hexadecimal numb er in I SO/

S character
I EC 8 859 -1 :19 9 8 a

<space> 20
– 2D
< 3C
a Re ference to ISO/IEC 8859-1:1998 is only for the purpose o f identi fying the
characters. Encoding methods are specified elsewhere.

The re ference string shall not contain any space characters (i.e. hexadecimal character ‘20’ o f
ISO/IEC 8859-1:1998). Thus, the IS shall delete all space characters (hexadecimal code 20 of
ISO/IEC 8859-1:1998) from the input string before further processing.
IA’s should care fully consider the level o f entropy o f existing fields be fore use within the SAI. Any rules
followed in the construction o f the field will decrease the entropy.

IA’s considering the use o f 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.

20
I n tern ati o n al Org an i z ati o n fo r S tan d ard i z ati o n
© ISO/IEC 2017 – All rights reserved
 ISO/IEC 1 801 3 -3 : 2 0 1 7(E)

Figure 7 — E xis ting data field on portrait side o f I DL designated as input s tring (not to scale)

8.3 .2 .3 SAI content consisting o f 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 o f a rectangle constructed by a black single line with a thickness o f
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 o f 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 o f characters per line shall be used;
c) i f characters are printed in more than one line, each line shall have the same number o f 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 % o f 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) f or one line only, string lengths o f 4 or 6 characters are permitted;
2) f or two lines, string lengths o f 8 or 12 characters are permitted;

I n tern ati o n al Org an i z ati o n

© ISO/IEC 2017 – All rights reserved
fo r S tan d ard i z ati o n
21
 ISO/IEC 1 80 1 3 -3 : 2 01 7(E)

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 VC defi ne d b y the formu la VC = EC , where EC is a unique number
a l lo tte d to e ach cha rac ter va lue, a s defi ne d i n Table 5.

Table 5 — C haracter numerical equivalents

C har 0 1 2 3 4 5 6 7 8 9 A B C D E F G H I
E C 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
C har J K L M N O P Q R S T U V W X Y Z <
E C 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36

I f l i ne 1 i s the on ly l i ne, then the un ique che ck d igit wi l l b e c a lc u late d a s fol lows:

a) A check sum S is calculated as S = Σ VC i, where i runs from 0 to n −1 and VCi indicates the respective
value VC 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
Get more FREE digit c is from
standards calculated as c Sharing
Standard = S mo du
Group
lo 3 7; and
(i nteour
ger chats
remai nder when

dividing S by 3 7 ) .
If there are two or three lines, then the check digits c1 for line one and c 2 for line two will be calculated
as follows:
a) A check sum SV is calculated over the entire input string (before it is split into lines and before
adding the check digits) as SV = Σ VC i, where i runs from 0 to n −1 and i nd ic ate s the cha rac ter i n 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 SP is calculated over the entire input string (before it is split into lines, and before
adding the check digits) as SP = Σ( VC i * 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 VC i indicates the respective value for the character in the i-th position.
c) Check digits c1 and c2 are calculated as c1 = (SV modulo 37) and c2 = (SP mo du lo 3 7 ) , re s p e c ti vely.

c3 in the centre of line three will represent

I n the c as e o f exac tly th re e l i ne s , the i n s er te d cha rac ter

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.

22
I n tern ati o n al Org an i z ati o n fo r S tan d ard i z ati o n
© ISO/IEC 2017 – All rights reserved
 ISO/IEC 1 801 3 -3 : 2 0 1 7(E)

Input
E D H T U L V X C D G B Z 4 G 8 H F
string
EC 14 13 17 29 30 21 31 33 12 13 16 11 35 4 16 8 17 15
i 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
VCi * i 238 208 255 406 390 252 341 330 108 104 112 66 175 16 48 16 17 0

S V = 335
S P = 3082

C heck digit Numeric value Code value

c1 2 2
c2 11 B

c3 = 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 s1 + s2 + s3 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 identi fying any single digit reading error in the case
o f a one-line input string and to correct any single digit reading error, as well as identi fying any double error in
the case o f a two-line or three-line input string. Less than 3 % o f any other statistical reading error may pass
inadvertently. This is only true i f adequate measures are taken on the side o f the reading equipment to make use
o f the in formation o ffered by the check digit scheme.
It is recommended that the minimum entropy o f the input string be 40 bits or more (be fore addition o f
the check digits). The use of random data is recommended.
NOTE IA’s may consider imposing restrictions on allowable content o f input strings to meet local
requirements, e.g. to address the “nasty word” problem, or to limit the value range o f practically existing check
digits (i.e. numerical characters only). Methods exist that allow en forcement o f 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 o f the input string.
EXAMPLE See Figure 10.

I n tern ati o n al Org an i z ati o n

© ISO/IEC 2017 – All rights reserved
fo r S tan d ard i z ati o n
23
 ISO/IEC 1 80 1 3 -3 : 2 01 7(E)

Fi gu re 10 — D ed ic ated data field on non- p or tra it s ide o f I DL des i gnate d a s i nput s tri ng (not
to s ca le)

8.3 .2 .4 SAI content consisting o f a barcode

A barcode may be used within a SAI as the primary means o f input. The SAI’s corners shall be clearly
shown. Each cornerGet
indicator shall be
more FREE constructed
standards from oStandard
f two perpendicular lines joined at the end points,
Sharing Group and our chats
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.
1 Qrt5% bMM *$3j84mzDp8R

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 o f the input string
(in accordance with ISO/IEC 8859-1:1998), printed in a font not smaller than 6pt.
EXAMPLE See Figure 12 .

24
I n tern ati o n al Org an i z ati o n fo r S tan d ard i z ati o n
© ISO/IEC 2017 – All rights reserved
 ISO/IEC 1 801 3 -3 : 2 0 1 7(E)

1 Qrt5%bMM *$3j84mzDp8R
PDE CATEGORIES
P Passengers
G Goods
D Dangerous goods

DRIVER RESTRICTIONS
Corrective lenses
Prosthesis
VEHICLE RESTRICTIONS
Automatic transmission AT
Electrically powered
Physically disabled
Bus > 1 6000 kg (GVM) permitted
Tractor only
Industrial/Agricultural only

Figure 1 2 — B arcode on non-portrait side o f I DL designated as input string (not to scale)

8.3 .2 .5 SAI consisting o f an IDL MRZ

8.3 .2 .5 .1 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 di ffers 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 o f the IDL MRZ is identified as follows:
a) I f 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 o f 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:1998.
The IDL MRZ may be located on the portrait side or the non-portrait side o f 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.

I n tern ati o n al Org an i z ati o n

© ISO/IEC 2017 – All rights reserved
fo r S tan d ard i z ati o n
25
 ISO/IEC 1 80 1 3 -3 : 2 01 7(E)

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)

1
12,12 ± 1,0

2,95 7,27 ± 1,0

(0.12)

4,0
(0.16) 77,7 (3.06)
85,60 (3.37)

Key

1 machine reading zone

2 reference centre line
3 printing zone

Figure 13 — Location o f 1 line M RZ at the bottom o f the I DL (not to scale)

Get more FREE standards from Standard Sharing Group and our chats
8.3 .2 .5 .2 Printing

The position o f the le ft edge o f the first character o f 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:1980 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 o f 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 in frared band defined in ISO 1831:1980. 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 sur face gloss exceeding natural transparent overlay gloss that will
inter fere with readability). The brightness o f the printing background (including the e ffects o f overlays)
will not be less than 40 % compared to an ideal white sur face under the same illumination.
The contrast ratio between character lines and the background shall be a minimum o f 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.

8.3 .2 .5 .3 Use o f 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.

26
I n tern ati o n al Org an i z ati o n fo r S tan d ard i z ati o n
© ISO/IEC 2017 – All rights reserved
 ISO/IEC 1 801 3 -3 : 2 0 1 7(E)

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

Table 6 — I DL M RZ data elements

I DL M RZ
Numb er o f
character D ata element Specification
characters
po sitions

1 Identifier The first character shall be “D”. 1

2 Configuration The second character shall designate the configuration as follows. 1
“1” for IDL SIC protected with BAP configuration 1
“P” for IDL SIC protected with PACE only (i.e. without BAP support)
“N” for IDL SIC protected with non-match alert
“<” for an MRZ does not contain a reference string
Any other characters are reserved for future use.
NOTE I f the second character o f the MRZ is set to 1, PACE may be
supported in addition to BAP configuration 1.
3 to 29 Discretionary The contents o f this field are to be determined at the discretion o f 27
data the Issuing Authority. Unused character positions shall be complet-
ed with filler characters (<) repeated up to position 29, as required.
30 Check digit The check digit allows verification o f all the data in the OCR line. 1
Check digit is calculated over the characters in positions 1 to 29
according to requirements set out below
The IA should ensure that the entropy o f the input string is commensurate with its purpose.

8.3 .2 .5 .4 Check digit calculation

The IDL MRZ check digit shall be calculated on modulus 10 with a continuously repetitive weighting o f
731 731 ..., as follows:
— Step 1:Going from le ft to right, multiply each digit o f 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 — C heck digit calculation

Character A B C D E F G H I J K L M
Value 10 11 12 13 14 15 16 17 18 19 20 21 22
Character N O P Q R S T U V W X Y Z <
Value 23 24 25 26 27 28 29 30 31 32 33 34 35 0

I n tern ati o n al Org an i z ati o n

© ISO/IEC 2017 – All rights reserved
fo r S tan d ard i z ati o n
27
 ISO/IEC 1 80 1 3 -3 : 2 01 7(E)

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

Table 8 — E xample I DL M RZ data elements

I DL M RZ element Value Meaning

Identifier “D” In accordance with this document

Configuration “1” BAP configuration 1
Discretionary data “23T09PJ3Y8478FSD<<<<<<<<<<<” 16 random characters followed by special
characters to fill vacant positions
Check digit “?” Check digit to be calculated over characters 1
to 29

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

Step 1: Multiplication:

D ata D 1 2 3 T 0 9 P J 3 Y 8 4 7 8 F S D < < < < < < < < < < <
Value 13 1 2 3 29 0 9 25 19 3 34 8 4 7 8 15 28 13 0 0 0 0 0 0 0 0 0 0 0
Weight 7 3 1 7 3 1 7 3 1 7 3 1 7 3 1 7 3 1 7 3 1 7 3 1 7 3 1 7 3
Product 91 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

Get more FREE standards from Standard Sharing Group and our chats

Step 2 : Sum of products:

91 +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
751
Step 3 : Division by modulus: = 75, remainder 1.
10
Step 4: Check digit is the remainder, 1. The resulting MRZ including check digit shall be written as:
D123T09PJ3Y8478FSD<<<<<<<<<<<1

Table 9 — E xample I DL M RZ data elements and check digit

I DL M RZ element Value Meaning

Identifier “D” In accordance with this document

Configuration “1” BAP configuration 1
Discretionary data “23T09PJ3Y8478FSD<<<<<<<<<<<”
16 random characters followed by special
characters to fill vacant positions
Check digit “1” Check digit calculated over characters 1 to 29

The corresponding hex value o f the above input string (Configuration and Discretionary data) given in
Table 9 encoded in accordance with ISO/IEC 8859-1:1998 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’

28
I n tern ati o n al Org an i z ati o n fo r S tan d ard i z ati o n
© ISO/IEC 2017 – All rights reserved
 ISO/IEC 1 801 3 -3 : 2 0 1 7(E)

8.3 .2 .5 .5 Use o f IDL MRZ for non-match alert

The IDL MRZ can be used with the non-match alert mechanism as described in 8.4.
I n order to de s crib e s uch u s e i n D G1 2 , b yte 1 o f the SAI _inputmethod field s ha l l b e as s igne d a va lue

o f ‘41’. T he fou r mo s t s ign i fic ant bits (upp er nibble) o f th i s b yte identi fie s the I DL M RZ a s the i nput

me tho d . T he fou r le a s t s ign i fic ant bits ( lower n ibb le) o f b yte 1 i s as s igne d i n accord ance with Table 10.
I f b yte 2 o f the SAI _inputmethod i s pre s ent, it sh a l l h ave the va lue ‘F F ’.

I f the pre s ence o f the non-match a ler t me cha n i s m i s i nd ic ate d i n the E F. C O M fi le and i f the op tiona l

parameters are provided, the vers ion field sh a l l b e s e t to v1 (1) for th i s vers ion o f the non-match a ler t

mechanism.
EXAMPLE See Figure 14.

Figure 14 — I DL M RZ on portrait side o f I DL designated as input s tring (not to scale)

EXAMPLE See Figure 15.

I n tern ati o n al Org an i z ati o n

© ISO/IEC 2017 – All rights reserved
fo r S tan d ard i z ati o n
29
 ISO/IEC 1 80 1 3 -3 : 2 01 7(E)

Figure 15 — I DL M RZ on non-portrait side o f I DL designated as input string (not to scale)

8.4 Non-match alert

8.4.1 Purpose

This mechanism allows detection

Get more FREE ostandards
f any di fferences betweenSharing
from Standard the machine-readable in formation and
Group and our chats
(some o f) the human-readable in formation (printed on an IDL). This mechanism may be o f 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 trans ferred completely from one IDL to another without
strong visual evidence of alteration.

8.4.2 Applicability

This mechanism is applicable to SICs and 2D barcode.

8.4.3 Description

Conceptually, the re ference string is verified via a digital signature, a fter which the re ference 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 veri fy the digital signature.
NOTE 2 I f the comparison is success ful, the RA may conclude that the machine-readable data and the physical
document are consistent i f it can be assumed that alteration to any part o f the printed data (i.e. not just the area
that contains the input string) would be visually apparent.
The re ference 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 per forming passive
authentication followed by a visual comparison o f the human-readable data printed on the document with the
authenticated machine-readable data.

30
I n tern ati o n al Org an i z ati o n fo r S tan d ard i z ati o n
© ISO/IEC 2017 – All rights reserved
 ISO/IEC 1 801 3 -3 : 2 0 1 7(E)

8.4.4 Mechanism

8.4.4.1 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

Name, F i xed ( F ) or Varia-

ble ( V ) , M and ator y ( M ) or F ield format/ length/typ e E xamp le
O p tion al (O)

SAI _referencestring , V, M Byte 1: An input string of ABC4DEF contained in the

SAI_re ferencestring field will be coded as
‘00’ i f the input string follows ‘00 41 42 43 34 44 45 46’, where ‘41 42 43 34
‘01’ i f a re ference to where the input string can be obtained follows 44 45 46’ is the encoded form of ABC4DEF.
If the licence number is used as the input
string, this will be coded as ‘01 01 08’.
Subsequent bytes:
If the 16 th data element of Data Group 12 is
I f byte 1 = ‘00’, the input string follows from byte 2 (inclu - used as the input parameter, the input string
sive) . The input s tring is encoded in accordance with I SO/ will be coded as ‘01 12 16’
IEC 8859-1:1998.
I f byte 1 = ‘01’, the re ference to the field that contains the
input string is constructed as aabb where aa is the data group
and bb is the sequence number of the referenced data element,
with aabb encoded as unsigned BCD
SAI _inputmethod, V, O Byte 1: SAI standard and input method. The four most significant If the licence number is used as the input
bits (upper nibble) o f byte 1 can take on any o f the following values: string (i.e. a SAI is constructed around the
existing licence number field on the IDL), the
— ‘0x’ i f the input string is based on an existing field; value o f SAI_inputmethod will be ‘00’.
— ‘1x’ i f the input string is based on a dedicated field; If, in addition, the input string is printed in
— ‘2x’ i f the input string is stored in a barcode. OCR-B font, the input string will be ‘00 01’,
or alternatively ‘00 01 00’.
The four least significant bits (lower nibble) o f byte 1 denotes
the input method, and can take on any o f the following values: If, in addition, the SAI is located on the por-
trait side of the IDL, with the top left corner
— ‘x0’ i f the input string is intended for manual input; of the SAI at 29 mm from the left edge of the
card and 24 mm from the bottom edge of the
— ‘x1’ i f the input string is intended for OCR interpretation; card, and the right bottom corner of the SAI
— ‘x2’ i f the input string is stored as a barcode. at 59 mm from the left edge of the card and
14 mm from the bottom edge of the card, the
input string will be ‘00 01 00 00 29 24 59 14’
Byte 2: Barcode standard. I f the first byte is o f the form ‘x2’, byte
2 is mandatory, taking on any o f the following values:
— ‘00’ for PDF417;
— ‘01’ for Code 39 (ISO/IEC 16388);
— ‘02’ for Code 128 (ISO/IEC 15417);
— ‘03’ for data matrix (ISO/IEC 16022);
— ‘FE’ for other barcode standards not provided for above;
— ‘FF’ no barcode.
Byte 2 is also mandatory i f Bytes 3 to 7 are present.
Bytes 3 to 7: Position o f the SAI, expressed as ‘aa bb cc dd ee’,
where ‘aa’ is the side o f the card on which the SAI appears (‘00’
for portrait side, and ‘01’ for non-portrait side), ‘bb cc’ is the top
le ft corner o f the SAI (where ‘bb’ is the distance from the le ft
edge o f the IDL and ‘cc’ is the distance from the bottom edge o f
the card), and ‘dd ee’ is the bottom right corner o f the SAI (where
‘dd’ is the distance from the le ft edge o f the IDL and ‘ee’ is the
distance from the bottom edge of the card) , with all distances
measured in millimetres, and encoded as BCD.
The bytes are progressively mandatory, i.e. SAI_inp utmethod can
consist only o f byte 1, or only o f bytes 1 and 2, or o f bytes 1 to 7.

I n tern ati o n al Org an i z ati o n

© ISO/IEC 2017 – All rights reserved
fo r S tan d ard i z ati o n
31
 ISO/IEC 1 80 1 3 -3 : 2 01 7(E)

8.4.4.2 Compact encoding

When used with compact encoding, DG12 shall be constructed as a Type 1 data group as follows:
… × [SAI_referencestring] ÷ [SAI_inputmethod] × …

8.4.4.3 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 s tandard encoding

Tag Length Value

‘82’ X SAI_re ferencestring as defined in Table 10.
‘81’ X SAI_inputmethod as defined in Table 10.

IA’s may optionally indicate the presence o f 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-s m-NMA .
id-s m-NMA OBJECT I DENTI FI ER : : = {
is o( 1 ) s tandard( 0 ) driving-licence( 1 8 0 1 3) part-3( 3)
s ecurity-mechanis ms ( 2 ) 4
}
The parameters are optional and shall be o f type param-NMA .
param-NMA : : = SEQUENCE {
Get more
vers ion I NTEGER, FREE standards
SAI _inputmethod OCTETfrom
STRIStandard
NG Sharing Group and our chats
}
The vers ion field shall be set to v1(0) for this version o f the non-match alert mechanism.
The SAI _inputmethod field shall be set to the corresponding value in D G12. I f the SAI _inputmethod
field is not present in DG12, the field shall also not be included in EF.COM.

8.5 Basic access protection

8.5 .1 Purpose

BAP confirms that an IS has physical access to a PICC be fore 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 satis fy a variety o f functional requirements
for ICs with contacts as listed in Table 1.

8.5 .2 Applicability

This mechanism is limited to PICCs and ICs with contacts.

8.5 .3 Description

For a SIC that is accessed via a contactless inter face and protected by the BAP, mechanism shall deny
access to its content by the contactless inter face 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 (K ENC and K MAC ) that are derived from the input string.

32
I n tern ati o n al Org an i z ati o n fo r S tan d ard i z ati o n
© ISO/IEC 2017 – All rights reserved
 ISO/IEC 1 801 3 -3 : 2 0 1 7(E)

A fter the IS has been authenticated success fully, the SIC shall en force encryption and message
authentication o f the communication channel between the IS and the SIC by Secure Messaging
techniques.

8.5 .4 Mechanism

The document basic access keys are stored in the internal elementary file (see ISO/IEC 7816-4:2013).
A SIC that supports BAP shall respond to unauthenticated read attempts (including selection o f files
in the logical data structure) with ‘Security status not satisfied’ (0x6982). The presence o f 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 re ference 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 (i f present) into the IS;
c) the first byte o f the input string shall identi fy the BAP configuration used.
NOTE BAP is intended mainly as an anti-skimming mechanism. However, provided that the entropy o f
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 o f the logo shall be 5 mm, and the B-dimension shall be scaled proportionally in a ratio
o f 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 — B asic access protection logo (not to scale)

I n tern ati o n al Org an i z ati o n

© ISO/IEC 2017 – All rights reserved
fo r S tan d ard i z ati o n
33
 ISO/IEC 1 80 1 3 -3 : 2 01 7(E)

1 Qrt5%bMM *$3j84m zDp8R

PDE CATEGORIES
P Passengers
G Goods
D Dangerous goods

DRIVER RESTRICTIONS
Corrective lenses
Prosthesis
VEHICLE RESTRICTIONS
Automatic transmission AT
Electrically powered
Physically disabled
Bus > 1 6000 kg (GVM) permitted
Tractor only
Industrial/Agricultural only

Figure 17 — B asic access protection logo on I DL (not to scale)

EXAMPLE Suppose the following barcode is printed on the IDL:

This barcode encodes the string “1462483345434115654434034118361284817041”, whose

hexadecimal rendering is ‘31FREE
Get more 34 36 standards
32 34 38 33from
33 34 35 34 33Sharing
Standard 34 31 31Group
35 36and
35 34
our34 33 34 30 33 34
chats
31 31 38 33 36 31 32 38 34 38 31 37 30 34 31’
The first byte (‘31’) o f the input string indicates BAP configuration 1. The entire input string is used as
Kdoc . The resulting derived document access keys are:
— Kenc : ‘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
in formation, only the following 39 bytes may contribute entropy. Assuming they were generated
randomly, the resulting Kdoc contains log 2 (10 39 ) ≈ 129 bits o f entropy.

8.6 Extended Access Control v1

8.6.1 Purpose

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.

8.6.2 Applicability

This mechanism is applicable only to SICs.

8.6.3 Description and mechanism

EACv1 is defined in Annex D.

34
I n tern ati o n al Org an i z ati o n fo r S tan d ard i z ati o n
© ISO/IEC 2017 – All rights reserved
 ISO/IEC 1 801 3 -3 : 2 0 1 7(E)

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 (ID SIC ). I f PACE is per formed be fore EACv1, the SIC identifier (ID SIC ) 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.

8.7 PACE

8.7.1 Purpose

The PACE protocol confirms that an IS has physical access to a SIC be fore 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).

8.7.2 Applicability

This mechanism is applicable only to SICs.

8.7.3 Description and mechanism

PACE is defined in Annex C . This document only supports PACE with ECDH generic mapping. The first
byte o f the input string shall be ‘50’ (“P”) i f PACE is used as a stand-alone protocol, i.e. not used in
conjunction with BAP configuration 1.
I f PACE is used to gain access to the SIC, the SIC shall deny access to the content o f the IDL application
by its inter face unless the IS can prove that it is authorized to access the SIC. This proo f is given in a
password authenticated Elliptic Curve Di ffie Hellman key agreement protocol where the IS proves its
knowledge o f a SIC-specific key Kπ , which is derived from the input string.
A fter the IS has been authenticated success fully, the SIC shall en force encryption and message
authentication o f the communication channel between the SIC and the IS by Secure Messaging
techniques.
PACE shall be per formed in the master file (MF) o f the SIC. The SIC provides the relevant
SecurityI nfos 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.
NOTE See TR-PACE sections 2 .2 and 3.1.5.

8.7.4 PACE relative to BAP

PACE differs from BAP in the following respects:

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

I n tern ati o n al Org an i z ati o n

© ISO/IEC 2017 – All rights reserved
fo r S tan d ard i z ati o n
35
 ISO/IEC 1 80 1 3 -3 : 2 01 7(E)

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 o f the strength o f the input string.
b) The entropy o f the input string(s) used to authenticate the IS can be very low (e.g. 6 digits are
su fficient 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 o f an input string for PACE.

9 Security mechanism indicator

The security mechanism(s) deployed on an IDL with an SIC can be identified to reading authorities by
the addition o f tag ‘86’ to EF.COM. Tag ‘86’ identifies the data groups subject to each mechanism used.
NOTE Use o f 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:
SecurityMechanis ms : : = SET OF SecurityMechanis m
Get more FREE standards from Standard Sharing Group and our chats
SecurityMechanis m : : = SEQUENCE {
mechanism MechanismI dentifer,
datagroups SET OF I NTEGER}

MechanismI dentifer : : = SEQUENCE {

mechanis m OBJECT I DENTI FI ER,
parameters ANY DEFI NED BY mechanis m OPTI ONAL}
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 o f the file identifier
’55 66’ for EF.CVCA and does not speci fy 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):
' 60' ' 36'
' 5F 01 ' ' 0 2 '
' 01 00'
' 5C' ' 0 3'
' 61 6B 63'
' 86' ' 2 A'
' 31 2 8 30 2 1 30 1 F 0 6 0 8 0 4 0 0 7 F 0 0 0 7 0 2 0 2 0 2
30 1 3 0 6 0 8 0 4 0 0 7 F 0 0 0 7 0 2 0 2 0 2 0 2 0 1 0 1 30
0 4 0 4 0 2 55 66 31 0 3 0 2 0 1 0 7 '

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

SET
SEQUENCE
SEQUENCE
OBJECT I DENTI FI ER: 0 . 4 . 0 . 1 2 7 . 0 . 7 . 2 . 2 . 2
SEQUENCE
OBJECT I DENTI FI ER: 0 . 4 . 0 . 1 2 7 . 0 . 7 . 2 . 2 . 2
I NTEGER: 0 1
SEQUENCE

36
I n tern ati o n al Org an i z ati o n fo r S tan d ard i z ati o n
© ISO/IEC 2017 – All rights reserved
 ISO/IEC 1 801 3 -3 : 2 0 1 7(E)

OCTET STRI NG: 55 66

SET
I NTEGER: 0 7

1 0 SIC LDS

1 0.1 General

In addition to the data groups identified in ISO/IEC 18013-2, 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 1 2 — Assignment o f file identifiers and Data Group Tags

S hort EF
E lementary fi le Name E FI D Tag
Identifier

EF.SOD Document security object ’1D’ ’001D’ ’77’

EF.DG12 Non-match alert ’0C’ ’000C’ ’71’
EF.DG13 Active authentication ’0D’ ’000D’ ’6F’
EF.DG14 EACv1 ’0E’ 000E ’6E’

I n tern ati o n al Org an i z ati o n

© ISO/IEC 2017 – All rights reserved
fo r S tan d ard i z ati o n
37
 ISO/IEC 1 80 1 3 -3 : 2 01 7(E)

IDL Standard Application Other Domestic Other Domestic

AID = A0 00 00 02 48 02 00 Application Application
DF DF DF

K ENC
K MAC Data groups speci?ied in
ISO/IEC 18013-2, i.e.
EF.COM and EF.DG1 to
EF.DG11
EF.SOD Document security
object
Tag = ‘77’
Short EF identi?ier = '1D'

EF.DG12 Non-match alert

Tag = ‘71’
Short EF identi?ier = '0C'

EF.DG13 Active
authentication
Tag = ‘6F’
Short
Get more FREE EF identi?ier
standards from= Standard
'0D' Sharing Group and our chats

EF.DG14 EACv1
Tag = ‘6E’
Short EF identi?ier = '0E'

Figure 18 — Data groups

38
I n tern ati o n al Org an i z ati o n fo r S tan d ard i z ati o n
© ISO/IEC 201 7 – All rights reserved
 ISO/IEC 1 801 3 -3 : 2 0 1 7(E)

MF

EF.CardAccess EF.ATR/INFO DF DF
File ID = '011C' File ID = '2F01' IDL Standard Application Other Domestic
Short EF identi?ier = '1C' See NOTE belo w AID = 'A0 00 00 02 48 02 00' Application

K ENC

K MAC

Data groups speci?ied in ISO/IEC

18013-2, i.e. EF.COM and
EF.DG1 to EF.DG11

EF.SOD Document security object

Tag = ‘77’
Short EF identi?ier = '1D'

EF.DG12 Non-match alert

Tag = ‘71’
Short EF identi?ier = '0C'

EF.DG13 Active authentication

Tag = ‘6F’
Short EF identi?ier = '0D'

EF.DG14 EACv1
Tag = ‘6E’
Short EF identi?ier = '0E'

NO TE This EF m ay co nta i n s o ftwa re fu nc tio n s s up p o r ti ng es pecial ly com m a nd ch a i n i n g a nd e x tende d

Lc/Le fie ld .

Figure 19 — File s tructure for an I DL supporting PACE

1 0.2 EF.SOD – Document security obj ect (short EF identifier = ‘1 D’, Tag = ‘77’)

E F. S OD i s defi ne d i n 8.1. 5 .1 .

1 0.3 EF.DG1 2 Non-match alert (short EF identifier= ‘0C’, Tag = ‘71 ’)

D G1 2 i s defi ne d i n 8.4.4.

1 0.4 EF.DG1 3 Active authentication (short EF identifier = ‘0D’, Tag = ‘6F’)

D G1 3 i s defi ne d i n 8.2 .4.1 .

I n tern ati o n al Org an i z ati o n

© ISO/IEC 201 7 – All rights reserved
fo r S tan d ard i z ati o n
39
 ISO/IEC 1 80 1 3 -3 : 2 01 7(E)

1 0.5 EF.DG1 4 EACv1 (short EF identifier = ‘0E’, Tag = ‘6E’)

DG14 is defined in Annex D for EACv1.

I f PACE is supported, additional DG14 content is defined in Annex C.
NOTE See TR-PACE section 3.1.5.

1 0.6 EF.CardAccess i f PACE is supported (short EF identifier = ‘1 C’)

EF.CardAccess is defined in Annex C for PACE.

NOTE See TR-PACE section 3.1.5.

Get more FREE standards from Standard Sharing Group and our chats

40
I n tern ati o n al Org an i z ati o n fo r S tan d ard i z ati o n
© ISO/IEC 2017 – All rights reserved
 ISO/IEC 1 801 3 -3 : 2 0 1 7(E)

Annex A
(informative)

Public key in frastructure (PKI)

A.1 General

This annex suggests a structure for a public key in frastructure specifically in respect o f IDLs that
are used internationally. Such a use environment poses unique challenges, primarily the in feasibility
o f any one issuing jurisdiction to conclude, implement and maintain key sharing agreements and
in frastructures 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 o f a PKI. Standardisation o f 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 in fallible confirmation o f the origin and integrity o f a public key.

A.2 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 itsel f.
d) Use a two-level key approach, consisting o f a root key-pair and a document key pair. The document
key pair is used to sign and veri fy an IDL, and the root key pair is used to sign and veri fy the
document key and other in formation 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 in formation.
NOTE 3 Given the autonomy o f each country, and the political sensitivities that exist between some, a trust
model that uses one global certification authority is considered in feasible.

I n tern ati o n al Org an i z ati o n

© ISO/IEC 2017 – All rights reserved
fo r S tan d ard i z ati o n
41
 ISO/IEC 1 80 1 3 -3 : 2 01 7(E)

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

A.3 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 o f 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 certi fying the association between the public root key and IA A. I f IA B trusts the CA, IA B would
then also trust the association between IA A and its public root key. I f IA A sel f-signs its public root key,
and IA B trusts IA A, a CA becomes superfluous (at least for the purpose o f associating IA A with its
public root key). The public root key is distributed out-o f-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 Re ference [9] ) .
NOTE 3 The document key as used in this document is similar to the Document Signer Key in the ICAO PKI
Specification (see Re ference[ 9] ) .
NOTE 4 ICAO’s PKI GetSpecification
more FREE (see Re ference[
standards from Standardthe
9] ) mentions Sharing Groupcon
out-of-band and our chats
firmation of a root public
key, thus in ferring that the actual distribution o f such keys may take place separately from the out-o f-band
confirmation, possibly using “in-band” communication.
As noted above, it is in feasible to expect each IA’s public root key to be distributed (out o f band) to every
other IA. Consequently, i f 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 I A B’s private
root key) o f the IAs (including IA A, i f applicable) that it trusts. IA B also signs the public root key o f 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-o f-band fashion.
NOTE 6 In addition, IA B would also publish in formation 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.

Trust list IA1 public root key IA2 public root key IAn public root key
IA1 identifying details IA1 identifying details IA2 identifying details IAn identifying details
IA2 identifying details IA1 public root key IA2 public root key IAn public root key
...
IAn identifying details Digital signature Digital signature Digital signature
(created with IA B's (created with IA B's (created with IA B's
Digital signature private root key) private root key) private root key)
(created with IA B's
private root key)

Figure A.1 — Certificates published by an I A

42
I n tern ati o n al Org an i z ati o n fo r S tan d ard i z ati o n
© ISO/IEC 2017 – All rights reserved
 ISO/IEC 1 801 3 -3 : 2 01 7(E)

I f every IA publishes the same items that IA B publishes (i.e. a signed trust list, and signed public root
keys o f each authority on the trust list), it enables IA A to construct a diagram o f the complete trust
network. For example, i f IA B trusts IA C, IA A uses IA C’s public root key (signed by IA B), to veri fy IA
C’s trust list. I f IA C trusts IA D, IA A uses IA C’s public root key to veri fy 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
veri fy any IDL presented.
NOTE 7 The trust network diagram includes all the public keys, lists and other in formation required to veri fy
an IDL in an o ff-line manner. Typically, the trust network diagram is updated periodically (e.g. daily), and used as
re ference for all internal verification actions.
The above allows IA A to veri fy the public root key o f each IA (in the trust network). The public root key
then is used to veri fy the public document keys published by each IA.
Public root keys distributed between IAs in an out-o f-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 o f the public root key. The ICAO PKI
Specification (see Re ference[ 9 ]) however appears to discourage such availability o f ICAO’s equivalent o f the
public root key.
It is anticipated that the global trust network will eventually consist o f a collection o f “local” trust
networks, with the di fferent local trust networks connected by a limited number o f trust “links”.
For example, in the Southern A frica Development Community (SADC), South A frica may act as an
aggregator for the SADC countries. That is, each SADC country exchanges public root keys (out-o f-band)
only with South A frica, and vice versa. South A frica then signs each public root key, and publishes same
along with the list o f 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 o f Motor
Vehicle Administrators (AAMVA) may fulfil a similar function in North America. Figure A.2 illustrates
an example of a trust network.

I n tern ati o n al Org an i z ati o n

© ISO/IEC 2017 – All rights reserved
fo r S tan d ard i z ati o n
43
 ISO/IEC 1 80 1 3 -3 : 2 01 7(E)

IA 1.1 IA 2.2
trust list: [IA1 ]
trust list: [IA2. 3]
p ublic root key 1
p ublic root key 2. 3
IA1 . 1 public IA 2.1 IA2. 2 public
document key(s) trust list: [PIA1 ,
document key(s)
IA2. 2]
public root key 1
public root key 2. 2
IA 1.2
IA2. 1 public
trust list: [IA1 ]
document key(s) IA 2.3
p ublic root key 1 PIA 1 trust list: [IA2. 4]
IA1 . 2 public trust list: [IA1 . 1 ,
p ublic root key 2. 4
document key(s) IA1 . 2, IA1 . 3]
IA2. 3 public
p ublic root key 1 . 1
document key(s)
p ublic root key 1 . 2

IA 1.3 p ublic root key 1 . 3

trust list: [IA1 ]

public root key 1
IA1 . 3 public document IA 2.4
key(s) trust list: [IA2. 1 ]
p ublic root key 2. 1
IA2. 4 public
document key(s)

IA 3
trust list: [IA 4. 1 ]
p ublic root key 4. 1
IA3 public document
key(s)
Legend

ENTITY NAME
IA 4.1
IA 4.2 IA 4.3 published
trust list: [PIA1 , IA3,
IA4. 2]
trust list: [IA4. 1 , trust list: [IA4. 2, IA 4.4 information
IA4. 3] IA4. 4]
public root key 1 Get more FREE standards
p ublic root key 4. 1
from Standard Sharing
public root key 4. 2
Group
trust list: [IA4. 3] and our chats
public root key 3 p ublic root key 4. 3
p ublic root key 4. 3 public root key 4. 4 IA 4. 4 public
p ublic root key 4. 2
IA 4. 2 public IA 4. 3 public document key(s)
IA4. 1 public Local trust
document key(s) document key(s)
document key(s) network

Figure A. 2 — Trus t network example

A.4 Implementation

A.4.1 Publication mechanism

It is suggested that the in formation to be published, be published (as signed certificates) in a location
that is easily accessible by all veri fying entities. Consequently, each IA’s identi fying 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. I f the Internet is used, a requirement to
use server side authenticated SSL (similar to the IC AO 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 o f alternative publication locations in general is that they may not be readily accessible to all
veri fying entities (with the potential for consequential di fficulties for the IA’s card holders). In the end, it remains
the responsibility o f the IA to select a suitable publication location.
The security o f the publication location is the responsibility o f each IA. However, the authenticity o f all
published in formation can be verified using the IA’s public root key, thus adding an additional layer o f
security to published in formation.

44
I n tern ati o n al Org an i z ati o n fo r S tan d ard i z ati o n
© ISO/IEC 2017 – All rights reserved
 ISO/IEC 1 801 3 -3 : 2 0 1 7(E)

It follows that in cases where an IA may not have the necessary in frastructure or expertise or may not
want to publish and/or maintain published in formation in-house, such publication may be per formed
(under agreement) by other IAs or trusted third parties.
The availability o f published in formation is crucial. I f published in formation is not available, a veri fying
entity cannot update its trust network diagram, and thus will be unaware o f 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).

A.4.2 In formation published

As discussed in A.3 , each IA (in its role as VA) publishes a trust list and the public root key o f each IA on
the trust list. Each o f 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 re ferenced by local industry (e.g. airlines and car
hire companies) as a primary source to veri fy 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 Re ference [9 ]), with the di fference 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 (i f it is also an IA) also publishes its own public document keys.
A standard format for each o f the above documents (or certificates) has to be specified.

A.5 Certificate content

In considering certificate content, cognizance was taken o f industry experts’ recommendations

that X.509 certificates should only be used i f absolutely necessary (see Re ference [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 care fully considered by an
I A 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.

A.5 .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) Identi fy 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 i f a digital signature is used). Additional
identification in formation includes directions on how and where in formation published by the IA
can be accessed.

b) Using a trust network diagram, identi fy the IA’s public root key(s). I f the IA has published more than
one root key, identi fy the public root key used associated with the public document key certificate.
NOTE I f 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-o f-band
exchange o f the IA’s public root key with any o f the existing IAs on the VA’s trust network diagram.
The following options exist to identi fy this particular public root key:

I n tern ati o n al Org an i z ati o n

© ISO/IEC 2017 – All rights reserved
fo r S tan d ard i z ati o n
45
 ISO/IEC 18013-3:2017(E)

1) Include a public root key identifier in the public document key certificate and include the same
identifier in the public root key certificate.
2) Use the date that the public document key certificate was signed to identi fy the public root key
that was used for signing certificates during this period. This requires that the public root key
certificate contain “valid for signing from” and “valid for signing until” dates, and limits the IA
to the use o f only one key at any given time.
c) Use the IA’s public root key to check the public document key certificate’s digital signature. This
requires knowledge o f the digital signature algorithm (and accompanying parameters) used. The
algorithm and parameters are specified in the public document key certificate.
d) Veri fy 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 o f 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 (re fer to A.6.2
for more in formation), thus reducing the complexity o f the overall solution.

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

a) Identi fy the IA. The same identification process as for the public document key certificate
verification is followed.
b) Obtain the correct public document key. Regardless o f whether or not the public document
key is includedGet
onmore
the IDL, an attempt should be made to obtain the public document key from
FREE standards from Standard Sharing Group and our chats
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) .

For compact encoding, the appropriate public document key is identified by comparing the issue
date of the IDL with the “valid for signing from” and “valid for signing until” dates of the available
public document keys o f the IA. For standard encoding, the appropriate public document key can be
identified using a key identifier.
c) Veri fy the public document key certificate, as described above.
d) Check the digital signature on the IDL using the public document key. This requires knowledge o f
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).

A.5.2 Document key

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

a) IA identi fying details;

b) public document key;
c) public document key identifier (i f dates are not used to identi fy the public document key);
d) identifier o f the public root key used to sign the document public key certificate (i f dates are not
used to identi fy the public root key);
e) beginning (and ending) issuing dates for which the key is valid (at the time o f signing the certificate)
(i f dates are used to identi fy the public document key);
f ) digital signature algorithm and parameter in formation;

46
I n tern ati o n al Org an i z ati o n fo r S tan d ard i z ati o n
© ISO/IEC 2017 – All rights reserved
 ISO/IEC 1 801 3 -3 : 2 0 1 7(E)

g) revocation indicator (Yes/No);

h) revocation date (mandatory i f revocation indicator is Yes) (i f dates are used to identi fy the public
document key);
i) notes (optional), which can be used to add additional information regarding the revocation, in
English, French or Spanish i f required;
j) date o f signing (i f dates are used to identi fy the public root key), which is used to identi fy the
private key that was used to sign the certificate; this is optional i f the public key is included on the
IDL, as it can be assumed that the date o f signing is the same as the IDL issue date;
k) digital signature (assuming a digital signature with appendix scheme).

A.5 .3 Root key

Based on the discussion in A.5.1 , a root key certificate should consist o f the following in formation:
a) IA identi fying details;
b) public root key;
c) public root key identifier (i f dates are not used to identi fy the public root key);
d) beginning (and ending) signing dates for which the key is valid (at the time o f signing the certificate);
e) date o f 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).

A.6 Key revocation

A.6.1 Root key compromise

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

a) none o f the documents signed with the private root key can be considered “sa fe” anymore;
b) the IA (whose private root key has been compromised) is e ffectively 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 veri fy such
in formation, since there is no way in which the compromised IA can sign such publication.
In case o f a compromise, the compromised IA thus has to noti fy all the immediate VAs o f the compromise
in an out-o f-band fashion. Following such notification, the immediate VAs have to immediately remove
the compromised I A 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-o f-band) the public root keys o f the IAs in the compromised IA’s

I n tern ati o n al Org an i z ati o n

© ISO/IEC 2017 – All rights reserved
fo r S tan d ard i z ati o n
47
 ISO/IEC 1 80 1 3 -3 : 2 01 7(E)

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 o f 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 o f its public root key (by out-o f-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 care fully
consider the frequency with which it updates its trust network diagram.
A.6.2 Document key compromise

The compromise o f a private document key is easier to communicate and process than in the case o f 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 o f the “Revocation indicator” field set to “Y”, and
(i f necessary) the value o f 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.

A.7 Trust model weak points

A.7.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
o f the weak pointsGet
o f the model,
more FREE so standards
that these from
can be adequately
Standard addressed.
Sharing Group This subclause
and our chats 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.
A.7.2 General

One o f the inherent weaknesses o f 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 o f chain lengths for all IDLs verified.
NOTE This approach does not guarantee the lowest probability o f letting a problematic IDL slip through.
Knowing about the above approach, criminals can specifically target the end points o f long trust chains in a VA’s
trust network in their attempts to circumvent the system.
I f 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 identi fy the point o f compromise. As described above, minimizing the sum o f
chain lengths for all IDLs verified can minimize this problem.
A VA may include an IA in a trust list for political reasons, even i f the VA does not trust the IA
internally. Even though such conduct would e ffectively sabotage the trust model, it cannot be ruled
out. Consequently, it is important that VAs augment the trust model with other methods o f establishing
trust in an IDL issued by an IA.

48
I n tern ati o n al Org an i z ati o n fo r S tan d ard i z ati o n
© ISO/IEC 2017 – All rights reserved
 ISO/IEC 18013 -3 :2 017(E)

A.7.3 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 o f 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 o f the attacks that are specific to the proposed trust model.
The distributed nature o f the proposed trust model requires each IA to take responsibility for the
sa fekeeping o f its own private keys. The general level o f security which an IA is capable o f 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-o f-band means. The main attack
on such an exchange would be to replace the public key somewhere in the process. IAs should be aware
o f this risk, and implement appropriate procedures to secure their out-o f-band key exchanges.
Several attacks against published in formation (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 veri fy 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 in formation) are not influenced
by the frequency o f trust network verification. These attacks are however likely to be uncovered over
time, when it is realized that IDLs that do not veri fy is due to incorrect public keys being used to try and
veri fy authentic IDLs.
A variant on the published in formation attack is to try and sneak the details o f a fictitious IA into the
trust list and public keys published by an existing IA. Although this would require some inside help (as
the in formation has to be signed using the existing IA’s private root key), this subter fuge can potentially
remain undetected.
Denial o f service attacks could be used on their own or in conjunction with some o f 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 su fficient 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?

I n tern ati o n al Org an i z ati o n

© ISO/IEC 2017 – All rights reserved
fo r S tan d ard i z ati o n
49
 ISO/IEC 1 801 3 -3 : 2 01 7(E)

EXAMPLE 2 A fter 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 I A C in its trust list, and I A C includes I A B in its trust list. VA A thus has to
manually ensure that IA B is not included in its trust network diagram.

Get more FREE standards from Standard Sharing Group and our chats

50
I n tern ati o n al Org an i z ati o n fo r S tan d ard i z ati o n
© ISO/IEC 2017 – All rights reserved
 ISO/IEC 1 801 3 -3 : 2 0 1 7(E)

Annex B
(normative)

Basic access protection

B.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 o f a secure channel using pre-defined key
material which should only be revealed by closer physical inspection o f the document, be fore access is
granted to information stored in the SIC.
The secure channel protects the integrity and authenticity o f authorized communication between an
IS and an identity document. I f the entropy o f the key material is high enough, a certain amount o f
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, i f knowledge about the keying material
is gained, it can be used to decrypt any past sessions. However, knowledge o f a particular session’s session keys
does not enable the decryption o f past or future sessions.
NOTE 2 This protocol is based on ICAO’s Basic Access Control.

B.2 Parameters

Re ferring specifications shall speci fy the following when re ferencing BAP:

a) the source of Kdoc ;
b) the method(s) by which Kdoc is entered into the IS.
NOTE This document uses information printed on the IDL in machine and/or human-readable form as Kdoc .
The SAI demarcates the in formation used. The first byte o f the input string indicates the use o f BAP and has the
value “1”. For further details, see 8.3 and 8.5 .

B.3 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) A fter success ful 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.

B.4 Key derivation mechanism

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

I n tern ati o n al Org an i z ati o n

© ISO/IEC 2017 – All rights reserved
fo r S tan d ard i z ati o n
51
 ISO/IEC 1 801 3 -3 : 2 01 7(E)

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 per formed 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 o f D (H = h (D)).
c) The k le ftmost bits o f H form the key K.
The document basic access keys Kenc and K mac are derived using the mechanism described above, with
c = 1 and 2, respectively. In addition, the most significant 16 bytes o f the h (Kdoc) is used as the value for
K seed . h is the selected cryptographic hash function defined the BAP configuration.

Kdoc should be di fferent for every document and care should be taken to ensure that Kdoc is su fficiently
random for the intended application.

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

B.5 Authentication and key establishment

Authentication and key establishment is provided by a three pass challenge-response protocol
Get11770-2:1996
according to ISO/IEC more FREE key establishment
standards mechanism
from Standard 6 using
Sharing the and
Group selected block cipher e. A
our chats
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 o f 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 (IC AO 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 [K mac](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 o f 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.

52
I n tern ati o n al Org an i z ati o n fo r S tan d ard i z ati o n
© ISO/IEC 2017 – All rights reserved
 ISO/IEC 1 801 3 -3 : 2 0 1 7(E)

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 [K mac](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 o f 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.

B.6 Secure messaging

A fter a success ful execution o f 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:2013 according to the requirements below. The modes of operation described in B.7 shall be used.

B.6.1 Message structure o f 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, there fore the class byte CLA shall be ‘0C’.
The actual value o f Lc will be modified to Lc’ a fter application o f secure messaging. In the protected
command APDU, the new Le byte shall be set to ‘00’, while the value o f the original Le byte may be
conveyed in the appropriate data object.

Table B .1 — Usage o f SM Data Obj ects

D O ‘87 ’ D O ‘97 ’ D O ‘9 9 ’ D O ‘8E ’

Content Padding-content Le (1 or 2 bytes) Processing status Cryptographic check-

indicator byte (shall (SW1-SW2) sum (MAC)
be ‘01’) followed by
the cryptogram
Command APDU Mandatory i f data Mandatory i f data is Not used. Mandatory.
is sent, otherwise requested, other-
absent. wise absent.
Response APDU Mandatory i f data is Not used. Mandatory, only Mandatory i f DO‘87’
returned, other- absent when a SM and/or DO‘99’ are
wise absent. error occurs. present.

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. I f Le is not available (case 1 and 3), leave building DO‘97’ out.

I n tern ati o n al Org an i z ati o n

© ISO/IEC 2017 – All rights reserved
fo r S tan d ard i z ati o n
53
 ISO/IEC 1 80 1 3 -3 : 2 01 7(E)

Unprotected command APDU

Cmd Hdr Lc Data Data ... Data Le
4 bytes n bits nbits m bits (m< n )

Pad data
Data Data Data '80 00 ..'
...
n bits n bits m bits (m< n ) n -m bits

Encrypt using e [KS enc ]

X1 X2 X3 ... Xn
n bits n bits nbits n bits

Build DO'87'

'87' L '01' <encdata>

Pad command header Build DO'97'

Cmd Hdr '80 00 00 ..' '87' L '01' <encdata> '97' L Ne
4 bytes n -32 bits

Compute MAC
using m [KS mac ]

CC

Build DO'8E' New Le

Cmd Hdr Lc' '87' L '01' <encdata> '97' L Ne '8E' L='08' CC '00'
4 bytes
Get more FREE standardsProtected
from command APDUSharing Group and our chats
Standard

Figure B .1 — Computation o f a SM command APDU

Figure B.2 shows the transformation of an unprotected response APDU to a protected response APDU
i n c a s e data i s ava i lable . I f no d ata i s avai lab le, le ave bu i ld i ng D O ‘8 7 ’ out.

54
I n tern ati o n al Org an i z ati o n fo r S tan d ard i z ati o n
© ISO/IEC 2017 – All rights reserved
 ISO/IEC 1 801 3 -3 : 2 0 1 7(E)

Unprotected response APDU

Data Data ... Data SW1-SW2
n bits n bits m bits (m < n ) 2 bytes

Pad data
Data Data Data '80 00 ..'
...
n bits n bits m bits (m < n ) n-m bits

Encrypt using e [KS enc ]

X1 X2 X3 ... Xn
n bits n bits n bits n bits

Build DO'87' Build DO'99'

'87' L '01' <encdata> '99' L SW1-SW2

2 bytes

Compute MAC
using m [KS mac ]

CC

Build DO'8E'

'87' L '01' <encdata> '99' L SW1-SW2 '8E' L='08' CC SW1-SW2

2 bytes 2 bytes
Protected response APDU

Figure B . 2 — Computation o f a SM response APDU

B.6.2 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:2013 defines the following status bytes to indicate SM errors:
a) ‘6987’ Expected SM data objects missing
b) ‘6988’ SM data objects incorrect
B.6.3 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.

B.7 Modes o f operation

B.7.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 i f it is not a multiple o f the block
cipher’s block length n . During the computation o f SM APDUs, data shall always be padded.
Padding according to ISO/IEC 9797-1:1999 padding method 2 shall be used.

I n tern ati o n al Org an i z ati o n

© ISO/IEC 2017 – All rights reserved
fo r S tan d ard i z ati o n
55
 ISO/IEC 1 80 1 3 -3 : 2 01 7(E)

B.7.2 Message authentication

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

A fter a success ful authentication, the datagram to be MACed shall be prepended with an 8 byte send
sequence counter (SSC). I f 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 be fore a MAC is calculated, i.e. i f the
starting value is x, in the first command the value o f SSC is x+1. The value o f SSC for the first response
is then x+2. The initial value o f the SSC is computed by concatenating the four least significant bytes o f
RND.ICC and RND.IFD, respectively:
SSC = RND.ICC (4 least significant bytes) || RND.IFD (4 least significant bytes)

B.8 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:2004;
— TDEA according to ISO/IEC 18033-3:2005 (“Triple DES”);
— ISO/IEC 9797-1:1999 MAC algorithm 3.

NOTE The first edition o f ISO/IEC 18013-3:2005 supported multiple BAP configurations. This edition
supports BAP configuration 1 only. See Table B.2 .
Get more FREE standards from Standard Sharing Group and our chats
Table B . 2 — BAP configuration 1

O ne- byte identi fier ’31’

OI D bap-confg-1
H ash algorithm ,h SH A-1
Blo ck cipher ,e TDEA using keying option 2. The le ftmost 64 bits o f the 128-bit key form K1, while the
right-most 64 bits form K2 .
Block length , n 64 bits
Key length ,k 128 bits
Note that only 112 bits are e ffectively used by this block cipher as keying material;
certain implementations may require adjustment o f the remaining parity bits.
M AC algorithm, m ISO/IEC 9797-1:1999 M AC algorithm 3 with block cipher TDEA and padding method 2 .
TDEA is used with the keying option that K1=K2=K3 (reduces to DEA). For MAC calcu -
lation, the le ftmost 64 bits o f the 128-bit key form K, while the right-most 64 bits form
K’. The resulting M AC algorithm is also known as “Retail M AC”.

BAP configuration 1 is equivalent to Basic Access Control (BAC) as described in ICAO Doc 9303
(ISO/IEC 7501-1), Annex A, Appendix 5.

The following ASN.1 object identifier is used to re fer to the BAP configuration 1:
bap-confg-1 OBJECT I DENTI FI ER : : = {
is o( 1 ) s tandard( 0 ) driving-licence( 1 8 0 1 3) part-3( 3) s ecurity-mechanis ms ( 2 ) id-s m-
BAP( 1 ) 1
}

56
I n tern ati o n al Org an i z ati o n fo r S tan d ard i z ati o n
© ISO/IEC 2017 – All rights reserved
 ISO/IEC 1 801 3 -3 : 2 0 1 7(E)

B.9 Card commands

B.9.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 B . 3 — Command APDU: GE T CH ALLENGE

CLA As defined in ISO/IEC 7816-4:2013

INS 0x84 GET CHALLENGE
P1 0x00 No information given
P2 0x00 (any other values reserved for future use)
Lc field Absent
Data field Absent
Le field 0x08

Table B .4 — Response APDU: GET CH ALLENGE

Data field 8-byte random challenge (RND.ICC)

SW1-SW2 ’9000’ Normal processing
Other Operating system dependent error

B.9.2 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 B . 5 — Command APDU: M U TUAL AU THEN TIC ATE

CLA As defined in ISO/IEC 7816-4:2013

INS 0x82 MUTUAL AUTHENTICATE
P1 0x00 re ference algorithm implicitly known
P2 0x00 qualifier re ference implicitly known
Lc field Length o f subsequent data field.
Data field Host cryptogram including MAC (E_IFD || M_IFD).
Le field 0x28

Table B .6 — Response APDU: M U TUAL AU THEN TIC ATE

Data field Card cryptogram including MAC (E_ICC || M_ICC)

SW1-SW2 ’9000’ Normal processing
‘6300’ Verification failed. Host cryptogram or MAC verification failed
Other Operating system dependent error

B.1 0 Worked example (in formative)

This subclause provides a worked example for BAP configuration 1. Note that not all steps are
explicitly shown.
Static document keying material:
Kdoc = ‘31239AB9CB282DAF66231DC5A4DF6BFBAE’

I n tern ati o n al Org an i z ati o n

© ISO/IEC 2017 – All rights reserved
fo r S tan d ard i z ati o n
57
 ISO/IEC 1 801 3 -3 : 2 01 7(E)

Computation o f basic access keys:

Input: K seed = H SHA-1 (Kdoc)
K seed = ‘BFE25204D0A589510CD9C397C064CC2DAF5E952F’
Encryption Key (Kenc) computation:
1. Concatenate K seed and c (c = 1):
D = ‘BFE25204D0A589510CD9C397C064CC2D
00000001’
2. Calculate the hash of D:
H SHA-1 (D) = ‘AE161CC6AFB5FB766BD20016CAC3F181
E77D9428’
3. Form key:
Kenc = ‘AE161CC6AFB5FB766BD20016CAC3F181’
K1 = K 3 = ‘AE161CC6AFB5FB76’
K 2 = ‘6BD20016CAC3F181’
Message Authentication Key (K mac) computation:
4. Concatenate K seed and c (c = 2):
Get more FREE standards from Standard Sharing Group and our chats
D = ‘BFE25204D0A589510CD9C397C064CC2D
00000002’
5. Calculate the hash of D:
H SHA-1 (D) 24F522867731552B72533F5D25CC4806
777D5953’
6. Form key:
K mac = ‘24F522867731552B72533F5D25CC4806’
K = ‘24F522867731552B’
K’ = ‘72533F5D25CC4806’
Authentication and Establishment o f Session Keys:
IS:
1. Request an 8 byte random challenge from the document’s SIC:
Command APDU:

CLA INS P1 P2 Le
‘00’ ‘84’ ‘00’ ‘00’ ‘08’

58
I n tern ati o n al Org an i z ati o n fo r S tan d ard i z ati o n
© ISO/IEC 2017 – All rights reserved
 ISO/IEC 1 801 3 -3 : 2 01 7(E)

Document SIC:
2. Generate random challenge and return it to IS:
RND.ICC = ‘4608F91988702212’
Response APDU:

Response Data Field SW1 SW2

RND.ICC ‘90’ ‘00’

IS:
3. Generate an 8-byte random challenge and 16-byte random keying material:
RND.IFD = ‘781723860C06C226’
K.IFD = ‘0B795240CB7049B01C19B33E32804F0B’
4. Concatenate RND.IFD, RND.ICC and K.IFD:
S = ‘781723860C06C2264608F91988702212
0B795240CB7049B01C19B33E32804F0B’
5. Encrypt S using TDEA with key Kenc :
E_IFD = ‘861D8A36082E38FB1F699FFDFAF7F903
ADF74AA79E8459E50080F43ACB096B52’
6. Compute “Retail MAC” over E_IFD with key K mac :
M_IFD = ‘20498D845BE458C3’
7. Construct command data for MUTUAL AUTHENTICATE and send command to the
document’s SIC:
cmd_data = ‘861D8A36082E38FB1F699FFDFAF7F903
ADF74AA79E8459E50080F43ACB096B52
20498D845BE458C3’

Command APDU:

CLA INS P1 P2 Lc Command Data Field Le

‘00’ ‘82’ ‘00’ ‘00’ ‘28’ cmd_data ‘28’

Document SIC:
8. Generate 16-byte random keying material:
K.ICC = ‘0B4F80323EB3191CB04970CB4052790B’
9. Calculate XOR of K.IFD and K.ICC:

I n tern ati o n al Org an i z ati o n

© ISO/IEC 2017 – All rights reserved
fo r S tan d ard i z ati o n
59
 ISO/IEC 1 801 3 -3 : 2 01 7(E)

K seed = ‘0036D272F5C350ACAC50C3F572D23600’
10. Derive session keys:
KS enc = ‘969EC03B1CBFE9DDD11AB1FED206EBE4’
KS mac = ‘F0CA1E1EB5ADF208816B88DD579CC1F8’

11. Initialize send sequence counter:

SSC = ‘887022120C06C226’
12. Concatenate RND.ICC, RND.IFD and K.ICC:
R = ‘4608F91988702212781723860C06C226
0B4F80323EB3191CB04970CB4052790B’
13. Encrypt R using TDEA with key Kenc :
E_ICC = ‘C8F977C50533BE2104E68A844040310A
11362AF11EC09D972CE8AD3FDCB9164B’
14. Compute “Retail MAC” over E_ICC with key K mac :
M_ICC = ‘9E8E43F7B5CEDB06’
15. Construct response data and send response APDU to the IS:
resp_data = ‘C8F977C50533BE2104E68A844040310A
11362AF11EC09D972CE8AD3FDCB9164B
Get more FREE standards from Standard Sharing Group and our chats
9E8E43F7B5CEDB06’
Response APDU:

Response Data Field SW1 SW2

resp_data ‘90’ ‘00’
IS:

16. Calculate XOR of K.IFD and K.ICC:

K seed = ‘0036D272F5C350ACAC50C3F572D23600’
17. Derive session keys:
KS enc = ‘969EC03B1CBFE9DDD11AB1FED206EBE4’
KS mac = ‘F0CA1E1EB5ADF208816B88DD579CC1F8’
18. Initialize send sequence counter:
SSC = ‘887022120C06C226’

60
I n tern ati o n al Org an i z ati o n fo r S tan d ard i z ati o n
© ISO/IEC 2017 – All rights reserved
 ISO/IEC 1 801 3 -3 : 2 01 7(E)

Secure Messaging:
IS
1. SELECT EF.COM (file identifier = ’01 1E’):
Unprotected command APDU:

CLA INS P1 P2 Lc Command Data Field

‘00’ ‘A4’ ‘02’ ‘00’ ‘02’ ’01 1E’

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 KS mac :
— Increment SSC:
SSC = ‘887022120C06C227’
— Concatenate SSC and M:
N = ‘887022120C06C2270CA4020C80000000
8709016375432908C044F6’
— Compute MAC:
CC = ‘BF8B92D635FF24F8’
g) Build DO‘8E’:
DO8E = ‘8E08BF8B92D635FF24F8’
h) Construct command data:
cmd_data = ‘8709016375432908C044F68E08BF8B92
D635FF24F8’

I n tern ati o n al Org an i z ati o n

© ISO/IEC 2017 – All rights reserved
fo r S tan d ard i z ati o n
61
 ISO/IEC 1 801 3 -3 : 2 01 7(E)

Protected command APDU:

CLA INS P1 P2 Lc Command Data Field Le

‘0C’ ‘A4’ ‘02’ ‘0C’ ‘15’ cmd_data ‘00’
Document SIC:
2. Set EF.COM as the currently selected file and send a ffirmative response to IS:
Unprotected response APDU:
a) Build DO‘99’:
DO99 = ‘99029000’
b) Compute “Retail MAC” of DO99 with KS mac :
— Increment SSC:
SSC = ‘887022120C06C228’
— Concatenate SSC and DO99:
N = ‘887022120C06C22899029000’
— Compute MAC:
CC = ‘FA855A5D4C50A8ED’
c) Build DO‘8E’:
DO8E = Get more FREE standards from Standard Sharing Group and our chats
‘8E08FA855A5D4C50A8ED’
d) Construct response data:
resp_data = ‘990290008E08FA855A5D4C50A8ED’
SW1 SW2
‘90’ ‘00’
Protected response APDU:

Response Data Field SW1 SW2

resp_data ‘90’ ‘00’
IS:
3. READ BINARY o f the first 4 bytes:
Unprotected command APDU:

CLA INS P1 P2 Le
‘00’ ‘B0’ ‘00’ ‘00’ ‘04’

a) Mask class byte and pad command header:

cmd_header = ‘0CB0000080000000’
b) Build DO ‘97’:

62
I n tern ati o n al Org an i z ati o n fo r S tan d ard i z ati o n
© ISO/IEC 2017 – All rights reserved
 ISO/IEC 1 801 3 -3 : 2 01 7(E)

DO97 = ‘970104’
c) Concatenate cmd_header and DO97:
M = ‘0CB0000080000000970104’
d) Compute “Retail MAC” of M with KS mac :
— Increment SSC:
SSC = ‘887022120C06C229’
— Concatenate SSC and M:
N = ‘887022120C06C2290CB0000080000000
970104’
— Compute MAC:
CC = ‘ED6705417E96BA55’
e) Build DO‘8E’:
DO8E = ‘8E08ED6705417E96BA55’
f) Construct command data:
cmd_data = ‘9701048E08ED6705417E96BA55’
Protected command APDU:

CLA INS P1 P2 Lc Command Data Field Le

‘0C’ ‘B0’ ‘00’ ‘00’ ‘0D’ cmd_data ‘00’
Document SIC:
4. Return 4 bytes o f EF.COM starting at o ffset 0:
data = ‘600D5F01’
Unprotected response APDU:

Response Data Field SW1 SW2

data ‘90’ ‘00’

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’

I n tern ati o n al Org an i z ati o n

© ISO/IEC 2017 – All rights reserved
fo r S tan d ard i z ati o n
63
 ISO/IEC 1 801 3 -3 : 2 01 7(E)

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

M = ‘870901F9435D056E27C52E99029000’
f) Compute “Retail MAC” of M with KS mac :
— Increment SSC:
SSC = ‘887022120C06C22A’
— Concatenate SSC and M:
N = ‘887022120C06C22A870901F9435D056E
27C52E99029000’
— Compute MAC:
CC = ‘0C15238078E0A4C9’
g) Build DO‘8E’:
DO8E = ‘8E080C15238078E0A4C9’
h) Construct response data:
resp_data = ‘870901F9435D056E27C52E990290008E
080C15238078E0A4C9’
Protected response APDU:
Get more FREE standards from Standard Sharing Group and our chats
Response Data Field SW1 SW2
resp_data ‘90’ ‘00’
IS:
5. READ BINARY o f the remaining 11 bytes:
Unprotected command APDU:

CLA INS P1 P2 Le
‘00’ ‘B0’ ‘00’ ‘04’ ‘0B’

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 KS mac :
— Increment SSC:
SSC = ‘887022120C06C22B’

64
I n tern ati o n al Org an i z ati o n fo r S tan d ard i z ati o n
© ISO/IEC 2017 – All rights reserved
 ISO/IEC 1 801 3 -3 : 2 01 7(E)

— Concatenate SSC and M:

N = ‘887022120C06C22B0CB0000480000000
97010B’
— Compute MAC:
CC = ‘40900A27C4C390D6’
e) Build DO‘8E’:
DO8E = ‘8E0840900A27C4C390D6’
f) Construct command data:
cmd_data = ‘97010B8E0840900A27C4C390D6’
Protected command APDU:

CLA INS P1 P2 Lc Command Data Field Le

‘0C’ ‘B0’ ‘00’ ‘04’ ‘0D’ cmd_data ‘00’
Document SIC:
6. Return 11 bytes o f EF.COM starting at o ffset 4:
data = ‘04303130305C04616B6567’
Unprotected response APDU:

Response Data Field SW1 SW2

data ‘90’ ‘00’

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 :
— Increment SSC:

I n tern ati o n al Org an i z ati o n

© ISO/IEC 2017 – All rights reserved
fo r S tan d ard i z ati o n
65
 ISO/IEC 1 801 3 -3 : 2 01 7(E)

SSC = ‘887022120C06C22C’
— Concatenate SSC and M:
N = ‘887022120C06C22C871101B3CD033441
7393661AA9B39206EC89CC99029000’
— Compute MAC:
CC = ‘0747E8CEC180EB48’
g) Build DO‘8E’:
DO8E = ‘8E080747E8CEC180EB48’
h) Construct response data:
resp_data = ‘871101B3CD0334417393661AA9B39206
EC89CC990290008E080747E8CEC180EB
48’
Protected response APDU:

Response Data Field SW1 SW2

resp_data ‘90’ ‘00’

Get more FREE standards from Standard Sharing Group and our chats

66
I n tern ati o n al Org an i z ati o n fo r S tan d ard i z ati o n
© ISO/IEC 2017 – All rights reserved
 ISO/IEC 1 801 3 -3 : 2 0 1 7(E)

Annex C
(normative)

PACE

C.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 by the ICAO Technical Report – Supplemental Access Control for Machine Readable
Travel Documents , v1.01, 2010 [TR-PACE] .
A fter PACE, AES and 3DES shall be applied in Secure Messaging as specified in TR-PACE.
NOTE 1 The Secure Messaging syntax is specified in B.6.
NOTE 2 According to TR-PACE, padding is always per formed by the secure messaging layer, so that the
underlying message authentication code need not per form any internal padding.

C.2 Changes to ICAO TR-PACE

C.2 .1 Overview

This subclause describes the changes that apply to TR-PACE to support access to the IDL application
using PACE.

C.2 .2 General

Only ECDH generic mapping shall be used.

For Basic Access Control (BAC), read Basic Access Protection (BAP).
For DG2, read DG6.
For DG15 read DG13.
For ePassport, read IDL.
For ePassport Application, read Driving Licence Application.
For MRTD, read IDL.
For MRTD chip, read SIC.
For MRZ, read input string.
For password, read input string.
For PCD, read IS/IFD.
For PICC, read SIC.
For Supplemental Access Control, read PACE.

I n tern ati o n al Org an i z ati o n

© ISO/IEC 2017 – All rights reserved
fo r S tan d ard i z ati o n
67
 ISO/IEC 1 80 1 3 -3 : 2 01 7(E)

C.2 .3 Clauses not applicable to IDL

The following clauses of TR-PACE are not applicable to the IDL application:
a) 4.1.1: DH;
b) 4.3.2: DH Mapping;
c) 4.3.3: Pseudorandom Number Mapping;
d) 4.5.1: Di ffie Hellman Public Keys;
e) Clause 5: Point Encoding for the Integrated Mapping.

C.2 .4 Clause 1 .3 : PACE

The second and the third paragraphs are replaced by:

“This Annex specifies PACE as an optional access control mechanism. IAs MAY implement PACE instead o f
BAP. The IS MUST implement and use PACE i f access to the data o f the SIC on the IDL is protected by PACE.”
PACE is a supplemental authentication protocol that may be combined with EACv1. An IDL that supports
PACE may also support BAP configuration 1.
C.2 .5 Clause 2 .1 : General outline

Replace the second paragraph, starting with “PACE uses keys...” and ending with “... front side of the
datapage.” with:
“The input string must be used to derive Kπ (see C.2.5).”.
Get more FREE standards from Standard Sharing Group and our chats
C.2 .6 Clause 2 .2 : Inspection procedure

Replace the following:

“a MRTD with OPTIONAL Supplemental Access Control” by “an IDL supporting PACE”.
“DOC 9303” by “ISO/IEC 18013-3”.
The last sentence of the third paragraph starting with “If the MRTD chip supports both PACE and Basic
Access Control …” is deleted.
In the step2 . PACE (CONDI TIONAL) o f the opening procedure, the first sentence is replaced by “This
step is REQUIRED, i f PACE is supported by the IDL chip.”.
C.2 .7 Clause 2 .3 .2 : Protocol specification

In step 3. a) delete: “For the integrated mapping the inspection system sends an additional nonce to the
MRTD chip.”

C.2 .8 Clause 3 .1 .2 : PACEIn fo

Replace the PACEIn fo data structure by:

PACEI nfo : : = SEQUENCE {
protocol OBJECT I DENTI FI ER(
id-PACE-ECDH-GM-3DES-CBC-CBC |
id-PACE-ECDH-GM-AES-CBC-CMAC-1 2 8 |
id-PACE-ECDH-GM-AES-CBC-CMAC-1 92 |
id-PACE-ECDH-GM-AES-CBC-CMAC-2 56) ,
vers ion I NTEGER, -- MUST be 2
parameterI d I NTEGER OPTI ONAL
}

68
I n tern ati o n al Org an i z ati o n fo r S tan d ard i z ati o n
© ISO/IEC 2017 – All rights reserved
 ISO/IEC 1 801 3 -3 : 2 0 1 7(E)

C.2 .9 Clause 3 .1 .3 : PACEDomainParameterIn fo

In the first bullet point replace “(i.e. DH or ECDH)” with “(i.e. ECDH)”.
Replace the PACEDomainParameterI nfo data structure by:
PACEDomainParameterI nfo : : = SEQUENCE {
protocol OBJECT I DENTI FI ER(
id-PACE-ECDH-GM) ,
domainParameter AlgorithmI dentifer,
parameterI d I NTEGER OPTI ONAL
}

Replace

“The object identifier algorithm SHALL be dhpublicnumber or ecPublicKey for DH or ECDH,

respectively.”
with

“The object identifier algorithm SHALL be ecPublicKey for ECDH.”

Delete
" dhpublicnumber OBJECT I DENTI FI ER : : = {
is o( 1 ) member-body( 2 ) us ( 8 4 0 ) ans i-x94 2 ( 1 0 0 4 6) number-type( 2 ) 1
}"
Replace

“Details on the parameters can be found in Reference [5] and Reference [10] .”

with

“Details on the parameters can be found in Reference [10] .”

C.2 .1 0 Clause 3 .1 .4: PACE Obj ect Identifier

Replace the content of this subclause with the following:

The following Object Identifier SHALL be used:

id-PACE OBJECT I DENTI FI ER : : = {
bs i-de protocols ( 2 ) s martcard( 2 ) 4
}
id-PACE-ECDH-GM OBJECT I DENTI FI ER : : = { id-PACE
2}
id-PACE-ECDH-GM-3DES-CBC-CBC OBJECT I DENTI FI ER : : = { id-PACE-ECDH-GM 1 }
id-PACE-ECDH-GM-AES-CBC-CMAC-1 2 8 OBJECT I DENTI FI ER : : = { id-PACE-ECDH-GM 2 }
id-PACE-ECDH-GM-AES-CBC-CMAC-1 92 OBJECT I DENTI FI ER : : = { id-PACE-ECDH-GM 3}
id-PACE-ECDH-GM-AES-CBC-CMAC-2 56 OBJECT I DENTI FI ER : : = { id-PACE-ECDH-GM 4 }

C.2 .1 1 Clause 3 .3 .2 : Mapping Data

Delete the following:

“Integrated Mapping

The nonce t SH ALL be encoded as octet string.

Note: The context specific data object 0x82 SHALL be empty.”

I n tern ati o n al Org an i z ati o n

© ISO/IEC 2017 – All rights reserved
fo r S tan d ard i z ati o n
69
 ISO/IEC 1 80 1 3 -3 : 2 01 7(E)

Replace
“The ephemeral public keys (c f. Section 4.3 and Section 4.5.3) SHALL be encoded as elliptic curve point
(ECDH) or unsigned integer (DH).”
by
“The ephemeral public keys (c f. Section 4.3 and Section 4.5.3) SHALL be encoded as elliptic curve point
(ECDH).”

C.2 .1 2 Clause 4.1 : Key Agreement Algorithm

In the first sentence delete “Di ffie-Hellman and”.

In Table 2 delete the DH column.

C.2 .1 3 Clause 4.1 .2 : ECDH

In Table 4 delete the last 4 rows.

C.2 .1 4 Clause 4.1 .3 : Standardized Domain Parameters

A fter the first sentence include the following:

“The standardized domain parameters identified by the ID 0, 1, and 2 shall not be used for the IDL.”
C.2 .1 5 Clause 4.2 : Key Derivation Function

Replace the sentence preceding Table 5, starting with “The encoding of ...”
Get more FREE standards from Standard Sharing Group and our chats
with
“For the encoding o f passwords, f (π) = input string.”
Delete Table 5.
In Table 6:
delete the asterisk “*” after the name “NIST P-224 (secp224r1)”, and
delete “* This curve cannot be used with the integrated mapping.” under the table.

C.2 .1 6 Clause 4.3 : Encrypting and Mapping Nonces

Replace
“To map the nonce s or the nonces s,t into the cryptographic group either the generic mapping or the
integrated mapping, respectively, SHALL be used.”
by
“To map the nonce s into the cryptographic group the generic mapping SHALL be used.”
Delete “The nonce t∈ R {0…2 k−1} required in the Integrated Mapping SHALL be sent in clear.”
C.2 .1 7 Clause 4.3 .1 : ECDH Mapping

Delete the paragraph with the heading “Integrated Mapping”.

Delete Figure 4.1.

70
I n tern ati o n al Org an i z ati o n fo r S tan d ard i z ati o n
© ISO/IEC 2017 – All rights reserved
 ISO/IEC 1 801 3 -3 : 2 0 1 7(E)

C.2 .1 8 Clause 4.5 .3 : Ephemeral Public Keys

D ele te “the publ ic va lue y for D i ffie -H el l ma n publ ic keys and”.

I n tern ati o n al Org an i z ati o n

© ISO/IEC 201 7 – All rights reserved
fo r S tan d ard i z ati o n
71
 ISO/IEC 1 80 1 3 -3 : 2 01 7(E)

Annex D
(normative)

Extended Access Control v1

D.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 o f EACv1 requires a BAP configuration 1 or PACE configuration for the IDL.
A fter EACv1 Chip Authentication, AES and 3DES shall be applied in Secure Messaging as specified in
TR-PACE.
NOTE 1 The Secure Messaging syntax is specified in B.6.
NOTE 2 Padding is always per formed by the secure messaging layer, so that the underlying message
authentication code need not per form any internal padding.

D.2 Changes to TR-0 3 1 1 0 -1 v2 .1 0

Get more FREE standards from Standard Sharing Group and our chats
D.2 .1 Overview

This subclause defines the changes that apply to TR-03110-1 v2.10 to support the IDL.
D.2 .2 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.

72
I n tern ati o n al Org an i z ati o n fo r S tan d ard i z ati o n
© ISO/IEC 2017 – All rights reserved
 ISO/IEC 1 801 3 -3 : 2 0 1 7(E)

For PICC, read SIC.

D.2 .3 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)

D.2 .4 Clause 2 .1 : Driving Licence Application

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

D.2 .5 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 o f the D riving Licence Application

Read/ M andator y/ Acces s Control

DG Content
Write O ptional a BAP or PAC E E AC v1

DG1 Text data elements R m m x

DG2 Licence Holder details R o m x
DG3 Issuing Authority details R o m x
DG4 Portrait Image of licence holder R o m x
DG5 Signature R o m r
DG6 Facial biometric template R o m o
DG7 Finger biometric template R o m r
DG8 Iris biometric template R o m r
DG9 Other biometric template R o m o
DG10 Reserved for future use R o m o
DG11 Domestic application data R o m o
DG12 Non-Match Alert R o m x
DG13 Active Authentication R o m x
DG14 Extended Access Control v1 b R o m x
SOD Security Object R m m x
a As defined in ISO/IEC 18013-2 and ISO/IEC 18013-3.
b Although named Extended Access Control, the content in this annex is defined as EACv1 in 10.4.

D.2 .6 Clause 2 .4: Inspection Procedures

For the entire clause, read:

I n tern ati o n al Org an i z ati o n

© ISO/IEC 2017 – All rights reserved
fo r S tan d ard i z ati o n
73
 ISO/IEC 1 80 1 3 -3 : 2 01 7(E)

The Standard Inspection Procedure is not applicable to the IDL and only one inspection procedure is
supported, namely the Advanced Inspection Procedure.
D.2 .7 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 .

D.3 Changes to TR-0 3 1 1 0 -3 v2 .1 0

D.3 .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.
D.3 .2 General

For BAC, read BAP.

For DG2, read DG6.
For DG3, read DG7.
For DG4, read DG8.
Get more FREE standards from Standard Sharing Group and our chats
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.

D.3 .3 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”).
D.3 .4 Clause C.4.1 : Inspection Systems

Success ful 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:

74
I n tern ati o n al Org an i z ati o n fo r S tan d ard i z ati o n
© ISO/IEC 2017 – All rights reserved
 ISO/IEC 1 801 3 -3 : 2 0 1 7(E)

Table 2 0 — Authorisation o f I nspection Systems

7 6 5 4 3 2 1 0 D escription

x x Role

1 1 CVC A
1 0 DV (o fficial domestic)
0 1 DV (o fficial foreign)
0 0 Inspection System
- - x x x x x x Acces s Rights

- - x x x x - - RFU
- - - - - - 1 - Read access to Driving Licence Application: DG8 (Iris)
- - - - - - - 1 Read access to Driving Licence Application: DG7 (Finger)

D.4 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 o f type param-EAC (same definition as the
TerminalAuthenticationI nfo in clause A.1.1.3 of TR-03110-3).
param-EAC : : = SEQUENCE {
protocol id-TA,
vers ion I NTEGER, -- MUST be 1
efCVCA FileI D OPTI ONAL
}

id-TA OBJECT I DENTI FI ER : : = {

bs i-de protocols ( 2 ) s martcard( 2 ) 2
}

FileI D : : = SEQUENCE {
fd OCTET STRING ( SIZE( 2 ) ) ,
sfd OCTET STRING ( SIZE( 1) ) OPTIONAL
}
The set o f data groups shall only contain data groups as specified in D.2 .4. Other data groups cannot be
protected with EACv1.

When the structure TerminalAuthenticationI nfo is present in DG14 as specified in TR-03110-3,

it shall contain the same data as param-EAC .

NOTE Unless specified in e fCVCA (in param-EAC or TerminalAuthenticationI nfo ) , the EFID/SFI of
the EF.C VC A is the one indicated in TR 03110.

I n tern ati o n al Org an i z ati o n

© ISO/IEC 2017 – All rights reserved
fo r S tan d ard i z ati o n
75
 ISO/IEC 1 80 1 3 -3 : 2 01 7(E)

Annex E
(normative)

SIC command set

E.1 Class byte

The value for CLA shall be ’0X’ in this document to confirm that:
— 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 — C lass byte

b8 b7 b6 b5 b4 b3 b2 b1 Meaning

0 0 0 X — — — — Command chaining control

0 0 0 0 — — — — The command is the last or only command o f a chain
0 0 0 1 — — — — The command is not the last command of a chain
0 0 0 — X X — — Secure messaging indication
0 0 0 Get—more 0FREE0standards
— — Standard
from No secureSharing
messaging or no and
Group indication
our chats
Secure messaging with command header authenticat-
0 0 0 — 1 1 — —
ed
0 0 0 — — — X X Logical channel number from zero to three

E.2 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).

76
I n tern ati o n al Org an i z ati o n fo r S tan d ard i z ati o n
© ISO/IEC 2017 – All rights reserved
 ISO/IEC 1 801 3 -3 : 2 0 1 7(E)

T he de tai l s o f the com mand s s p e ci fie d i n th i s do c u ment a re s hown i n Table E.2 . For reference purposes,
the com mand s s p e ci fie d i n I S O/I E C 1 8 01 3 -2 are provide d as wel l .

Table E . 2 — Command details

C ase number
Command name CLA I NS M/O Re ference
1 2 3 4
SELECT A4 X M ISO/IEC 18013-2
READ BINARY B0/B1 X X M ISO/IEC 18013-2
GENERAL AUTHENTICATE 86 X O Annex C, Annex D
GET CHALLENGE 84 X O B.9.1 , Annex D
INTERNAL AUTHENTICATE 88 X O 8.2.4.1
EXTERNAL AUTHENTICATE 0X 82 X O Annex D
MUTUAL AUTHENTICATE 82 X O B.9.2
PERFORM SECURITY OPERATION
2A X O Annex D
(VERIFY CERTIFICATE)
MANAGE SECURITY ENVIRONMENT
22 X O Annex C, Annex D
(SET AT)
MANAGE SECURITY ENVIRONMENT
22 X O Annex D
(SET DST)
MANAGE SECURITY ENVIRONMENT
22 X O Annex D
(SET KAT)

I n tern ati o n al Org an i z ati o n

© ISO/IEC 2017 – All rights reserved
fo r S tan d ard i z ati o n
77
 ISO/IEC 1 80 1 3 -3 : 2 01 7(E)

Annex F
(normative)

List o f tags used

‘06’ Object identifier

‘42’ Authority key identifier
‘53’ Authorization
‘5F20’ Subject key identifier
‘5F24’ Certificate expiration date
‘5F25’ Certificate e ffective date
‘5F29’ Certificate format version
‘5F37’ Signature
‘6E’ EF.DG14 – EACv1
‘6F’ EF.DG13 – Active authentication
‘71’ EF.DG12
Get –more
Non-match
FREE alert
standards from Standard Sharing Group and our chats

‘77’ EF.SOD – Document security object

‘7F49’ Public key details
‘7F4C’ Certificate holder authorization
‘7F4E’ Certificate body
‘81’ Composite modulus n
‘81’ Prime modulus p
‘81’ SAI_inputmethod
‘82’ First coe fficient a
‘82’ Public exponent e
‘82’ SAI_referencestring
‘83’ Second coe fficient b
‘83’ Re ference data object containing a re ference to the trust root
‘84’ Base point G
‘85’ Order of base point r

78
I n tern ati o n al Org an i z ati o n fo r S tan d ard i z ati o n
© ISO/IEC 2017 – All rights reserved
 ISO/IEC 1 801 3 -3 : 2 01 7(E)

‘86’ Public point Y

‘86’ Security mechanism indicator

‘87’ Co-factor f

I n tern ati o n al Org an i z ati o n

© ISO/IEC 2017 – All rights reserved
fo r S tan d ard i z ati o n
79
 ISO/IEC 1 80 1 3 -3 : 2 01 7(E)

Bibliography

[1] ISO/IEC 2382, Information technology — Vocabulary

[2] ISO/IEC 7501-1, Identification cards — Machine readable travel documents — Part 1: Machine
readable passport
[3] ISO/IEC 8825-1, Information technology — ASN.1 encoding rules: Specification of Basic Encoding
Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)
[4] A dams C., & L loyd S. Understanding PKI. Addison-Wesley, 2003
[5] BSI Technical Guideline TR-03111: Elliptic Curve Cryptography — Version 2.0 – 2012-06-28.
[6] F erguson N., & S chneier B. Practical Cryptography. Wiley, 2003
[7] G utm ann P. Everything you never wanted to know about PKI but have been forced to find out,
available at http://www.cs .auckland .ac .nz/~pgut001/pubs/pkitutor ial .pdf
[8] G utm ann P. X.509 Style Guide , October 2000, available at http://www.cs .auckland .ac .nz/
~pgut001/pubs/x509guide .txt
[9] D oc ICAO 9303-1, Machine Readable Travel Documents, Part 1: Machine Readable Passports, Volume
2: Specifications for Electronically Enabled Passports with Biometric Identification Capability
[10] International Civil Aviation Organization, Development of a Logical Data Structure – LDS for
Optional Capacity Expansion Technologies, Revision 1.7, Technical Report, 2004
[11] O fficial Journal o f the FREE
Get more European Union, from
standards COMMISSION
StandardREGULATION
Sharing Group(EU)
andNoour
383/2012
chats o f 4 May
2012 — Technical requirements with regard to driving licences which include a storage medium
[12] RFC 3447, J. Jonsson, B. Kaliski, Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography
Specifications Version 2.1, February 2003 5)

5) http://www.ietf.org/rfc/rfc3447 .txt

80
I n tern ati o n al Org an i z ati o n fo r S tan d ard i z ati o n
© ISO/IEC 2017 – All rights reserved
I n tern ati o n al Org an i z ati o n fo r S tan d ard i z ati o n
 ISO/IEC 1 801 3 -3 : 2 01 7(E)

Get more FREE standards from Standard Sharing Group and our chats

ICS 3 5 .2 40.1 5
Price based on 8 0 pages

© ISO/IEC 2017 – All rights reserved

I n tern ati o n al Org an i z ati o n fo r S tan d ard i z ati o n