Tag Archives: PACE

TR-03105 Part 3.2 V1.5.1 or How I met your master file

What’s new in TR-03105 Part 3.2 Version 1.5.1?

Reference documentation: Re-arranged documents of the same type are now in direct neighbourhood to make them easier to find
Reference documentation: Added ICAO Doc9303 Part 9 and ICAO Doc9303 Part 12
Added a new profile “Master File” for eMRTD supporting a Master File as root directory
Unit ISO7816_J: Clarification, that all test cases of this test unit which require the “Open ePassport Application” procedure must be performed twice (one test run with BAC and one with PACE) if the chip supports both protocols. If the chip only supports one of these protocols (BAC or PACE), only one test run has to be performed with the supported protocol used in the “Open ePassport Application” procedure
Test case ISO7816_J_12: Clarification in expected result (step 1)
Test case ISO7816_L_13: Added new profile “MF”
Test case ISO7816_L_14: Clarification in purpose
Test case ISO7816_L_15: Clarification in purpose
Test case ISO7816_L_16: Clarification in purpose
Some minor editorial changes

The one and only technical change in this version is test case ISO7816_L_13 where the new specified profile “MF” is added. This profile assures that this test case is only performed if the chip supports a Master File. Why is this profile needed? In the field there are several eMRTD without a MF. In case of PACE you need a MF to store files like EF.CadAccess or EF.ATR/INFO. But in the case of BAC a MF is not necessary. In clause 4 of ICAO Doc9303 Part 9 (7th edition) you can find the information “An optional master file (MF) may be the root of the file system” and further on “The need for a master file is determined by the choice of operating systems and optional access conditions”.

Characteristics of smart card file systems

All information of an eMRTD is stored in a file system defined in ISO 7816-4. A usual file system is organized hierarchically into dedicated files (DFs) and elementary files (EFs). Dedicated files can contain elementary files or other dedicated files. Applications are special variants of dedicated files (Application DF) and have to be selected by their DF name indicating the application identifier (AID). After the selection of an application, the file within this application can be accessed. On this way a smart card file system has a typical tree structure, as described in the following figure:

Example for smart card file structure (Source ISO/IEC 7816-4:2013)

Additionally, ICAO Doc 9303 describes in part 10 another sample file strucure with focus on eMRTD. Also in this case the master file is the root of the file system and all aditional files or applications are nodes or leafs of the tree For instance, following figure visuals a sample eMRTD file system including a master file:

