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:
- Arjo Systems
- Atos IT Solutions and Services
- Canadian Banknote Company
- De La Rue
- Imprimerie Nationale Group
- Iris Corporation Berhad
- NXP Semiconductors
- Oberthur Technologies
- PAV Card
- Polygraph combine ‘Ukraina’
And the following test laboratories performed a subset of tests focusing on PACE (and of course PACE-CAM):
- Keolabs (France)
- 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)
- Test Unit LDS_E (Data Group 14)
- Test Unit LDS_I (EF.CardAccess)
- Test Unit LDS_K (EF.CardSecurity)
Some statistics concerning the samples:
- PACE-CAM was supported in the following types:
- Generic Mapping (GM), Chip Authentication Mapping (CAM): 18 samples
- Integrated Mapping (IM), CAM: 4 samples
- GM, IM and CAM: 4 samples
- 25 samples used LDS1.7
- 1 sample used LDS1.8
- 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).
Thank you for those updates.
It is indeed frustrating that more than ten years later, PA is still a problem and I fully agree with Dr. Seidel that this also happens in operational inspection systems. PA is the single most important security feature in an e-passport and failing to utilise it is really wrong.
Regarding the SAC mechanism, it looks like the dust is settling and it is becoming ready for prime time.
One good question is the impact on performance. Will the exact timings for each implementation be published? Will it be published with the OS/Chip/Vendor details?
Thanks, Yoram, for your feedback. Concerning your questions focusing the performance: as in the last interoperability tests the performance of the chips was not measured. In our test tool we saw chips in London that needed time starting from a few minutes up to 45 minutes. But these measurements cannot be compared because there were also chips tested not optimized for performance or with activated security mechanisms. Maybe the next event will also focusing on performance. This was also requested during the discussion of the test results at SDW.
Diretor at Rótulo Ltda
Thank you for yor quick report.
Your point bellow shall be discussed.
1. Correct implemention of Passive Authentication
2. Some clarification in the specification Doc9303 and finally in the test specification
Thank you for good information about Interoperability Test for 3rd generation e-passport.
If possible, can you upload more detail result of this test?
Actually, I attended this interoperablity test event in SDW2013.
The final test report with detailed information can be found here: http://www.securitydocumentworld.com/creo_main/ajax/includes_download_document.cfm?file_id=3908
Pingback: How to assure interoperability? - protocolbench