ISO/IEC 18013-3:2009

INTERNATIONAL ISO/IEC
STANDARD 18013-3
First edition
2009-03-01
Information technology — Personal
identification — ISO-compliant driving
licence
Part 3:
Access control, authentication and
integrity validation
Technologies de l'information — Identification des personnes — Permis
de conduire conforme à l'ISO
Partie 3: Contrôle d'accès, authentification et validation d'intégrité

Reference number
©
ISO/IEC 2009
PDF disclaimer
This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but
shall not be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In
downloading this file, parties accept therein the responsibility of not infringing Adobe's licensing policy. The ISO Central Secretariat
accepts no liability in this area.
Adobe is a trademark of Adobe Systems Incorporated.
Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation
parameters were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In
the unlikely event that a problem relating to it is found, please inform the Central Secretariat at the address given below.

©  ISO/IEC 2009
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means,
electronic or mechanical, including photocopying and microfilm, without permission in writing from either ISO at the address below or
ISO's member body in the country of the requester.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail copyright@iso.org
Web www.iso.org
Published in Switzerland
ii © ISO/IEC 2009 – All rights reserved

Contents Page
Foreword. iv
Introduction . v
1 Scope . 1
2 Conformance. 1
3 Normative references . 1
4 Terms and definitions. 3
5 Abbreviated terms . 6
6 Functional requirements. 7
6.1 Access control . 7
6.2 Document authentication. 7
6.3 Data integrity validation . 7
7 Mapping of mechanisms to requirements and technologies. 10
8 Mechanisms . 13
8.1 Passive authentication. 13
8.2 Active authentication. 18
8.3 Scanning area identifier . 19
8.4 Non-match alert. 25
8.5 Basic access protection. 28
8.6 Extended access protection . 30
9 Security mechanism indicator. 31
10 SIC LDS. 31
10.1 EF.SOD – Document security object (short EF identifier = ‘1D’, Tag = '77'). 33
10.2 EF.DG12 Non-match alert (short EF identifier= '0C', Tag = ‘71’). 33
10.3 EF.DG13 Active authentication (short EF identifier = '0D', Tag = ‘6F’). 33
10.4 EF.DG14 Extended access protection (short EF identifier = '0E', Tag = ‘6E’) . 33
Annex A (informative) Public key infrastructure (PKI) . 34
Annex B (normative) Basic access protection. 43
Annex C (normative) Extended access protection . 82
Annex D (normative) SIC command set. 106
Annex E (normative) List of tags used. 108
Annex F (normative) Brainpool curves. 109
Bibliography . 117

© ISO/IEC 2009 – All rights reserved iii

Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that are members of
ISO or IEC participate in the development of International Standards through technical committees
established by the respective organization to deal with particular fields of technical activity. ISO and IEC
technical committees collaborate in fields of mutual interest. Other international organizations, governmental
and non-governmental, in liaison with ISO and IEC, also take part in the work. In the field of information
technology, ISO and IEC have established a joint technical committee, ISO/IEC JTC 1.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of the joint technical committee is to prepare International Standards. Draft International
Standards adopted by the joint technical committee are circulated to national bodies for voting. Publication as
an International Standard requires approval by at least 75 % of the national bodies casting a vote.
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights. ISO and IEC shall not be held responsible for identifying any or all such patent rights.
ISO/IEC 18013-3 was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology,
Subcommittee SC 17, Cards and personal identification.
ISO/IEC 18013 consists of the following parts, under the general title Information technology — Personal
identification — ISO-compliant driving licence:
⎯ Part 1: Physical characteristics and basic data set. Part 1 defines the basic terms for ISO/IEC 18013,
including physical characteristics, basic data element set, visual layout, and physical security features.
⎯ Part 2: Machine-readable technologies. Part 2 defines the technologies that may be used for
ISO/IEC 18013, including the logical data structure and data mapping for each technology.
⎯ Part 3: Access control, authentication and integrity validation. Part 3 defines the electronic security
features that may be incorporated under ISO/IEC 18013, including mechanisms for controlling access to
data, verifying the origin of an ISO-compliant driving licence, and confirming data integrity.

iv © ISO/IEC 2009 – All rights reserved