Example for eMRTD file system (Source: ICAO Doc 9303 , Part 10 (7th edition, 2015)

Likewise, the eMRTD Application in the figure is the Application DF mentioned above in the ISO 7816 file structure. Both EF and DF can be selected with the APDU called SELECT. Compared to an EF, that is selected with the command ’00 A4 02 0C <Lc> <FID>’, an application is selected by the following APDU: ’00 A4 04 0C <Lc> <AID>’ (where <Lc> length of command, <FID> means File ID and <AID> means Application ID. The difference is in parameter P1 of the APDU: 04 indicates a ‘Select by DF name’ and 02 indicates a ‘Select EF under the current DF’.

Characteristics of a Master File

You can address the master file in almost the same manner as a EF or DF. A master file has s special file identifier, which is reserved only for master files: ‘3F 00′. This FID can be used to select the MF. Therefore ISO 7816 specifies the APDU ’00 A4 00 0C 02 3F 00′ to select the MF. On the other hand ICAO Doc 9303 part 10 (clause 3.9.1.1) specifies an alternative APDU to select MF: ’00 A4 00 0C’. In short: both commands are valid and select the MF. Beyond that, Doc 9303 recommends in the same clause in a note not to use the SELECT MF command. Why might this APDU cause problems? You can find the answer in ISO 7816 (clause 11.1.1): “If the current DF is neither a descendant of, nor identical to the previously selected DF, then the security status specific to the previously selected DF shall be revoked”. To sum up: changing the directory during Secure Messaging results in closing the secure channel and losing the secure session.

Update of ICAO RF and Protocol Test Specification

2 Replies

Introduction

Simultaneously the ICAO released updated and new versions of their ICAO test specifications for eMRTD and corresponding inspection systems. While the Technical Advisory Group (TAG) of ICAO endorsed the update on the ICAO website, from now on these test specifications can be referenced officially and can also be used for certification. Additionally, there is also a new test specification part 5 available focusing on PKI objects like certificates and revocation lists.

ICAO Test Specification Part 3 (eMRTD)

Finally version 2.11 of the ICAO test specification for eMRTDs is a result of two ISO SC17 WG3 TF4 meetings 2017 in Paris and 2018 in Tokyo and also a result of the interoperability test in Ispra 2017. First of all there are some interesting modifications compared with the previous version 2.10 released in 2016:

Test cases and ICS adoption for Chip Authentication Version 1 (test cases are moved from BSI TR-03105 Part 3.2)
Test of command robustness with invalid class bytes are removed
Clarifications concerning PACE test cases
Clarification concerning ISO execution errors
Clarification concerning extended length APDUs used during Active Authentication
Some corrections concerning LDS version 1.8
Additionally, there are some clarifications and minor editorial changes

New test cases in Version 2.11

Most noteworthy the ICAO test specification part 3 contains the following new test cases:

ISO7816_P_79: Negative test case to verify the Secure Messaging handling while PACE access is granted for the SELECT application command (bad send sequence counter)
ISO7816_R_07: Positive test case to verify the behavior of a PACE-protected eMRTD in response to the INTERNAL AUTHENTICATE
Test suite ISO7816_T: New test cases for Chip Authentication (this tests were moved from BSI TR-03105 Part 3.2 with minor corrections and remove robustness test of invalid class bytes)
LDS_E_01: Test the LDS tag of the DG14 object
LDS_E_02: Test the ASN.1 encoding of the SecurityInfos for Chip Authentication
LDS_E_03: Test the ASN.1 encoding of the ChipAuthenticationPublicKeyInfo
LDS_E_04: Test the ASN.1 encoding of the ChipAuthenticationInfo
LDS_K_05: Test the ASN.1 encoding of a PCKS#7 signedData object
LDS_K_06: Test the value that is encoded into the signedData element
LDS_K_07: Test the SignerInfo element of the signedData structure
LDS_K_08: Test the signing certificate used to verify the EF.CardSecurity object

Modified test cases in Version 2.11

The ICAO test specification part 3 contains the following modified test cases:

ISO7816_A_2: SELECT Application command with CLA byte ‘8F’ is removed
ISO7816_C_15: Test case removed (invalid CLA byte)
ISO7816_C_19: Test case removed (invalid CLA byte)
ISO7816_D_2: Test case removed (invalid CLA byte)
ISO7816_E_2: Test case removed (invalid CLA byte)
ISO7816_F_2: Test case removed (invalid CLA byte)
ISO7816_G_2: Test case removed (invalid CLA byte)
ISO7816_P_04: Test case removed (invalid CLA byte)
ISO7816_P_18: Test case removed
ISO7816_P_37: Test case removed (invalid CLA byte)
ISO7816_P_38: Test case removed (invalid CLA byte)
ISO7816_P_39: Test case removed (invalid CLA byte)
ISO7816_P_40: Test case removed (invalid CLA byte)
ISO7816_P_66: Hint, that in test scenario step 1 the length encoding of DO ’80’ must be correct
ISO7816_P_67: Hint, that in test scenario step 1 the length encoding of DO ’80’ must be correct
ISO7816_R_01: Generic length encoding of APDU
ISO7816_R_02: Generic use of DO ’97’ and length encoding of APDU
ISO7816_R_03: Hint, that INTERNAL AUTHENTICATE command must use Secure Messaging if access control mechanism is supported
ISO7816_R_04: Hint, that INTERNAL AUTHENTICATE command must use Secure Messaging if access control mechanism is supported
ISO781_S_03: Padding indicator ’01’ in DO ’85’ is removed (odd ins)
ISO781_S_04: Padding indicator ’01’ in DO ’85’ is removed (odd ins)
LDS_A_03: In EF.COM there is also LDS version 1.8 accepted
LDS_A_05: Purpose of test case is corrected
LDS_C_04: Check that the number of Biometric Information Group Templates (BIGT) is one
LDS_D_04: Check also the LDS security object version in test scenario step 4; a future version of Doc9303 part 10 requires that the signedData certificates field in LDS v1.8
SHALL include the Document Signer Certificate (CDS)
LDS_D_06: Check that LDS Version Info element does not exist in test scenario step 8 and handle also LDS version 1.8 in this test case
LDS_D_07: Check that the validity period of the signing certificate MUST be within the validity period of the country signing certificate in test scenario step 4
Test suite LDS_E: Numbering of test cases has changed
LDS_E_07: Check also the hash algorithm output length of the signatureAlgorithm
LDS_J_05: ECDSA is also be handled in test scenario step 3 from now on

ICAO Test Specification Part 4 (Inspection Systems)

Also ICAO test specification part 4 version 2.11 is the result of a typical ISO process finalized by the same meetings in Paris and Tokyo of ISO SC17 WG3 TF4 mentioned above. Finally this specification contains also some interesting changes compared with the previous version 2.10 released in 2016:

Configuration of default EAC MRTD specifies EF.DG15
Specification of a default PACE-CAM protected eMRTD
Clarifications concerning PACE and PACE-CAM
Additionally, there are some clarifications and minor editorial changes.
Added profile AA.B4 to test signature generation scheme specified in ISO/IEC 9796-2 paragraph B.4.

New test cases in Version 2.11

The ICAO test specification part 4 contains the following new test cases:

ISO7816_E_11: Test case verifies that the inspection system performs the Active Authentication with RSA algorithm in the signature function and B.4 method
ISO7816_B_04: Positive test with BAC protected eMRTD and three line MRZ
ISO7816_G_16: Check correct execution of the Chip Authentication protocol
LDS_B_29: Test verifies that the test object can detect a mismatch between MRZ and EF.DG1 where MRZ uses TD2 format and EF.DG1 uses TD1 format
LDS_B_30: Test verifies that the test object can detect a mismatch between MRZ and EF.DG1 where MRZ uses TD1 format and EF.DG1 uses TD2 format
LDS_D_01: Added test cases for missing algorithm and signature combinations
LDS_D_19: Added test cases for DSA with various SHA algorithms
LDS_D_39: Test case verifies that the inspection system checks the signature in EF.CardSecurity and detects an invalid signature

Modified test cases in Version 2.11

The ICAO test specification part 4 contains the following modified test cases:

ISO7816_C_01: Test case include three line MRZ from now on
ISO7816_C_03: Editorial correction of protocol name
ISO7816_C_29: Use new configuration for PACE CAM protected eMRTD
ISO7816_C_30: Use new configuration for PACE CAM protected eMRTD
ISO7816_C_31: Use new configuration for PACE CAM protected eMRTD
ISO7816_C_32: Use new configuration for PACE CAM protected eMRTD
ISO7816_C_33: Use new configuration for PACE CAM protected eMRTD
ISO7816_C_34: Use a special configuration to indicate that the IS performs Passive Authentication
ISO7816_C_36: Change context form PACE-CAM to PACE (CAM -> GM)
ISO7816_C_39: Use new configuration for PACE CAM protected eMRTD
ISO7816_E_01: Use signature production function B.6
ISO7816_E_02: Clarification of EF.DG14 and specification of EF.DG15 and using of signature production function B.6
ISO7816_E_03: Use signature production function B.6
ISO7816_E_04: Use signature production function B.6
ISO7816_E_05: Use signature production function B.6
ISO7816_E_06: Use signature production function B.6
ISO7816_E_07: Use signature production function B.6
ISO7816_E_08: Use signature production function B.6
ISO7816_E_09: Perform Active Authentication with B.6 method of ISO/IEC 9796-2 and use RSA-SHA1; Hint, that the RSA operation during AA must result in a value bigger than n/2 with n being the modulus to ensure that method B6 is really used in this test case
ISO7816_E_10: Use signature production function B.6
ISO7816_F_03: Test case removed
ISO7816_G_07: Correction of key agreement algorithm (id-CA-DH-3DES-CBC-CBC)
ISO7816_G_11: Correction of key agreement algorithm (id-CA-DH-3DES-CBC-CBC)
ISO7816_G_15: Use default EAC configuration in this test case
LDS_A_01: Correction in EF.COM (removed data groups)
LDS_A_02: Correction in EF.COM (removed data groups)
LDS_A_03: Correction in EF.COM (removed data groups and correction of increased length)
LDS_A_04: Correction in EF.COM (removed data groups)
LDS_A_05: Correction in EF.COM (removed data groups)
LDS_A_06: Correction in EF.COM (removed data groups)
LDS_A_07: Correction in EF.COM (removed data groups)
LDS_A_08: Correction in EF.COM (removed data groups)
LDS_A_09: Correction in EF.COM (removed data groups)
LDS_A_10: Correction in EF.COM (removed data groups)
LDS_C_14: Access condition of EF.DG2 changed from BAC to PACE
LDS_C_17: Corrected ID of configuration
LDS_D_26: Access condition of EF.SOD changed from BAC to PACE
LDS_D_35: Corrected wording in specification of EF.SOD
LDS_D_36: Corrected wording in specification of EF.SOD and corrected title of test case
LDS_D_37: Corrected wording in specification of EF.SOD and corrected title of test case
LDS_D_38: Test case removed
LDS_E_01: Access condition of EF.DG15 changed from BAC to PACE
LDS_E_02: Access condition of EF.DG15 changed from BAC to PACE
LDS_E_03: Access condition of EF.DG15 changed from BAC to PACE
LDS_F_01: Correction in content of EF.DG14 (generic length)
LDS_F_02: Correction in content of EF.DG14 (generic length)
LDS_F_03: Correction in content of EF.DG14 (generic length)

New and noteworthy ICAO documents and updates

As mentioned in the introduction ICAO has release a new test specification for PKI objects. The new part 5 of ICAO test specifications is focusing on various things used in this context like certificates, certificate revocation lists (CRL) as well as master and deviation lists. Furthermore, there is a new version 1.7 of the technical report Visible Digital Seals for Non-Electronic Documents available. Technical report Portrait Quality is released in version 1.0 where reference facial images for eMRTD are specified. Concerning LDS2 the technical report LDS2 – PKI specifies the PKI to support the ICAO LDS2 project including travel records, visa records and additional biometrics. Last but not least there is also a new version of technical report Logical Data Structure (LDS) for Storage of Data in the Contactless IC, Doc 9303-10 LDS 2 – New Applications available at the ICAO website.

First results of eMRTD Interoperability Test 2017 in Ispra

6 Replies

The European Commission (EC) organised another eMRTD interoperability test. This time the event took place in Ispra at the Joint Research Center of the European Union. The objective of this interoperability test was to assure that countries and companies have established a stable PACE protocol in their eMRTD, respective ePassports, and ID cards.

Test setup of eMRTD interoperability test

Every participant had the chance to submit up to two different sets of documents with different implementations. Altogether there were 42 different samples available at the beginning of the event. 2 samples didn’t pass the smoke test and one sample was not suitable to be tested by the labs. All remaining samples were tested in two different test procedures: crossover test and conformity test. Twelve document verification system providers with 16 different solutions took part in the crossover test. And 23 document providers threw 42 sets in the ring (28 countries, 14 industries).

In this blog post the conformity test is focused on, because protocols are in foreground in this kind of test. There were three test labs (Keolabs, UL and secunet) taking part in the interoperability test with their test tools to perform a subset of “ICAO TR RF Protocol and Application Test Standard for e-Passports, Part 3” (Version 2.10). The subset includes the following test suites and test cases:

ISO7816_O: Security conditions for PACE protected eMRTDs
ISO7816_P: Password Authenticated Connection Establishment (PACEv2)
ISO7816_Q: Command READ and SELECT for file EF.CardAccess
LDS_E: Matching between EF.DG14 and EF.CardAccess
LDS_I: Structure of EF.CardAccess
LDS_K: Structure of EF.CardSecurity
LDS_D_06: Test case to perform Passive Authentication

Information concerning documents

The document providers describe in the implementation conformance statement (ICS) the features of their chips. Not all ICS were fulfilled consistently, so the following information concerning the documents should be read carefully. Concerning the LDS version 16 providers reported version 1.7 to be used in their documents. And three reported version 1.8, while all others don’t deliver any information concerning the version number.

The following diagram describes the relation between DH and ECDH in PACE:

PACE algorithms

The following diagram describes the relation of the mapping protocols in PACE:

Mapping protocols

16 documents supported besides the MRZ also a CAN as a password to get access to the stored data.

Again, the number of PACEInfos store in EF.CardAccess varied:

28 documents stored one PACEInfo,
Eight documents stored two PACEInfos,
One stored each three, seven or ten PACEInfos.

Investigations concerning EF.ATR/INFO in documents

The file EF.ATR/INFO allows storing some information about the chip, that allows the reader to handle the chip optimally. On this way the chip can offer the ideal buffer size used with extended length during reading and writing. In context of the event I had a closer look at EF.ATR/INFO. 26 documents of 42 stored an EF.ATR/INFO but 5 of them don’t offer information concerning extended length and buffer sizes there. So at the end I’ve investigated the reading buffer sizes of 21 documents of the eMRTD interoperability test with the following result:

Seven documents support buffer sizes between 1 and 1.5 KByte,
Three documents support buffer sizes between 1.5 and 2 KByte,
Eleven documents support buffer sizes of ~64 KByte.

Buffer sizes in EF.ATR/INFO (reading)

With these large buffer sizes data groups like DG2 storing the facial image or DG3 storing the finger prints can be read in only one command. This allows the inspection system to read the content of the chip faster and improves the reading time at eGates.

Results of conformity testing

During the conformity test, all three test labs performed 18.135 test cases altogether. Less than 1 percent of these test cases failed during the conformity test.

Overall results (layer 6 and layer 7):

Passed: 11.563
Failed: 155 (0,86%)
Not applicable: 6.417

Layer 6 (16.614 test cases performed):

Passed: 10.885
Failed: 124 (0,74%)

Layer 7 (1.521 test cases performed):

Passed: 679
Failed: 32 (2,10%)

The following diagram shows failed test cases per document during the eMRTD interoperability test:

Number of failures per document

The diagram below shows the number of failure per test case during the eMRTD interoperability test:

Failures per test case

Observations during conformity testing

There are minor differences between implementation conformance statement (ICS) and chip.
Test results differ between test labs in some test cases.
There are differences in handling errors at the test tools and labs (e.g. no CAN causes a failure at the one lab and a ‘not applicable’ at the other lab).
Relatively more failures on layer 7 (personalisation) than on layer 6 (COS).
Very good quality of chip and personalisation.
Improvements during the last interoperability tests in London 2016 and Madrid 2014.
Stable specifications (BSI TR-03110, ICAO Doc 9303) and test specifications (BSI TR-03105, ICAO TR Part 3).

Call for Participation: Interoperability Test 2017 in Ispra

1 Reply

The European Commission will organize conformity and interoperability tests for eMRTDs together with a conference on 25th and 26th September 2017. It will be held in the European Commission Joint Research Centre (JRC) premises in Ispra, Italy. The tests will focus on the latest access control specifications (e.g. the operation of the PACE protocol with Chip Authentication Mapping). This security mechanism, known as “Password Authenticated Connection Establishment with Chip Authentication Mapping” (PACE-CAM) is specified in Technical Report BSI TR-03110 “Advanced Security Mechanisms for Machine Readable Travel Documents and eIDAS token” and it combines PACE and Chip Authentication (CA) into one protocol leading to faster ID document verification.

Logo JRC

The conference will take place on the second day (26/09/2017) and will include speakers from the EU Commission, ICAO (requested) and Member States (requested). At its end, the high-level aggregate results of the tests will be presented.

The main beneficiaries of these tests are EU Member States. Depending on the number of EU Member States that will participate in the event, and provided that it is possible from an organisational perspective, a limited number of non-EU ICAO Member States and private sector travel document manufacturers will be allowed to participate in the test (on a first come first serve basis).

The test will focus on the implementation of PACE as specified in the Technical Report “Radio Frequency Protocol and Application Test Standard for eMRTD Part 3 Tests for Application Protocol and Logical Data Structure“, Version: 2.10, July 2016.

You can find the Call for Participation for the interoperability test here with more information concerning preregistration etc. See you in Ispra!

Update of RF and Protocol Testing Part 4 V2.10 online

Introduction

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:

Support of protocol PACE-CAM:
- New test suite ISO7816_G to test Chip Authentication,
- New default configuration including Chip Authentication,
- Updated implementation conformance statement (ICS) to specify IS supporting PACE-CAM,
- Updated list of abbreviations,
Tests for LDS 1.8,
Updated references concerning Doc9303 7th edition,
Added Advanced Inspection Procedure (AIP),
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.

Update of RF and Protocol Testing Part 3 V2.10 online

1 Reply

Introduction

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_I_04: Test case deleted.
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).

First results of eMRTD Interoperability Test 2016

8 Replies

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
Bundesdruckerei
Canadian Banknote Company
cryptovision
De La Rue
Gemalto
ID&Trust
Imprimerie Nationale Group
Iris Corporation Berhad
MaskTech
Morpho
NXP Semiconductors
Oberthur Technologies
PAV Card
Polygraph combine ‘Ukraina’
PWPW

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
LDS:
- 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).

