MACHINE READABLE TRAVEL DOCUMENTS

Similar documents
TECHNICAL ADVISORY GROUP ON MACHINE READABLE TRAVEL DOCUMENTS (TAG/MRTD)

This document is a preview generated by EVS

Advanced Security Mechanisms for Machine Readable Travel Documents and eidas Token

MACHINE READABLE TRAVEL DOCUMENTS

Machine Authentication of MRTDs for Public Sector Applications

BSI TR Part 1.1 A framework for Official Electronic ID Document conformity tests

Roadmap for Implementation of New Specifications for MRTDs

Security Mechanism of Electronic Passports. Petr ŠTURC Coesys Research and Development

TECHNICAL ADVISORY GROUP ON MACHINE READABLE TRAVEL DOCUMENTS (TAG/MRTD)

SmartCards as electronic signature devices Progress of standardization. Helmut Scherzer, CEN TC224/WG16 (Editor) IBM Germany

The New Seventh Edition of Doc Barry J. Kefauver Nairobi, Kenya November 2015

Conformity and Interoperability Key Prerequisites for Security of eid documents. Holger Funke, 27 th April 2017, ID4Africa Windhoek

Internet Engineering Task Force (IETF) Request for Comments: 6160 Category: Standards Track April 2011 ISSN:

The epassport: What s Next?

Security Target Lite SK e-pass V1.0

Internet Engineering Task Force (IETF) Request for Comments: 7192 Category: Standards Track April 2014 ISSN:

Introduction of the Seventh Edition of Doc 9303

Test plan for eid and esign compliant smart card readers with integrated EACv2

The EAC for MRTD. 26 January 2010

Verifying emrtd Security Controls

EU Passport Specification

Test Report. For the participants of the SDW InterOp Final Report, secunet Security Networks AG

Logical Data Structure (LDS) for Storage of Data in the Contactless IC Doc LDS 2 New Applications

Conformance Requirements Guideline Version 0.1

FINEID - S1 Electronic ID Application

For example, under Presentation Node Type, one would not say:

WAP Provisioning Architecture Overview

Security of Biometric Passports ECE 646 Fall Team Members : Aniruddha Harish Divya Chinthalapuri Premdeep Varada

Internet Engineering Task Force (IETF) Request for Comments: 5754 Updates: 3370 January 2010 Category: Standards Track ISSN:

Future Expansion for emrtd PKI Mark Joynes, Entrust

Internet Engineering Task Force (IETF) ISSN: January Suite B Profile for Transport Layer Security (TLS)

Technical report. Signature creation and administration for eidas token Part 1: Functional Specification

PKCS #3: Diffie-Hellman Key-Agreement

Interoperability Specification for ICCs and Personal Computer Systems

Internet Engineering Task Force (IETF) Request for Comments: 5959 Category: Standards Track August 2010 ISSN:

PKCS #3: Diffie-Hellman Key- Agreement Standard

Biometric Passport from a Security Perspective

Overview of cryptovision's eid Product Offering. Presentation & Demo

PKCS #15: Conformance Profile Specification

MULTIAPP V2 PACE - SAC PUBLIC SECURITY TARGET

Technical report. Signature creation and administration for eidas token. Version 1.0 Release Candidate 6. Version 1.0 Release Candidate 6

2 Electronic Passports and Identity Cards

TECHNICAL ADVISORY GROUP ON MACHINE READABLE TRAVEL DOCUMENTS (TAG/MRTD)

Internet Engineering Task Force (IETF) Request for Comments: 7193 Category: Informational. J. Schaad Soaring Hawk Consulting April 2014

This document is a preview generated by EVS

SPass NX V1.0 on S3CT9KW/S3CT9KC/S3CT9K9 Certification Report

International Civil Aviation Organization TECHNICAL ADVISORY GROUP ON MACHINE READABLE TRAVEL DOCUMENTS (TAG/MRTD) TWENTIETH MEETING