Introduction
This part of ISO/IEC 18013 prescribes requirements for the implementation of mechanisms to control access
to data recorded in the machine-readable technology on an ISO-compliant driving licence (IDL), verifying the
origin of an IDL, and confirming data integrity.
One of the functions of an IDL is to facilitate international interchange. Whilst storing data in machine-readable
form on the IDL supports this function by speeding up data input and eliminating transcription errors, certain
machine-readable technologies are vulnerable to being read without the knowledge of the card holder and to
other means of unauthorized access by unintended persons, that is other than driving licence or law
enforcement authorities. Controlling access to IDL data stored in machine-readable form protects the data on
the card from being read remotely by electronic means without the knowledge of the card holder.
Identifying falsified driving licences, or an alteration to the human-readable data on authentic driving licences
present a major problem for driving licence and law enforcement authorities, both domestically and in the
context of international interchange. Verifying the authenticity of an IDL and confirming the integrity of the data
recorded on an IDL provide driving licence and law enforcement authorities with a means to identify an
authentic IDL from a falsified or altered one in the interests of traffic law enforcement and other traffic safety
processes.
© ISO/IEC 2009 – All rights reserved v

INTERNATIONAL STANDARD ISO/IEC 18013-3:2009(E)

Information 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 of their specific needs.
This part of ISO/IEC 18013
a) is based on the machine-readable data content specified in ISO/IEC 18013-2;
b) specifies mechanisms and rules available to issuing authorities (IAs) for
1) access control (i.e. limiting access to the machine-readable data recorded on the IDL),
2) document authentication (i.e. confirming that the document was issued by the claimed IA),
3) data integrity validation (i.e. confirming that the data has not been changed since issuing).
This part of ISO/IEC 18013 does not address issues related to the subsequent use of data obtained from the
IDL, e.g. privacy issues.
2 Conformance
A driving licence is in conformance with this part of ISO/IEC 18013 if it meets all mandatory requirements
specified directly or by reference herein. Compliance with ISO/IEC 18013-2 is required for compliance with
this part of ISO/IEC 18013.
Compliance with ISO/IEC 18013-1 is not required for compliance with this part of ISO/IEC 18013. Conversely,
the incorporation of a machine-readable technology which is not compliant with this part of ISO/IEC 18013
does not render the IDL non-compliant with ISO/IEC 18013-1.
3 Normative references
The following referenced documents are indispensable for the application of this document. For dated
references, only the edition cited applies. For undated references, the latest edition of the referenced
document (including any amendments) applies.
ISO 1831:1980, Printing specifications for optical character recognition
© ISO/IEC 2009 – All rights reserved 1

ISO/IEC 7816-4:2005, Identification cards — Integrated circuit cards — Part 4: Organization, security and
commands for interchange
ISO/IEC 7816-8:2004, Identification cards — Integrated circuit cards — Part 8: Commands for security
operations
ISO/IEC 8825-1:2002, Information technology — ASN.1 encoding rules: Specification of Basic Encoding
Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)
ISO/IEC 8859-1:1998, Information technology — 8-bit single-byte coded graphic character sets — Part 1:
Latin alphabet No. 1
ISO/IEC 9797-1:1999, 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
ISO/IEC 11770-2:1996, Information technology — Security techniques — Key management — Part 2:
Mechanisms using symmetric techniques
ISO/IEC 11770-2:1996/Cor.1:2005, Information technology — Security techniques — Key management —
Part 2: Mechanisms using symmetric techniques — Corrigendum 1
ISO/IEC 11770-3, Information technology — Security techniques — Key management — Part 3: Mechanisms
using asymmetric techniques
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, Information technology — Security techniques — Encryption algorithms — Part 3:
Block ciphers
ISO/IEC 18033-3:2005/Cor.1:2006, Information technology — Security techniques — Encryption algorithms —
Part 3: Block ciphers — Corrigendum 1
ISO/IEC 18033-3:2005/Cor.2:2007, Information technology — Security techniques — Encryption algorithms —
Part 3: Block ciphers — Corrigendum 2
ANSI X9.62:2005, Public Key Cryptography For The Financial Services Industry: The Elliptic Curve Digital
Signature Algorithm (ECDSA)
FIPS 186-2 (including Change Notice), Digital Signature Standard (DSS), Federal Information Processing
Standards Publication, National Institute of Standards and Technology, 27 January 2000
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, http://www.ietf.org/rfc.html
RFC 3279, W. Polk et al., Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate
and Certificate Revocation List (CRL) Profile, April 2002, http://www.ietf.org/rfc.html
RFC 3280, R. Housley et al., Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation
List (CRL) Profile, April 2002, http://www.ietf.org/rfc.html
RFC 3369, R. Hously, Cryptographic Message Syntax, August 2002, http://www.ietf.org/rfc.html
2 © ISO/IEC 2009 – All rights reserved

