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

Transcription

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

2 Copyright 2013 by secunet Security Networks AG 2 Final Report,

3 SDW InterOp 2013 Contents Contents Contents... 3 List of Figures... 4 List of Tables... 5 Preface Participants Registered Document Provider Registered Document Verification System Provider Registered Conformity Test Laboratories Operations of tests Registration Tests Conformity Tests Cross Over Tests SDW InterOp 2013 Result Summary General Statistics Registration Test Results SAC/PACE Results Other Security Mechanisms Static vs. Dynamic Binding Windows 7 interoperability issue Conformity Results Cross Over Results Conclusion...18 Final Report,

4 List of Figures SDW InterOp 2013 List of Figures Figure 1: Definition of Dynamic Binding in BSI TR Figure 2 : Definition of Static Binding in BSI TR Figure 3: Process definition for dynamic and static binding from BSI TR Figure 4: Conformity testing: Passed vs. Failed test cases...15 Figure 5: Number of failures per test case...15 Figure 6: Number of samples read successfully per system...17 Figure 7: Successful reads of PACE per passport Final Report,

5 SDW InterOp 2013 List of Tables List of Tables Table 1: Scope of the Conformity Tests... 9 Table 2: General statistics...11 Table 3: PACE Mapping functions...12 Table 4: First PACE Algorithm in EF.CardAccess...12 Table 5: Complete list of all used PACE algorithms...13 Table 6: Other security mechanisms...13 Table 7: Conformity Test cases with the highest number of failures...16 Final Report,

6 Preface SDW InterOp 2013 Preface The SDW InterOp 2013 was held alongside the SDW 2013 on May in London. It continued the series of international epassport interoperability testing. The event was organized by Science Media Partners Ltd; the technical aspects have been supervised by secunet Security Networks AG. The event focused on the new Supplemental Access Control (SAC) mechanism, which will be implemented by various countries from December 31st SAC will be implemented as a supplement to the existing BAC mechanism. Global interoperability is important to make the enhancement reliable for the document verification process. This document summarizes the results of this event. Vendor specific results are only disclosed to the corresponding vendor. 6 Final Report,