Merit Network, Incorporated Bernard Aboba Microsoft March 1997

Internet Engineering Task Force (IETF) Category: Standards Track August 2018 ISSN:

Internet Engineering Task Force (IETF) Request for Comments: 6032 Category: Standards Track. December 2010

The Cryptographic Sensor

Internet Engineering Task Force (IETF) Category: Informational July 2012 ISSN: S/MIME Capabilities for Public Key Definitions

Certification Report. EAL 4+ (ALC_DVS.2) Evaluation of TÜBİTAK BİLGEM UEKAE. AKİS v1.4i PASAPORT

Visible Digital Seals for Non-Electronic Documents

An emrtd inspection system on Android. Design, implementation and evaluation

Key Lifecycle Security Requirements. Version 1.0.2

ANSI/SCTE

Cryptographic Mechanisms: Recommendations and Key Lengths

PKCS #15 v1.0: Cryptographic Token Information Format Standard

Whitepaper: GlobalTester Prove IS

Security Target Lite for CEITEC epassport Module CTC21001 with EAC

Category: Informational January 2010 ISSN:

Internet Engineering Task Force (IETF) Obsoletes: 6485 Category: Standards Track August 2016 ISSN:

Internet Engineering Task Force (IETF) Category: Informational ISSN: October 2013

Getting to Grips with Public Key Infrastructure (PKI)

File Type Specification

Network Working Group Request for Comments: 4432 March 2006 Category: Standards Track

J. Basney, NCSA Category: Experimental October 10, MyProxy Protocol

epass ICAO essential configuration BAC and EAC RSA or configuration BAC and EAC ECC, Version 1.0 running on SLE77CLFX2400P & SLE77CLFX2407P

Security Specification for Cloud Data Services. Enterprise Cloud Customer Council Technical Working Group

XSmart e-passport V1.2

CONFORMITY TESTING OF EAC INSPECTION SYSTEMS

AMERICAN NATIONAL STANDARD

Category: Informational September 2004

Internet copy. DSRC Key Management. Annex 2.5 to Joint Venture Agreement Toll Service Provider Agreement

Internet Engineering Task Force (IETF) Request for Comments: 6403 Category: Informational ISSN: M. Peck November 2011

PKI Knowledge Dissemination Program. PKI Standards. Dr. Balaji Rajendran Centre for Development of Advanced Computing (C-DAC) Bangalore

PKCS #10 v1.7: Certification Request Syntax Standard (Final draft)

ISO/IEC INTERNATIONAL STANDARD

REQUIREMENTS. Michael Weintraub Spring, 2016

ETSI TS V1.2.1 ( ) Technical Specification

ANSI/SCTE

Internet Engineering Task Force (IETF) Category: Informational. August IANA Registration for the Cryptographic Algorithm Object Identifier Range

Applicability Statement: DNS Security (DNSSEC) DNSKEY Algorithm Implementation Status

EMV Contactless Specifications for Payment Systems

Legal Regulations and Vulnerability Analysis

1) Revision history Revision 0 (Oct 29, 2008) First revision (r0)

Functional Specification of the OpenPGP application on ISO Smart Card Operating Systems

Internet Engineering Task Force (IETF) April Elliptic Curve Digital Signature Algorithm (DSA) for DNSSEC

TECHNICAL REPORT TR-105. ADSL2/ADSL2plus Functionality Test Plan. Issue: 2 Amendment 1 Issue Date: May The Broadband Forum. All rights reserved.

BSI-CC-PP for

Security Target Lite

ANSI/SCTE

Category: Informational March Methods for Avoiding the "Small-Subgroup" Attacks on the Diffie-Hellman Key Agreement Method for S/MIME

Security Target Bundesdruckerei Document Application

Internet Engineering Task Force (IETF) Request for Comments: 6379 Obsoletes: 4869 Category: Informational October 2011 ISSN:

