Simultaneously with Part 3, the ICAO released also version 2.10 of the test specification ‘RF and Protocol Testing Part 4‘ to test the interoperability of inspection systems (IS) in context of eMRTD. While the Technical Advisory Group (TAG) of ICAO endorsed the update on the ICAO website, from now on the test specification can be referenced officially. Finally in version 2.10 of the test specification there are some significant modifications compared with the previous version 1.01 released in 2013:
Additionally, there are some clarifications and minor editorial changes.
Furthermore you can find a more detailed list of changes and modifications in version 2.10 to test interoperability of inspection systems.
New test cases in Version 2.10 Update
Basically the new test cases are testing the protocol PACE-CAM or make use of the new LDS 1.8 data structure where the LDS version number is stored in EF.SOD (additionally to EF.COM).
ISO7816_C_29: PACE-CAM with missing tag 8Ah but correct ECAD
ISO7816_C_30: PACE-CAM with incorrectly encoded ECAD (no octet string)
ISO7816_C_31: PACE-CAM with wrong ECAD
ISO7816_C_32: PACE-CAM with wrong tag 8Ah (use 8Bh) but correct ECAD
ISO7816_C_33: PACE-CAM with correct tag 8Ah but missing ECAD
ISO7816_C_34: PACE-CAM with Passive Authentication
ISO7816_C_35: Return additional tag 8Ah during PACE-GM
ISO7816_C_36: Use DG14 without SecurityInfo during PACE-CAM
ISO7816_C_37: Use EF.CardSecurity with wrong ChipAuthenticationPublicKey during PACE-CAM
ISO7816_C_38: Use EF.CardSecurity without ChipAuthenticationPublicKeyInfo during PACE-CAM
ISO7816_C_39: Check supported standardized Domain Parameters with Chip Authentication Mapping
ISO7816_G_01: Chip Authentication with DH
ISO7816_G_02: Chip Authentication with ECDH
ISO7816_G_03: DG14 with one key reference
ISO7816_G_04: DG14 with two key references
ISO7816_G_05: DG14 with three key references
ISO7816_G_06: DG14 with invalid key reference
ISO7816_G_07: DG14 with corrupted DH public key
ISO7816_G_08: DG14 with corrupted ECDH public key
ISO7816_G_09: Use old session keys after Chip Authentication
ISO7816_G_10: Verify lifetime of ephemeral keys
ISO7816_G_11: DG14 with invalid DH public key specification
ISO7816_G_12: DG14 with invalid ECDH public key specification
ISO7816_G_13: ChipAuthenticationPublicKeyInfo: key reference does not match key reference in ChipAuthenticationInfo
ISO7816_G_14: Chip Authentication with Extended Length
ISO7816_G_15: Use various status words for invalid key reference
LDS_A_10: EF.COM with LDS version 1.8
LDS_D_35: EF.SOD with LDS Version 1.8
LDS_D_36: Security Object with LDS Version 1.8 but Version wrong number
LDS_D_37: Security Object with LDS Version 1.7 but Version number 1
LDS_D_38: EF.SOD with future LDS Version 1.9
Modified test cases in Version 2.10 Update
Due to the new document structure of version 2.10, it’s difficult to detect all modifications. Therefore please be aware that the list of modified test cases may not be complete and there might be more changes compared to previous version 1.01.
ISO7816_C_04: Added new OID for PACE-CAM in table corresponding to test case
ISO7816_D_07: Test case deleted
With the release of this test specification, version 2.10 is relevant for certification. So from now on, your inspection system must fulfill these conformity tests to achieve a certificate.
There is an update of ICAO’s test specification ‘RF and Protocol Testing Part 3‘ available. The specification is focusing on conformity testing and protocol testing for eMRTDs implementing protocols like BAC and PACE.
The Technical Advisory Group (TAG) of ICAO endorsed the updated release on the ICAO website, so from now on the test specification can be referenced officially. In version 2.10 of the test specification there are some major modifications:
Additional test cases for PACE-CAM (this includes modifications of existing test cases and also new test cases especially for PACE-CAM).
New test suite 7816_S to verify access rights (read and select) of EF.CardSecurity.
New test suite LDS_K to test presence and coding of SecurityInfo structures in EF.CardSecurity
The referenced documents are updated to Doc 9303 Edition 7 and old specifications including supplements are replaced.
With 7th edition of Doc 9303 the wording is changed from ‘PACEv2’ and ‘SAC’ to ‘PACE’.
And of course there are some minor editorial corrections.
The interim version 2.08 of this test specification was used during the interoperability test in London 2016 (first results of this event can be found in a previous post). This version was prepared at the meeting of ISO WG3 TF4R in Berlin to establish a valid version for the test event. Version 2.10 includes all the updates and some minor changes. In the following the update of version 2.10 is listed more detailed.
New test cases in layer 6
ISO7816_O_55: Accessing the EF.CardSecurity file with explicit file selection.
ISO7816_O_56: Accessing the EF.CardSecurity file with implicit file selection (ReadBinary with SFI).
ISO7816_O_57: Accessing the EF.CardSecurity file with ReadBinary. The test verifies the enforcement of SM after the PACE-CAM protocol has been performed successfully.
ISO7816_O_58: Accessing the EF.CardSecurity file with ReadBinary. The test verifies the enforcement of SM after a PACE protocol different from PACE-CAM has been performed successfully.
ISO7816_P_78: Positive test with a complete sequence of PACE without Chip Authentication Mapping commands and with MRZ password. The tag 0x8A during PACE-GM and PACE-IM MUST NOT be returned.
ISO7816_S_01: Accessing EF.CardSecurity with explicit file selection and Read Binary.
ISO7816_S_02: Accessing EF.CardSecurity with implicit file selection (ReadBinary with SFI).
ISO7816_S_03: Accessing EF.CardSecurity with explicit file selection and Read Binary OddIns.
ISO7816_S_04: Accessing EF.CardSecurity with implicit file selection (ReadBinary OddIns with SFI).
Modified test cases in layer 6
ISO7816_P_01: New step 6 and step 7 added for PACE-CAM, Step 5 return new data object 0x8A used in PACE-CAM.
ISO7816_P_02: New step 6 and step 7 added for PACE-CAM, Step 5 return new data object 0x8A used in PACE-CAM.
ISO7816_P_03: Step 5 return new data object 0x8A used in PACE-CAM.
ISO7816_P_14: Step 6 return new data object 0x8A used in PACE-CAM.
ISO7816_P_25: Step 5 return new data object 0x8A used in PACE-CAM.
ISO7816_P_26: Step 5 return new data object 0x8A used in PACE-CAM.
ISO7816_P_27: Step 5 return new data object 0x8A used in PACE-CAM.
ISO7816_P_28: Step 5 return new data object 0x8A used in PACE-CAM.
ISO7816_P_41: Adopted profile to handle PACE-CAM.
ISO7816_P_42: Adopted profile to handle PACE-CAM.
ISO7816_P_43: Adopted profile, step 5 return new data object 0x8A used in PACE-CAM.
ISO7816_P_44: Adopted profile, Step 5 return new data object 0x8A used in PACE-CAM.
ISO7816_P_45: Adopted profile, step 5 return new data object 0x8A used in PACE-CAM.
ISO7816_P_46: Adopted profile, step 5 return new data object 0x8A used in PACE-CAM.
ISO7816_P_49: Adopted profile to handle PACE-CAM.
ISO7816_P_50: Adopted profile to handle PACE-CAM.
ISO7816_P_68: Adopted purpose.
ISO7816_P_73: Step 5 return new data object 0x8A used in PACE-CAM.
ISO7816_P_74: Step 5 return new data object 0x8A used in PACE-CAM.
ISO7816_R_05: Correction in referenced RFC.
ISO7816_R_06: Correction in referenced RFC.
New test cases in layer 7
LDS_E_09: Test that EF.DG14 contains at least one valid set of SecurityInfos for Chip Authentication. A chip supporting PACE-CAM must also support CA.
LDS_I_05: Verify that EF.CardAccess contains at least one valid PACEInfo for PACE-GM or PACE-IM as an additional mapping procedure if PACE-CAM is supported.
LDS_K_01: Test the ASN.1 encoding of the SecurityInfos.
LDS_K_02: Verify the ASN.1 encoding of the ChipAuthenticationPublicKey.
LDS_K_03: Test the coherency between the EF.CardSecurity and EF.CardAccess.
LDS_K_04: Verify that the parameterID also denotes the ID of the Chip Authentication key used, i.e. the chip MUST provide a ChipAuthenticationPublicKeyInfo with keyID equal to parameterID.
Modified test cases in layer 7
LDS_I_02: Added OIDs for PACE-CAM and new step 3 (to check that a valid OID is present for each declared configuration).
LDS_I_03: Added OID for PACE-CAM.
LDS_J_04: Correction in referenced RFC.
Previous ideas to migrate this test specification to an ISO document are canceled due to political reasons. Part 3 (eMRTD) and Part 4 (inspection systems) will be ICAO documents furthermore whereas Part 1 (durability of ePassports) and Part 2 (contactless interface) are still migrated to ISO documents (ISO 18745-1 and ISO 18745-2).
During 10th Security Document World 2016 an additional Interoperability Test for eMRTD with PACE took place in London. In context of ePassports this was the 14th event starting 2003 on Canberra. This time there were two test labs involved, 17 document providers and twelve inspection system providers. Here I will focus on the conformity test including test labs and document providers and the InteropTest results. The event was organised by the colleagues of secunet. The following document providers delivered in sum 27 samples:
Atos IT Solutions and Services
Canadian Banknote Company
De La Rue
Imprimerie Nationale Group
Iris Corporation Berhad
Polygraph combine ‘Ukraina’
And the following test laboratories performed a subset of tests focusing on PACE (and of course PACE-CAM):
HJP Consulting / TÜViT (Germany)
The test cases performed during the event based on ICAO’s test specification ‘RF Protocol and Application Test Standard for eMRTD – Part 3‘ Version 2.08 RC2 including some minor adaptions based on the last WG3TF4 meeting in Berlin. The final version 2.08 of this test specification will be released soon and deltas will be listed in an additional blog post here. With focus on PACE-CAM the following test suites were performed by both test labs:
Test Unit 7816_O (Security Conditions for PACE-protected eMRTDs)
Test Unit 7816_P (Password Authenticated Connection Establishment)
Test Unit 7816_Q (Select and Read EF.CardAccess)
Test Unit 7816_S (Select and Read EF.CardSecurity)
1 sample used LDS2.0 (with backward compatibility to LDS1.7)
In the preliminary InteropTest results presented by Michael Schlüter during the SDW he mentioned, that 8502 test cases were performed during conformity testing by the test labs and 98% of the relevant test cases were passed by the samples. Additionally, the test results of both labs were fairly consistent. There was one test case that causes the most failures and this test case verifies ChipAuthenticationPublicKey in EF.CardSecurity (LDS_K_2). Here we need some clarification in the specification Doc9303 and finally in the test specification.
During the crossover test there were three problems detected: At first the sequence of PACE, CA and TA was performed correctly while the sequence of PACE-CAM and TA causes some problems during the inspection procedure of the readers. This might be based in the fact, that PACE-CAM is specified in an ICAO document and TA in a BSI document. Some inspection systems had also problems with alternative File IDs for EF.CVCA. The alternative FID can be defined in TerminalAuthenticationInfo (see A.1.1.3 in TR-03110 Part 3) and must be used by the inspection systems to address and read EF.CVCA. But a bad surprise in the InteropTest results was, that around 50% of the inspection systems don’t perform Passive Authentication (PA) correctly. During the preparation of the InteropTest a wrong CSCA certificate was distributed and 50% of the systems have not detected this wrong certificate, this means: 50% of the inspection systems failed in Passive Authentication! During the conference Dr. Uwe Seidel (Bundeskriminalamt, BKA) noticed, that this number mirrors the real world and that in fact PA is currently a real problem in border control.
The InteropTest results can be summed up in two statements:
There is a very good quality of the eMRTD samples.
Reader vendors have still some work to do, especially to implement Passive Authentication correctly.
A detailed test report of this event and the InteropTest results will be published by secunet in June 2016.
Update: The final test report can now be downloaded here (after a short registration at the SDW website).
The German BSI has published a maintenance release of technical guideline TR-03105 Part 5.1 Version 1.41 for inspection systems with Extended Access Control (EAC).
Since last release of TR-03105 several (mostly editorial) comments were resolved and integrated in this maintenance release. Part 5.1 describes conformity tests for inspection systems with protocols like PACE, Terminal Authentication and Chip Authentication typically used at (automatic) border control, e.g. eGates.
Besides some editorial changes the new version 1.41 contains the following modifications:
ISO7816_G_36: If a EF.CardAccess contains an invalid OID for PACE-CAM, the inspection system shall use an alternative mapping protocol, that is supported by the chip.
ISO7816_G_37: This test case is deleted, because it’s not necessary for an inspection system to check that GM and IM are also supported by the chip besides PACE-CAM.
ISO7816_G_41: Curves with parameterID 0, 1 and 2 are based on DH and DH is not supported in context of PACE-CAM. So these curves are deleted.
LDS_H_86: Correction in expected result (PASS instead of FAIL).
Chapter 7: Relevant algorithms and OIDs for PACE, that must be supported by the inspection system, are added.
Chapter 7: Update of hashing algorithms.
For the next major update there should be a discussion how to handle fingerprints (data group 3, EF.DG3) and iris (data group 4, EF.DG4) of people who don’t have a finger or an iris. In this case these data groups should store an empty but valid data structure. Currently there are no test cases specified for these situations in TR-03105 Part 5.1. But inspection systems should be able to handle such cases also, of course.
So you can see, that test specifications in context of eMRTD (ePassports) and inspection systems are always in progress. If you have any comments concerning these test specifications or ideas of test cases, that should also be performed focusing on interoperability, please don’t hesitate to contact me or leave a comment.
Another interoperability test in context of ePassports (eMRTD) and inspection systems will be performed during SecurityDocumentWorld 2016 in London. The test will be focused on Supplemental Access Control (SAC) respective PACEv2, a security protocol to protect personal data stored in electronic ID documents.
An interoperability test is similar to a plugtest performed e.g. by ETSI. It’s an event during which devices (ePassport, inspection systems and test tools) are tested for interoperability with emerging standards by physically connecting them. This procedure is called crossover testing and allows all vendors to test their devices against other devices. The efforts to perform this kind of test increases very strongly with every ePassport and inspection system. Therefore these kind of tests can be performed only with a small number of devices under test.
Additionally, there is the opportunity besides this crossover tests to test the devices against conformity test suites implemented in test tools like open source tool GlobalTester. This procedure reduces efforts and allows comprehensive failure analyses of the devices like ePassports or inspection systems. To assure interoperability it is state of the art to set up test specifications. These specifications are implemented by the test labs respectively in the test tools they use.
This posting describes the current relation between test specifications and the protocols used in context of ePassports (eMRTD) and eID cards including their associated readers (terminals) and inspection systems.
This mapping reflects the current(!) status quo of protocols and their test specifications. All these specifications are in intensive editing at present.
Mapping between protocols and test specifications
The following image represents the mapping between protocols and the corresponding test specifications:
Mapping between protocols and test specifications in context of eID
You can see all protocols used currently in context of ePassports and eID cards in the rows and in the columns you can find specifications focusing on testing these protocols. For example you can find the test cases for Active Authentcation in the specification ICAO TR Protocol Testing Part 3 for chips and in BSI TR-03105 Part 5.1 for inspection systems.
As soon as there are updates available I will present here in this blog the new structure of these test specifications, including new protocols like Pseudonymous Signatures (PS), Chip Authentication Version 3 (CAv3) or Enhanced Role Authentication (ERA).
There is an maintenance update of ICAO’s test specification ‘RF and Protocol Testing Part 3‘ available since today. The specification is focusing on conformity testing and protocol testing for ePassports implementing protocols like BAC and Supplemental Access Control (SAC) respective PACE v2.
The Technical Advisory Group (TAG) of ICAO endorsed the release on the ICAO website, so from now on the test specification can be referenced officially. In version 2.07 of the test specification there are no technical or fundamental changes, but editorial changes. The following test cases are modified in the new release 2.07:
ISO7816_B_16: Profile corrected
ISO7816_B_26: Added version
ISO7816_B_34: Profile corrected
ISO7816_B_52: Profile corrected
ISO7816_D_06: Updated version
ISO7816_D_09 – ISO7816_D_22: Profile corrected and version updated
ISO7816_E_09 – ISO7816_E_22: Profile corrected and version updated
ISO7816_F_20: Profile corrected and version updated
ISO7816_G_20: Profile corrected and version updated
ISO7816_O_12: Deleted obsolete Test-ID
ISO7816_O_13: Corrected sequence tags
ISO7816_O_31: Deleted obsolete Test-ID
ISO7816_O_35: Added missing caption
ISO7816_P_xx: Deleted sample in description of step 1 (‘i.e. more than one set of
domain parameters are available for PACE’)
ISO7816_P_04: Corrected numbering in expected results
ISO7816_P_06: Corrected numbering in expected results
ISO7816_P_07: Corrected numbering in expected results
ISO7816_P_14: Updated version
ISO7816_P_74: In preconditions step 3 concretized concerning PACEInfos in EF.CardAccess
ISO7816_Q_03: Added missing reference TR-SAC
LDS_D_06: Corrected typos in step 8
With the new edition of Doc 9303 several technical reports are now obsolete except the test specifications. These test specifications are still independent documents.
International Civil Aviation Organization (ICAO) has released the seventh edition of ICAO Doc 9303. This document is the de-facto standard for machine readable travel documents (MRTD). It specifies passports and visas starting with the dimensions of the travel document and ending with the specification of protocols used by the chip integrated in travel documents.
A fundamental problem of the old sixth edition of Doc 9303 (released 2006) resides in the fact, that there are in sum 14 supplemental documents. All of these supplements include clarifications and corrections of Doc 9303, e.g. Supplement 14 contains 253 different issues. Additionally, there are separate documents specifying new protocols like Supplemental Access Control (SAC) also known as PACE v2. So ICAO started in 2011 to re-structure the specifications with the result that all these technical reports, guidelines and supplements are now consolidated in the seventh edition of ICAO Doc 9303. Also several inconsistencies of the documents are resolved. On this way several technical reports, like TR – Supplemental Access Control for MRTDs V1.1 and TR LDS and PKI Maintenance V2.0, are obsolete now with the seventh edition of Doc 9303.
The new edition of ICAO Doc 9303 consists now of twelve parts:
Part 1: Introduction
Part 2: Specifications for the security of the design, manufacture and issuance of MRTDs
Part 3: Specifications common to all MRTDs
Part 4: Specifications for Machine Readable Passports (MRPs) and other td3 size MRTDs
Part 5: Specifications for td1 size Machine Readable Official Travel Documents (MROTDs)
Part 6: Specifications for td2 size Machine Readable Official Travel Documents (MROTDs)
Part 7: Machine Readable Visas
Part 8: RFU (Reserved for future use): Emergency Travel Documents
Part 9: Deployment of biometric identification and electronic storage of data in eMRTDs
Part 10: Logical Data Structure (LDS) for storage of biometrics and other data in the contactless integrated circuit (IC)
Part 11: Security mechanisms for MRTDs
Part 12: Public Key Infrastructure (PKI) for MRTDs
From a protocol point of view there are two interesting parts in Doc 9303: part 10 describes the data structures used in a smart card to store information. In addition part 11 describes the technical protocols to get access to this data, e.g. Chip Authentication Mapping.
Special thanks to Garleen Tomney-McGann working at ICAO headquarter in Montreal. As a member of the Traveller Identification Programme (TRIP) she has coordinated all the activities resulting in the seventh release of ICAO Doc 9303.
Supplemental Access Control (SAC) is a set of security protocols published by ICAO to protect personal data stored in electronic travel documents like ePassports and ID cards. One protocol of SAC is the well known Password Authenticated Connection Establishment (PACE) protocol, which supplements and enhances Basic Access Control (BAC). PACE was developed originally by the German Federal Office for Information Security (BSI) to provide a cryptographic protocol for the German ID card (Personalausweis).
Currently PACE supports three different kinds of mapping as part of the security protocol execution:
Generic Mapping (GM) based on a Diffie-Hellman Key Agreement,
Integrated Mapping (IM) based on a direct mapping of a field element to the cryptographic group,
Since Version 1.1 of ICAO technical report TR – Supplemental Access Control for MRTDs there is a specification of a third mapping procedure for PACE, the Chip Authentication Mapping (CAM), which extends established Generic Mapping. This third mapping protocol combines PACE and Chip Authentication into only one protocol PACE-CAM. On this way it is possible to perform Chip Authentication Mapping faster than both separate protocols.
The chip indicates the support of Chip Authentication Mapping by the presence of a corresponding PACEInfo structure in the file EF.CardAccess. The Object Identifier (OID) defines the cryptographic parameters that must be used during the mapping. CAM supports AES with key length of 128, 192 and 256. But in contrast to GM and IM there is no support of 3DES (for security reasons) and only support of ECDH.
The mapping phase of the CAM itself is 100% identical to the mapping phase of GM. The ephemeral public keys are encoded as elliptic curve points.
To perform PACE a chain of GENERAL AUTHENTICATE commands is used. For CAM there is a deviation in step 4 when Mutual Authentication is performed. In this step the terminal sends the authentication token of the terminal (tag 0x85) and expects the authentication token of the chip (tag 0x86). Additionally, in CAM the chip sends also encrypted chip authentication data with tag 0x8A to the terminal.
If GENERAL AUTHENTICATION procedure was performed successfully, the terminal must perform the following two steps to authenticate the chip:
Read and verify EF.CardSecurity,
Use the public key of EF.CardSecurity in combination with the mapping data and the encrypted chip authentication data received during CAM to authenticate the chip.
It is necessary to perform Passive Authentication in combination with Chip Authentication Mapping to consider that the chip is genuine.
The benefit of Chip Authentication Mapping is the combination of PACE and Chip Authentication. The combination of both protocols saves time and allows a faster performance than the execution of both protocol separately.
You can find interesting information concerning CAM in the patent of Dr. Dennis Kügler and Dr. Jens Bender in the corresponding document of the German Patent and Trademark Office.
The results of the InterOp test 2013 concerning the new protocol SAC (Supplemental Access Control) are available. The test event was split into two slots – a conformity test (to test if the document conform to the latest ICAO standards) and a crossover test (to test, if each document can be read by the inspection system). A concluding test report is available here. Thanks to Mark Lockie and Michael Schlüter for organizing this successful event.
Next week another ePassport interoperability test takes place in London. The community will join to test their next generation smart cards in ePassports with the new protocol Supplemental Access Control (SAC) as a replacement of Basic Access Control (BAC). BAC was designed in the beginning of this century and will be replaced by SAC in December 2014 latest. The protocol SAC bases on the well known protocol Password Authenticated Connection Establishment (PACE) that was mainly developed by German BSI and that is also used in German ID cards issued since November 2010. PACE is specified in TR-03110.
During the interoperability test vendors of chips and inspections system will test their implementations against current conformity test suites of several test labs. More information can be found here: InterOp 2013.