RFC 4055, J. Schaad, B. Kaliski, R. Housley, Additional Algorithms and Identifiers for RSA Cryptography for
use in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile,
June 2005, http://www.ietf.org/rfc.html
4 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO/IEC 18013-1, ISO/IEC 18013-2 and
the following apply.
4.1
active authentication
mechanism that uses information stored in a secure area of a secure integrated circuit (SIC) to confirm that
the SIC and the other machine-readable data were issued together
NOTE See 8.2.
4.2
basic access protection
BAP
mechanism to confirm that an inspection system (IS) has physical access to a proximity integrated circuit card
(PICC) before the IS is allowed access to the data stored on the PICC and to ensure that communication
between the IS and the PICC (once access is authorized) is protected
NOTE See 8.5 and Annex B.
4.3
chip authentication
ephemeral-static key agreement protocol that provides authentication of the secure integrated circuit and
strong secure messaging
NOTE See 8.6 and C.3.
4.4
clone
unauthorized exact copy of a document that has the same security characteristics as the original document
and that cannot be distinguished from the legitimate one
4.5
eavesdropping
unauthorized interception and interpretation of information-bearing emanations
NOTE Adapted from ISO/IEC 2382-8:1998, 08.05.25.
4.6
extended access protection
EAP
protocol for limiting access to select optional data groups to reading authorities
NOTE See 8.6.
4.7
input string
string of characters printed on an ISO-compliant driving licence [as human-readable text, optionally (or by
specification) accompanied by or consisting of a machine-readable rendering thereof] used as input (either
manually or automatically through the use of suitable equipment) for the non-match alert and basic access
protection mechanisms
© ISO/IEC 2009 – All rights reserved 3

4.8
issuing authority
IA
licensing authority, or issuing country if separate licensing authorities have not been authorized, which applies
a digital signature to an ISO-compliant driving licence and is responsible for the associated key management
NOTE Adapted from ISO/IEC 18013-1.
4.9
non-match alert
mechanism to detect any differences between the machine-readable information and (some of) the human-
readable information on an ISO-compliant driving licence
NOTE See 8.4.
4.10
passive authentication
mechanism to confirm that machine-readable data on an ISO-compliant driving licence (IDL) has not been
changed since the IDL was issued
NOTE See 8.1.
4.11
pseudo issuing authority
PIA
authority that does not issue ISO-compliant driving licences [but that is similar to an issuing authority (IA) in all
other respects] and which does not issue document keys, but which does have a root key pair with which it
can sign documents of other IAs or PIAs that it trusts
4.12
public key infrastructure
PKI
technologies and products using public key (asymmetric) cryptography
NOTE Both passive authentication and extended access protection use this technology.
4.13
reading authority
RA
authorized entity reading the machine-readable data on an ISO-compliant driving licence (IDL)
NOTE Driving licence authorities other than the authority that issued the IDL and law enforcement authorities are
examples of reading authorities.
4.14
reference string
string of characters used as a reference against which to compare the input string when using the non-match
alert mechanism, and used for session key calculation purposes by the secure integrated circuit during
execution of the basic access protection mechanism
4.15
scanning area identifier
SAI
one or more graphical elements that demarcate an input string
4.16
secure integrated circuit
SIC
integrated circuit that includes both a security feature (or security features), and memory and/or a central
processing unit
4 © ISO/IEC 2009 – All rights reserved