Internet Engineering Task Force (IETF) Request for Comments: Category: Informational ISSN: January 2010

Technical Guideline TR eid-client Part 2: Conformance Test Specification. Version 1.3

Updates: 2409 May 2005 Category: Standards Track. Algorithms for Internet Key Exchange version 1 (IKEv1)

Internet Engineering Task Force (IETF) Category: Standards Track ISSN: March 2010

Transcription:

MACHINE READABLE TRAVEL DOCUMENTS ADVANCED SECURITY MECHANISMS FOR MACHINE READABLE TRAVEL DOCUMENTS EXTENDED ACCESS CONTROL (EACv1) COMPLEMENTARY TO TEST METHODS FOR MRTDs USING STATIC BINDING Version 1.0 September 12, 2012

Version history Version Date Editor Description 1.0 RC1 25-06-2012 N.Regnault Initial version 1.0RC2 27-06-2012 N.Regnault AFNOR review 1.0RC3 02-07-2012 N.Regnault BSI comments: 1.0 12-09-21012 N.Regnault Public Release Static binding is not defined but noted in EACv2.10, Suppression of annex A specifying the StaticBindingInfo element, Addition of a reference to the Application Notes on Static Binding and addition of a note about the StaticBindingInfo workaround 2/14

Content 1 Introduction 4 1.1 Reference documentation 4 1.2 Terminology 4 2 General test requirements 6 2.1 Test setup 6 2.2 Test profiles 6 3 Complementary tests for layer 6 (ISO 7816) 7 3.1 Unit ISO7816_K Terminal Authentication 7 3.1.1 Test case ISO7816_KSB_1 7 3.1.2 Test case ISO7816_KSB_2 9 3.1.3 Test case ISO7816_KSB_3 10 3.1.4 Test case ISO7816_KSB_4 12 4 Complementary tests for layer 7 (LDS) 14 4.1 Unit LDS_ESB Data group 14 14 4.1.1 Test case ISO7816_ESB_1 14 3/14

1 Introduction This document is a complement to [R10]. It specifies alternative and additional test cases for MRTD using static bindings for the combination of PACE and Terminal Authentication, as noted in [R2] ( 3.5). Alternative test cases replace some test cases which are defined in [R10] i.e. the replaced test case in [R10] MUST NOT be executed with a static binding MRTD. Additionnal test cases do not replace test cases but come in addition. 1.1 Reference documentation The following documentation serves as a reference for this specification: [R1] ICAO 9303 Edition 6 Part 1, Part 2 and Part 3 [R2] Technical Guideline TR-03110-1 Advanced Security Mechanisms formachine Readable Travel Documents - Part 1: emrtds with BAC/PACEv2 and EACv1, Version 2.10, March 2012 [R3] RFC 2119, S. Bradner, "Key Words for Use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 [R4] ISO/IEC 7816-4:2005. Identification cards -- Integrated circuit cards -- Part 4: Organization, security and commands for interchange [R5] Supplement ICAO 9303 V4.0, June 2006 [R6] PKCS #3: Diffie-Hellman Key-Agreement Standard [R7] TR-03111: Technical Guideline, Elliptic Curve Cryptography (ECC) based on ISO 15946 [R8] ICAO Technical Report RF protocol and application test standard for epassport Part 3, Version 1.01, February 2007 [R9] ICAO Technical Report Supplemental Access Control for Machine Readable Travel Documents, Version 1.01, November 2010 [R10] AFNOR/BSI Advanced Security Mechanisms for Machine Readable Travel Documents Extended Access Control (EACv1) Tests for Security Implementation, Version 1.2 [R11] Gixel, Application Notes on Static Binding, v1.0 1.2 Terminology The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY" in this document are to be interpreted as described in [R3]. MUST MUST NOT SHOULD SHOULD NOT This word, or the terms "REQUIRED" or "SHALL", mean that the definition is an absolute requirement of the specification. This phrase, or the phrase SHALL NOT, means that the definition is an absolute prohibition of the specification. This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications MUST be understood and carefully weighed before choosing a different course. This phrase, or the phrase "NOT RECOMMENDED" mean that there may 4/14

