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 clarifications. 1.10 2007-09-04 Revised version. 1.11 2008-02-21 Minor corrections and clarifications. 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 Verifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 2.2.3 Card Verifiable Certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 2.2.3.1 Certificate Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . 16 2.2.4 Certificate Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 2.2.4.1 General Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 2.2.4.2 Example Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 3 Protocol Specifications 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 Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 3.2.2 Security Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 3.3 Terminal Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 3.3.1 Protocol Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 Office 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 Certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 A.4.1 Certificate Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 A.4.1.1 Certificate Profile Identifier . . . . . . . . . . . . . . . . . . . . . . . 33 A.4.1.2 Certification Authority Reference . . . . . . . . . . . . . . . . . . . . 33 A.4.1.3 Public Key . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 A.4.1.4 Certificate Holder Reference . . . . . . . . . . . . . . . . . . . . . . 33 A.4.1.5 Certificate Holder Authorization Template . . . . . . . . . . . . . . . 33 A.4.1.6 Certificate Effective/Expiration Date . . . . . . . . . . . . . . . . . . 34 A.4.1.7 Signature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 A.4.2 Certificate Requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 A.4.2.1 Certificate Profile Identifier . . . . . . . . . . . . . . . . . . . . . . . 34 A.4.2.2 Certification Authority Reference . . . . . . . . . . . . . . . . . . . . 34 A.4.2.3 Public Key . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 A.4.2.4 Certificate Holder Reference . . . . . . . . . . . . . . . . . . . . . . 35 A.4.2.5 Signature(s) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 A.4.3 Certificate 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 Office 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 Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 Identifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 AlgorithmIdentifier . . . . . . . . . . . . . . . . . . 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 AlgorithmIdentifier . . . . . . . . . . . . . . . . . . 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 Office for Information Security v Technical Guideline - Extended Access Control D.2 Card Verifiable Certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 D.2.1 Example 1: CVCA Certificate with ECDSA . . . . . . . . . . . . . . . . . . . . 52 D.2.1.1 General Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 D.2.1.2 Public Key . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 D.2.1.3 Certificate Holder Authorization Template . . . . . . . . . . . . . . . 53 D.2.1.4 ECDSA Plain Signature . . . . . . . . . . . . . . . . . . . . . . . . . 53 D.2.2 Example 2: CVCA Certificate 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 Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 F Challenge Semantics (Informative) 58 List of Figures 2.1 Public Key Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 2.2 Certificate 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 Certificate (ECDSA) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 D.6 CVCA Private Key (ECDSA) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 D.7 CVCA Certificate (RSA) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 D.8 CVCA Private Key (RSA) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 E.1 Basic Access Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 vi Federal Office 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 Certificate Holder Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 A.3 Elementary File EF.CVCA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 A.4 Object Identifiers for Terminal Authentication with RSA . . . . . . . . . . . . . . . . . 32 A.5 Object Identifiers for Terminal Authentication with ECDSA . . . . . . . . . . . . . . . 33 A.6 CV Certificate Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 A.7 CV Certificate Request Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 Office 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: Specifications for Electronically Enabled Passports with Biometric Identification Ca- pability Part 2: Machine Readable Visa Part 3: Machine Readable Official 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 confidentiality of the data stored on the radio frequency chip embedded in the passport (MRTD chip). In a nutshell the security mechanisms specified 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 Confidentiality 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 confidentiality of the stored data cannot be guaranteed. This guideline focuses on those aspects and specifies 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 Office 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 defined in this specification (cf. Appendix A.1). Table 1.2: Data Groups of the ePassport Application 2. Retrieve the corresponding Document Signer Certificate and the trusted Country Signing CA Cer- tificate. 3. Verify the Document Signer Certificate 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 Office 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. fingerprints 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) specified 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 qualified under which conditions the item is REQUIRED or RECOMMENDED. When used in tables (profiles), 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 specification. 10 Federal Office for Information Security Technical Guideline - Extended Access Control Name Abbrev. Card Verifiable CV Certification Authority CA Chip Authentication Public Key PKPICC Chip Authentication Private Key SKPICC Country Signing CA CSCA Country Verifying CA CVCA Country Verifying CA Certificate CCVCA Security Object SOD Document Verifier DV Document Verifier Certificate CDV Domain Parameters D International Civil Aviation Organization ICAO Inspection System IS Inspection System Certificate 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 Office for Information Security 11 Technical Guideline - Extended Access Control 2 Advanced Security Mechanisms This technical guideline specifies 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 specification 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 Office 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 Office 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 Certificate, 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 Certificate. The PKI required for issuing and validating Inspection System Certificates consists of the following entities: 1. Country Verifying CAs (CVCAs) 2. Document Verifiers (DVs) 3. Inspection systems (ISs) This PKI forms the basis of Extended Access Control. It is illustrated in Figure 2.1. 14 Federal Office 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 Verifier Certificates: the Country Verifying CA (CVCA). NOTE: The Country Signing CA issuing certificates 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 certificates 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 certificate policy (cf. Appendix A.4.3). Document Verifier Certificates 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 Verifier Certificates 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 Verifier the certificate is issued to. 2.2.2 Document Verifiers A Document Verifier (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 Certificates. A Document Verifier is therefore a CA, authorized by at least the national CVCA to issue certificates for national inspection systems. The Inspection System Certificates issued by a DV usually inherit both the access rights and the validity period from the Document Verifier Certificate, however, the Document Verifier MAY choose to further restrict the access rights or the validity period depending on the inspection system the certificate is issued for. If a Document Verifier requires its inspection systems to access sensitive data stored on other States' MRTD chips, it MUST apply for a DV Certificate issued by the CVCA of the respective States. The Document Verifier MUST also ensure that all received Document Verifier Certificates are forwarded to the inspection systems within its domain. 2.2.3 Card Verifiable Certificates CVCA Link Certificates, DV Certificates, and IS Certificates are to be validated by MRTD chips. Due to the computational restrictions of those chips, the certificates MUST be in a card verifiable format: Federal Office for Information Security 15 Technical Guideline - Extended Access Control } CVCA DV IS certificate effective date certificate expiration date max. distribution time Figure 2.2: Certificate Scheduling * The certificate format and profile specified 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 certificate chain.1 * CVCA Link Certificates 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 Certificate Scheduling Each certificate MUST contain a validity period. This validity period is identified by two dates, the certificate effective date and the certificate expiration date. Certificate Effective Date: The certificate effective date SHALL be the date of the certificate genera- tion. Certificate Expiration Date: The certificate expiration date MAY be arbitrarily chosen by the certificate issuer. When generating certificates the issuer MUST carefully plan the renewal of certificates, as sufficient time for propagation of certificates and set up of certificate chains MUST be provided. Obviously, a new certificate must be generated before the current certificate expires. The resulting maximum distribution time equals the certificate expiration date of the old certificate minus the certificate effective date of the new certificate. Certificate scheduling is illustrated in Figure 2.2. 2.2.4 Certificate Validation To validate an IS Certificate, the MRTD chip MUST be provided with a certificate 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 Verifiers and inspection systems will have to be provided with several key pairs. 16 Federal Office 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 Certificates have to be produced. The MRTD chip is REQUIRED to internally update its trust-point(s) according to received valid link certificates. NOTE: Due to the scheduling of CVCA Link Certificates (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 Certificates. If the MRTD chip has no internal clock, the current date SHALL be approximated as described below. Thus, the MRTD chip only verifies that a certificate 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 certificate effective date contained in a valid CVCA Link Certificate, a DV Certificate or a domestic IS Certificate. An inspection system MAY send CVCA Link Certificates, DV Certificates, and IS Certificates 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 certificate validation procedure consists of two steps: 1. Certificate Verification: The signature MUST be valid, the certificate MUST NOT be expired. If the verification 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 certificate chain. For each received certificate the MRTD chip performs the following steps: 1. The MRTD chip verifies the signature on the certificate. If the signature is incorrect, the verification fails. 2. The certificate expiration date is compared to the MRTD chip's current date. If the expiration date is before the current date, the verification fails. 3. The certificate is valid and the public key and the relevant attributes contained in the certificate are imported. a) For CVCA Link Certificates: 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 Certificates: The new DV or IS public key is temporarily imported for subsequent certificate verification or Terminal Authentication, respectively. Federal Office for Information Security 17 Technical Guideline - Extended Access Control 4. For CVCA, DV, and domestic IS Certificates: The certificate 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 Office for Information Security Technical Guideline - Extended Access Control 3 Protocol Specifications In this section cryptographic protocols for Chip Authentication and Terminal Authentication are specified 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 Diffie-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 Diffie-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 Office 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 Diffie-Hellman key agreement protocol that provides secure communication and implicit unilateral authentication of the MRTD chip. 3.2.1 Protocol Specification The following steps are performed by the inspection system and the MRTD chip, a simplified version is also shown in Figure 3.1: 1. The MRTD chip sends its static Diffie-Hellman public key PKPICC, and the domain parameters DPICC to the inspection system. 2. The inspection system generates an ephemeral Diffie-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 Office 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 Specification The following steps are performed by the inspection system and the MRTD chip, a simplified version is also shown in Figure 3.2: 1. The inspection system sends a certificate chain to the MRTD chip. The chain starts with a certificate verifiable with a CVCA public key stored on the chip and ends with the inspection system's IS Certificate. 2. The MRTD chip verifies the certificates 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 Diffie-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 Office 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 sufficient to set up the secure channel. The security of the underlying Diffie-Hellman protocol is directly based on the assumption that the Computational DiffieHellman 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 definition 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 definition 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 sufficient 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 Diffie-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 Diffie-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 identifier 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 Office 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 verified 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 Office 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 confirmation 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 difficult 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 Office for Information Security Technical Guideline - Extended Access Control Appendix A Key Management (Normative) The object identifiers 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 specified 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 identifier protocol identifies the supported protocol. * The open type requiredData contains protocol specific mandatory data. * The open type optionalData contains protocol specific optional data. A.1.1 Supported Protocols The ASN.1 specifications for the protocols provided in this specification are described in the following. NOTE: The following data structures were introduced in version 1.1 of this specification: * ChipAuthenticationInfo * TerminalAuthenticationInfo MRTD chips implemented according to Version 1.0.x of this specification 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 file EF.CVCA. Federal Office 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 identifier. ChipAuthenticationPublicKeyInfo: This data structure provides an Chip Authentication Public Key of the MRTD chip. * The object identifier 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 specification of SubjectPublicKeyInfo and AlgorithmIdentifier can be found in [4]. * The integer keyId MAY be used to indicate the local key identifier. 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 identifier 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 Office for Information Security Technical Guideline - Extended Access Control * The integer keyId MAY be used to indicate the local key identifier. 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 identifier protocol SHALL identify the general Terminal Authentication Protocol as the specific 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) file identifier of the file EF.CVCA. It MUST be used, if the default (short) file identifier 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 Office 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 specification (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 identifier 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 Office for Information Security Technical Guideline - Extended Access Control Table A.2: Certificate 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: fixed 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 Certificates according to the certificate profile defined in Appendix A.4.1. Each CV Certificate MUST contain two public key references, a Certificate Holder Reference and a Certification Authority Reference: Certificate Holder Reference: The Certificate Holder Reference is an identifier for the public key provided in the certificate that SHALL be used to reference this public key. Certification Authority Reference: The Certification Authority Reference is a reference to the (external) public key of the certification authority that SHALL be used to verify the signature of the certificate. NOTE: As a consequence the Certification Authority Reference contained in a certificate MUST be equal to the Certificate Holder Reference in the corresponding certificate of the issuing certification authority. The Certificate 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 certificate holder's country. 2. Holder Mnemonic The Holder Mnemonic SHALL be assigned as unique identifier 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 certificate holder. Federal Office 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 certification 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 certificate 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 Certificate Holder Reference is already known to the MRTD chip. A.3.2.1 Permanent Import Public keys contained in CVCA Link Certificates SHALL be permanently imported by the MRTD chip and MUST be stored in secure memory. A permanently imported public key and its metadata SHALL fulfill 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 Certificate 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 Certificate 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 reflected in the file EF.CVCA (cf. Table A.3). A.3.2.2 Temporary Import Public keys contained in DV and IS Certificates SHALL be temporarily imported by the MRTD chip. A temporarily imported public key and its metadata SHALL fulfill 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 Certificate 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 Office 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 (fixed) 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 certificate (cf. Appendix A.4.1) MUST be stored: * Certificate Holder Reference * Certificate Holder Authorization (effective role and effective authorization) * Certificate Effective Date * Certificate Expiration Date The calculation of the effective role (CVCA, DV, or IS) and the effective authorization of the certificate 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- ification. 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 file EF.CVCA as specified in Table A.3. This file contains a sequence of Certification Authority Reference (CAR) data objects (cf. Appendix C.2) structured as follows: * It SHALL contain at most two Certification Authority Reference data objects. * The most recent Certification Authority Reference SHALL be the first data object in this list. * The file MUST be padded by appending zeros. The file EF.CVCA has a default file identifier and short file identifier. If the default values cannot be used, the (short) file identifier SHALL be specified in the OPTIONAL parameter efCVCA of the TerminalAuthenticationInfo. If efCVCA is used to indicate the file identifier to be used, the default file identifier is overridden. If no short file identifier is given in efCVCA, the file EF.CVCA MUST be explicitly selected using the given file identifier. A.3.3 Terminal Authentication with RSA For Terminal Authentication with RSA the following algorithms and formats MUST be used. Federal Office for Information Security 31 Technical Guideline - Extended Access Control Table A.4: Object Identifiers 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 specified in Table A.4 SHALL be used. The default parameters to be used with RSA-PSS are defined 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 identifier 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 specified 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 identifier 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 Certificates A.4.1 Certificate Profile Self-descriptive card verifiable (CV) certificates according to ISO 7816 [10, 11, 12] and the certificate profile specified in Table A.6 SHALL be used. Details on the encoding of the data objects used in the certificate profile can be found in Appendix C.2. 32 Federal Office for Information Security Technical Guideline - Extended Access Control Table A.5: Object Identifiers 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 Certificate Profile Data Object Cert CV Certificate m Certificate Body m Certificate Profile Identifier m Certification Authority Reference m Public Key m Certificate Holder Reference m Certificate Holder Authorization Template m Certificate Effective Date m Certificate Expiration Date m Signature m A.4.1.1 Certificate Profile Identifier The version of the profile is indicated by the Certificate Profile Identifier. Version 1 as specified in Table A.6 is identified by a value of 0. A.4.1.2 Certification Authority Reference The Certification Authority Reference is used to identify the public key to be used to verify the signature of the certification authority (CVCA or DV). The Certification Authority Reference MUST be equal to the Certificate Holder Reference in the corresponding certificate of the certification authority (CVCA Link Certificate or DV Certificate). Details on the Certification 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 Certificate Holder Reference The Certificate Holder Reference is used to identify the public key contained in the certificate. Details on the Certificate Holder Reference can be found in Appendix A.3.1. A.4.1.5 Certificate Holder Authorization Template The role and authorization of the certificate holder SHALL be encoded in the Certificate Holder Authorization Template. This template is a sequence that consists of the following data objects: 1. An object identifier that specifies the format of the template. 2. A discretionary data object that encodes the relative authorization, i.e. the role and authorization of the certificate holder relative to the certification authority. Federal Office for Information Security 33 Technical Guideline - Extended Access Control Table A.7: CV Certificate Request Profile Data Object Req Authentication c CV Certificate m Certificate Body m Certificate Profile Identifier m Certification Authority Reference r Public Key m Certificate Holder Reference m Signature m Certification Authority Reference c Signature c For the ePassport application the content and evaluation of the Certificate Holder Authorization Template is described in Appendix A.5. A.4.1.6 Certificate Effective/Expiration Date Indicates the validity period of the certificate. The Certificate Effective Date MUST be the date of the certificate generation. A.4.1.7 Signature The signature on the certificate SHALL be created over the encoded certificate body (i.e. including tag and length). The Certification Authority Reference SHALL identify the public key to be used to verify the signature. A.4.2 Certificate Requests Certificate requests are reduced CV certificates that may carry an additional signature. The certificate request profile specified in Table A.7 SHALL be used. Details on the encoding of the data objects used in the certificate request profile can be found in Appendix C.2. A.4.2.1 Certificate Profile Identifier The version of the profile is identified by the Certificate Profile Identifier. Version 1 as specified in Table A.7 is identified by a value of 0. A.4.2.2 Certification Authority Reference The Certification Authority Reference SHOULD be used to inform the certification authority about the private key that is expected by the applicant to be used to sign the certificate. If the Certification Authority Reference contained in the request deviates from the Certification Authority Reference contained in the issued certificate (i.e. the issued certificate is signed by a private key that is not expected by the applicant), the corresponding certificate of the certification authority SHOULD also be provided to the applicant in response. Details on the Certification 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 Office for Information Security Technical Guideline - Extended Access Control A.4.2.4 Certificate Holder Reference The Certificate Holder Reference is used to identify the public key contained in the request and the resulting certificate. Details on the Certificate Holder Reference can be found in Appendix A.3.1. A.4.2.5 Signature(s) A certificate request may have two signatures, an inner signature and an outer signature: * Inner Signature (REQUIRED) The certificate body is self-signed, i.e. the inner signature SHALL be verifiable with the public key contained in the certificate request. The signature SHALL be created over the encoded certificate body (i.e. including tag and length). * Outer Signature (CONDITIONAL) ­ The signature is OPTIONAL if an entity applies for the initial certificate. In this case the request MAY be additionally signed by another entity trusted by the receiving certification 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 certificate. In this case the request MUST be additionally signed by the applicant using a recent key pair previously registered with the receiving certification authority. If the outer signature is used, an authentication data object SHALL be used to nest the CV Certificate (Request), the Certification Authority Reference and the additional signature. The Certification 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 Certificate and the encoded Certification Authority Reference (i.e. both including tag and length). A.4.3 Certificate Policy It is RECOMMENDED that each CVCA and every DV publishes a certificate policy and/or a certification practice statement. A.4.3.1 Procedures The certificate policy SHOULD specify the following procedures: * Entity identification, authentication, and registration. * Certificate application, issuance, and distribution. * Compromise and disaster recovery. * Auditing. A.4.3.2 Usage Restrictions The certificate 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 certification (e.g. Common Criteria Protection Profiles). * Data Protection. Federal Office 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 identifier 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 certificate 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 certificates in the chain. A.5.2 Effective Authorization To determine the effective authorization of a certificate holder, the MRTD chip MUST calculate a bitwise Boolean 'anď of the relative authorization contained in the current certificate and effective authorization of the previous certificate in the chain. As the certificate 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 certificate 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 certificate issuer is a trusted source of time and the MRTD chip MUST update its current date using the Certificate 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 Office for Information Security Technical Guideline - Extended Access Control ­ The certificate was issued by the national CVCA for an authorized DV. ­ The certificate issuer is a trusted source of time and the MRTD chip MUST update its current date using the Certificate 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 certificate was issued by either a domestic or a foreign DV. ­ If the certificate 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 Certificate Effective Date. ­ The MRTD chip MUST grant the authenticated IS extended access to sensitive data according to the effective access rights. Federal Office 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 field 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 Certificate 3. MSE:Set AT 38 Federal Office for Information Security Technical Guideline - Extended Access Control 4. Get Challenge 5. External Authenticate Steps 1 and 2 are repeated for every CV certificate to be verified (CVCA Link Certificates, DV Certificate, IS Certificate). 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 verification: 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 Certificate Command CLA 0x0C Secure Messaging with authenticated header, no chaining INS 0x2A Perform Security Operation P1/P2 0x00BE Verify self-descriptive certificate Data 0x7F4E Certificate body The body of the certificate to be verified. REQUIRED 0x5F37 Signature The signature of the certificate to be verified. REQUIRED Response Data ­ Absent Status Bytes 0x9000 Normal operation The certificate 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 certificate was not ac- cepted). Federal Office 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 verified cer- tificate. other Operating system dependent error The authentication failed. 40 Federal Office 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 specified by ICAO [5] SHALL be used (i.e. Select File and Read Binary). In accordance with ICAO specifications any unauthorized access to EAC-protected data groups SHALL be denied and the MRTD chip MUST respond with status bytes 0x6982 ("Security status not satisfied"). 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 fingerprints (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 fields 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 specified in [10]. Federal Office 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 Certificate * MSE:Set KAT * External Authenticate B.6.3 Errors The MRTD chip SHALL indicate extended length errors with status bytes 0x6700. 42 Federal Office 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 specific) 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 defined 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 specification. NOTE: The tag 0x7F4C is not yet defined by ISO/IEC 7816. The allocation is requested. C.2.2 Encoding of Values The basic value types used in this specification are the following: (unsigned) integers, elliptic curve points, dates, character strings, octet strings, object identifiers, and sequences. C.2.2.1 Unsigned Integers All integers used in this specification 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 specified in [3]. The uncompressed format SHALL be used. Federal Office for Information Security 43 Technical Guideline - Extended Access Control Table C.1: Overview on Data Objects Name Tag Len Value Comment Object Identifier 0x06 V Object Identifier Discretionary Data 0x53 V Octet String Contains arbitrary data. Public Key 0x7F49 V Sequence Nests the public key value and the domain parameters. CV Certificate 0x7F21 V Sequence Nests certificate body and signature. Certificate Body 0x7F4E V Sequence Nests data objects of the certificate body. Certificate Profile Identifier 0x5F29 1F Unsigned Integer Version of the certificate and certificate request format. Certification Authority Reference 0x42 16V Character String Identifies the public key of the issuing certification authority in a certificate. Certificate Holder Reference 0x5F20 16V Character String Associates the public key contained in a certificate with an identifier. Certificate Holder Authorization Template 0x7F4C V Sequence Encodes the role of the certificate holder (i.e. CVCA, DV, IS) and assigns read/write access rights to data groups storing sensitive data. Certificate Effective Date 0x5F25 6F Date The date of the certificate generation. Certificate Expiration Date 0x5F24 6F Date The date after which the certificate expires. Signature 0x5F37 V Octet String Digital signature produced by an asymmetric cryptographic algorithm. Authentication 0x67 V Sequence Nests certificate request with additional authentication data. F: fixed 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 Office 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 Identifiers An object identifier 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 first 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 identifier and several context specific data objects: * The object identifier is application specific and refers not only to the public key format (i.e. the context specific data objects) but also to its usage. Federal Office for Information Security 45 Technical Guideline - Extended Access Control Table C.4: RSA Public Key Data Object Tag Type CV Certificate Object Identifier 0x06 Object Identifier 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 Certificate Object Identifier 0x06 Object Identifier m Prime modulus p 0x81 Unsigned Integer o First coefficient a 0x82 Unsigned Integer o Second coefficient 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 specific data objects are defined by the object identifier and contain the public key value and the domain parameters. The format of public keys data objects used in this specification 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 specific 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 fixed. 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 fixed, OPTIONAL domain parameters MUST be either all present or all absent as follows: * CVCA Link Certificates MAY contain domain parameters. * DV and IS Certificates MUST NOT contain domain parameters. The domain parameters of DV and IS public keys SHALL be inherited from the respective CVCA public key. * Certificate 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 specific 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 specific data object 0x91. 46 Federal Office for Information Security Technical Guideline - Extended Access Control Appendix D Worked Examples (Informative) This appendix provides worked examples for data structures (DG14 and CV certificates) defined by this specification. 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 first example is based on Elliptic Curve Diffie Hellman and the second example is based on Diffie 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 Office for Information Security 47 Technical Guideline - Extended Access Control Tag Length Value ASN.1 Type Comment 6E 82 01 4A - Application specific 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 AlgorithmIdentifier 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 AlgorithmIdentifier 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 AlgorithmIdentifier 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 field 06 07 2A 86 48 CE OBJECT Prime field 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 specified as ASN.1 data structures. 48 Federal Office 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 Office 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 specific 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 AlgorithmIdentifier 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 Office for Information Security Technical Guideline - Extended Access Control D.1.2.2 Encoding of the AlgorithmIdentifier 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 AlgorithmIdentifier 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 Office 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 Verifiable Certificates This section provides two examples for CV certificates. Both examples are self-signed CVCA certificates. The first example is based on ECDSA and the second example is based on RSA. D.2.1 Example 1: CVCA Certificate with ECDSA The hexdump of the encoded certificate 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 Certificate (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 first worked example is examined in the following table. Details on the encoding of the public key and the Certificate Holder Authorization Template are given in the following sections. Tag Length Value Comment 7F 21 82 01 8D CV Certificate 7F 4E 82 01 4D Certificate Body 5F 29 01 00 Certificate Profile Identifier 42 10 44 45 43 ... Certification Authority Reference: 30 30 31 DECVCAEPASS00001 7F 49 81 FD see below Public key 5F 20 10 44 45 43 ... Certificate Holder Reference: 30 30 31 DECVCAEPASS00001 7F 4C 0E see below Certificate Holder Authorization Template 5F 25 06 00 07 00 Certificate Effective Date: 04 00 01 2007-APR-01 5F 24 06 00 09 00 Certificate Expiration Date: 03 03 01 2009-MAR-31 52 Federal Office 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 certificate 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 coefficient a D2 9F 43 83 1C 25 80 F6 ... Second coefficient 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 Certificate Holder Authorization Template The discretionary data object contained in the CHAT identifies a CVCA that allows read access to DG3 and DG4. Tag Length Value Comment 7F 4C 0E Certificate 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 specified 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 Certificate with RSA The hexdump of the encoded certificate 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 Office for Information Security 53 Technical Guideline - Extended Access Control Figure D.7: CVCA Certificate (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 Certificate Holder Authorization Template is described in Appendix D.2.1.3. Tag Length Value Comment 7F 21 82 02 6E CV Certificate 7F 4E 82 01 64 Certificate Body 5F 29 01 00 Certificate Profile Identifier 42 10 44 45 43 ... Certification Authority Reference: 30 30 31 DECVCAEPASS00001 7F 49 82 01 13 see below Public key 5F 20 0E 44 45 43 ... Certificate Holder Reference: 30 30 31 DECVCAEPASS001 7F 4C 0E see above Certificate Holder Authorization Template 5F 25 06 00 07 00 Certificate Effective Date: 04 00 01 2007-APR-01 5F 24 06 00 09 00 Certificate 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 certificate is explained in the following table. The corresponding private key (private exponent d) is show in Figure D.8. 54 Federal Office 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 Office for Information Security 55 Technical Guideline - Extended Access Control Appendix E Basic Access Control (Informative) The protocol for Basic Access Control is specified by ICAO [5]. Basic Access Control checks that the inspection system has physical access to the MRTĎ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 confidentiality (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 significant 16 bytes of the SHA-1 [15] hash of some fields of the MRZ. As reading the MRZ optically is error-prone, only the fields 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 first 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 Specification 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 Office 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 verifies 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 verifies 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 Office 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 efficient 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) verifiable 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 Office 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 certificate and certificate revocation list (CRL) profile. RFC 3280, 2002. [5] ICAO Doc 9303. Specifications for electronically enabled passports with biometric identification 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. Identification cards ­ Integrated circuit cards ­ Part 4: Organization, security and commands for interchange, 2005. [11] ISO/IEC 7816-6:2004. Identification cards ­ Integrated circuit cards ­ Part 6: Interindustry data elements for interchange, 2004. [12] ISO/IEC 7816-8:2004. Identification cards ­ Integrated circuit cards ­ Part 8: Commands for security operations, 2004. [13] ITU-T. Information Technology ­ ASN.1 encoding rules: Specification 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 specifications 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. Diffie-Hellman key agreement method. RFC 2631, 1999. [17] RSA Laboratories. PKCS#3: Diffie-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 Office for Information Security 59