NOTE 1 An integrated circuit card with contacts and a proximity integrated circuit card (PICC) are examples of a SIC.
NOTE 2 A SIC can be embedded in different solutions, for example in ID-1 sized cards (as used for the ISO-compliant
driving licence) and in a booklet (as found in passports).
4.17
secure memory
integrated circuit (IC) memory of which the content (once populated by an issuing authority 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
4.18
skimming
reading data from a proximity integrated circuit card (PICC) without the card holder's awareness
4.19
trust chain
sequential set of trust points that a verifying authority references to verify a specific issuing authority's public
root key
4.20
trust model
description of the functional and logical aspects of a traditional public key infrastructure, specifically excluding
technical implementation details
4.21
trust network
component of a trust model that describes the trust relationships and chains between issuing authorities
4.22
trust point
issuing authority or pseudo issuing authority that publishes a trust list (and the related public root keys) that
verifying entities can reference
4.23
twinning
copying the data and/or integrated circuit of a physically and/or biometrically similar driver to the attacker’s
integrated circuit or ISO-compliant driving licence
4.24
unpacked BCD
binary coding of a sequence of integers using 4 bits for each integer (where the bit weights are 8421) and
encoding one integer in the least significant bits of each byte
NOTE Only unsigned BCD is used in this part of ISO/IEC 18013.
4.25
verifying authority
VA
verifying entity that is part of a trust network, i.e. that also is an issuing authority or a pseudo issuing authority
NOTE 1 Not all verifying entities are VAs: A car rental company can be a verifying entity, but is not a VA as it is not part
of the trust network.
NOTE 2 VAs can be divided into immediate VAs and non-immediate VAs.
4.25.1
immediate VA
VA that acquired the public root key of the issuing authority via out-of-band means
© ISO/IEC 2009 – All rights reserved 5

4.25.2
non-immediate VA
VA that acquired the public root key of the issuing authority from another VA
4.26
verifying entity
entity that tries to determine if a digital signature is valid (i.e. if the data to which a certificate has been applied
has not been changed, and if the signature was generated by the issuing authority the verifying entity expects)
5 Abbreviated terms
APDU application protocol data unit
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)
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:2005)
EAP extended access protection
EF elementary file
IA issuing authority
IC integrated circuit
ICC integrated circuit card
IDL ISO-compliant driving licence
IS inspection system
IV initialization vector
KAT control reference template for key agreement (see ISO/IEC 7816-4:2005)
LDS logical data structure
MAC message authentication code
MSE manage security environment (see ISO/IEC 7816-4:2005)
OCR optical character recognition
OID object identifier
PIA pseudo issuing authority
PIC proximity integrated circuit
6 © ISO/IEC 2009 – All rights reserved

PICC proximity integrated circuit card
PKI public key infrastructure
PSO perform security operation (see ISO/IEC 7816-4:2005)
RA reading authority
SAI scanning area identifier
SIC secure integrated circuit
SM secure messaging
SOD document security object
SSC send sequence counter
TRCA trust root certificate authority
UTC coordinated universal time
VA verifying authority
2D two-dimensional
6 Functional requirements
6.1 Access control
Access control can be broken down into the following functional requirements:
a) Prevent skimming of machine-readable data on a PICC by ensuring that physical access to the IDL is
acquired prior to reading.
b) Prevent unnoticed alteration of communication between a reader and a SIC.
c) Prevent eavesdropping between a reader and a SIC.
d) Selectively restrict access to specific optional machine-readable data groups for specific reading
authorities.
6.2 Document authentication
Document authentication can functionally be established by allowing for verification of the origin of an IDL.
6.3 Data integrity validation
Data integrity validation can be broken down into the following functional requirements:
a) Verify that the IDL (including the machine-readable data) is not a clone of another IDL. A cloning
attempt can schematically be illustrated as shown in Figure 1.

© ISO/IEC 2009 – All rights reserved 7

A
B
Legend
C
D
Physical IDL (before personalization)
Human-readable data
B
Data carrier
Machine-
D
readable
data
blank (no data)
blank
(no data)
Figure 1 — Data integrity validation: IDL cloning
b) Protect against the exchange of machine-readable data carriers between otherwise authentic IDLs .
This type of attack can schematically be illustrated as shown in Figure 2.
A
B
Legend
C
D Physical IDL (before personalization)
A
Human-readable data
B
Data carrier
Machine-
readable
data
Figure 2 — Data integrity validation: Data carrier exchange or twinning

This guards (amongst others) against an IC "twinning" attack. This type of attack is of particular concern in inspection environments
where machine-readable data and human-readable data is not compared (or only cursorily compared by an operator using e.g. a portrait
image). Finding a biometrically similar driver is possible by skimming the data of a few thousand IDL PICs.
8 © ISO/IEC 2009 – All rights reserved