MAY exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications SHOULD be understood and the case carefully weighed before implementing any behavior described with this label. This word, or the adjective OPTIONAL, means that an item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because the vendor feels that it enhances the product while another vendor may omit the same item. An implementation which does not include a particular option MUST be prepared to interoperate with another implementation which does include the option, though perhaps with reduced functionality. In the same vein an implementation which does include a particular option MUST be prepared to interoperate with another implementation which does not include the option (except, of course, for the feature the option provides.) 5/14

2 General test requirements 2.1 Test setup The Test setup defined in [R10] applies to this document. 2.2 Test profiles In addition to the profiles already specified in [R10] this complement defines the following additional profiles. Profile-ID Profile Remark SB Static Binding The MRTD is using the static binding for the combination of PACE and Terminal Authentication. When PACE is done with the MRZ, ID PICC is the MRTD chip s Document Number as contained in the MRZ including the check digit. When PACE is done with the CAN, ID PICC is the CAN. DG14SB EF.DG14 containing a SecurityInfo element for static binding A SecurityInfo element is present in the EF.DG14 to indicate to the terminal that the MRTD is using the static binding. 1 1 See Application Notes [R11] for the SecurityInfo workaround on static binding 6/14

3 Complementary tests for layer 6 (ISO 7816) This chapter defines alternative and additionnal tests which replace test case ISO7816_K_1b and ISO7816_K_20 specified in [R10]. The following test cases from [R10] MUST NOT be executed with an emrtd using static binding: ISO7816_K_1b ISO7816_K_20 3.1 Unit ISO7816_K Terminal Authentication 3.1.1 Test case ISO7816_KSB_1 This test case is an alternative to test case ISO7816_K_1b Test - ID Purpose Version 1.0 Profile ISO7816_KSB_1 Test the card to perform Terminal Authentication with PACE using the MRZ. TA, PACE, SB Preconditions 1. The "Open epassport Application" procedure MUST have been performed. PACE with MRZ MUST be used. 2. The Chip Authentication mechanism MUST have been performed as well. 3. The Certification Authority Reference MUST have been read from the EF.CVCA file (Primary trust point). Test scenario 1. Send the given MSE: Set DST APDU to the emrtd. <Cryptogram> contains the following encrypted data objects 83 <L 83 > The Certification Authority Reference MUST be used as read from the EF.CVCA file. 2. Send the appropriate DV-Certificate as specified in the Certificate Set 1 chapter as DV_CERT_1. <Cryptogram> contains the following encrypted data objects 7F 4E <L 7F4E > <certificate body> 5F 37 <L 5F37 > <certificate signature> 3. Send the given MSE: Set DST APDU to the emrtd. <Cryptogram> contains the following encrypted data objects 83 <L 83 > The Certification Holder Reference stored inside the DV-Certificate sent in step 2 has to be used. 4. Send the appropriate IS-Certificate as specified in the Certificate Set 1 chapter as IS_CERT_1. 7/14