Maintenance release of BSI TR-03105 Part 5.1

1 Reply

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.

Interoperability Test during SDW in May 2016

2 Replies

Puzzle of InteropTest

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.

Crossover Testing

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.

Conformity Testing

There are well established test specifications available, both for ePassports and for inspection systems. Previous interoperability tests took place in Madrid (2014) and London (2013). Both events focused also on SAC/PACE.

If you are interested as a document provider, as a vendor of an inspection system, as a test lab or as an observer, you can register here.

Looking forward to seeing you in London during the InteropTest!

BTW: The EU article 6 group is preparing a document describing how to process an interoperability test and how to prepare such an event.

Mapping between protocols and test specifications

2 Replies

Introduction

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).

Abbreviation of protocols referred here

BAC: Basic Access Control
AA: Active Authentication
PACE: Password Authenticated Connection Establishment
SAC: Supplemental Access Control
CA: Chip Authentication
TA: Terminal Authentication
EAC: Extended Access Control
RI: Restricted Identification
eSign: electronic Signature

Test Specifications referred here

Short Name	Title
TR-03105 3.1	BSI Test plan for eMRTD Application Protocol and Logical Data Structure
TR-03105 3.2	BSI Test plan for eMRTDs with EACv1
TR-03105 3.3	BSI Test plan for eID-Cards with Advanced Security Mechanisms EAC 2.0
TR-03105 3.4	BSI Test plan for eID-cards with eSign-application acc. to BSI TR-03117
TR – RF and Protocol Testing Part 3	ICAO TR – RF and Protocol Testing Part 3
TR-03105 5.1	BSI Test plan for ICAO compliant Inspection Systems with EAC
TR-03105 5.2	BSI Test plan for eID and eSign compliant eCard reader systems with EACv2

Update (30.11.2015)

Once again, you can find some discussions concerning this posting at LinkedIn.

Update of RF and Protocol Testing Part 3 V2.07 online

3 Replies

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.

Update of ICAO Doc 9303 Edition

5 Replies

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.