c) Verify that the physical IDL and the machine-readable data thereon were issued (belong) together.
This type of attack can schematically be illustrated as shown in Figure 3.
A
B
Legend
C
D
Physical IDL (before personalization)
A
Human-readable data
B
Data carrier
C
Machine-
readable
data
Figure 3 — Data integrity validation: Machine-readable data exchange
d) Validate the integrity of the human readable data (i.e. confirm that the human-readable data has not
changed since issuing). This type of attack can schematically be illustrated as shown in Figure 4.
Legend
Physical IDL (before personalization)
A A
Human-readable data
B’
B
Data carrier
C
C
Machine-
D
D
readable
data
Figure 4 — Data integrity validation: Human-readable data alteration
© ISO/IEC 2009 – All rights reserved 9

e) Validate the integrity of the machine-readable data (i.e. confirm that the machine-readable data has
not changed since issuing). This can schematically be illustrated as shown in Figure 5.
Legend
Physical IDL (before personalization)
A A
Human-readable data
B B
Data carrier
C
C
Machine-
D D’
readable
data
Figure 5 — Data integrity validation: Machine-readable data alteration
7 Mapping of 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.
10 © ISO/IEC 2009 – All rights reserved

Table 1 — Applicable mechanisms
Mechanisms
Functional
2D bar code, optical
requirement
ICC with contacts PICC
memory, magnetic stripe
Prevent skimming Physical access to the IDL Physical access to the IDL is BAP
is required to read the required to read the machine-
machine-readable data readable data
Prevent unnoticed N/A Chip authentication (EAP) in BAP
alteration of combination with BAP secure
Chip authentication (EAP) in
communication messaging
combination with BAP secure
between a reader and
messaging
an IDL
a
Prevent N/A Chip authentication (EAP) in
BAP
eavesdropping combination with BAP secure
Chip authentication (EAP) in
messaging
combination with BAP secure
messaging
Selectively restrict N/A Terminal authentication (EAP) Terminal authentication (EAP)
access to specific
optional machine-
readable data groups
for specific reading
authorities
Allow for verification Step 1: Verify Step 1: Verify trustworthiness of / Step 1: Verify trustworthiness of /
of the origin of an IDL trustworthiness of / obtain a obtain a trustworthy obtain a trustworthy
trustworthy asymmetric/public key (via a PKI asymmetric/public key (via a PKI
asymmetric/public key (via and a protected distribution and a protected distribution
a PKI and a protected communication channel, or via communication channel, or via
distribution communication alternative trust building alternative trust building
channel, or via alternative methods) methods)
trust building methods)
Step 2: Use trusted key to Step 2: Use trusted key to
Step 2: Use trusted key to perform passive authentication; if perform passive authentication; if
perform passive the passive authentication was the passive authentication was
authentication, followed by preceded by BAP the IDL is preceded by BAP the IDL is
use of the non-match alert authentic, if BAP is not authentic, if BAP is not
mechanism, or followed by implemented passive implemented passive
visual comparison of the authentication can be followed authentication can be followed
human-readable data by use of the non-match alert by use of the non-match alert
printed on the document mechanism, or followed by visual mechanism, or followed by visual
with the authenticated comparison of the human- comparison of the human-
machine-readable data readable data printed on the readable data printed on the
document with the authenticated document with the authenticated
machine-readable data machine-readable data
Verify that the IDL 2D bar code and magnetic Active authentication via Active authentication via

(including the stripe: Cannot be verified challenge response challenge response
machine-readable through available
Chip authentication (EAP) Chip authentication (EAP)
data) is not a clone of international standards
another IDL
Optical memory: Include
unique card serial number
in data protected by
passive authentication
© ISO/IEC 2009 – All rights reserved 11