Expected results <Cryptogram> contains the following encrypted data objects 7F 4E <L7F4E> <certificate body> 5F 37 <L5F37> <certificate signature> 5. Send the given MSE: Set AT APDU to the emrtd. 0C 22 81 A4 <Lc> 87 <L 87 > 01 <Cryptogram> 8E 08 <Cryptogram> contains the following encrypted data objects 83 <L 83 > <Certification Holder Reference > The Certification Holder Reference stored inside the IS-Certificate sent in step 4 has to be used. 6. Send the given Get Challenge APDU to the emrtd. 0C 84 00 00 0D 97 01 08 8E 08 7. Send the given external authenticate command to the emrtd. 0C 82 00 00 <Lc> 87 <L 87 > 01 <Cryptogram> 8E 08 The MRTD chip s ephemeral PACE public key MUST be used to build the encrypted terminal signature (SPCD) for the External Authenticate command. IDPICC = Comp(ehpPKPICC) <Cryptogram> contains the encrypted terminal generated signature created with the private key of IS_KEY_01. 8. Reset the chip by switching off the field and switching in on again Open the epassport Application using PACE with MRZ Perform Chip Authentication Read the Certification Authority Reference from the EF.CVCA file (Primary trust point) Perform step 1 of this test case 9. Perform step 2 of this test case 10. Perform step 3 of this test case 11. Perform step 4 of this test case 12. Perform step 5 of this test case 13. Perform step 6 of this test case 14. Send the given external authenticate command to the emrtd. 0C 82 00 00 <Lc> 87 <L 87 > 01 <Cryptogram> 8E 08 The MRTD chip s Document Number as contained in the MRZ including the check digit. MUST be used to build the encrypted terminal signature (SPCD) for the External Authenticate command. IDPICC = Document Number as contained in the MRZ. <Cryptogram> contains the encrypted terminal generated signature created with the private key of IS_KEY_01. 1. 90 00 in an SM response 2. 90 00 in an SM response 3. 90 00 in an SM response 4. 90 00 in an SM response 8/14

5. 90 00 in an SM response 6. <Eight bytes of random data> 90 00 in an SM response 7. ISO checking error in an SM response. 8. 90 00 in an SM response 9. 90 00 in an SM response 10. 90 00 in an SM response 11. 90 00 in an SM response 12. 90 00 in an SM response 13. <Eight bytes of random data> 90 00 in an SM response 14. 90 00 in an SM response 3.1.2 Test case ISO7816_KSB_2 This test case is an alternative to test case ISO7816_K_1b Test - ID Purpose Version 1.0 Profile ISO7816_KSB_2 Test the card to perform Terminal Authentication with PACE using the MRZ. TA, PACE, SB Preconditions 1. The "Open epassport Application" procedure MUST have been performed. PACE with MRZ MUST be used. 2. The Chip Authentication mechanism MUST have been performed as well. 3. The Certification Authority Reference MUST have been read from the EF.CVCA file (Primary trust point). Test scenario 1. Send the given MSE: Set DST APDU to the emrtd. <Cryptogram> contains the following encrypted data objects 83 <L 83 > The Certification Authority Reference MUST be used as read from the EF.CVCA file. 2. Send the appropriate DV-Certificate as specified in the Certificate Set 1 chapter as DV_CERT_1. <Cryptogram> contains the following encrypted data objects 7F 4E <L 7F4E > <certificate body> 5F 37 <L 5F37 > <certificate signature> 3. Send the given MSE: Set DST APDU to the emrtd. <Cryptogram> contains the following encrypted data objects 83 <L 83 > The Certification Holder Reference stored inside the DV-Certificate 9/14