7 SDW InterOp 2013 Participants 1 Participants The SDW InterOp 2013 targeted both document manufacturers and document verification system providers. 1.1 Registered Document Provider Registered document manufactures, listed below, could provide a maximum of two sets of documents. Each set contained three identical samples. During the registration process a unique ID (#1 28) was assigned to each document provider. The document sets were marked as Set A or Set B. 3M Security Systems AKD d.o.o. ASK SA Athena Smartcard Bundesdruckerei Canadian Banknote Cryptovision Gemalto Giesecke & Devrient HID Global Huntrust IRIS KOMSCO MaskTech Morpho Oberthur Technologies Orell Füssli Österreichische Staatsdruckerei OVD Kinegram PAV Card GmbH PWPW STC Final Report,

8 Participants SDW InterOp 2013 Toshiba Trüb Trusted Logic T-Systems 1.2 Registered Document Verification System Provider Registered document verification system providers, listed below, were identified by a unique ID (#1 13). 3M Security Systems ARH Inc Bundesdruckerei Canadian Banknote Cross Match Technologies Gemalto Giesecke & Devrient IRIS Morpho Morpho Trust USA PWPW Regula Toshiba 1.3 Registered Conformity Test Laboratories The conformity testing was conducted by four independent test laboratories listed below: They were identified by characters (A D). FIME HJP Consulting Keolabs UL Transaction Security 8 Final Report,

9 SDW InterOp 2013 Operations of tests 2 Operations of tests 2.1 Registration Tests Subsequent to the document registration, secunet started the initial registration test. All registered documents were read in a standard document verification scenario. For this purpose, the secunet Golden Reader Tool Platinum Edition was used. Before document readout, all provided certificates have been imported into the application. The reading process was started in Auto Detect mode. With this mode, the software used the PACE protocol if available; otherwise the BAC mechanism was used. Afterwards the Extended Access Control protocols were performed, if applicable. All data was read from the document and then logged to the hard disk. The logged data will only be available for the corresponding document provider. Chapter 3.2 contains the summary of these tests. 2.2 Conformity Tests Since the SDW InterOp 2013 event focused on the new Supplemental Access Control mechanism, the Conformity Tests applied an appropriate subset of the ICAO test plan for SAC Version %20RF%20and%20Protocol%20Testing%20Part%203%20V2.01.pdf Four independent test laboratories performed the following test units: Test Unit ISO7816_O ISO7816_P ISO7816_Q LDS_E LDS_I Test scope Security Conditions for PACE-protected emrtds Password Authenticated Connection Establishment (PACEv2) Select and Read EF CardAccess Data Group 14 (LDS_E_06 only) EF CardAccess Table 1: Scope of the Conformity Tests Final Report,

10 Operations of tests SDW InterOp 2013 The test results were reported in a standardized CSV file format. The specific results for the documents will only be provided to the corresponding document provider. Chapter 3.3 contains the summary of these tests. 2.3 Cross Over Tests The Cross Over test was performed by the 13 registered document verification systems. All registered document samples were sorted in 13 folders. Each folder contained 3 or 4 document samples. Each document verification system received one folder and conducted Cross Over tests with the received samples and their verification system. The findings of the Cross Over tests were noted on test protocol sheets. After each 30 minute time slot, the folders/samples were shifted to the next desk. During the day, all samples have been tested by all verification systems. The specific results reported by the verification system provider will only be disclosed to the corresponding document provider. Chapter 3.4 contains a summary of these tests. 10 Final Report,

11 SDW InterOp 2013 SDW InterOp 2013 Result Summary 3 SDW InterOp 2013 Result Summary 3.1 General Statistics Test participants Quantity Registered conformity test laboratories 4 Registered document verification systems 13 Registered document provider 27 Number of different document samples 48 Total number of document samples 139 Table 2: General statistics 3.2 Registration Test Results During the registration tests, 48 different sample configurations have been read. 1 sample couldn t be read at all, because of interoperability problem with Windows 7 (see additional note at the end of this chapter). For all remaining 47 samples the PACE protocol has been performed successfully SAC/PACE Results The ICAO standard for Supplemental Access Control (SAC) defines two different variants of the PACE protocols: Generic Mapping and Integrated Mapping. The mapping function used by the samples was distributed as follows: PACE Mapping functions Samples Using Generic Mapping only 43 Using Integrated Mapping only 2 Final Report,

12 SDW InterOp 2013 Result Summary SDW InterOp 2013 Using both Generic and Integrated Mapping 2 Table 3: PACE Mapping functions The PACE algorithms that are supported by the document are defined with the EF.CardAccess. It is possible that more than one algorithm is supported; in this case the EF.CardAccess file contains more than one PACEInfo element. 6 registered samples contained more than one PACEInfo element. Many verification systems use the first PACEInfo element listed in the EF.CardAccess. The following algorithms were listed in the first position of the EF.CardAccess: Algorithm Samples id-pace-ecdh-gm-3des-cbc-cbc 23 id-pace-ecdh-gm-aes-cbc-cmac id-pace-ecdh-gm-aes-cbc-cmac id-pace-ecdh-im-aes-cbc-cmac id-pace-dh-gm-aes-cbc-cmac Table 4: First PACE Algorithm in EF.CardAccess The following Table 5 contains all algorithms included in the EF.CardAccess: Algorithm Samples id-pace-ecdh-gm-3des-cbc-cbc 23 id-pace-ecdh-gm-aes-cbc-cmac id-pace-ecdh-gm-aes-cbc-cmac id-pace-ecdh-im-aes-cbc-cmac id-pace-dh-gm-aes-cbc-cmac id-pace-ecdh-gm-aes-cbc-cmac id-pace-ecdh-im-3des-cbc-cbc 2 12 Final Report,

13 SDW InterOp 2013 SDW InterOp 2013 Result Summary id-pace-ecdh-im-aes-cbc-cmac id-pace-ecdh-im-aes-cbc-cmac Table 5: Complete list of all used PACE algorithms Other Security Mechanisms Besides SAC the following security mechanisms were supported by the registered samples. Algorithm Samples Chip Authentication supported 39 Terminal Authentication supported (For 2 EAC samples, no certificates have been provided) 38 Active Authentication supported 23 CSCA certificate provided for Passive Authentication 46 Table 6: Other security mechanisms Static vs. Dynamic Binding For Terminal Authentication v1 the MRTD needs to bind the terminal s access rights to the secure messaging channel (BSI TR Part 1). This can be done via static or dynamic binding: Dynamic Binding: Figure 1: Definition of Dynamic Binding in BSI TR Final Report,

14 SDW InterOp 2013 Result Summary SDW InterOp 2013 Static Binding: Figure 2 : Definition of Static Binding in BSI TR Figure 3: Process definition for dynamic and static binding from BSI TR documents samples required static binding to access the document Windows 7 interoperability issue Windows 7 starts the communication with the chip as soon as the document is detected by the RF-reader. The smart card daemon tries to identify the chip configuration to determine the supported features of the document regarding login, encryption etc. Some samples are influenced by this communication and this could cause a failure in the subsequent document verification process. This Windows feature to access chips automatically can be disabled. The necessary steps are described in the Microsoft Knowledge Base ( 3.3 Conformity Results Over results were collected from the conformity test laboratories. Due to the limited testing time, not all samples could be tested by all labs. Depending on the sample configuration (for example supported algorithm), the number of applicable test cases is different between the samples. Therefore an effective number of test cases were performed. 93% of these tests were rated as PASS, while 7% failed. The following diagram shows the number of passed (green) vs. failed (red) test cases for each sample: 14 Final Report,

15 SDW InterOp 2013 SDW InterOp 2013 Result Summary Figure 4: Conformity testing: Passed vs. Failed test cases The test results in Figure 4 can be summarized as follows: 25 samples have 100 % positive test results 18 samples have between 90% and 100% positive test results 3 samples have between 50% and 90% positive test results 1 sample with more than 90% failed test cases The following diagram shows the distribution of the failed test cases: Figure 5: Number of failures per test case The following Table 7 details the test cases with the highest number of failures in Figure 5: Final Report,

16 SDW InterOp 2013 Result Summary SDW InterOp 2013 Test Case Description Failures ISO7816_P_10 ISO7816_P_30 ISO7816_P_09 ISO7816_Q_03 ISO7816_Q_04 MSE: Set AT command with an additional data object tag General Authenticate APDU to perform key agreement wrong point (value does not belong to the curve) MSE: Set AT command with a private key reference unknown from the chip Accessing EF.CardAccess with explicit file selection and Read Binary OddIns Accessing EF.CardAccess with implicit file selection (ReadBinary OddIns with SFI) Table 7: Conformity Test cases with the highest number of failures The evaluation of the Conformity Test results does not show any specific aggregation of problems within the ICAO SAC specification or the ICAO test plan. 3.4 Cross Over Results The 13 document verification system providers returned a total number of 619 protocol sheets. The results of the cross over test can be summarized as follows: 8 systems tested the BAC fall back in addition to PACE 10 systems used EAC on the EAC capable samples At least 4 system support Integrated Mapping Only 1 reader could read all 47 samples 70% of the reader were able to read 72% of the samples Only 1 sample could be read by all 13 readers 50% of the samples could be read by 77% of the readers In detail, Figure 6 shows the number of samples for each system that could be read successfully. 16 Final Report,

17 SDW InterOp 2013 SDW InterOp 2013 Result Summary Figure 6: Number of samples read successfully per system The following Figure 7 shows the successful operations of PACE for each sample. Figure 7: Successful reads of PACE per passport The evaluation of the Cross Over results indicates that establishing the Secure Messaging channel after performing the PACE protocol seems to be the biggest issue for the document verification systems. Final Report,

18 Conclusion SDW InterOp Conclusion The majority of the registered samples showed a stable implementation of the SAC mechanism. Even if performed conformity tests covered only a subset of the full test plan, the collected results are very positive. For the document verification system providers the situation is very complex. They have to support each and every algorithm and configuration that is possibly used by the documents in the field. Without the access to document samples it is difficult for them to provide a fully interoperable solution. This generates the need for further InterOp test events and extended conformity test plans for verification systems. 18 Final Report,