Technical Guideline TR-03110
Advanced Security Mechanisms for
Machine Readable Travel Documents –
Extended Access Control (EAC)
Version 1.11
History
Version Date Comment
1.00 2006-02-08 Initial public version.
1.01 2006-11-02 Minor corrections and clariﬁcations.
1.10 2007-09-04 Revised version.
1.11 2008-02-21 Minor corrections and clariﬁcations.
Bundesamt für Sicherheit in der Informationstechnik
Postfach 20 03 63, 53133 Bonn, Germany
Email: ExtendedAccessControl@bsi.bund.de
Internet: http://www.bsi.bund.de/fachthem/epass
© Bundesamt für Sicherheit in der Informationstechnik 2008
Technical Guideline - Extended Access Control
Contents
1 Introduction 8
1.1 Passive Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.2 Active Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.3 Access Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.4 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.5 Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2 Advanced Security Mechanisms 12
2.1 Inspection Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.1.1 Standard ePassport Inspection Procedure . . . . . . . . . . . . . . . . . . . . . 13
2.1.2 Advanced ePassport Inspection Procedure . . . . . . . . . . . . . . . . . . . . . 13
2.2 Public Key Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2.1 Country Verifying CA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2.2 Document Veriﬁers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2.3 Card Veriﬁable Certiﬁcates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2.3.1 Certiﬁcate Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.2.4 Certiﬁcate Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.2.4.1 General Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.2.4.2 Example Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3 Protocol Speciﬁcations 19
3.1 Cryptographic Algorithms and Notation . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.1.1 Key Agreement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.1.1.1 Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.1.1.2 Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.1.2 Signatures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.1.2.1 Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.1.2.2 Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.2 Chip Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.2.1 Protocol Speciﬁcation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.2.2 Security Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.3 Terminal Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.3.1 Protocol Speciﬁcation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.3.2 Security Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4 Security & Privacy 22
4.1 Chip Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.1.1 Summarized Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.1.2 Remaining Risks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.2 Terminal Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.2.1 Summarized Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.2.2 Remaining Risks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Federal Ofﬁce for Information Security iii
Technical Guideline - Extended Access Control
4.3 Challenge Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Appendices 25
A Key Management (Normative) 25
A.1 Information on Supported Security Protocols . . . . . . . . . . . . . . . . . . . . . . . 25
A.1.1 Supported Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
A.1.1.1 Chip Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
A.1.1.2 Terminal Authentication . . . . . . . . . . . . . . . . . . . . . . . . . 27
A.1.1.3 Other Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
A.2 Chip Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
A.2.1 Storage on the Chip . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
A.2.2 Chip Authentication with DH . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
A.2.3 Chip Authentication with ECDH . . . . . . . . . . . . . . . . . . . . . . . . . . 28
A.2.4 Ephemeral Public Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
A.3 Terminal Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
A.3.1 Public Key References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
A.3.2 Public Key Import . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
A.3.2.1 Permanent Import . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
A.3.2.2 Temporary Import . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
A.3.2.3 Imported Metadata . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
A.3.2.4 EF.CVCA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
A.3.3 Terminal Authentication with RSA . . . . . . . . . . . . . . . . . . . . . . . . . 31
A.3.3.1 Signature Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
A.3.3.2 Public Key Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
A.3.4 Terminal Authentication with ECDSA . . . . . . . . . . . . . . . . . . . . . . . 32
A.3.4.1 Signature Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
A.3.4.2 Public Key Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
A.4 CV Certiﬁcates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
A.4.1 Certiﬁcate Proﬁle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
A.4.1.1 Certiﬁcate Proﬁle Identiﬁer . . . . . . . . . . . . . . . . . . . . . . . 33
A.4.1.2 Certiﬁcation Authority Reference . . . . . . . . . . . . . . . . . . . . 33
A.4.1.3 Public Key . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
A.4.1.4 Certiﬁcate Holder Reference . . . . . . . . . . . . . . . . . . . . . . 33
A.4.1.5 Certiﬁcate Holder Authorization Template . . . . . . . . . . . . . . . 33
A.4.1.6 Certiﬁcate Effective/Expiration Date . . . . . . . . . . . . . . . . . . 34
A.4.1.7 Signature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
A.4.2 Certiﬁcate Requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
A.4.2.1 Certiﬁcate Proﬁle Identiﬁer . . . . . . . . . . . . . . . . . . . . . . . 34
A.4.2.2 Certiﬁcation Authority Reference . . . . . . . . . . . . . . . . . . . . 34
A.4.2.3 Public Key . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
A.4.2.4 Certiﬁcate Holder Reference . . . . . . . . . . . . . . . . . . . . . . 35
A.4.2.5 Signature(s) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
A.4.3 Certiﬁcate Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
A.4.3.1 Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
A.4.3.2 Usage Restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
A.5 Roles and Authorization Levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
A.5.1 Relative Authorization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
A.5.2 Effective Authorization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
A.5.3 Access Rights . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
iv Federal Ofﬁce for Information Security
Technical Guideline - Extended Access Control
B ISO 7816 Mapping (Normative) 38
B.1 Chip Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
B.1.1 MSE:Set KAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
B.2 Terminal Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
B.2.1 MSE:Set DST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
B.2.2 PSO: Verify Certiﬁcate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
B.2.3 MSE:Set AT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
B.2.4 Get Challenge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
B.2.5 External Authenticate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
B.3 Secure Messaging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
B.3.1 Send Sequence Counter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
B.3.2 Secure Messaging Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
B.4 Reading Data Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
B.5 Command Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
B.6 Extended Length . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
B.6.1 MRTD Chips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
B.6.2 Inspection Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
B.6.3 Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
C DER Encoding (Normative) 43
C.1 ASN.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
C.2 Data Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
C.2.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
C.2.2 Encoding of Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
C.2.2.1 Unsigned Integers . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
C.2.2.2 Elliptic Curve Points . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
C.2.2.3 Dates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
C.2.2.4 Character Strings . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
C.2.2.5 Octet Strings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
C.2.2.6 Object Identiﬁers . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
C.2.2.7 Sequences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
C.3 Public Key Data Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
C.3.1 RSA Public Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
C.3.2 ECDSA Public Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
C.3.3 Ephemeral DH Public Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
C.3.4 Ephemeral ECDH Public Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
D Worked Examples (Informative) 47
D.1 Data Group 14 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
D.1.1 ECDH-based Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
D.1.1.1 General Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
D.1.1.2 Encoding of the AlgorithmIdentiﬁer . . . . . . . . . . . . . . . . . . 48
D.1.1.3 Encoding of Elliptic Curve Points . . . . . . . . . . . . . . . . . . . . 48
D.1.1.4 Session Key Generation . . . . . . . . . . . . . . . . . . . . . . . . . 49
D.1.1.5 Hashed Ephemeral Public Key . . . . . . . . . . . . . . . . . . . . . 49
D.1.2 DH-based Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
D.1.2.1 General Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
D.1.2.2 Encoding of the AlgorithmIdentiﬁer . . . . . . . . . . . . . . . . . . 51
D.1.2.3 Encoding of the SubjectPublicKey . . . . . . . . . . . . . . . . . . . 51
D.1.2.4 Session Key Generation . . . . . . . . . . . . . . . . . . . . . . . . . 51
D.1.2.5 Hashed Ephemeral Public Key . . . . . . . . . . . . . . . . . . . . . 51
Federal Ofﬁce for Information Security v
Technical Guideline - Extended Access Control
D.2 Card Veriﬁable Certiﬁcates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
D.2.1 Example 1: CVCA Certiﬁcate with ECDSA . . . . . . . . . . . . . . . . . . . . 52
D.2.1.1 General Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
D.2.1.2 Public Key . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
D.2.1.3 Certiﬁcate Holder Authorization Template . . . . . . . . . . . . . . . 53
D.2.1.4 ECDSA Plain Signature . . . . . . . . . . . . . . . . . . . . . . . . . 53
D.2.2 Example 2: CVCA Certiﬁcate with RSA . . . . . . . . . . . . . . . . . . . . . 53
D.2.2.1 General Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
D.2.2.2 Public Key . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
D.3 Encoding of the Document Number . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
E Basic Access Control (Informative) 56
E.1 Document Basic Access Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
E.2 Protocol Speciﬁcation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
F Challenge Semantics (Informative) 58
List of Figures
2.1 Public Key Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2 Certiﬁcate Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.1 Chip Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.2 Terminal Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.1 Cipher-based Authenticator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.2 Signature-based Authenticator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
B.1 Command Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
D.1 DG14 (ECDH) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
D.2 Chip Authentication Private Key (ECDH) . . . . . . . . . . . . . . . . . . . . . . . . . 49
D.3 DG14 (DH) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
D.4 Chip Authentication Private Key (DH) . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
D.5 CVCA Certiﬁcate (ECDSA) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
D.6 CVCA Private Key (ECDSA) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
D.7 CVCA Certiﬁcate (RSA) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
D.8 CVCA Private Key (RSA) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
E.1 Basic Access Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
vi Federal Ofﬁce for Information Security
Technical Guideline - Extended Access Control
List of Tables
1.1 ICAO Security Mechanisms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.2 Data Groups of the ePassport Application . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.3 Key words . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.1 Inspection Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
A.1 Algorithms and Formats for Chip Authentication . . . . . . . . . . . . . . . . . . . . . 28
A.2 Certiﬁcate Holder Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
A.3 Elementary File EF.CVCA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
A.4 Object Identiﬁers for Terminal Authentication with RSA . . . . . . . . . . . . . . . . . 32
A.5 Object Identiﬁers for Terminal Authentication with ECDSA . . . . . . . . . . . . . . . 33
A.6 CV Certiﬁcate Proﬁle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
A.7 CV Certiﬁcate Request Proﬁle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
A.8 Encoding of Roles and Access Rights . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
C.1 Overview on Data Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
C.3 ISO/IEC 8859-1 Character Set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
C.4 RSA Public Key . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
C.5 ECDSA Public Key . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Federal Ofﬁce for Information Security vii
Technical Guideline - Extended Access Control
1 Introduction
The International Civil Aviation Organization (ICAO) standardizes machine readable travel documents
in ICAO Doc 9303. This standard consists of three parts:
Part 1: Machine Readable Passports
• Volume 1: Passports with Machine Readable Data Stored in Optical Character Recognition Format
• Volume 2: Speciﬁcations for Electronically Enabled Passports with Biometric Identiﬁcation Ca-
pability
Part 2: Machine Readable Visa
Part 3: Machine Readable Ofﬁcial Travel Documents
This technical guideline mainly focuses on and extends the electronic security mechanisms for electronic
passports described in Doc 9303 Part 1 Volume 2 [5] to protect the authenticity (including integrity),
originality, and conﬁdentiality of the data stored on the radio frequency chip embedded in the passport
(MRTD chip). In a nutshell the security mechanisms speciﬁed in [5] are Passive Authentication, Active
Authentication, and Access Control as summarized in Table 1.1.
Table 1.1: ICAO Security Mechanisms
Mechanism Protection Cryptographic Technique
Passive Authentication Authenticity Digital Signature
Active Authentication Originality Challenge-Response
Access Control Conﬁdentiality Authentication & Secure Channels
While the implementation of Passive Authentication is mandatory, Active Authentication and Access
Control are both optional. It directly follows that without implementing those or equivalent mechanisms
the originality and conﬁdentiality of the stored data cannot be guaranteed. This guideline focuses on
those aspects and speciﬁes supplementary mechanisms for authentication and access control that are
important for a secure MRTD chip.
1.1 Passive Authentication
The ICAO ePassport application basically consists of 16 data groups (DG1-DG16) and a Security Object
for Passive Authentication. An overview on the usage of those data groups is given in Table 1.2.
Passive Authentication uses a digital signature to authenticate data stored in the data groups on the
MRTD chip. This signature is generated by a Document Signer (e.g. the MRTD producer) in the personalization
phase of the MRTD chip over a Security Object containing the hash values of all data groups
stored on the chip. For details on the Security Object, Document Signers, and Country Signing CAs the
reader is referred to [5].
To verify data stored on an MRTD chip using Passive Authentication the inspection system has to
perform the following steps:
1. Read the Security Object from the MRTD chip.
8 Federal Ofﬁce for Information Security
Technical Guideline - Extended Access Control
DG Content Read / Write Mandatory / Optional Access Control
DG1 MRZ R m BAC
DG2 Biometric: Face R m BAC
DG3 Biometric: Finger R o BAC + EAC
DG4 Biometric: Iris R o BAC + EAC
... R o BAC
DG14 SecurityInfos∗ R o BAC
DG15 Active Authentication R o BAC
DG16 ... R o BAC
SOD Security Object R m BAC
∗DG14 is deﬁned in this speciﬁcation (cf. Appendix A.1).
Table 1.2: Data Groups of the ePassport Application
2. Retrieve the corresponding Document Signer Certiﬁcate and the trusted Country Signing CA Cer-
tiﬁcate.
3. Verify the Document Signer Certiﬁcate and the signature of the Security Object.
4. Compute hash values of read data groups and compare them to the hash values in the Security
Object.
Passive Authentication enables an inspection system to detect manipulated data groups, but it does not
prevent cloning of MRTD chips, i.e. copying the complete data stored on one MRTD chip to another
MRTD chip.
NOTE: Even with Passive Authentication, an inspection system can detect a cloned MRTD chip by
carefully comparing the machine readable zone (MRZ) printed on the datapage to the MRZ stored
in data group DG1 on the MRTD chip. This test, however, assumes that it is impossible to physically
copy the datapage – which exclusively relies on its physical security features.
1.2 Active Authentication
Active Authentication is a digital security feature that prevents cloning by introducing a chip-individual
key pair:
• The public key is stored in data group DG15 and thus protected by Passive Authentication.
• The corresponding private key is stored in secure memory and may only be used internally by the
MRTD chip and cannot be read out.
Thus, the chip can prove knowledge of this private key in a challenge-response protocol, which is called
Active Authentication. In this protocol the MRTD chip digitally signs a challenge randomly chosen by
the inspection system. The inspection system recognizes that the MRTD chip is genuine if and only if the
returned signature is correct. Active Authentication is a straightforward protocol and prevents cloning
very effectively, but introduces a privacy threat: Challenge Semantics (see Appendix F for a discussion
on Challenge Semantics).
1.3 Access Control
Access Control is not only required for privacy reasons but also mitigates the risk of cloning attacks. The
MRTD chip protects the stored data against unauthorized access by applying appropriate access control
mechanisms as described below:
Federal Ofﬁce for Information Security 9
Technical Guideline - Extended Access Control
• Less-sensitive data (e.g. the MRZ, the facial image and other data that is relatively easy to acquire
from other sources) required for global interoperable border crossing is protected by Basic Access
Control. For the reader’s convenience, Basic Access Control is described in Appendix E.
• Sensitive data (e.g. ﬁngerprints and other data that cannot be obtained easily from other sources
at a large scale) must only be available to authorized inspection systems. Such data is additionally
protected by Extended Access Control.
Basic Access Control only checks that the inspection system has physical access to the travel document
by requiring the MRZ to be read optically. Extended Access Control should additionally check that the
inspection system is entitled to read sensitive data. Therefore, strong authentication of the inspection
system is required. However, as Extended Access Control is not required for global interoperable border
crossing, this protocol is not (yet) speciﬁed by ICAO.
1.4 Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted
as described in RFC 2119 [2]. The key word “CONDITIONAL” is to be interpreted as follows:
CONDITIONAL: The usage of an item is dependent on the usage of other items. It is therefore further
qualiﬁed under which conditions the item is REQUIRED or RECOMMENDED.
When used in tables (proﬁles), the key words are abbreviated as shown in Table 1.3.
Table 1.3: Key words
Key word Abbrev.
MUST / SHALL REQUIRED m
MUST NOT / SHALL NOT – x
SHOULD RECOMMENDED r
MAY OPTIONAL o
– CONDITIONAL c
1.5 Abbreviations
The following abbreviations are commonly used throughout this speciﬁcation.
10 Federal Ofﬁce for Information Security
Technical Guideline - Extended Access Control
Name Abbrev.
Card Veriﬁable CV
Certiﬁcation Authority CA
Chip Authentication Public Key PKPICC
Chip Authentication Private Key SKPICC
Country Signing CA CSCA
Country Verifying CA CVCA
Country Verifying CA Certiﬁcate CCVCA
Security Object SOD
Document Veriﬁer DV
Document Veriﬁer Certiﬁcate CDV
Domain Parameters D
International Civil Aviation Organization ICAO
Inspection System IS
Inspection System Certiﬁcate CIS
Key Derivation Function KDF
Logical Data Structure LDS
Machine Readable Travel Document MRTD
Proximity Integrated Circuit Chip PICC
Proximity Coupling Device PCD
Terminal Authentication Public Key PKPCD
Terminal Authentication Private Key SKPCD
Federal Ofﬁce for Information Security 11
Technical Guideline - Extended Access Control
2 Advanced Security Mechanisms
This technical guideline speciﬁes two advanced security mechanisms for machine readable travel documents:
Chip Authentication and Terminal Authentication. While Chip Authentication can be used as a
stand-alone protocol, e.g. to replace Active Authentication, Terminal Authentication can only be used in
combination with Chip Authentication. The combination of both protocols provides an implementation
of Extended Access Control.
Chip Authentication
This protocol is an alternative to the optional Active Authentication, i.e. it enables the inspection system
to verify that the MRTD chip is genuine but has two advantages over the original protocol.
• Challenge Semantics are prevented because the transcripts produced by this protocol are non-
transferable.
• Besides authentication of the MRTD chip this protocol also provides strong session keys for Secure
Messaging.
An MRTD chip that supports Chip Authentication MUST also enforce Basic Access Control.
Terminal Authentication
This protocol enables the MRTD chip to verify that the inspection system is entitled to access sensitive
data. As the inspection system MAY access sensitive data afterwards, all further communication MUST
be protected appropriately. Therefore, Chip Authentication MUST have been successfully executed
before starting this protocol – which is enforced by the protocol itself.
2.1 Inspection Procedure
Depending on whether or not a device (i.e. an MRTD chip or an inspection system) is compliant to
this speciﬁcation the device is called compliant or non-compliant, respectively. Depending on the combination
of an inspection system and an MRTD chip, either the standard inspection procedure or the
advanced inspection procedure is used:
• A non-compliant inspection system uses the standard inspection procedure. Less-sensitive data
stored on a compliant MRTD chip MUST be readable by every non-compliant inspection system.
• A compliant inspection system SHALL use the advanced inspection procedure if the MRTD chip
is compliant. Otherwise the standard inspection procedure SHALL be used.
Table 2.1 gives an overview on the inspection procedures to be used.
NOTE: As described in Section 1.1 Passive Authentication is a continuous process that requires the
computation of a hash value of each data group read from the chip and its comparison to the corresponding
hash value contained in the Security Object. While this continuous process is assumed
to be applied in the following procedures, it is not explicitly described.
12 Federal Ofﬁce for Information Security
Technical Guideline - Extended Access Control
Table 2.1: Inspection Procedures
Inspection system MRTD chip
compliant non-compliant
compliant Advanced Standard
non-compliant Standard Standard
2.1.1 Standard ePassport Inspection Procedure
The standard inspection procedure consists of the following steps:
1. Select ePassport application (REQUIRED)
The MRTD chip performs the following:
a) BAC used: It SHALL NOT grant access to any data (except general system data).
b) BAC unused: It SHALL grant access to less-sensitive data (e.g. DG1, DG2, DG14, DG15,
etc. and the Security Object).
2. Basic Access Control (CONDITIONAL)
This step is REQUIRED if Basic Access Control is enforced by the MRTD chip.
If successful, the MRTD chip performs the following:
• It SHALL start Secure Messaging.
• It SHALL grant access to less-sensitive data (e.g. DG1, DG2, DG14, DG15, etc. and the
Security Object).
• It SHALL restrict access rights to require Secure Messaging.
3. Passive Authentication (started) (REQUIRED)
The inspection system MUST read and verify the Security Object.
4. Active Authentication (OPTIONAL)
If available, the inspection system MAY read and verify DG15 and perform Active Authentication.
5. Read and authenticate data
The inspection system MAY read and verify read data groups containing less-sensitive data.
2.1.2 Advanced ePassport Inspection Procedure
The advanced inspection procedure consists of the following steps:
1. Select ePassport application (REQUIRED)
The MRTD chip SHALL NOT grant access to any data (except general system data).
2. Basic Access Control (REQUIRED)
If successful, the MRTD chip performs the following:
• It SHALL start Secure Messaging.
• It SHALL grant access to less-sensitive data (e.g. DG1, DG2, DG14, DG15, etc. and the
Security Object).
• It SHALL restrict access rights to require Secure Messaging.
Federal Ofﬁce for Information Security 13
Technical Guideline - Extended Access Control
3. Chip Authentication (REQUIRED)
The inspection system SHALL read DG14 and perform Chip Authentication.
The MRTD chip performs the following:
• It SHALL restart Secure Messaging.
• It SHALL restrict access rights to require Secure Messaging established by Chip Authenti-
cation.
4. Passive Authentication (started) (REQUIRED)
The inspection system performs the following:
• It SHALL read and verify the Security Object.
• It SHALL verify DG14.
5. Active Authentication (OPTIONAL)
If available, the inspection system MAY read and verify DG15 and perform Active Authentication.
6. Terminal Authentication (CONDITIONAL)
This step is REQUIRED to access sensitive ePassport data.
If successful the MRTD chip performs the following:
• It SHALL additionally grant access to data groups according the inspection system’s access
rights.
• It SHALL restrict all access rights to require Secure Messaging established by Chip Authentication
using the ephemeral public key authenticated by Terminal Authentication.
7. Read and authenticate data
The inspection system MAY read and verify read data groups according to the inspection system’s
access rights.
NOTE: After a successful execution of Chip Authentication strong session encryption is established
rendering the decryption of an eavesdropped communication computationally impossible. However,
only after a successful Passive Authentication the MRTD chip may be considered genuine.
2.2 Public Key Infrastructure
Terminal Authentication requires the inspection system to prove to the MRTD chip that it is entitled
to access sensitive data. Such an inspection system is equipped with at least one Inspection System
Certiﬁcate, encoding the inspection system’s public key and access rights, and the corresponding private
key. After the inspection system has proven knowledge of this private key, the MRTD chip grants the
inspection system access to sensitive data as indicated in the Inspection System Certiﬁcate.
The PKI required for issuing and validating Inspection System Certiﬁcates consists of the following
entities:
1. Country Verifying CAs (CVCAs)
2. Document Veriﬁers (DVs)
3. Inspection systems (ISs)
This PKI forms the basis of Extended Access Control. It is illustrated in Figure 2.1.
14 Federal Ofﬁce for Information Security
Technical Guideline - Extended Access Control
− Access Rights
− Validity Period
DV−Cert. assigns:
− Access Rights
− Validity Period
IS−Cert. restricts:
Country A Country B
CVCA
DV
CVCA
DV
... ... ... ...IS IS IS IS IS IS IS IS
DV DV
Arrows denote certification.
Figure 2.1: Public Key Infrastructure
2.2.1 Country Verifying CA
Every State is required to set up one trust-point that issues Document Veriﬁer Certiﬁcates: the Country
Verifying CA (CVCA).
NOTE: The Country Signing CA issuing certiﬁcates for Document Signers (cf. [5]) and the Country
Verifying CA MAY be integrated into a single entity, e.g. a Country CA. However, even in this
case, separate key pairs MUST be used for different roles.
A CVCA determines the access rights to national MRTD chips for all DVs (i.e. national DVs as well
as the DVs of other States) by issuing certiﬁcates for DVs entitled to access some sensitive data. The
conditions under which a CVCA grants a DV access to sensitive data is out of the scope of this document
and SHOULD be stated in a certiﬁcate policy (cf. Appendix A.4.3).
Document Veriﬁer Certiﬁcates MUST contain information, such as which data a certain DV is entitled
to access. To diminish the potential risk introduced by lost or stolen inspection systems Document
Veriﬁer Certiﬁcates MUST contain a short validity period. The validity period is assigned by the issuing
CVCA at its own choice and this validity period may differ depending on the Document Veriﬁer the
certiﬁcate is issued to.
2.2.2 Document Veriﬁers
A Document Veriﬁer (DV) is an organizational unit that manages inspection systems belonging together
(e.g. inspection systems operated by a State’s border police) by – inter alia – issuing Inspection System
Certiﬁcates. A Document Veriﬁer is therefore a CA, authorized by at least the national CVCA to issue
certiﬁcates for national inspection systems. The Inspection System Certiﬁcates issued by a DV usually
inherit both the access rights and the validity period from the Document Veriﬁer Certiﬁcate, however, the
Document Veriﬁer MAY choose to further restrict the access rights or the validity period depending on
the inspection system the certiﬁcate is issued for.
If a Document Veriﬁer requires its inspection systems to access sensitive data stored on other States’
MRTD chips, it MUST apply for a DV Certiﬁcate issued by the CVCA of the respective States. The
Document Veriﬁer MUST also ensure that all received Document Veriﬁer Certiﬁcates are forwarded to
the inspection systems within its domain.
2.2.3 Card Veriﬁable Certiﬁcates
CVCA Link Certiﬁcates, DV Certiﬁcates, and IS Certiﬁcates are to be validated by MRTD chips. Due
to the computational restrictions of those chips, the certiﬁcates MUST be in a card veriﬁable format:
Federal Ofﬁce for Information Security 15
Technical Guideline - Extended Access Control
}
CVCA
DV
IS
certificate effective date
certificate expiration date
max. distribution time
Figure 2.2: Certiﬁcate Scheduling
• The certiﬁcate format and proﬁle speciﬁed in Appendix A.4.1 SHALL be used.
• The signature algorithm, domain parameters, and key sizes to be used are determined by the CVCA
of the issuing State, i.e. the same signature algorithm, domain parameters and key sizes MUST be
used within a certiﬁcate chain.1
• CVCA Link Certiﬁcates MAY include a public key that deviates from the current parameters, i.e.
the CVCA MAY switch to a new signature algorithm, new domain parameters, or key sizes.
2.2.3.1 Certiﬁcate Scheduling
Each certiﬁcate MUST contain a validity period. This validity period is identiﬁed by two dates, the
certiﬁcate effective date and the certiﬁcate expiration date.
Certiﬁcate Effective Date: The certiﬁcate effective date SHALL be the date of the certiﬁcate genera-
tion.
Certiﬁcate Expiration Date: The certiﬁcate expiration date MAY be arbitrarily chosen by the certiﬁcate
issuer.
When generating certiﬁcates the issuer MUST carefully plan the renewal of certiﬁcates, as sufﬁcient
time for propagation of certiﬁcates and set up of certiﬁcate chains MUST be provided. Obviously, a new
certiﬁcate must be generated before the current certiﬁcate expires. The resulting maximum distribution
time equals the certiﬁcate expiration date of the old certiﬁcate minus the certiﬁcate effective date of the
new certiﬁcate. Certiﬁcate scheduling is illustrated in Figure 2.2.
2.2.4 Certiﬁcate Validation
To validate an IS Certiﬁcate, the MRTD chip MUST be provided with a certiﬁcate chain starting at
a trust-point stored on the MRTD chip. Those trust-points are more or less recent public keys of the
1As a consequence Document Veriﬁers and inspection systems will have to be provided with several key pairs.
16 Federal Ofﬁce for Information Security
Technical Guideline - Extended Access Control
MRTD chip’s CVCA. The initial trust-point(s) SHALL be stored in the MRTD chip’s secure memory in
the production or (pre-) personalization phase.
As the key pair used by the CVCA changes over time, CVCA Link Certiﬁcates have to be produced.
The MRTD chip is REQUIRED to internally update its trust-point(s) according to received valid link
certiﬁcates.
NOTE: Due to the scheduling of CVCA Link Certiﬁcates (cf. Figure 2.2), at most two trust-points
need to be stored on the MRTD chip.
The MRTD chip MUST only accept recent IS Certiﬁcates. If the MRTD chip has no internal clock,
the current date SHALL be approximated as described below. Thus, the MRTD chip only veriﬁes that a
certiﬁcate is apparently recent (i.e. with respect to the approximated current date).
Current Date: The current date stored on the MRTD chip is initially the date of the (pre-) personalization.
This date is then autonomously approximated by the MRTD chip using the most recent
certiﬁcate effective date contained in a valid CVCA Link Certiﬁcate, a DV Certiﬁcate or a domestic
IS Certiﬁcate.
An inspection system MAY send CVCA Link Certiﬁcates, DV Certiﬁcates, and IS Certiﬁcates to an
MRTD chip to update the current date and the trust-point stored on the MRTD chip even if the inspection
system does not intend to or is not able to continue with Terminal Authentication.
2.2.4.1 General Procedure
The certiﬁcate validation procedure consists of two steps:
1. Certiﬁcate Veriﬁcation: The signature MUST be valid, the certiﬁcate MUST NOT be expired. If
the veriﬁcation fails, the procedure SHALL be aborted.
2. Internal Status Update: The current date MUST be updated, the public key and the attributes
MUST be imported, new trust-points MUST be enabled, expired trust-points MUST be disabled.
The operations of enabling or disabling a trust-point and the operation of updating the current date
MUST be implemented as an atomic operation.
2.2.4.2 Example Procedure
The following validation procedure, provided as an example, MAY be used to validate a certiﬁcate chain.
For each received certiﬁcate the MRTD chip performs the following steps:
1. The MRTD chip veriﬁes the signature on the certiﬁcate. If the signature is incorrect, the veriﬁcation
fails.
2. The certiﬁcate expiration date is compared to the MRTD chip’s current date. If the expiration date
is before the current date, the veriﬁcation fails.
3. The certiﬁcate is valid and the public key and the relevant attributes contained in the certiﬁcate are
imported.
a) For CVCA Link Certiﬁcates:
The new CVCA public key is added to the list of trust-points stored in the MRTD chip’s
secure memory. The new trust-point is then enabled.
b) For DV and IS Certiﬁcates:
The new DV or IS public key is temporarily imported for subsequent certiﬁcate veriﬁcation
or Terminal Authentication, respectively.
Federal Ofﬁce for Information Security 17
Technical Guideline - Extended Access Control
4. For CVCA, DV, and domestic IS Certiﬁcates:
The certiﬁcate effective date is compared to the MRTD chip’s current date. If the current date is
before the effective date, the current date is updated to the effective date.
5. Expired trust-points stored in the MRTD chip’s secure memory are disabled and may be removed
from the list of trust-points.
18 Federal Ofﬁce for Information Security
Technical Guideline - Extended Access Control
3 Protocol Speciﬁcations
In this section cryptographic protocols for Chip Authentication and Terminal Authentication are speciﬁed
assuming an arbitrary communication infrastructure. A mapping to ISO 7816 commands is given in
Appendix B.
3.1 Cryptographic Algorithms and Notation
The protocols are executed between two parties: the MRTD chip (PICC) and the inspection system
(PCD). The following cryptographic operations and notations are used.
3.1.1 Key Agreement
The keys and operations for key agreement are described in an algorithm-independent way. A mapping
to DH and ECDH can be found in Appendix A.2.
3.1.1.1 Keys
The following key pairs are used:
• The MRTD chip has a static Difﬁe-Hellman key pair (or Chip Authentication Key Pair). The public
key is PKPICC, the corresponding private key is SKPICC, the domain parameters are DPICC.
• The inspection system generates an ephemeral Difﬁe-Hellman key pair for every new communication
using the MRTD chip’s domain parameters DPICC. The ephemeral public key is PKPCD, the
corresponding private key is SKPCD.
It is RECOMMENDED that the MRTD chip validates the ephemeral public key received from the inspection
system.
3.1.1.2 Operations
Generating a shared secret K is denoted by KA(SKPICC,PKPCD,DPICC) for the MRTD chip and
KA(SKPCD,PKPICC,DPICC) for the inspection system.
3.1.2 Signatures
The keys and operations for signatures are described in an algorithm-independent way. A mapping to
RSA and ECDSA can be found in Appendix A.3.
3.1.2.1 Keys
The inspection system has a static signature key pair (or Terminal Authentication Key Pair). The public
key is PKPCD, the corresponding private key is SKPCD.
Federal Ofﬁce for Information Security 19
Technical Guideline - Extended Access Control
MRTD Chip (PICC) Inspection System (PCD)
static key pair:
(SKPICC,PKPICC,DPICC)
PKPICC
−−−−→
DPICC
choose random ephemeral key pair
(SKPCD,PKPCD,DPICC)
PKPCD
←−−−
K = KA(SKPICC,PKPCD,DPICC) K = KA(SKPCD,PKPICC,DPICC)
Figure 3.1: Chip Authentication
3.1.2.2 Operations
The operations for signing and verifying a message are denoted as follows:
• Signing a message m with private key SKPCD is denoted by s = Sign(SKPCD,m).
• Verifying the resulting signature s with public key PKPCD is denoted by Verify(PKPCD,s,m).
3.2 Chip Authentication
Chip Authentication is an ephemeral-static Difﬁe-Hellman key agreement protocol that provides secure
communication and implicit unilateral authentication of the MRTD chip.
3.2.1 Protocol Speciﬁcation
The following steps are performed by the inspection system and the MRTD chip, a simpliﬁed version is
also shown in Figure 3.1:
1. The MRTD chip sends its static Difﬁe-Hellman public key PKPICC, and the domain parameters
DPICC to the inspection system.
2. The inspection system generates an ephemeral Difﬁe-Hellman key pair (SKPCD,PKPCD,DPICC),
and sends the ephemeral public key PKPCD to the MRTD chip.
3. Both the MRTD chip and the inspection system compute the following:
a) The shared secret K = KA(SKPICC,PKPCD,DPICC) = KA(SKPCD,PKPICC,DPICC)
b) The session keys KMAC and KEnc derived from K for Secure Messaging.
c) The hash of the inspection system’s ephemeral public key H(PKPCD) for Terminal Authenti-
cation.
To verify the authenticity of the PKPICC the inspection system SHALL perform Passive Authentication
directly after Chip Authentication.
3.2.2 Security Status
If Chip Authentication was successfully performed, Secure Messaging is restarted using the derived
session keys KMAC and KEnc. Otherwise, Secure Messaging is continued using the previously established
session keys (Basic Access Control).
NOTE: Passive Authentication MUST be performed directly after Chip Authentication. Only after a
successful validation of the Security Object read from the MRTD chip using the new session keys
the MRTD chip may be considered genuine.
20 Federal Ofﬁce for Information Security
Technical Guideline - Extended Access Control
MRTD Chip (PICC) Inspection System (PCD)
choose rPICC randomly
rPICC
−−−→
sPCD
←−−
sPCD = Sign(SKPCD,
IDPICC||rPICC||H(PKPCD))
Verify(PKPCD,sPCD,
IDPICC||rPICC||H(PKPCD))
Figure 3.2: Terminal Authentication
3.3 Terminal Authentication
Terminal Authentication is a two move challenge-response protocol that provides explicit unilateral authentication
of the inspection system.
3.3.1 Protocol Speciﬁcation
The following steps are performed by the inspection system and the MRTD chip, a simpliﬁed version is
also shown in Figure 3.2:
1. The inspection system sends a certiﬁcate chain to the MRTD chip. The chain starts with a certiﬁcate
veriﬁable with a CVCA public key stored on the chip and ends with the inspection system’s
IS Certiﬁcate.
2. The MRTD chip veriﬁes the certiﬁcates and extracts the inspection system’s public key PKPCD.
Then it sends the challenge rPICC to the inspection system.
3. The inspection system responds with the signature
sPCD = Sign(SKPCD,IDPICC||rPICC||H(PKPCD)).
4. The MRTD chip checks that
Verify(PKPCD,sPCD,IDPICC||rPICC||H(PKPCD)) = true.
In this protocol IDPICC is the MRTD chip’s Document Number including the check digit (similar to Basic
Access Control) as contained in the MRZ and H(PKPCD) is the hash value of the inspection system’s
ephemeral Difﬁe-Hellman public key from Chip Authentication.
NOTE: All messages MUST be transmitted with Secure Messaging in Encrypt-then-Authenticate
mode using session keys derived from Chip Authentication.
3.3.2 Security Status
If Terminal Authentication was successfully performed, the MRTD chip SHALL grant access to stored
sensitive data according to the effective authorization level of the authenticated inspection system.
NOTE: Secure Messaging is not affected by Terminal Authentication. The MRTD chip SHALL retain
Secure Messaging even if Terminal Authentication fails (unless a Secure Messaging error occurs).
Federal Ofﬁce for Information Security 21
Technical Guideline - Extended Access Control
4 Security & Privacy
In this section the formal correctness of the protocols is shown. Following the ideas proposed in [1] a
transition from the Authenticated Link Model to the Unauthenticated Link Model is used to prove the
security of the protocols.
Authenticated Link Model: The Authenticated Link Model is an idealized setting where all messages
are a priori authenticated.
Unauthenticated Link Model: The Unauthenticated Link Model is the real-world setting where messages
are unauthenticated.
The Authenticated Link Model restricts the adversary to attacks on the cryptographic primitive itself
and to attacks that do not have impact on the security of the protocol (e.g. denial of service attacks).
In this model a key agreement would be sufﬁcient to set up the secure channel. The security of the
underlying Difﬁe-Hellman protocol is directly based on the assumption that the Computational DifﬁeHellman
Problem is hard.
The transition from the Authenticated Link Model to the Unauthenticated Link Model is done by applying
appropriate Authenticators, turning unauthenticated messages into authenticated messages. Actually,
Chip Authentication and Terminal Authentication are such authenticators. Unfortunately, there is
no clear deﬁnition of the properties of an authenticator in the literature and the corresponding security
proofs are quite blurred. To make such proofs more transparent, we give a deﬁnition of an authenticator:
Authenticator: A message sent from an originator to a recipient shall be authenticated. It directly
follows that the following three properties are sufﬁcient for authentication of the message:
• Origin: The recipient must be able to identify the sender of the message.
• Destination: The originator must be able to indicate the intended recipient of the message.
• Freshness: The recipient must be able to check that the message is not a copy of a previous
message.
4.1 Chip Authentication
Chip Authentication is similar to the cipher-based authenticator proposed in [1], also shown in Figure
4.1. It is a two-move protocol that is used to protect the message mPICC sent from the MRTD chip to the
inspection system by authenticating the message with a MAC.
To make the transition resulting from the application of the cipher-based authenticator to the
basic Difﬁe-Hellman protocol more clear, consider that the encryption ePCD = E(PKPICC,K) can
be safely replaced by the ephemeral key PKPCD, because this is actually an encryption of K =
KA(SKPCD,PKPICC,DPICC) (see also Proposition 5 and Remark 1 in [1]).
• Origin: Computation of the MAC requires knowledge of the authentication key K. It directly
follows from the Computational Difﬁe-Hellman assumption that only the MRTD chip (and the
inspection system) can generate K from PKPCD.
• Destination: The chip includes the identity of the inspection system in the MAC. If the inspection
system remains anonymous, the distinguishing identiﬁer IDPCD can be removed from the MAC.
In this case the message is intended for the inspection system that is able to verify the MAC (and
thus has knowledge of K).
22 Federal Ofﬁce for Information Security
Technical Guideline - Extended Access Control
MRTD Chip (PICC) Inspection System (PCD)
ePCD
←−−
choose K randomly
ePCD = E(PKPICC,K)
sPICC = MAC(K,mPICC||IDPCD)
mPICC
−−−→
sPICC
Figure 4.1: Cipher-based Authenticator
MRTD Chip (PICC) Inspection System (PCD)
mPCD
←−−−
choose rPICC randomly
rPICC
−−−→
sPCD
←−−
sPCD =
Sign(SKPCD,IDPICC||rPICC||mPCD)
Figure 4.2: Signature-based Authenticator
• Freshness: If the the inspection system chooses the ephemeral key pair (SKPCD,PKPCD) randomly
and uniformly, the authentication key K is also generated randomly and uniformly.
4.1.1 Summarized Properties
Chip Authentication has the following properties:
1. Implicit authentication of the MRTD chip.
2. Secure messaging with forward secrecy.1
4.1.2 Remaining Risks
Chip Authentication alone does not necessarily guarantee that the MRTD chip contained in a presented
document is genuine. To preclude sophisticated attacks (e.g. the “Grandmaster Chess Attack”) the
authenticity and integrity of the printed MRZ and DG1 of the ePassport application MUST be veriﬁed
and it MUST be checked that both are identical.
This implies that in addition to Chip Authentication and Passive Authentication the physical security
features of the document MUST be additionally checked to verify the integrity and authenticity of the
printed MRZ.
4.2 Terminal Authentication
Terminal Authentication is the signature-based authenticator proposed in [1], also shown in Figure 4.2. It
is a three-move protocol that is used to protect the integrity of the message mPCD sent from the inspection
system to the chip by authenticating the message with a signature.
• Origin: Computation of the signature sPCD requires knowledge of the private key SKPCD. Thus,
only the inspection system can generate the signature.
• Destination: The inspection system includes the identity of the chip in the signature.
1Assuming that the inspection system chooses PKPCD randomly and erases the secret key SKPCD directly after generating the
session keys, a compromise of the inspection system’s static key pair does not affect the secrecy of past sessions.
Federal Ofﬁce for Information Security 23
Technical Guideline - Extended Access Control
• Freshness: If the MRTD chip chooses the challenge randomly and uniformly it is guaranteed that
the signature sPCD is recent, as the challenge is included in the signed data.
4.2.1 Summarized Properties
Terminal Authentication has the following properties:
1. Explicit authentication of the inspection system.
2. Key conﬁrmation for Secure Messaging.
4.2.2 Remaining Risks
Terminal Authentication mitigates the risk introduced by lost or stolen inspection systems by authorizing
an inspection system to access sensitive data only for a short period of time. Due to the approximation
of the current date, sensitive data may be theoretically read by an already expired inspection system.
On the one hand, an infrequently used travel document is obviously more affected by such an attack.
On the other hand, the attack is more difﬁcult to mount on an infrequently used travel document, as
access to an MRTD chip still requires consent of the bearer which is enforced by Basic Access Control.
Furthermore, what cannot be prevented is an attacker being able to subvert an inspection system and
gain access to sensitive data.
4.3 Challenge Semantics
Terminal Authentication is a challenge-response protocol based on digital signatures, which is obviously
not free from challenge semantics. This potential attack is however less important, as the inspection
system is usually not concerned about its privacy.
Therefore, it only has to be shown that Chip Authentication and the cipher-based authenticator provide
a non-transferable proof of knowledge. This can be done by showing that the protocol may be simulated
without the chip’s private key, and that the simulated transcript is indistinguishable from a real transcript.
The simulation is trivial:
Input: The chip’s static public key PKPICC, the domain parameters DPICC, and a message mPICC.
Output: The authenticated message sPICC = MAC(K,mPICC||IDPCD), where the authentication key is
K = KA(SKPCD,PKPICC,DPICC) and SKPCD is a randomly chosen ephemeral private key of the
inspection system.
In other words, Chip Authentication is free from challenge semantics because the MAC is based on
symmetric cryptography. Any party being able to verify the MAC is also able to compute the MAC.
24 Federal Ofﬁce for Information Security
Technical Guideline - Extended Access Control
Appendix A
Key Management (Normative)
The object identiﬁers used in the following appendices are contained in the subtree of bsi-de:
bsi-de OBJECT IDENTIFIER ::= {
itu-t(0) identified-organization(4) etsi(0)
reserved(127) etsi-identified-organization(0) 7
}
A.1 Information on Supported Security Protocols
The ASN.1 data structure SecurityInfos SHALL be provided by the MRTD chip in DG14 to indicate
supported security protocols. The data structure is speciﬁed as follows:
SecurityInfos ::= SET of SecurityInfo
SecurityInfo ::= SEQUENCE {
protocol OBJECT IDENTIFIER,
requiredData ANY DEFINED BY protocol,
optionalData ANY DEFINED BY protocol OPTIONAL
}
The elements contained in a SecurityInfo data structure have the following meaning:
• The object identiﬁer protocol identiﬁes the supported protocol.
• The open type requiredData contains protocol speciﬁc mandatory data.
• The open type optionalData contains protocol speciﬁc optional data.
A.1.1 Supported Protocols
The ASN.1 speciﬁcations for the protocols provided in this speciﬁcation are described in the following.
NOTE: The following data structures were introduced in version 1.1 of this speciﬁcation:
• ChipAuthenticationInfo
• TerminalAuthenticationInfo
MRTD chips implemented according to Version 1.0.x of this speciﬁcation will only provide a
ChipAuthenticationPublicKeyInfo. In this case the inspection system SHOULD assume
the following:
• The MRTD chip supports Chip Authentication.
• The MRTD chip may support Terminal Authentication.
To determine whether or not sensitive data protected by Terminal Authentication is stored on
the MRTD chip, the inspection system may consult the Security Object and the elementary ﬁle
EF.CVCA.
Federal Ofﬁce for Information Security 25
Technical Guideline - Extended Access Control
A.1.1.1 Chip Authentication
To indicate support for Chip Authentication SecurityInfos may contain the following entries:
• At least one ChipAuthenticationPublicKeyInfo MUST be present.
• At least one ChipAuthenticationInfo SHOULD be present.
If more than one Chip Authentication Public Key is present the optional keyId MUST be used in both
data structures to indicate the local key identiﬁer.
ChipAuthenticationPublicKeyInfo: This data structure provides an Chip Authentication Public Key
of the MRTD chip.
• The object identiﬁer protocol SHALL identify the type of the public key (i.e. DH or ECDH).
• The sequence chipAuthenticationPublicKey SHALL contain the public key
in encoded form. More details on the speciﬁcation of SubjectPublicKeyInfo and
AlgorithmIdentifier can be found in [4].
• The integer keyId MAY be used to indicate the local key identiﬁer. It MUST be used if the
MRTD chip provides multiple public keys for Chip Authentication.
id-PK OBJECT IDENTIFIER ::= {
bsi-de protocols(2) smartcard(2) 1
}
id-PK-DH OBJECT IDENTIFIER ::= {id-PK 1}
id-PK-ECDH OBJECT IDENTIFIER ::= {id-PK 2}
ChipAuthenticationPublicKeyInfo ::= SEQUENCE {
protocol id-PK-DH||
id-PK-ECDH,
chipAuthenticationPublicKey SubjectPublicKeyInfo,
keyId INTEGER OPTIONAL
}
SubjectPublicKeyInfo ::= SEQUENCE {
algorithm AlgorithmIdentifier,
subjectPublicKey BIT STRING
}
AlgorithmIdentifier ::= SEQUENCE {
algorithm OBJECT IDENTIFIER,
parameters ANY DEFINED BY algorithm OPTIONAL
}
ChipAuthenticationInfo: This data structure provides detailed information on an implementation of
Chip Authentication.
• The object identiﬁer protocol SHALL identify the algorithms to be used (i.e. key agreement,
symmetric cipher and MAC).
• The integer version SHALL identify the version of the protocol. Currently, only version 1 is
supported.
26 Federal Ofﬁce for Information Security
Technical Guideline - Extended Access Control
• The integer keyId MAY be used to indicate the local key identiﬁer. It MUST be used if the
MRTD chip provides multiple public keys for Chip Authentication.
id-CA OBJECT IDENTIFIER ::= {
bsi-de protocols(2) smartcard(2) 3
}
id-CA-DH OBJECT IDENTIFIER ::= {id-CA 1}
id-CA-DH-3DES-CBC-CBC OBJECT IDENTIFIER ::= {id-CA-DH 1}
id-CA-ECDH OBJECT IDENTIFIER ::= {id-CA 2}
id-CA-ECDH-3DES-CBC-CBC OBJECT IDENTIFIER ::= {id-CA-ECDH 1}
ChipAuthenticationInfo ::= SEQUENCE {
protocol id-CA-DH-3DES-CBC-CBC||
id-CA-ECDH-3DES-CBC-CBC,
version INTEGER, -- MUST be 1
keyId INTEGER OPTIONAL
}
A.1.1.2 Terminal Authentication
To indicate support for Terminal Authentication SecurityInfos may contain the following entry:
• At least one TerminalAuthenticationInfo SHOULD be present.
TerminalAuthenticationInfo: This data structure provides detailed information on an implementation
of Terminal Authentication.
• The object identiﬁer protocol SHALL identify the general Terminal Authentication Protocol
as the speciﬁc protocol may change over time.
• The integer version SHALL identify the version of the protocol. Currently, only version 1 is
supported.
• The sequence efCVCA MAY be used to indicate a (short) ﬁle identiﬁer of the ﬁle EF.CVCA. It
MUST be used, if the default (short) ﬁle identiﬁer is not used.
id-TA OBJECT IDENTIFIER ::= {
bsi-de protocols(2) smartcard(2) 2
}
id-TA-RSA OBJECT IDENTIFIER ::= {id-TA 1}
id-TA-RSA-v1-5-SHA-1 OBJECT IDENTIFIER ::= {id-TA-RSA 1}
id-TA-RSA-v1-5-SHA-256 OBJECT IDENTIFIER ::= {id-TA-RSA 2}
id-TA-RSA-PSS-SHA-1 OBJECT IDENTIFIER ::= {id-TA-RSA 3}
id-TA-RSA-PSS-SHA-256 OBJECT IDENTIFIER ::= {id-TA-RSA 4}
id-TA-ECDSA OBJECT IDENTIFIER ::= {id-TA 2}
id-TA-ECDSA-SHA-1 OBJECT IDENTIFIER ::= {id-TA-ECDSA 1}
id-TA-ECDSA-SHA-224 OBJECT IDENTIFIER ::= {id-TA-ECDSA 2}
id-TA-ECDSA-SHA-256 OBJECT IDENTIFIER ::= {id-TA-ECDSA 3}
Federal Ofﬁce for Information Security 27
Technical Guideline - Extended Access Control
Table A.1: Algorithms and Formats for Chip Authentication
Algorithm / Format DH ECDH
Key Agreement Algorithm PKCS#3 [17] KAEG [7, 9, 3]
Public Key Format PKCS#3 [17] ECC [3]
Key Derivation Function ICAO 3DES KDF [5, 3]
Secure Messaging ICAO 3DES (CBC / Retail MAC) [5]
Ephemeral Public Key Hash SHA-1 [15] X-Coordinate
Ephemeral Public Key Validation RFC 2631[16] ECC [3]
TerminalAuthenticationInfo ::= SEQUENCE {
protocol id-TA,
version INTEGER, -- MUST be 1
efCVCA FileID OPTIONAL
}
FileID ::= SEQUENCE {
fid OCTET STRING (SIZE(2)),
sfid OCTET STRING (SIZE(1)) OPTIONAL
}
A.1.1.3 Other Protocols
SecurityInfos MAY contain references to protocols that are not contained in this speciﬁcation (including
Active Authentication and Basic Access Control).
A.2 Chip Authentication
A.2.1 Storage on the Chip
The Chip Authentication Key Pair MUST be stored on the MRTD chip.
• The private key SHALL be stored in the MRTD chip’s secure memory.
• The public key SHALL be provided in the ChipAuthenticationPublicKeyInfo struc-
ture.
The MRTD chip MAY support more than one Chip Authentication Key Pair (i.e. the chip may support
different algorithms and/or key lengths). In this case the local key identiﬁer MUST be disclosed in the
corresponding ChipAuthenticationPublicKeyInfo (cf. Appendix A.1.1.1). and MUST be
selected by the inspection system with MSE:Set KAT (cf. Appendix B.1.1).
A.2.2 Chip Authentication with DH
For Chip Authentication with DH the respective algorithms and formats from Table A.1 MUST be used.
A.2.3 Chip Authentication with ECDH
For Chip Authentication with ECDH the respective algorithms and formats from Table A.1
MUST be used. The elliptic curve domain parameters MUST be described explicitly in the
ChipAuthenticationPublicKeyInfo structure, i.e. named curves and implicit domain
parameters MUST NOT be used.
28 Federal Ofﬁce for Information Security
Technical Guideline - Extended Access Control
Table A.2: Certiﬁcate Holder Reference
Encoding Length
Country Code ISO 3166-1 ALPHA-2 2F
Holder Mnemonic ISO/IEC 8859-1 9V
Sequence Number ISO/IEC 8859-1 5F
F: ﬁxed length (exact number of octets), V: variable length (up to number of octets)
A.2.4 Ephemeral Public Keys
The domain parameters contained in the ChipAuthenticationPublicKeyInfo structure MUST
be used by the inspection system for the generation of an ephemeral public key. Ephemeral public keys
MUST be exchanged as plain public key values. More information on the encoding can be found in
Appendix C.3.
According to Section 3.1.1 the validation of ephemeral public keys is RECOMMENDED. For DH,
the validation algorithm requires the MRTD chip to have a more detailed knowledge of the domain
parameters (i.e. the order of the used subgroup) than usually provided by PKCS#3.
A.3 Terminal Authentication
A.3.1 Public Key References
Public keys to be used for Terminal Authentication MUST be contained in CV Certiﬁcates according
to the certiﬁcate proﬁle deﬁned in Appendix A.4.1. Each CV Certiﬁcate MUST contain two public key
references, a Certiﬁcate Holder Reference and a Certiﬁcation Authority Reference:
Certiﬁcate Holder Reference: The Certiﬁcate Holder Reference is an identiﬁer for the public key provided
in the certiﬁcate that SHALL be used to reference this public key.
Certiﬁcation Authority Reference: The Certiﬁcation Authority Reference is a reference to the (external)
public key of the certiﬁcation authority that SHALL be used to verify the signature of the
certiﬁcate.
NOTE: As a consequence the Certiﬁcation Authority Reference contained in a certiﬁcate MUST be
equal to the Certiﬁcate Holder Reference in the corresponding certiﬁcate of the issuing certiﬁcation
authority.
The Certiﬁcate Holder Reference SHALL consist of the following concatenated elements: Country
Code, Holder Mnemonic, and Sequence Number. Those elements MUST be chosen according to Table
A.2 and the following rules:
1. Country Code
The Country Code SHALL be the ISO 3166-1 ALPHA-2 code of the certiﬁcate holder’s country.
2. Holder Mnemonic
The Holder Mnemonic SHALL be assigned as unique identiﬁer as follows:
• The Holder Mnemonic of a CVCA SHALL be assigned by the CVCA itself.
• The Holder Mnemonic of a DV SHALL be assigned by the domestic CVCA.
• The Holder Mnemonic of an IS SHALL be assigned by the supervising DV.
3. Sequence Number
The Sequence Number SHALL be assigned by the certiﬁcate holder.
Federal Ofﬁce for Information Security 29
Technical Guideline - Extended Access Control
• The Sequence Number MUST be numeric or alphanumeric:
– A numeric Sequence Number SHALL consist of the characters “0”...”9”.
– An alphanumeric Sequence Number SHALL consist of the characters “0”...”9” and
“A”...”Z”.
• The Sequence Number MAY start with the ISO 3166-1 ALPHA-2 country code of the certifying
certiﬁcation authority, the remaining three characters SHALL be assigned as alphanumeric
Sequence Number.
• The Sequence Number MAY be reset if all available Sequence Numbers are exhausted.
A.3.2 Public Key Import
Public keys imported by the certiﬁcate validation procedure (cf. Section 2.2.4) are either permanently or
temporarily stored on the MRTD chip. The MRTD chip SHOULD reject to import a public key, if the
Certiﬁcate Holder Reference is already known to the MRTD chip.
A.3.2.1 Permanent Import
Public keys contained in CVCA Link Certiﬁcates SHALL be permanently imported by the MRTD chip
and MUST be stored in secure memory. A permanently imported public key and its metadata SHALL
fulﬁll the following conditions:
• It MAY be overwritten after expiration by a subsequent permanently imported public key.
• Either it MUST be overwritten by a subsequent permanently imported public key with the same
Certiﬁcate Holder Reference or the import MUST be rejected.
• It MUST NOT be overwritten by a temporarily imported public key.
NOTE: It is RECOMMENDED to reject to import a public key, if the Certiﬁcate Holder Reference is
already known to the MRTD chip.
Enabling and disabling a permanently imported public key MUST be an atomic operation. The internal
state MUST be reﬂected in the ﬁle EF.CVCA (cf. Table A.3).
A.3.2.2 Temporary Import
Public keys contained in DV and IS Certiﬁcates SHALL be temporarily imported by the MRTD chip. A
temporarily imported public key and its metadata SHALL fulﬁll the following conditions:
• It SHALL NOT be selectable or usable after a power down of the MRTD chip.
• It MUST remain usable until the subsequent cryptographic operation is successfully completed
(i.e. PSO:Verify Certiﬁcate or External Authenticate).
• It MAY be overwritten by a subsequent temporarily imported public key.
An inspection system MUST NOT make use of any temporarily imported public key but the most recently
imported.
30 Federal Ofﬁce for Information Security
Technical Guideline - Extended Access Control
Table A.3: Elementary File EF.CVCA
File Name EF.CVCA
File ID 0x011C (default)
Short File ID 0x1C (default)
Read Access BAC
Write Access NEVER (internally updated only)
Size 36 bytes (ﬁxed) padded with zeros
Content CARi[||CARi−1][||0x00..00]
A.3.2.3 Imported Metadata
For each permanently or temporarily imported public key the following additional data contained in the
certiﬁcate (cf. Appendix A.4.1) MUST be stored:
• Certiﬁcate Holder Reference
• Certiﬁcate Holder Authorization (effective role and effective authorization)
• Certiﬁcate Effective Date
• Certiﬁcate Expiration Date
The calculation of the effective role (CVCA, DV, or IS) and the effective authorization of the certiﬁcate
holder is described in Appendix A.5.
NOTE: The format of the stored data is operating system dependent and out of the scope of this spec-
iﬁcation.
A.3.2.4 EF.CVCA
The MRTD chip MUST make the references of trusted CVCA public keys available to inspection systems
in a transparent elementary ﬁle EF.CVCA as speciﬁed in Table A.3. This ﬁle contains a sequence of
Certiﬁcation Authority Reference (CAR) data objects (cf. Appendix C.2) structured as follows:
• It SHALL contain at most two Certiﬁcation Authority Reference data objects.
• The most recent Certiﬁcation Authority Reference SHALL be the ﬁrst data object in this list.
• The ﬁle MUST be padded by appending zeros.
The ﬁle EF.CVCA has a default ﬁle identiﬁer and short ﬁle identiﬁer. If the default values cannot
be used, the (short) ﬁle identiﬁer SHALL be speciﬁed in the OPTIONAL parameter efCVCA of the
TerminalAuthenticationInfo. If efCVCA is used to indicate the ﬁle identiﬁer to be used, the
default ﬁle identiﬁer is overridden. If no short ﬁle identiﬁer is given in efCVCA, the ﬁle EF.CVCA
MUST be explicitly selected using the given ﬁle identiﬁer.
A.3.3 Terminal Authentication with RSA
For Terminal Authentication with RSA the following algorithms and formats MUST be used.
Federal Ofﬁce for Information Security 31
Technical Guideline - Extended Access Control
Table A.4: Object Identiﬁers for Terminal Authentication with RSA
OID Signature Hash Parameters
id-TA-RSA-v1-5-SHA-1 RSASSA-PKCS1-v1_5 SHA-1 N/A
id-TA-RSA-v1-5-SHA-256 RSASSA-PKCS1-v1_5 SHA-256 N/A
id-TA-RSA-PSS-SHA-1 RSASSA-PSS SHA-1 default
id-TA-RSA-PSS-SHA-256 RSASSA-PSS SHA-256 default
A.3.3.1 Signature Algorithm
RSA [14, 18] as speciﬁed in Table A.4 SHALL be used. The default parameters to be used with RSA-PSS
are deﬁned as follows:
• Hash Algorithm: The hash algorithm is selected according to Table A.4.
• Mask Generation Algorithm: MGF1 [14, 18] using the selected hash algorithm.
• Salt Length: Octet length of the output of the selected hash algorithm.
• Trailer Field: 0xBC
A.3.3.2 Public Key Format
The TLV-Format [12] as described in Appendix C.3.1 SHALL be used.
• The object identiﬁer SHALL be taken from Table A.4.
• The bit length of the modulus SHALL be 1024, 1280, 1536, 2048, or 3072.
A.3.4 Terminal Authentication with ECDSA
For Terminal Authentication with ECDSA the following algorithms and formats MUST be used.
A.3.4.1 Signature Algorithm
ECDSA with plain signature format [7, 8, 3] as speciﬁed in Table A.5 SHALL be used.
A.3.4.2 Public Key Format
The TLV-Format [12] as described in Appendix C.3.2 SHALL be used.
• The object identiﬁer SHALL be taken from Table A.5.
• The bit length of the curve SHALL be 160, 192, 224, or 256.
• Domain Parameters SHALL be compliant to [3].
A.4 CV Certiﬁcates
A.4.1 Certiﬁcate Proﬁle
Self-descriptive card veriﬁable (CV) certiﬁcates according to ISO 7816 [10, 11, 12] and the certiﬁcate
proﬁle speciﬁed in Table A.6 SHALL be used. Details on the encoding of the data objects used in the
certiﬁcate proﬁle can be found in Appendix C.2.
32 Federal Ofﬁce for Information Security
Technical Guideline - Extended Access Control
Table A.5: Object Identiﬁers for Terminal Authentication with ECDSA
OID Signature Hash
id-TA-ECDSA-SHA-1 ECDSA SHA-1
id-TA-ECDSA-SHA-224 ECDSA SHA-224
id-TA-ECDSA-SHA-256 ECDSA SHA-256
Table A.6: CV Certiﬁcate Proﬁle
Data Object Cert
CV Certiﬁcate m
Certiﬁcate Body m
Certiﬁcate Proﬁle Identiﬁer m
Certiﬁcation Authority Reference m
Public Key m
Certiﬁcate Holder Reference m
Certiﬁcate Holder Authorization Template m
Certiﬁcate Effective Date m
Certiﬁcate Expiration Date m
Signature m
A.4.1.1 Certiﬁcate Proﬁle Identiﬁer
The version of the proﬁle is indicated by the Certiﬁcate Proﬁle Identiﬁer. Version 1 as speciﬁed in Table
A.6 is identiﬁed by a value of 0.
A.4.1.2 Certiﬁcation Authority Reference
The Certiﬁcation Authority Reference is used to identify the public key to be used to verify the signature
of the certiﬁcation authority (CVCA or DV). The Certiﬁcation Authority Reference MUST be equal to
the Certiﬁcate Holder Reference in the corresponding certiﬁcate of the certiﬁcation authority (CVCA
Link Certiﬁcate or DV Certiﬁcate). Details on the Certiﬁcation Authority Reference can be found in
Appendix A.3.1.
A.4.1.3 Public Key
Details on the encoding of public keys can be found in Appendix C.3.
A.4.1.4 Certiﬁcate Holder Reference
The Certiﬁcate Holder Reference is used to identify the public key contained in the certiﬁcate. Details
on the Certiﬁcate Holder Reference can be found in Appendix A.3.1.
A.4.1.5 Certiﬁcate Holder Authorization Template
The role and authorization of the certiﬁcate holder SHALL be encoded in the Certiﬁcate Holder Authorization
Template. This template is a sequence that consists of the following data objects:
1. An object identiﬁer that speciﬁes the format of the template.
2. A discretionary data object that encodes the relative authorization, i.e. the role and authorization
of the certiﬁcate holder relative to the certiﬁcation authority.
Federal Ofﬁce for Information Security 33
Technical Guideline - Extended Access Control
Table A.7: CV Certiﬁcate Request Proﬁle
Data Object Req
Authentication c
CV Certiﬁcate m
Certiﬁcate Body m
Certiﬁcate Proﬁle Identiﬁer m
Certiﬁcation Authority Reference r
Public Key m
Certiﬁcate Holder Reference m
Signature m
Certiﬁcation Authority Reference c
Signature c
For the ePassport application the content and evaluation of the Certiﬁcate Holder Authorization Template
is described in Appendix A.5.
A.4.1.6 Certiﬁcate Effective/Expiration Date
Indicates the validity period of the certiﬁcate. The Certiﬁcate Effective Date MUST be the date of the
certiﬁcate generation.
A.4.1.7 Signature
The signature on the certiﬁcate SHALL be created over the encoded certiﬁcate body (i.e. including tag
and length). The Certiﬁcation Authority Reference SHALL identify the public key to be used to verify
the signature.
A.4.2 Certiﬁcate Requests
Certiﬁcate requests are reduced CV certiﬁcates that may carry an additional signature. The certiﬁcate
request proﬁle speciﬁed in Table A.7 SHALL be used. Details on the encoding of the data objects used
in the certiﬁcate request proﬁle can be found in Appendix C.2.
A.4.2.1 Certiﬁcate Proﬁle Identiﬁer
The version of the proﬁle is identiﬁed by the Certiﬁcate Proﬁle Identiﬁer. Version 1 as speciﬁed in Table
A.7 is identiﬁed by a value of 0.
A.4.2.2 Certiﬁcation Authority Reference
The Certiﬁcation Authority Reference SHOULD be used to inform the certiﬁcation authority about the
private key that is expected by the applicant to be used to sign the certiﬁcate. If the Certiﬁcation Authority
Reference contained in the request deviates from the Certiﬁcation Authority Reference contained
in the issued certiﬁcate (i.e. the issued certiﬁcate is signed by a private key that is not expected by the
applicant), the corresponding certiﬁcate of the certiﬁcation authority SHOULD also be provided to the
applicant in response.
Details on the Certiﬁcation Authority Reference can be found in Appendix A.3.1.
A.4.2.3 Public Key
Details on the encoding of public keys can be found in Appendix C.3.
34 Federal Ofﬁce for Information Security
Technical Guideline - Extended Access Control
A.4.2.4 Certiﬁcate Holder Reference
The Certiﬁcate Holder Reference is used to identify the public key contained in the request and the
resulting certiﬁcate. Details on the Certiﬁcate Holder Reference can be found in Appendix A.3.1.
A.4.2.5 Signature(s)
A certiﬁcate request may have two signatures, an inner signature and an outer signature:
• Inner Signature (REQUIRED)
The certiﬁcate body is self-signed, i.e. the inner signature SHALL be veriﬁable with the public key
contained in the certiﬁcate request. The signature SHALL be created over the encoded certiﬁcate
body (i.e. including tag and length).
• Outer Signature (CONDITIONAL)
– The signature is OPTIONAL if an entity applies for the initial certiﬁcate. In this case the
request MAY be additionally signed by another entity trusted by the receiving certiﬁcation
authority (e.g. the national CVCA may authenticate the request of a DV sent to a foreign
CVCA).
– The signature is REQUIRED if an entity applies for a successive certiﬁcate. In this case
the request MUST be additionally signed by the applicant using a recent key pair previously
registered with the receiving certiﬁcation authority.
If the outer signature is used, an authentication data object SHALL be used to nest the CV Certiﬁcate
(Request), the Certiﬁcation Authority Reference and the additional signature. The Certiﬁcation
Authority Reference SHALL identify the public key to be used to verify the additional
signature. The signature SHALL be created over the concatenation of the encoded CV Certiﬁcate
and the encoded Certiﬁcation Authority Reference (i.e. both including tag and length).
A.4.3 Certiﬁcate Policy
It is RECOMMENDED that each CVCA and every DV publishes a certiﬁcate policy and/or a certiﬁcation
practice statement.
A.4.3.1 Procedures
The certiﬁcate policy SHOULD specify the following procedures:
• Entity identiﬁcation, authentication, and registration.
• Certiﬁcate application, issuance, and distribution.
• Compromise and disaster recovery.
• Auditing.
A.4.3.2 Usage Restrictions
The certiﬁcate policy SHOULD imply restrictions on the devices used to store/process corresponding
private keys and other sensitive (personal) data:
• Physical and operational security.
• Access control mechanisms.
• Evaluation and certiﬁcation (e.g. Common Criteria Protection Proﬁles).
• Data Protection.
Federal Ofﬁce for Information Security 35
Technical Guideline - Extended Access Control
Table A.8: Encoding of Roles and Access Rights
7 6 5 4 3 2 1 0 Description
x x - - - - - - Role
1 1 - - - - - - CVCA
1 0 - - - - - - DV (domestic)
0 1 - - - - - - DV (foreign)
0 0 - - - - - - IS
- - x x x x x x Access Rights
- - 0 0 0 0 - - RFU
- - - - - - 1 - Read access to DG 4 (Iris)
- - - - - - - 1 Read access to DG 3 (Fingerprint)
A.5 Roles and Authorization Levels
The following object identiﬁer SHALL be used to identify roles and authorization levels for EACprotected
ePassports:
id-EAC-ePassport OBJECT IDENTIFIER ::= {
bsi-de applications(3) mrtd(1) roles(2) 1
}
A.5.1 Relative Authorization
The relative authorization of the certiﬁcate holder is encoded in one byte which is to be interpreted as
binary bit map as shown in Table A.8. In more detail, this bit map contains a role and access rights. Both
are relative to the authorization of all previous certiﬁcates in the chain.
A.5.2 Effective Authorization
To determine the effective authorization of a certiﬁcate holder, the MRTD chip MUST calculate a bitwise
Boolean ’and’ of the relative authorization contained in the current certiﬁcate and effective authorization
of the previous certiﬁcate in the chain. As the certiﬁcate chain always starts with a CVCA public key
stored on the MRTD chip, the initial value for the effective authorization is set to the (relative) authorization
of the CVCA stored on the chip.
A.5.3 Access Rights
The effective authorization is to be interpreted by the MRTD chip as follows:
• The effective role is a CVCA:
– This link certiﬁcate was issued by the national CVCA.
– The MRTD chip MUST update its internal trust-point, i.e. the public key and the effective
authorization.
– The certiﬁcate issuer is a trusted source of time and the MRTD chip MUST update its current
date using the Certiﬁcate Effective Date.
– The MRTD chip MUST NOT grant the CVCA extended access to sensitive data (i.e. the
effective access rights SHOULD be ignored).
• The effective role is a DV:
36 Federal Ofﬁce for Information Security
Technical Guideline - Extended Access Control
– The certiﬁcate was issued by the national CVCA for an authorized DV.
– The certiﬁcate issuer is a trusted source of time and the MRTD chip MUST update its current
date using the Certiﬁcate Effective Date.
– The MRTD chip MUST NOT grant a DV extended access to sensitive data (i.e. the effective
access rights SHOULD be ignored).
• The effective role is an IS:
– The certiﬁcate was issued by either a domestic or a foreign DV.
– If the certiﬁcate was issued by a domestic DV, the issuer is a trusted source of time and the
MRTD chip MUST update its current date using the Certiﬁcate Effective Date.
– The MRTD chip MUST grant the authenticated IS extended access to sensitive data according
to the effective access rights.
Federal Ofﬁce for Information Security 37
Technical Guideline - Extended Access Control
Appendix B
ISO 7816 Mapping (Normative)
In this Appendix the protocols for Chip Authentication and Terminal Authentication are mapped to ISO
7816 APDUs (Application Program Data Units) [10].
B.1 Chip Authentication
The following command SHALL be used to implement Chip Authentication: MSE:Set KAT.
B.1.1 MSE:Set KAT
Command
CLA 0x0C Secure Messaging with authenticated header, no chaining
INS 0x22 Manage Security Environment
P1/P2 0x41A6 Set for computation / Key Agreement Template
Data 0x91 Ephemeral Public Key
Ephemeral public key PKPCD (cf. Section A.2) encoded
as plain public key value.
REQUIRED
0x84 Reference of a private key
This data object is REQUIRED if the private key is
ambiguous, i.e. more than one key pair is available for
Chip Authentication (cf. Appendix A.1.1.1 and Appendix
A.2.1).
CONDITIONAL
Response
Data – Absent
Status
Bytes
0x9000 Normal operation
The key agreement operation was successfully performed. New session
keys have been derived.
0x6A80 Incorrect Parameters in the command data ﬁeld
The validation of the ephemeral public key failed. The previously established
session keys remain valid.
other Operating system dependent error
The previously established session keys remain valid.
B.2 Terminal Authentication
The following sequence of commands SHALL be used to implement Terminal Authentication:
1. MSE:Set DST
2. PSO:Verify Certiﬁcate
3. MSE:Set AT
38 Federal Ofﬁce for Information Security
Technical Guideline - Extended Access Control
4. Get Challenge
5. External Authenticate
Steps 1 and 2 are repeated for every CV certiﬁcate to be veriﬁed (CVCA Link Certiﬁcates, DV Certiﬁcate,
IS Certiﬁcate).
B.2.1 MSE:Set DST
Command
CLA 0x0C Secure Messaging with authenticated header, no chaining
INS 0x22 Manage Security Environment
P1/P2 0x81B6 Set for veriﬁcation: Digital Signature Template
Data 0x83 Reference of a public key
ISO 8859-1 encoded name of the public key to be set.
REQUIRED
Response
Data – Absent
Status
Bytes
0x9000 Normal Operation
The key has been selected for the given purpose.
0x6A88 Referenced data not found
The selection failed as the public key is not available
other Operating system dependent error
The key has not been selected.
NOTE: Some operating systems accept the selection of an unavailable public key and return an error
only when the public key is used for the selected purpose.
B.2.2 PSO: Verify Certiﬁcate
Command
CLA 0x0C Secure Messaging with authenticated header, no chaining
INS 0x2A Perform Security Operation
P1/P2 0x00BE Verify self-descriptive certiﬁcate
Data 0x7F4E Certiﬁcate body
The body of the certiﬁcate to be veriﬁed.
REQUIRED
0x5F37 Signature
The signature of the certiﬁcate to be veriﬁed.
REQUIRED
Response
Data – Absent
Status
Bytes
0x9000 Normal operation
The certiﬁcate was successfully validated and the public key has been
imported.
other Operating system dependent error
The public key could not be imported (e.g. the certiﬁcate was not ac-
cepted).
Federal Ofﬁce for Information Security 39
Technical Guideline - Extended Access Control
B.2.3 MSE:Set AT
Command
CLA 0x0C Secure Messaging with authenticated header, no chaining
INS 0x22 Manage Security Environment
P1/P2 0x81A4 Set for external authentication: Authentication Template
Data 0x83 Reference of a public key
ISO 8859-1 encoded name of the public key to be set.
REQUIRED
Response
Data – Absent
Status
Bytes
0x9000 Normal Operation
The key has been selected for the given purpose.
0x6A88 Referenced data not found
The selection failed as the public key is not available
other Operating system dependent error
The key has not been selected.
NOTE: Some operating systems accept the selection of an unavailable public key and return an error
only when the public key is used for the selected purpose.
B.2.4 Get Challenge
Command
CLA 0x0C Secure Messaging with authenticated header, no chaining
INS 0x84 Get Challenge
P1/P2 0x0000
Data – Absent
Le 0x08
Response
Data rPICC 8 bytes of randomness.
Status 0x9000 Normal operation
Bytes other Operating system dependent error
B.2.5 External Authenticate
Command
CLA 0x0C Secure Messaging with authenticated header, no chaining
INS 0x82 External Authenticate
P1/P2 0x0000 Keys and Algorithms implicitly known
Data Signature generated by the inspection system. REQUIRED
Response
Data – Absent
Status
Bytes
0x9000 Normal operation
The authentication was successful. Access to data groups will be granted
according to the effective authorization of the corresponding veriﬁed cer-
tiﬁcate.
other Operating system dependent error
The authentication failed.
40 Federal Ofﬁce for Information Security
Technical Guideline - Extended Access Control
B.3 Secure Messaging
B.3.1 Send Sequence Counter
Only after a successful MSE:Set KAT command Secure Messaging is restarted using the new session
keys derived from the key agreement operation, i.e.
• The old session keys and the old SSC are used to protect the response of the MSE:Set KAT com-
mand.
• The Send Sequence Counter is set to zero (SSC=0).
• The new session keys and the new SSC are used to protect subsequent commands/responses.
B.3.2 Secure Messaging Errors
The MRTD chip MUST abort Secure Messaging if and only if a Secure Messaging error occurs:
• If expected Secure Messaging data objects are missing, the MRTD chip SHALL respond with
status bytes 0x6987.
• If Secure Messaging data objects are incorrect, the MRTD chip SHALL respond with status bytes
0x6988.
If Secure Messaging is aborted, the MRTD chip SHALL delete the session keys and reset the inspection
system’s access rights.
B.4 Reading Data Groups
The APDUs for selecting and reading EAC-protected data groups already speciﬁed by ICAO [5] SHALL
be used (i.e. Select File and Read Binary). In accordance with ICAO speciﬁcations any unauthorized
access to EAC-protected data groups SHALL be denied and the MRTD chip MUST respond with status
bytes 0x6982 (“Security status not satisﬁed”).
B.5 Command Flow
The sequence of ISO 7816 commands required to implement the Advanced Inspection Procedure described
in Section 2.1 is illustrated in Figure B.1. In this example the MRZ (DG1), the facial image
(DG2), and the ﬁngerprints (DG3) are read from the MRTD chip. It is assumed that the LDS application
is already selected and Basic Access Control was successfully performed.
B.6 Extended Length
Depending on the size of the cryptographic objects (e.g. public keys, signatures), APDUs with extended
length ﬁelds MUST be used to send this data to the MRTD chip. For details on extended length see [10].
B.6.1 MRTD Chips
For MRTD chips support of extended length is CONDITIONAL. If the cryptographic algorithms and key
sizes selected by the issuing state require the use of extended length, the MRTD chips SHALL support
extended length. If the MRTD chip supports extended length this MUST be indicated in the ATR/ATS
or in EF.ATR as speciﬁed in [10].
Federal Ofﬁce for Information Security 41
Technical Guideline - Extended Access Control
Read Binary
EF.DG1
Read Binary
EF.DG2
Read Binary
EF.DG3
External
Authenticate
Read Binary
EF.CVCA
Get Challenge
MSE Set
DST
Verify
Certificate
MSE Set
AT
Read Binary
EF.DG14
MSE Set
KAT
Read Binary
EF.SOD
Chip Authentication Terminal Authentication
Biometric Data
Figure B.1: Command Flow
B.6.2 Inspection Systems
For inspection systems support of extended length is REQUIRED. An inspection system SHOULD
examine whether or not support for extended length is indicated in the MRTD chip’s ATR/ATS or in
EF.ATR before using this option. The inspection system MUST NOT use extended length for APDUs
other than the following commands unless the exact input and output buffer sizes of the MRTD chip are
explicitly stated in the ATR/ATS or in EF.ATR.
• PSO:Verify Certiﬁcate
• MSE:Set KAT
• External Authenticate
B.6.3 Errors
The MRTD chip SHALL indicate extended length errors with status bytes 0x6700.
42 Federal Ofﬁce for Information Security
Technical Guideline - Extended Access Control
Appendix C
DER Encoding (Normative)
The Distinguished Encoding Rules (DER) according to X.690 [13] SHALL be used to encode both
ASN.1 data structures and (application speciﬁc) data objects. The encoding results in a Tag-LengthValue
(TLV) structure as follows:
Tag: The tag is encoded in one or two octets and indicates the content.
Length: The length is encoded as unsigned integer in one, two, or three octets resulting in a maximum
length of 65535 octets. The minimum number of octets SHALL be used.
Value: The value is encoded in zero or more octets.
C.1 ASN.1
The encoding of data structures deﬁned in ASN.1 syntax is described in X.690 [13].
C.2 Data Objects
C.2.1 Overview
Table C.1 gives an overview on the tags, lengths, and values of the data objects used in this speciﬁcation.
NOTE: The tag 0x7F4C is not yet deﬁned by ISO/IEC 7816. The allocation is requested.
C.2.2 Encoding of Values
The basic value types used in this speciﬁcation are the following: (unsigned) integers, elliptic curve
points, dates, character strings, octet strings, object identiﬁers, and sequences.
C.2.2.1 Unsigned Integers
All integers used in this speciﬁcation are unsigned integers. An unsigned integer SHALL be converted to
an octet string using the binary representation of the integer in big-endian format. The minimum number
of octets SHALL be used, i.e. leading 0x00 octets MUST NOT be used.
NOTE: In contrast the ASN.1 type INTEGER is always a signed integer.
C.2.2.2 Elliptic Curve Points
The conversion of Elliptic Curve Points to octet strings is speciﬁed in [3]. The uncompressed format
SHALL be used.
Federal Ofﬁce for Information Security 43
Technical Guideline - Extended Access Control
Table C.1: Overview on Data Objects
Name Tag Len Value Comment
Object Identiﬁer 0x06 V Object
Identiﬁer
–
Discretionary Data 0x53 V Octet
String
Contains arbitrary data.
Public Key 0x7F49 V Sequence Nests the public key value and the
domain parameters.
CV Certiﬁcate 0x7F21 V Sequence Nests certiﬁcate body and signature.
Certiﬁcate Body 0x7F4E V Sequence Nests data objects of the certiﬁcate body.
Certiﬁcate Proﬁle
Identiﬁer
0x5F29 1F Unsigned
Integer
Version of the certiﬁcate and certiﬁcate
request format.
Certiﬁcation
Authority Reference
0x42 16V Character
String
Identiﬁes the public key of the issuing
certiﬁcation authority in a certiﬁcate.
Certiﬁcate Holder
Reference
0x5F20 16V Character
String
Associates the public key contained in a
certiﬁcate with an identiﬁer.
Certiﬁcate Holder
Authorization
Template
0x7F4C V Sequence Encodes the role of the certiﬁcate holder
(i.e. CVCA, DV, IS) and assigns
read/write access rights to data groups
storing sensitive data.
Certiﬁcate Effective
Date
0x5F25 6F Date The date of the certiﬁcate generation.
Certiﬁcate
Expiration Date
0x5F24 6F Date The date after which the certiﬁcate
expires.
Signature 0x5F37 V Octet
String
Digital signature produced by an
asymmetric cryptographic algorithm.
Authentication 0x67 V Sequence Nests certiﬁcate request with additional
authentication data.
F: ﬁxed length (exact number of octets), V: variable length (up to number of octets)
C.2.2.3 Dates
A date is encoded in 6 digits d1 ···d6 in the format YYMMDD using timezone GMT. It is converted to
an octet string o1 ···o6 by encoding each digit dj to an octet oj as unpacked BCDs (1 ≤ j ≤ 6).
NOTE: The year YY is encoded in two digits and to be interpreted as 20YY, i.e. the year is in the
range of 2000 to 2099.
C.2.2.4 Character Strings
A character string c1 ···cn is a concatenation of n characters cj with 1 ≤ j ≤ n. It SHALL be converted to
an octet string o1 ···on by converting each character cj to an octet oj using the ISO/IEC 8859-1 character
set. For informational purposes the character set can be found in Table C.3.
NOTE: The character codes 0x00-0x1F and 0x7F-0x9F are unassigned and MUST NOT be used. The
conversion of an octet to an unassigned character SHALL result in an error.
44 Federal Ofﬁce for Information Security
Technical Guideline - Extended Access Control
Table C.3: ISO/IEC 8859-1 Character Set
Code 0 1 2 3 4 5 6 7 8 9 A B C D E F
0
1
2 SP ! " # $ % & ’ ( ) * + , - . /
3 0 1 2 3 4 5 6 7 8 9 : ; < = > ?
4 @ A B C D E F G H I J K L M N O
5 P Q R S T U V W X Y Z [ \ ] ^ _
6 ‘ a b c d e f g h i j k l m n o
7 p q r s t u v w x y z { | } ~
8
9
A NBSP ¡ ¢ £ ¤ ¥ ¦ § ¨ © ª « ¬ SHY ® ¯
B ° ± ² ³ ´ µ ¶ · ¸ ¹ º » ¼ ½ ¾ ¿
C À Á Â Ã Ä Å Æ Ç È É Ê Ë Ì Í Î Ï
D Ð Ñ Ò Ó Ô Õ Ö × Ø Ù Ú Û Ü Ý Þ ß
E à á â ã ä å æ ç è é ê ë ì í î ï
F ð ñ ò ó ô õ ö ÷ ø ù ú û ü ý þ ÿ
SP: Space, NBSP: Non-breaking Space, SHY: Soft Hyphen
C.2.2.5 Octet Strings
An octet string o1 ···on is a concatenation of n octets oj with 1 ≤ j ≤ n. Every octet oj consists of 8 bits.
C.2.2.6 Object Identiﬁers
An object identiﬁer i1.i2.··· .in is an ordered list of n unsigned integers ij with 1 ≤ j ≤ n. It SHALL be
converted to an octet string o1 ···on−1 using the following procedure:
1. The ﬁrst two integers i1 and i2 are packed into a single integer i that is then converted to the octet
string o1. The value i is calculated as follows:
i = i1 ·40+i2
2. The remaining integers ij are directly converted to octet strings oj−1 with 3 ≤ j ≤ n.
More details on the encoding can be found in [13].
C.2.2.7 Sequences
A sequence D1 ···Dn is an ordered list of n data objects Dj with 1 ≤ j ≤ n. The sequence SHALL be
converted to a concatenated list of octet strings O1 ···On by DER encoding each data object Dj to an
octet string Oj.
C.3 Public Key Data Objects
A public key data object is a sequence consisting of an object identiﬁer and several context speciﬁc data
objects:
• The object identiﬁer is application speciﬁc and refers not only to the public key format (i.e. the
context speciﬁc data objects) but also to its usage.
Federal Ofﬁce for Information Security 45
Technical Guideline - Extended Access Control
Table C.4: RSA Public Key
Data Object Tag Type CV Certiﬁcate
Object Identiﬁer 0x06 Object Identiﬁer m
Composite modulus n 0x81 Unsigned Integer m
Public exponent e 0x82 Unsigned Integer m
Table C.5: ECDSA Public Key
Data Object Tag Type CV Certiﬁcate
Object Identiﬁer 0x06 Object Identiﬁer m
Prime modulus p 0x81 Unsigned Integer o
First coefﬁcient a 0x82 Unsigned Integer o
Second coefﬁcient b 0x83 Unsigned Integer o
Base point G 0x84 Elliptic Curve Point o
Order of the base point r 0x85 Unsigned Integer o
Public Point Y 0x86 Elliptic Curve Point m
Cofactor f 0x87 Unsigned Integer o
• The context speciﬁc data objects are deﬁned by the object identiﬁer and contain the public key
value and the domain parameters.
The format of public keys data objects used in this speciﬁcation is described below.
NOTE: Ephemeral public keys are only used in the MSE:Set KAT command (cf. Appendix B.1.1). As
the public key format and the domain parameters are already known, only the plain public key
value, i.e. only the context speciﬁc data object 0x91, is used to convey the ephemeral public key.
C.3.1 RSA Public Keys
The data objects contained in an RSA public key are shown in Table C.4. The order of the data objects
is ﬁxed.
C.3.2 ECDSA Public Keys
The data objects contained in an ECDSA public key are shown in Table C.5. The order of the data objects
is ﬁxed, OPTIONAL domain parameters MUST be either all present or all absent as follows:
• CVCA Link Certiﬁcates MAY contain domain parameters.
• DV and IS Certiﬁcates MUST NOT contain domain parameters. The domain parameters of DV
and IS public keys SHALL be inherited from the respective CVCA public key.
• Certiﬁcate Requests MUST always contain domain parameters.
C.3.3 Ephemeral DH Public Keys
An ephemeral DH public key is an unsigned integer y contained in a context speciﬁc data object 0x91.
C.3.4 Ephemeral ECDH Public Keys
An ephemeral ECDH public key is an elliptic curve point Y contained in a context speciﬁc data object
0x91.
46 Federal Ofﬁce for Information Security
Technical Guideline - Extended Access Control
Appendix D
Worked Examples (Informative)
This appendix provides worked examples for data structures (DG14 and CV certiﬁcates) deﬁned by this
speciﬁcation.
NOTE: All numbers contained in the examples below are hexadecimal unless the notation is selfevident
or explicitly stated.
D.1 Data Group 14
This section provides two examples for DG14. The ﬁrst example is based on Elliptic Curve Difﬁe
Hellman and the second example is based on Difﬁe Hellman.
D.1.1 ECDH-based Example
The hexdump of the encoded DG14 can be found in Figure D.1. The hexdump of the corresponding
private key can be found in Figure D.2 at the end of the section.
Figure D.1: DG14 (ECDH)
0000 : 6E82014A 31820146 30820122 06090400 7F000702 02010230 82011330 81D40607
0020 : 2A8648CE 3D020130 81C80201 01302806 072A8648 CE3D0101 021D00D7 C134AA26
0040 : 4366862A 18302575 D1D787B0 9F075797 DA89F57E C8C0FF30 3C041C68 A5E62CA9
0060 : CE6C1C29 9803A6C1 530B514E 182AD8B0 042A59CA D29F4304 1C2580F6 3CCFE441
0080 : 38870713 B1A92369 E33E2135 D266DBB3 72386C40 0B043904 0D9029AD 2C7E5CF4
00A0 : 340823B2 A87DC68C 9E4CE317 4C1E6EFD EE12C07D 58AA56F7 72C0726F 24C6B89E
00C0 : 4ECDAC24 354B9E99 CAA3F6D3 761402CD 021D00D7 C134AA26 4366862A 18302575
00E0 : D0FB98D1 16BC4B6D DEBCA3A5 A7939F02 0101033A 0004680E C4FF3851 12D9A401
0100 : 76D36733 157B11FC 08B4A280 CE9B8246 4D765C38 C21CB883 6EE05724 3C1EBC7B
0120 : B80EC484 41107C38 E4F545EB 213C300F 060A0400 7F000702 02030201 02010130
0140 : 0D060804 007F0007 02020202 0101........................................
D.1.1.1 General Structure
The general structure of the worked example is examined in the following table. Details on
the encoding in the AlgorithmIdentifier and the SubjectPublicKey contained in the
SubjectPublicKeyInfo are given in the subsequent sections.
Federal Ofﬁce for Information Security 47
Technical Guideline - Extended Access Control
Tag Length Value ASN.1 Type Comment
6E 82 01 4A - Application speciﬁc tag “14”
31 82 01 46 SET Set of SecurityInfos
30 82 01 22 SEQUENCE SecurityInfo
06 09 04 00 7F 00 07 OBJECT ChipAuthenticationPublicKeyInfo
02 02 01 02 IDENTIFIER CA with ECDH
30 82 01 13 SEQUENCE SubjectPublicKeyInfo
30 81 D4 see below SEQUENCE AlgorithmIdentiﬁer
03 3A see below BIT STRING SubjectPublicKey
– – – optional keyId is unused
30 0F SEQUENCE SecurityInfo
06 0A 04 00 7F 00 07 OBJECT ChipAuthenticationInfo
02 02 03 02 01 IDENTIFIER CA with ECDH
02 01 01 INTEGER Version 1
– – – optional keyId is unused
30 0D SEQUENCE SecurityInfo
06 08 04 00 7F 00 07 OBJECT TerminalAuthenticationInfo
02 02 02 IDENTIFIER
02 01 01 INTEGER Version 1
– – – optional FileID is unused
D.1.1.2 Encoding of the AlgorithmIdentiﬁer
The AlgorithmIdentifier is not only used to identify the type of public key contained in the
SubjectPublicKeyInfo but does also contain the domain parameters to be used. The encoding of
the group generator as part of the domain parameter can be found in Section D.1.1.3.
Tag Length Value ASN.1 Type Comment
30 81 D4 SEQUENCE AlgorithmIdentiﬁer
06 07 2A 86 48 CE OBJECT Elliptic Curve Public Key
3D 02 01 IDENTIFIER
30 81 C8 SEQUENCE Domain parameter
02 01 01 INTEGER Version
30 28 SEQUENCE Underlying ﬁeld
06 07 2A 86 48 CE OBJECT Prime ﬁeld
3D 01 01 IDENTIFIER
02 1D 00 D7 C1 ... INTEGER Prime p
C8 C0 FF
30 3C SEQUENCE Curve equation
04 1C 68 A5 E6 ... OCTET Parameter a
D2 9F 43 STRING
04 1C 25 80 F6 ... OCTET Parameter b
6C 40 0B STRING
– – – Optional seed is unused
04 39 see below OCTET Group generator G
STRING
02 1D 00 D7 C1 ... INTEGER Group order n
A7 93 9F
02 01 01 INTEGER Cofactor f
D.1.1.3 Encoding of Elliptic Curve Points
The group generator as part of the elliptic curve domain parameters and the public key are both points
on an elliptic curve. According to [3] elliptic curve points are not speciﬁed as ASN.1 data structures.
48 Federal Ofﬁce for Information Security
Technical Guideline - Extended Access Control
Encoding of the Group Generator: The group generator is part of the elliptic curve domain parameters
contained in the AlgorithmIdentifier. The encoded elliptic curve point is embedded in an
OCTET STRING.
Tag Length Value ASN.1 Type Comment
04 39 OCTET Encoded group generator
STRING
04 – Uncompressed point
0D 90 29 ... – x-coordinate
12 C0 7D
58 AA 56 ... – y-coordinate
14 02 CD
Encoding of the SubjectPublicKey: The public key contained in the SubjectPublicKeyInfo is
an elliptic curve point embedded in a BIT STRING.
Tag Length Value ASN.1 Type Comment
03 3A BIT STRING Encoded public key
00 Number of unused bits
04 – Uncompressed point
68 0E C4 ... – x-coordinate
46 4D 76
5C 38 C2 ... – y-coordinate
EB 21 3C
D.1.1.4 Session Key Generation
The following table shows the ephemeral key pair randomly chosen by the inspection system and the
shared secret resulting from the key agreement. The domain parameters are omitted.
Private Key 7756F0C5 D1AB06C0 03672668 2B720C2F B1D5F789 B58244A6 DC07E5A2
Public Key 69D489F6 8A99ABC8 7106B3E1 3A52C6AF 2C57CEE5 72755FE3 712C8AC3,
8A6A3E9F E0694482 31BDC1BE FC826035 67E72602 EBA5C3EE EEAC3F15
Shared Secret A770F66A CC78ED59 0581CC82 033C79F3 3BECE0A2 0C280244 79A4E97C
Using the ICAO KDF the following two 3DES session keys are derived from the shared secret. The
parity bits are not adjusted.
KEnc 61915BEE D2FA715E CFEC8390 A77AA2F3
KMAC 1A72218D E5B4A2CA 3F6374B8 08AC37C4
D.1.1.5 Hashed Ephemeral Public Key
For ECDH the MRTD chip stores the x-coordinate of the ephemeral public key received from the inspection
system.
H(PKPCD) 69D489F6 8A99ABC8 7106B3E1 3A52C6AF 2C57CEE5 72755FE3 712C8AC3
Figure D.2: Chip Authentication Private Key (ECDH)
0000 : 12528622 D8947E85 E4988853 69ECDCAB F10E343A F7B95A99 DF610031
Federal Ofﬁce for Information Security 49
Technical Guideline - Extended Access Control
D.1.2 DH-based Example
The hexdump of the encoded DG14 is shown in Figure D.3. The corresponding private key can be found
in Figure D.4 at the end of this section.
Figure D.3: DG14 (DH)
0000 : 6E8201DC 318201D8 308201B4 06090400 7F000702 02010130 8201A530 82011A06
0020 : 092A8648 86F70D01 03013082 010B0281 8100DCB5 54DF8C69 31E865C1 B588273D
0040 : 80A2D87A B539C5E4 A074B402 49FF655A 9AB83063 3B457C4C F885E31C D79F8114
0060 : 8C8A68D1 DBFC2F7B 70ED55C0 387C23A0 479A9572 E8A6714F 418A6BF9 B00EC5BC
0080 : 4DEF255A 9485058A 4271008B A694AA62 CC18385E F9D7B6E8 33A7088A C817AA1F
00A0 : 9B93A86B 983EAB73 C15884E7 33665659 CA7D0281 802E69FE 94D3C0A4 378C8A47
00C0 : 9D83091A ED419234 25C10300 8C6AB3F6 E83E20CB 16C4AE0B 0E28ED9B C79CD7D7
00E0 : E9DFD39D D0A39141 F2DD5714 9AB688DB AD177C68 6F771828 E5A04408 512F1564
0100 : 74B0BFD4 30CBBF91 C01589E7 21DDDFFC DF450043 EB771E61 084C597F 7AEA9048
0120 : 420A2180 EBFEC1B3 B93C1A6C B1AD38B3 984FF052 10020203 F9038184 00028180
0140 : 553CE735 ECF5CBF2 029D30FA A4F97335 DF404047 E4F8586D 76A7D221 A09E7F55
0160 : BBE255C6 587BF288 5D41B786 BCEF2177 D52BF3CD BA785D37 D70B88D6 AB4E1CA6
0180 : 6A63B601 1376ED44 444A662B D0DC9524 176E9712 87AD41D2 9BED3D35 EAC7D39C
01A0 : A73ECB2A 3B4D3967 1CE4125C 92658C5B F3DEDA91 5ED71B88 FC031BAB 887248A1
01C0 : 300F060A 04007F00 07020203 01010201 01300D06 0804007F 00070202 02020101
D.1.2.1 General Structure
The general structure of the second worked example is examined in the following table. Details
on the encoding of the AlgorithmIdentifier and the SubjectPublicKey contained in the
SubjectPublicKeyInfo are given in the following sections.
Tag Length Value ASN.1 Type Comment
6E 82 01 DC - Application speciﬁc tag “14”
31 82 01 D8 SET Set of SecurityInfos
30 82 01 B4 SEQUENCE SecurityInfo
06 09 04 00 7F 00 07 OBJECT ChipAuthenticationPublicKeyInfo
02 02 01 01 IDENTIFIER CA with DH
30 82 01 A5 SEQUENCE SubjectPublicKeyInfo
30 82 01 1A see below SEQUENCE AlgorithmIdentiﬁer
03 81 84 see below BIT STRING SubjectPublicKey
– – – – optional keyId unused
30 0F SEQUENCE SecurityInfo
06 0A 04 00 7F 00 07 OBJECT ChipAuthenticationInfo
02 02 03 01 01 IDENTIFIER CA with DH
02 01 01 INTEGER Version 1
– – – optional keyId unused
30 0D SEQUENCE SecurityInfo
06 08 04 00 7F 00 07 OBJECT TerminalAuthenticationInfo
02 02 02 IDENTIFIER
02 01 01 INTEGER Version 1
– – – optional FileID is unused
50 Federal Ofﬁce for Information Security
Technical Guideline - Extended Access Control
D.1.2.2 Encoding of the AlgorithmIdentiﬁer
The AlgorithmIdentifier is not only used to identify the type of public key contained in the
SubjectPublicKeyInfo but does also contain the domain parameters to be used.
Tag Length Value ASN.1 Type Comment
30 82 01 1A SEQUENCE AlgorithmIdentiﬁer
06 09 2A 86 48 86 F7 OBJECT PKCS#3
0D 01 03 01 IDENTIFIER dhKeyAgreement
30 82 01 0B SEQUENCE Domain parameter
02 81 81 00 DC B5 ... INTEGER Prime p
59 CA 7D
02 81 80 2E 69 FE ... INTEGER Group generator g
F0 52 10
02 02 03 F9 INTEGER Private key length
D.1.2.3 Encoding of the SubjectPublicKey
The public key contained in the SubjectPublicKey is a DER encoded INTEGER embedded in a
BIT STRING. In the example below the value of the BIT STRING is decoded. The decoded structure is
put in brackets.
Tag Length Value ASN.1 Type Comment
03 81 84 BIT STRING Encoded public key
00 Number of unused bits
(02) (81 80) (55 3C E7 ... (INTEGER) Public key
72 48 A1)
D.1.2.4 Session Key Generation
The following table shows the ephemeral key pair randomly chosen by the inspection system and the
shared secret resulting from the key agreement. The domain parameters are omitted.
Private 0170A377 AA4B612B 69A6762E CD71A91C 3D7CD149 A870F37F 357A196F F1134BF7
Key E0B33DDC EC645560 54EA9959 23189BDB 3893656F E05F8DAB E67F8998 3799E16F
9BF7A9CA 8050C949 31BAB4D8 CAA5F84B 33D71ACA 77A817CB C44CA92C 4B8960A2
034FBC31 999E7DEE 025E1001 EAF96113 BD06EFED FBBD5F2E 916ADC73 1971F019
Public 8EBC4457 EABBEF83 65D6EF83 9A1A3672 449486B2 779EF88E B0198ADD C64A096B
Key 0AFC3C26 4D64EDFD F543C03B AEC7ED5D 58C2F2A1 4B63BB5D 280E62FE CAC0A6DD
F255CEB9 2AB51C0D B672A251 68934F86 7B95552A 189A3244 4AF890B7 7509ED92
EC5A81A7 D787F5F5 51B37EB2 FA3A49C7 787B5F61 3527649C 151C1786 8417E9CA
Shared C30AAE5F DC23EFF6 E477734A C318D32D F128AF25 2542087F 1FA239DD 3734DE5C
Secret C7E154ED 93BDEC78 E87CD691 6307976F B2603425 133A61D4 10F7F050 EA0797B3
59A5009F 20C9BF0D 227C8866 B2C701FB 04ADF646 B138B1D6 D2623C17 AB3A910A
5A2C72E6 2B554B3F B5B2C310 A1F3334E D4C6AA77 919EA912 5A147C64 9C9E6556
Using the ICAO KDF the following two 3DES session keys are derived from the shared secret. The
parity bits are not adjusted.
KEnc EFF63AC6 29184F19 99C69B7C 3BFA4F17
KMAC 7AD463F3 6997CB2B CB3D1B88 2CE8E4A7
D.1.2.5 Hashed Ephemeral Public Key
For DH the MRTD chip stores the SHA-1 hash of the ephemeral public key received from the inspection
system.
H(PKPCD) 97D9AC36 0DCA6BB0 F2699B85 2DE37793 C29458CD
Federal Ofﬁce for Information Security 51
Technical Guideline - Extended Access Control
Figure D.4: Chip Authentication Private Key (DH)
0000 : 01CD4A70 FFDC3D42 C862FD5E 3D781EB6 DE97677B 4FF61319 242E1499 B5CD1908
0020 : A9B54221 135D1EDB AD787A5C E37586CF E86A61C4 78187157 267C97B4 0A7F2727
0040 : B9B92FAC EC267CC0 1C883FA3 783BA07D C090EE04 99C9CE88 C684C874 0FEB84F4
0060 : 49B0F544 C1747716 46BDB7A3 0B0E3AB5 6C655F0E 83A98A4B A99EB9F1 0B0C0FBF
D.2 Card Veriﬁable Certiﬁcates
This section provides two examples for CV certiﬁcates. Both examples are self-signed CVCA certiﬁcates.
The ﬁrst example is based on ECDSA and the second example is based on RSA.
D.2.1 Example 1: CVCA Certiﬁcate with ECDSA
The hexdump of the encoded certiﬁcate can be found in Figure D.5. The hexdump of the corresponding
private key can be found in Figure D.6 at the end of the section.
Figure D.5: CVCA Certiﬁcate (ECDSA)
0000: 7F218201 8D7F4E82 014D5F29 01004210 44454356 43414550 41535330 30303031
0020: 7F4981FD 060A0400 7F000702 02020202 811CD7C1 34AA2643 66862A18 302575D1
0040: D787B09F 075797DA 89F57EC8 C0FF821C 68A5E62C A9CE6C1C 299803A6 C1530B51
0060: 4E182AD8 B0042A59 CAD29F43 831C2580 F63CCFE4 41388707 13B1A923 69E33E21
0080: 35D266DB B372386C 400B8439 040D9029 AD2C7E5C F4340823 B2A87DC6 8C9E4CE3
00A0: 174C1E6E FDEE12C0 7D58AA56 F772C072 6F24C6B8 9E4ECDAC 24354B9E 99CAA3F6
00C0: D3761402 CD851CD7 C134AA26 4366862A 18302575 D0FB98D1 16BC4B6D DEBCA3A5
00E0: A7939F86 3904AE54 D71E532C 16D3CCE8 54DD1298 D1068F70 BD2C0F68 E62A32BC
0100: D87BA20E 7534683D 1ED8B94D E64A6E5A 63277FAD 738EA907 C5049B99 7B018701
0120: 015F2010 44454356 43414550 41535330 30303031 7F4C0E06 0904007F 00070301
0140: 02015301 C35F2506 00070004 00015F24 06000900 0303015F 37381DAF 7AA198B9
0160: 48A6DFB6 26BDDDAD 3C0343AB D1F1049C 4CA1B098 21C77A5A 3BBB18A5 D2F6D9AF
0180: 0A2463B4 C137287B AFF19DB8 684C1441 989F...............................
D.2.1.1 General Structure
The general structure of the ﬁrst worked example is examined in the following table. Details on the
encoding of the public key and the Certiﬁcate Holder Authorization Template are given in the following
sections.
Tag Length Value Comment
7F 21 82 01 8D CV Certiﬁcate
7F 4E 82 01 4D Certiﬁcate Body
5F 29 01 00 Certiﬁcate Proﬁle Identiﬁer
42 10 44 45 43 ... Certiﬁcation Authority Reference:
30 30 31 DECVCAEPASS00001
7F 49 81 FD see below Public key
5F 20 10 44 45 43 ... Certiﬁcate Holder Reference:
30 30 31 DECVCAEPASS00001
7F 4C 0E see below Certiﬁcate Holder Authorization Template
5F 25 06 00 07 00 Certiﬁcate Effective Date:
04 00 01 2007-APR-01
5F 24 06 00 09 00 Certiﬁcate Expiration Date:
03 03 01 2009-MAR-31
52 Federal Ofﬁce for Information Security
Technical Guideline - Extended Access Control
Tag Length Value Comment
5F 37 38 see below Digital Signature: ECDSA in Plain Format
D.2.1.2 Public Key
The encoding of the public key and the domain parameters contained in the certiﬁcate is explained in the
following table. The corresponding private key is shown in Figure D.6.
Figure D.6: CVCA Private Key (ECDSA)
0000 : 73D03A00 E3A51A20 2F61DEE3 8806758D 25961643 C312C89C 852164AB
Tag Length Value Comment
7F 49 81 FD Public key
06 0A 04 00 7F ... Terminal Authentication with ECDSA-SHA-224
02 02 02
81 1C D7 C1 34 ... Prime modulus p
C8 C0 FF
82 1C 68 A5 E6 ... First coefﬁcient a
D2 9F 43
83 1C 25 80 F6 ... Second coefﬁcient b
6C 40 0B
84 39 04 0D 90 ... Base point G
14 02 CD
85 1C D7 C1 34 ... Order of the base point r
A7 93 9F
86 39 04 AE 54 ... Public point Y
99 7B 01
87 01 01 Cofactor f
D.2.1.3 Certiﬁcate Holder Authorization Template
The discretionary data object contained in the CHAT identiﬁes a CVCA that allows read access to DG3
and DG4.
Tag Length Value Comment
7F 4C 0E Certiﬁcate Holder Authorization Template
06 09 04 00 7F ... Extended Access Control for ePassports
01 02 01
53 01 C3 CVCA granting access to DG3 and DG4
D.2.1.4 ECDSA Plain Signature
According to [3] ECDSA signatures in plain format are speciﬁed as direct concatenation of two octet
strings R||S. For ECDSA-224, each octet string has length 28 (decimal).
R 1DAF7AA1 98B948A6 DFB626BD DDAD3C03 43ABD1F1 049C4CA1 B09821C7
S 7A5A3BBB 18A5D2F6 D9AF0A24 63B4C137 287BAFF1 9DB8684C 1441989F
NOTE: The X9.62 signature format based on ASN.1 MUST NOT be used.
D.2.2 Example 2: CVCA Certiﬁcate with RSA
The hexdump of the encoded certiﬁcate can be found in Figure D.7. The hexdump of the corresponding
private key can be found in Figure D.8 at the end of the section.
Federal Ofﬁce for Information Security 53
Technical Guideline - Extended Access Control
Figure D.7: CVCA Certiﬁcate (RSA)
0000: 7F218202 6E7F4E82 01645F29 01004210 44454356 43414550 41535330 30303031
0020: 7F498201 13060A04 007F0007 02020201 02818201 00B0010B 3897E9B0 EF24E195
0040: CC4CB6E7 3B4DD1C0 34DFC89C 965E84DA FD152B6F 20BCC094 53DAFBD1 E108FC1E
0060: 42F76110 CCCCCB9B E2B9AFB0 8A63E0EE F2C72B79 0F4C14CA 19538F1F 4AFDA4B6
0080: 247F3CD6 131BDA07 30B369C3 35BAE265 308C81C8 10E98C23 7E1370FE B05AA036
00A0: 6AFBE16E 51E5333D 771983DE 58BE9659 6857A950 2D567BF0 8B6B270C CDFCFCAF
00C0: 7A69BDFE B23DB2E2 D7D1ABEC 8C622EB1 A93FFD3E 110828AC 96DCE746 E4BBB280
00E0: 5C62A2DC 3BD02B78 A04AC823 18F498BF 6F1F5152 3FCBC6E7 486A3021 70A86BC7
0100: 40448BB9 FB277979 1B2B0D75 0DFF57A2 DA38697A 9A57BC26 1FD9A4DA 7097BD8F
0120: FD2FC11F 799C40B0 4BC52683 C3D8A936 92EE2019 1F820111 5F201044 45435643
0140: 41455041 53533030 3030317F 4C0E0609 04007F00 07030102 015301C3 5F250600
0160: 07000400 015F2406 00090003 03015F37 8201008F CD777994 4F38213A 97361B4F
0180: 5A601778 C0F47FE6 CDB1042D 1C406E2A 02450357 122AE61E 8B2F138C 243532F8
01A0: 00DAA5F0 4448901B 1C51F73B 888970CB 8906A429 C5BCBDA5 A50AED7C C747E826
01C0: 5AE4BCA1 2711E90D C7AC4B41 32ADB63B CFB2988C 8D8A7C64 FA75CD43 995E63B5
01E0: 3FD0F2A4 193A6F58 BF87D368 C412F37A C56092FD AA81DB51 B742FE52 03B78ADD
0200: 75CC86BE 68B52393 0B4E05E9 81523E45 FED99079 38A4C8DE 20426DCE 62A2EA01
0220: C728C251 DC1A3EA4 B7DD4907 C7A0B211 90E0F6FF EF6F196D E5F87E07 8B0B52C8
0240: BFECC23E 75E327DF AE96AADF 4D2BFB35 229790ED 74423F3B A47FE34B 199799B0
0260: 19D6705C 1F1E925F 67892E9F D8BFD0F8 BAD26D.............................
D.2.2.1 General Structure
The general structure of the second worked example is examined in the following table. Details on the
encoding of the public key are given in the following section. The encoding of the Certiﬁcate Holder
Authorization Template is described in Appendix D.2.1.3.
Tag Length Value Comment
7F 21 82 02 6E CV Certiﬁcate
7F 4E 82 01 64 Certiﬁcate Body
5F 29 01 00 Certiﬁcate Proﬁle Identiﬁer
42 10 44 45 43 ... Certiﬁcation Authority Reference:
30 30 31 DECVCAEPASS00001
7F 49 82 01 13 see below Public key
5F 20 0E 44 45 43 ... Certiﬁcate Holder Reference:
30 30 31 DECVCAEPASS001
7F 4C 0E see above Certiﬁcate Holder Authorization Template
5F 25 06 00 07 00 Certiﬁcate Effective Date:
04 00 01 2007-APR-01
5F 24 06 00 09 00 Certiﬁcate Expiration Date:
03 03 01 2009-MAR-31
5F 37 82 01 00 8F CD 77 ... Digital Signature: RSA PKCS#1 version 1.5
BA D2 6D
D.2.2.2 Public Key
The encoding of the public key and the domain parameters contained in the certiﬁcate is explained in the
following table. The corresponding private key (private exponent d) is show in Figure D.8.
54 Federal Ofﬁce for Information Security
Technical Guideline - Extended Access Control
Figure D.8: CVCA Private Key (RSA)
0000 : 0F879F1B 94EEF906 0AC89C46 BB798CDF 95ECDC40 E691B376 ADFCA9E9 2783D519
0020 : 7A10FE07 66254739 80CAF39C 7F3D453F 3F3F2457 C517080C 35FD4242 991A6C90
0040 : 68986C2F 69415595 ACF7F1F4 29583101 AFA24BED B57A45EE 2713F9DE A2FC6479
0060 : F67D4E6D 01B72588 07FF13DC 4366B6E9 1BC0C1A8 A05E7580 4D0D441F CB7FE16D
0080 : 43FA92AD D80684D7 EBC3023A 9A9197A9 F207134C 0CBE4A9F EFE2F02D B36867B1
00A0 : 478A3742 6F11764A 9E558AAC 3A8A2C7D EDA2DE2A D266BEC6 BD6E8586 7497A340
00C0 : FCE480F1 852BD0CB CAF27AB4 3E9866F8 93C033E7 EAC8FC1D 68AD0AF4 77614EA6
00E0 : EAAF3978 C93B4A97 877D87BD 0E705204 A9B7C663 54A03FD3 8E506D39 66289A95
Tag Length Value Comment
7F 49 82 01 13 Public key
06 0A 04 00 7F ... Terminal Authentication with RSA-v1-5-SHA-256
02 01 02
81 82 01 00 B0 01 0B ... Composite Modulus n
20 19 1F
82 01 11 Exponent e
D.3 Encoding of the Document Number
The MRTD chip’s document number is used as IDPICC in Terminal Authentication. Let the document
number be “123456789”, thus, the check digit is “7”. The corresponding Octet String to be used in
Terminal Authentication is 31323334353637383937.
Federal Ofﬁce for Information Security 55
Technical Guideline - Extended Access Control
Appendix E
Basic Access Control (Informative)
The protocol for Basic Access Control is speciﬁed by ICAO [5]. Basic Access Control checks that
the inspection system has physical access to the MRTD’s data page. This is enforced by requiring
the inspection system to derive an authentication key from the optically read MRZ of the MRTD. The
protocol for Basic Access Control is based on ISO/IEC 11770-2 [6] key establishment mechanism 6. This
protocol is also used to generate session keys that are used to protect the conﬁdentiality (and integrity)
of the transmitted data.
E.1 Document Basic Access Keys
The Document Basic Access Keys KBEnc and KBMAC stored on the RF-chip in secure memory, have
to be derived by the inspection system from the MRZ of the MRTD prior to accessing the RF-chip.
Therefore, the inspection system optically reads the MRZ and generates the Document Basic Access
Keys by applying the ICAO KDF [5] to the most signiﬁcant 16 bytes of the SHA-1 [15] hash of some
ﬁelds of the MRZ. As reading the MRZ optically is error-prone, only the ﬁelds protected by a check-digit
are used to generate the Basic Access Key(s): Document Number, Date of Birth, and Date of Expiry. As
a consequence the resulting authentication key has a relatively low entropy. The actual entropy mainly
depends on the type of the Document Number. For 10 year valid travel document the maximum strength
of the authentication key is approximately:
• 56 Bit for a numeric Document Number (3652 ·1012 possibilities)
• 73 Bit for an alphanumeric Document Number (3652 ·369 ·103 possibilities)
NOTE: Especially in the second case this estimation requires the Document Number to be randomly
and uniformly chosen. Depending on the knowledge of the attacker, the actual entropy of the
Document Basic Access Key may be lower, e.g. if the attacker knows all Document Numbers in
use or is able to correlate Document Numbers and Dates of Expiry.
Given that in the ﬁrst case the maximum entropy (56 Bit) is relatively low, calculating the authentication
key from an eavesdropped session is possible. On the other hand, this still requires more effort than
to obtain the same (less-sensitive) data from another source.
E.2 Protocol Speciﬁcation
Basic Access Control is shown in Figure E.1. For better readability encryption and message authentication
are combined into a single authenticated encryption primitive
EK(S) = EKBEnc
(S)||MACKMAC (EKBEnc
(S)),
where K = {KBEnc,KBMAC}.
1. The MRTD chip sends the nonce rPICC to the inspection system.
56 Federal Ofﬁce for Information Security
Technical Guideline - Extended Access Control
MRTD Chip (PICC) Inspection System (PCD)
read MRZ optically and derive K
choose rPICC and KPICC randomly choose rPCD and KPCD randomly
rPICC
−−−→
ePCD
←−− ePCD = EK(rPCD||rPICC||KPCD)
rPCD||rPICC||KPCD = DK(ePCD)
check rPICC = rPICC
ePICC = EK(rPICC||rPCD||KPICC)
ePICC
−−−→
rPICC||rPCD||KPICC = DK(ePICC)
check rPCD = rPCD
Figure E.1: Basic Access Control
2. The inspection system sends the encrypted challenge
ePCD = EK(rPCD||rPICC||KPCD)
to the MRTD chip, where rPICC is the MRTD chip’s nonce, rPCD is the inspection system’s randomly
chosen nonce, and KPCD is keying material for the generation of the session keys.
3. The MRTD chip performs the following actions:
a) It decrypts the received challenge to rPCD||rPICC||KPCD = DK(ePCD) and veriﬁes that rPICC =
rPICC.
b) It responds with the encrypted challenge ePICC = EK(rPICC||rPCD||KPICC), where rPICC is the
MRTD chip’s randomly chosen nonce and KPICC is keying material for the generation of the
session keys.
4. The inspection system decrypts the encrypted challenge to rPICC||rPCD||KPICC = DK(ePICC) and
veriﬁes that rPCD = rPCD.
After a successful authentication all further communication MUST be protected by Secure Messaging
in Encrypt-then-Authenticate mode using session keys KEnc and KMAC derived according to [5] from the
common master secret KMaster = KPICC ⊕ KPCD and a Send Sequence Counter SSC derived from rPICC
and rPCD.
Federal Ofﬁce for Information Security 57
Technical Guideline - Extended Access Control
Appendix F
Challenge Semantics (Informative)
Consider a signature based challenge-response protocol between an MRTD chip (PICC) and an inspection
system (PCD), where the MRTD chip wants to prove knowledge of its private key SKPICC:
1. The inspection system sends a randomly chosen challenge c to the MRTD chip.
2. The MRTD chip responds with the signature s = Sign(SKPICC,c).
While this is a very simple and efﬁcient protocol, the MRTD chip in fact signs the message c without
knowing the semantic of this message. As signatures provide a transferable proof of authenticity, any
third party can – in principle – be convinced that the MRTD chip has indeed signed this message.
Although c should be a random bit string, the inspection system can as well generate this bit string in
an unpredictable but (publicly) veriﬁable way, e.g. let SKPCD be the inspection system’s private key and
c = Sign(SKPCD,IDPICC||Date||Time||Location),
be the challenge generated by using a signature scheme with message recovery. The signature guarantees
that the inspection system has indeed generated this challenge. Due to the transferability of the
inspection system’s signature, any third party having trust in the inspection system and knowing the
corresponding public key PKPCD can check that the challenge was created correctly by verifying this
signature. Furthermore, due to the transferability of MRTD chip’s signature on the challenge, the third
party can conclude that the assertion became true: The MRTD chip was indeed at a certain date and time
at a certain location.
On the positive side, countries may use Challenge Semantics for their internal use, e.g. to prove
that a certain person indeed has immigrated. On the negative side such proves can be misused to track
persons. In particular since Active Authentication is not restricted to authorized inspection systems
misuse is possible. The worst scenario would be MRTD chips that provide Active Authentication without
Basic Access Control. In this case a very powerful tracking system may be set up by placing secure
hardware modules at prominent places. The resulting logs cannot be faked due to the signatures. Basic
Access Control diminishes this problem to a certain extent, as interaction with the bearer is required.
Nevertheless, the problem remains, but is restricted to places where the travel document of the bearer is
read anyway, e.g. by airlines, hotels etc.
One might object that especially in a contactless scenario, challenges may be eavesdropped and reused
at a different date, time or location and thus render the proof at least unreliable. While eavesdropping
challenges is technically possible, the argument is still invalid. By assumption an inspection system
is trusted to produce challenges correctly and it can be assumed that it has checked the MRTD chip’s
identity before starting Active Authentication. Thus, the eavesdropped challenge will contain an identity
different from the prover’s identity who signs the challenge.
58 Federal Ofﬁce for Information Security
Technical Guideline - Extended Access Control
Bibliography
[1] Mihir Bellare, Ran Canetti, and Hugo Krawczyk. A modular approach to the design and analysis
of authentication and key exchange protocols. In 30th Annual ACM Symposium on the Theory of
Computing, pages 419–428. ACM Press, 1998.
[2] Scott Bradner. Key words for use in RFCs to indicate requirement levels. RFC 2119, 1997.
[3] BSI. Technical Guideline: Elliptic Curve Cryptography (ECC) based on ISO 15946, Version 1.0.
TR-03111, 2007.
[4] Russel Housley, Tim Polk, Warwick Ford, and David Solo. Internet X.509 public key infrastructure
certiﬁcate and certiﬁcate revocation list (CRL) proﬁle. RFC 3280, 2002.
[5] ICAO Doc 9303. Speciﬁcations for electronically enabled passports with biometric identiﬁcation
capabilities. In Machine Readable Travel Documents – Part 1: Machine Readable Passport, volume
2. ICAO, 6th edition, 2006.
[6] ISO 11770-2. Information technology – Security techniques – Key management – Part 2: Mechanisms
using symmetric techniques, 1996.
[7] ISO 15946-1. Information technology – Security techniques – Cryptographic techniques based on
elliptic curves – Part 1: General, 2002.
[8] ISO 15946-2. Information technology – Security techniques – Cryptographic techniques based on
elliptic curves – Part 2: Digital signatures, 2002.
[9] ISO 15946-3. Information technology – Security techniques – Cryptographic techniques based on
elliptic curves – Part 3: Key establishment, 2002.
[10] ISO/IEC 7816-4:2005. Identiﬁcation cards – Integrated circuit cards – Part 4: Organization, security
and commands for interchange, 2005.
[11] ISO/IEC 7816-6:2004. Identiﬁcation cards – Integrated circuit cards – Part 6: Interindustry data
elements for interchange, 2004.
[12] ISO/IEC 7816-8:2004. Identiﬁcation cards – Integrated circuit cards – Part 8: Commands for
security operations, 2004.
[13] ITU-T. Information Technology – ASN.1 encoding rules: Speciﬁcation of Basic Encoding Rules
(BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER). X.690, 2002.
[14] Jakob Jonsson and Burt Kaliski. Public-key cryptography standards (PKCS) #1: RSA cryptography
speciﬁcations version 2.1. RFC 3447, 2003.
[15] NIST. Secure hash standard. FIPS PUB 180-2 (+ Change Notice to include SHA-224), 2002.
[16] Eric Rescorla. Difﬁe-Hellman key agreement method. RFC 2631, 1999.
[17] RSA Laboratories. PKCS#3: Difﬁe-Hellman key-agreement standard. RSA Laboratories Technical
Note, 1993.
[18] RSA Laboratories. PKCS#1 v2.1: RSA cryptography standard. RSA Laboratories Technical Note,
2002.
Federal Ofﬁce for Information Security 59