sent in step 2 has to be used. 4. Send the appropriate IS-Certificate as specified in the Certificate Set 1 chapter as IS_CERT_1. Expected results <Cryptogram> contains the following encrypted data objects 7F 4E <L7F4E> <certificate body> 5F 37 <L5F37> <certificate signature> 5. Send the given MSE: Set AT APDU to the emrtd. 0C 22 81 A4 <Lc> 87 <L 87 > 01 <Cryptogram> 8E 08 <Cryptogram> contains the following encrypted data objects 83 <L 83 > <Certification Holder Reference > The Certification Holder Reference stored inside the IS-Certificate sent in step 4 has to be used. 6. Send the given Get Challenge APDU to the emrtd. 0C 84 00 00 0D 97 01 08 8E 08 7. Send the given external authenticate command to the emrtd. 0C 82 00 00 <Lc> 87 <L 87 > 01 <Cryptogram> 8E 08 The MRTD chip s Document Number as contained in the MRZ including the check digit. MUST be used to build the encrypted terminal signature (SPCD) for the External Authenticate command. IDPICC = Document Number as contained in the MRZ. <Cryptogram> contains the encrypted terminal generated signature created with the private key of IS_KEY_01. 1. 90 00 in an SM response 2. 90 00 in an SM response 3. 90 00 in an SM response 4. 90 00 in an SM response 5. 90 00 in an SM response 6. <Eight bytes of random data> 90 00 in an SM response 7. 90 00 in an SM response 3.1.3 Test case ISO7816_KSB_3 This test case is an alternative to test case ISO7816_K_20 Test - ID Purpose Version 1.0 Profile ISO7816_KSB_3 Test the card to perform Terminal Authentication with PACE using the CAN. This test case is only applicable for emrtd which supports CAN. TA, PACE, SB Preconditions 1. The "Open epassport Application" procedure MUST have been performed. PACE with CAN MUST be used. 2. The Chip Authentication mechanism MUST have been performed as well. 10/14

Test scenario 3. The Certification Authority Reference MUST have been read from the EF.CVCA file (Primary trust point). 1. Send the given MSE: Set DST APDU to the emrtd. <Cryptogram> contains the following encrypted data objects 83 <L 83 > The Certification Authority Reference MUST be used as read from the EF.CVCA file. 2. Send the appropriate DV-Certificate as specified in the Certificate Set 1 chapter as DV_CERT_1. <Cryptogram> contains the following encrypted data objects 7F 4E <L 7F4E > <certificate body> 5F 37 <L 5F37 > <certificate signature> 3. Send the given MSE: Set DST APDU to the emrtd. <Cryptogram> contains the following encrypted data objects 83 <L 83 > The Certification Holder Reference stored inside the DV-Certificate sent in step 2 has to be used. 4. Send the appropriate IS-Certificate as specified in the Certificate Set 1 chapter as IS_CERT_1. <Cryptogram> contains the following encrypted data objects 7F 4E <L7F4E> <certificate body> 5F 37 <L5F37> <certificate signature> 5. Send the given MSE: Set AT APDU to the emrtd. 0C 22 81 A4 <Lc> 87 <L 87 > 01 <Cryptogram> 8E 08 <Cryptogram> contains the following encrypted data objects 83 <L 83 > <Certification Holder Reference > The Certification Holder Reference stored inside the IS-Certificate sent in step 4 has to be used. 6. Send the given Get Challenge APDU to the emrtd. 0C 84 00 00 0D 97 01 08 8E 08 7. Send the given external authenticate command to the emrtd. 0C 82 00 00 <Lc> 87 <L 87 > 01 <Cryptogram> 8E 08 The MRTD chip s ephemeral PACE public key MUST be used to build the encrypted terminal signature (SPCD) for the External Authenticate command. IDPICC = Comp(ehpPKPICC) <Cryptogram> contains the encrypted terminal generated signature 11/14

Expected results created with the private key of IS_KEY_01. 8. Reset the chip by switching off the field and switching in on again Open the epassport Application using PACE with CAN Perform Chip Authentication Read the Certification Authority Reference from the EF.CVCA file (Primary trust point) Perform step 1 of this test case 9. Perform step 2 of this test case 10. Perform step 3 of this test case 11. Perform step 4 of this test case 12. Perform step 5 of this test case 13. Perform step 6 of this test case 14. Send the given external authenticate command to the emrtd. 0C 82 00 00 <Lc> 87 <L 87 > 01 <Cryptogram> 8E 08 The CAN MUST be used to build the encrypted terminal signature (SPCD) for the External Authenticate command. IDPICC = CAN. <Cryptogram> contains the encrypted terminal generated signature created with the private key of IS_KEY_01. 1. 90 00 in an SM response 2. 90 00 in an SM response 3. 90 00 in an SM response 4. 90 00 in an SM response 5. 90 00 in an SM response 6. <Eight bytes of random data> 90 00 in an SM response 7. ISO checking error in an SM response. 8. 90 00 in an SM response 9. 90 00 in an SM response 10. 90 00 in an SM response 11. 90 00 in an SM response 12. 90 00 in an SM response 13. <Eight bytes of random data> 90 00 in an SM response 14. 90 00 in an SM response 3.1.4 Test case ISO7816_KSB_4 This test case is an alternative to test case ISO7816_K_20 Test - ID Purpose Version 1.0 Profile ISO7816_KSB_4 Test the card to perform Terminal Authentication with PACE using the CAN. This test case is only applicable for emrtd which supports CAN. TA, PACE, SB Preconditions 1. The "Open epassport Application" procedure MUST have been 12/14