Mechanisms
Functional
2D bar code, optical
requirement
ICC with contacts PICC
memory, magnetic stripe
Protect against the Non-match alert Non-match alert Non-match alert
exchange of machine
Passive authentication BAP BAP
readable data carriers
followed by a visual
between otherwise
Passive authentication followed Passive authentication followed
comparison of the human-
authentic IDLs
by a visual comparison of the by a visual comparison of the
readable data printed on
human-readable data printed on human-readable data printed on
the document with the
the document with the the document with the
authenticated machine-
authenticated machine-readable authenticated machine-readable
readable data
data data
Verify that the Non-match alert Non-match alert Non-match alert
physical IDL and the
Passive authentication BAP BAP
machine-readable
followed by a visual
data thereon were
Passive authentication followed Passive authentication followed
comparison of the human-
issued (belong)
by a visual comparison of the by a visual comparison of the
readable data printed on
together (i.e. that the
human-readable data printed on human-readable data printed on
the document with the
machine-readable
the document with the the document with the
authenticated machine-
data has not been
authenticated machine-readable authenticated machine-readable
readable data
copied from another
data data
IDL)
Active authentication via Active authentication via
a a
challenge response challenge response
Validate the integrity Non-match alert Non-match alert Non-match alert
of the human
Passive authentication BAP BAP
readable data (i.e.
followed by a visual
confirm that the
Passive authentication followed Passive authentication followed
comparison of the human-
human-readable data
by a visual comparison of the by a visual comparison of the
readable data printed on
has not changed
human-readable data printed on human-readable data printed on
the document with the
since issuing)
the document with the the document with the
authenticated machine-
authenticated machine-readable authenticated machine-readable
readable data
data data
Visual inspection of the
Visual inspection of the security Visual inspection of the security
security features
features incorporated into the features incorporated into the
incorporated into the IDL
IDL (see ISO/IEC 18013-1) IDL (see ISO/IEC 18013-1)
(see ISO/IEC 18013-1)
Validate the integrity Passive authentication Passive authentication Passive authentication
of the machine-
readable data (i.e.
confirm that the
machine-readable
data has not 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 part of ISO/IEC 18013; it is assumed that such comparison can be
implemented by any RA in a manner that meets local needs.

a
The entropy of the reference string used has to be commensurate with the IA's assessment of the threat.

IA's may selectively implement the mechanisms identified above, subject to any dependencies noted in
Clause 8.
12 © ISO/IEC 2009 – All rights reserved

8 Mechanisms
8.1 Passive authentication
8.1.1 Purpose
The purpose of 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 of a digital signature over specified machine-readable data on
the IDL, using a public-private (asymmetric) key pair.
In the case of standard encoding, a separate message digest is calculated for each data group, and included
in the machine-readable data. The collection of message digests is then digitally signed (using a private key
that is kept secret by the IA), and the digital signature is added to the machine-readable data.
In the case of compact encoding, no message digests are calculated separately. The contents of the data
groups present is directly signed (using a private key that is kept secret by the IA), and the digital signature is
added to the machine-readable data.
NOTE A message digest has the following properties:
a) It is very small in size compared to the IDL data.
b) The probability of finding any two (different) IDL data sets that lead to the same message digest is
negligible. This has the following implications:
i. The probability of finding an IDL data set A that produces the same message digest as a given IDL
data set B is negligible.
ii. The probability that a message digest (for the data on an IDL) remains the same upon a change in
the data is negligible.
When the IDL is presented to a RA, the RA uses the IA's public key to verify the digital signature. The RA also
computes the message digests of each of the data groups that it is interested in, and compares them to the
corresponding message digests stored in the machine-readable data. If:
a) the digital signature verifies,
b) the calculated message digests are the same as the message digests stored in the machine-readable
data, and
c) the RA is confident that the public key used to verify the digital signature belongs to the claimed IA,
the RA can consider the data groups that it is interested in to be authentic. If the digital signature does not
verify, either an incorrect public key was used, or the data on the IDL has been changed. Depending on the
digital signature method used, it may be possible to further narrow down the cause of the non-verification.
This part of ISO/IEC 18013 does not prescribe methods to obtain and/or to establish trust in public keys. It is
the responsibility of each RA to obtain and/or to establish trust in the public keys used to verify a digital
signature on an IDL. Informative methods and approaches to establish such trust are however provided in
© ISO/IEC 2009 – All rights reserved 13

Annex A, which describes the principles for a PKI that may be used for public key distribution in the absence
of one global certification authority.
This part of ISO/IEC 18013 does not prescribe methods for the generation, administration and safekeeping of
key pairs. It is the responsibility of each issuing jurisdiction to ensure that keys are generated, administered
and protected as necessary.
8.1.4 Hash function
8.1.4.1 Standard encoding
For standard encoding, IA's shall choose the SHA-1, SHA-224, SHA-256, SHA-384 or the SHA-512 hash
function.
NOTE 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.
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 of any digital signature
mechanism – see 8.1.5.3).
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 verify signatures according to RSASSA-PKCS1-v1_5. The minimum size
of the modulus, n, shall be 1024 bits.
IA's implementing ECDSA shall use ANSI X9.62. The elliptic curve domain parameters used to generate the
ECDSA key pair shall be described explicitly in the parameters of the public key, i.e. parameters shall be of
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 SOD is implemented as a SignedData Type, as specified in RFC 3369 (including processing
rules). The SOD shall be produced in DER format.
14 © ISO/IEC 2009 – All rights reserved

Table 2 — SignedData Type
a
Value Comments
Type
SignedData m
Version m
digestAlgorithms m
encapContentInfo m
eContentType m id-icao-ldsSecurityObject
eContent m The encoded contents of an ldsSecurityObject
certificates
o
Crls
x
signerInfos m
SignerInfo
m
version
m
Sid m
issuerandSerialNumber
c It is recommended that IA's support this field over subjectKeyIdentifier.
subjectKeyIdentifier
c
digestAlgorithm
m The algorithm identifier of the algorithm used to produce the hash value over
encapsulatedContent and SignedAttrs.
signedAttrs
m IA's may wish to include additional attributes for inclusion in the signature, however
these do not have to be processed by a RA except to verify the signature value.
signatureAlgorithm m The algorithm identifier of the algorithm used to produce the signature value and
any associated parameters.
signature
m The result of the signature generation process.
unsignedAttrs
o IA's may wish to use this field, but it is not recommended and reading authorities
may choose to ignore them.
a
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
LDSSecurityObject { joint-iso-itu-t(2) international-organizations(23) icao(136) mrtd(1)
security(1) ldsSecurityObject(1)}
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
-- Imports from RFC 3280 [PROFILE], Appendix A.1
AlgorithmIdentifier FROM
PKIX1Explicit88 { iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7)
id-mod(0) id-pkix1-explicit(18) }
-- Constants
ub-DataGroups INTEGER ::= 16
© ISO/IEC 2009 – All rights reserved 15

-- Object Identifiers
id-icao OBJECT IDENTIFIER ::= {2.23.136}
id-icao-mrtd OBJECT IDENTIFIER ::= {id-icao 1}
id-icao-mrtd-security OBJECT IDENTIFIER ::= {id-icao-mrtd 1}
id-icao-ldsSecurityObject OBJECT IDENTIFIER ::= {id-icao-mrtd-security 1}
-- LDS Security Object
LDSSecurityObjectVersion ::= INTEGER {V0(0)}
DigestAlgorithmIdentifier ::= AlgorithmIdentifier
LDSSecurityObject ::= SEQUENCE {
version LDSSecurityObjectVersion,
hashAlgorithm DigestAlgorithmIdentifier,
dataGroupHashValues SEQUENCE SIZE (2.ub-DataGroups) OF DataGroupHash }
DataGroupHash ::= SEQUENCE {
dataGroupNumber DataGroupNumber,
dataGroupHashValue OCTET STRING }
DataGroupNumber ::= INTEGER {
dataGroup1 (1),
dataGroup2 (2),
dataGroup3 (3),
dataGroup4 (4),
dataGroup5 (5),
dataGroup6 (6),
dataGroup7 (7),
dataGroup8 (8),
dataGroup9 (9),
dataGroup10 (10),
dataGroup11 (11),
dataGroup12 (12),
dataGroup13 (13),
dataGroup14 (14),
dataGroup15 (15),
dataGroup16 (16)}
END
NOTE 1 The field dataGroupHashValue contains the calculated hash over the complete contents of the Data Group
EF, specified by dataGroupNumber.
NOTE 2 Data Groups 15 and 16 may be defined in future.
8.1.5.2 Standard encoding for optical memory
The DER encoded SOD defined in 8.1.5.1 shall be stored as one data object in tag 15140.
In order to allow identification of clone attempts, IA's may optionally include the card serial number (found at
Track 4, Sector 14, in 43-byte sector format; see ISO/IEC 11694-4) in DG3 using tag 1500. With reference to
Table D.11 in ISO/IEC 18013-2, tag 1500 shall follow tag 1438 (Optional Data Discriminator) in sequence.
16 © ISO/IEC 2009 – All rights reserved

8.1.5.3 Compact encoding
An IDL digital signature is generated over the full data s
...