Test scenario performed. PACE with CAN MUST be used. 2. The Chip Authentication mechanism MUST have been performed as well. 3. The Certification Authority Reference MUST have been read from the EF.CVCA file (Primary trust point). 1. Send the given MSE: Set DST APDU to the emrtd. <Cryptogram> contains the following encrypted data objects 83 <L 83 > The Certification Authority Reference MUST be used as read from the EF.CVCA file. 2. Send the appropriate DV-Certificate as specified in the Certificate Set 1 chapter as DV_CERT_1. <Cryptogram> contains the following encrypted data objects 7F 4E <L 7F4E > <certificate body> 5F 37 <L 5F37 > <certificate signature> 3. Send the given MSE: Set DST APDU to the emrtd. <Cryptogram> contains the following encrypted data objects 83 <L 83 > The Certification Holder Reference stored inside the DV-Certificate sent in step 2 has to be used. 4. Send the appropriate IS-Certificate as specified in the Certificate Set 1 chapter as IS_CERT_1. <Cryptogram> contains the following encrypted data objects 7F 4E <L7F4E> <certificate body> 5F 37 <L5F37> <certificate signature> 5. Send the given MSE: Set AT APDU to the emrtd. 0C 22 81 A4 <Lc> 87 <L 87 > 01 <Cryptogram> 8E 08 <Cryptogram> contains the following encrypted data objects 83 <L 83 > <Certification Holder Reference > The Certification Holder Reference stored inside the IS-Certificate sent in step 4 has to be used. 6. Send the given Get Challenge APDU to the emrtd. 0C 84 00 00 0D 97 01 08 8E 08 7. Send the given external authenticate command to the emrtd. 0C 82 00 00 <Lc> 87 <L 87 > 01 <Cryptogram> 8E 08 The CAN MUST be used to build the encrypted terminal signature (SPCD) for the External Authenticate command. IDPICC = CAN. 13/14

Expected results <Cryptogram> contains the encrypted terminal generated signature created with the private key of IS_KEY_01. 1. 90 00 in an SM response 2. 90 00 in an SM response 3. 90 00 in an SM response 4. 90 00 in an SM response 5. 90 00 in an SM response 6. <Eight bytes of random data> 90 00 in an SM response 7. 90 00 in an SM response 4 Complementary tests for layer 7 (LDS) This chapter defines additionnal tests to unit LDS_E Data group 14. 4.1 Unit LDS_ESB Data group 14 4.1.1 Test case ISO7816_ESB_1 This test case is an additional test. Test - ID Purpose Version 1.0 Profile ISO7816_ESB_1 Test the ASN.1 encoding of the StaticBindingInfo TA, PACE, DG14SB Preconditions 1. Data group 14 MUST have been read from the MRTD Test scenario Expected results 1. The data content of the data group 14 MUST be encoded according to the SecurityInfos syntax definition. 2. The SecurityInfos set MUST contain one StaticBindingInfo element containing the Static Binding OID as defined in Annex A. 3. The StaticBindingInfo element MUST contain the version element set to 1. 1. true 2. true 3. true 14/14