Category Archives: test specification

Call for Participation: Interoperability Test 2017 in Ispra

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!

Flattr this!

How to assure interoperability?

Motivation

Typically protocols are connecting two different systems. In an open system with several stakeholders interoperability between these systems is a fundamental requirement. To assure this interoperability there are various way. In this blog post I present you two popular approaches in cooperation with my colleague Dr. Guido Frank who works at the German Federal Office for Information Security (BSI).

Interoperability

Interoperability is a characteristic of a product or system, whose interfaces are completely understood, to work with other products or systems, present or future, in either implementation or access, without any restrictions (Source: Wikipedia).

puzzle - interoperability test

From a system perspective, this means that all implementations need to comply to the same technical specifications. Interoperability is essential because these systems are open systems with different stakeholders. It refers to the collaboration ability of cross-system protocols.

Crossover Testing vs. Conformity Testing

To ensure interoperability, implementations need to be tested. In general, there are different approaches to test systems or implementations.

Crossover Testing

The scope of a crossover test is to test every system component with all other system components. This procedure allows to detect incompatibilities between existing implementations with a fixed release status.

The efforts to perform this kind of test increases disproportionately with every additional instance of the system. Therefore these kinds of tests can practically be performed only with a small number of involved test partners. The following figure illustrates the interaction between different systems in a crossover test.

Crossover Testing

Crossover Testing

Another problem of crossover testing is maintenance: every new implementation or any new version of existing implementations must be tested with every corresponding system, which again increases the testing efforts significantly. A benefit of crossover testing can be found in the early phase of developing when crossover testing helps the developer to implement their own system and can be used as an indicator to use the right way. On the other side, this kind of testing only indicates a positive test case with two correct systems to test (“smoke test”). The behaviour of the systems in bad cases is not tested. Additionally, with two different systems to be tested in a crossover test it’s difficult to decide which system behaves correctly in case of a failure and which implementation has to be changed.

Conformity Testing

The purpose of conformity tests is to verify that a system implements the specifications correctly (i.e. it “conforms” to the specifications).  These specifications need to be defined by stakeholders and finally implemented e.g. by test labs to run their conformity test tools.

This way these test suites verify the implementation under test with protocol data units which mimic both “correct” and “incorrect” behaviour of the system. The figure below illustrates the interactions between the test suite implementation and the system in a conformity test. The test definitions have to be tested with regard to harmonised interpretation among test participants.

Conformity Testing

Conformity Testing

Conclusion

Both approaches of testing allow assuring interoperability to other systems components to a certain extent. But with increasing complexity of the systems to be tested and the increasing number of systems at all the crossover testing is getting more and more extensive. Only conformity testing scales well with the complexity and the number of systems in an adequate way. The following diagram illustrates the increasing efforts of crossover tests in relation to conformity test.

Compared efforts of crossover testing and conformity testing

Compared efforts of crossover testing and conformity testing

Direct tests between a subset of implementations are be useful during implementation or integration phase of a node.  Such tests could also be performed via bilateral appointment between different stakeholders, e.g. via pilots. Experience from such test could also be used as additional input for conformity tests. Crossover testing or a central coordination of such tests would not be necessary for this purpose. As soon as there are several system components to be tested, conformity testing should be chosen.

The benefits of such an approach of interoperability testing can also be seen in several so called ‘InterOp tests‘ that have been performed for more than a decade in context of eMRTD. Detailed failure analysis allows to improve the stability of the whole eMRTD system. Additionally, the results of ‘InterOp tests’ helps not only to improve the stability of ePassports and inspection systems but also to improve the quality of (test) specifications and test tools.

Another open system with several vendors is banking. All cash cards or credit cards must fulfill international test specifications. This way of interoperability testing allows customers to use their cards worldwide at cash machines of various banks.

To assure systematic interoperability, it is necessary to set up conformity test specifications that systematically test the requirements as defined in the technical specifications. The tests should not only define good cases but also bad cases that mirror the pitfalls typically occurring in a system. Only this way allows to assure real system-wide interoperability.

Setup of test specification

Important components of a conformance test specifications are:

  • Description of general test requirements
  • Test setup / Testing environment
  • Definition of suitable test profiles / implementation profiles
  • Implementation Conformance Statement (ICS)
  • Definition of testing or configuration data
  • Definition of test cases according to a unified data structure
  • Each test case should concentrate on a single feature to be tested

The following structure of a test specification has been established since the beginning of eMRTD testing in 2005. It is based on the ISO/OSI layer model where data is tested on layer 7 and protocols are tested on layer 6.

Typical structure of a test case in this context:

  • Test case ID: unique identifier for each test case
  • Purpose: objective of the test case
  • Version: current version of this test case independent from the test specification
  • Reference: where is this feature / behaviour specified
  • Preconditions: setup of test case
  • Test scenario: description of test case, step by step
  • Postconditions: setdown of test case

Test cases can be combined in test suites to cluster test cases of similar topics or objectives. As the test specifications need to be implemented in suitable testing tools, it is useful to define the test cases already in a way, that eases their implementation, e.g. via XML using a suitable XML scheme.

 

Flattr this!

eMRTD Test Specification Overview

Currently I’m preparing a project where an ePassport has to be tested. These tests start with the booklet and end with the chip. During the preparation the need for a test specification overview popped up. This need was the root of a new service here on this blog: an overview of all current specifications in the domains of this blog starting with eMRTDs and their corresponding inspection systems.
Keep calm and continue testingTo list all current specifications I’ve added a new page called ‘test specifications‘ in menu above. I will keep this list up-to-date in the future. Finally with every new version of a test specification I will update this list. Currently the list contains test specification released by ICAO and BSI. Both organisations are in the front of implementing tests in context of eMRTD and the corresponding back-end-systems. These certification schemes of BSI and ANSSI also base on these test specification.

Test specifications are “living documents”, which causes several modifications over the time. You need the test specifications, listed here, to prove conformity and finally certify your passport or inspection system.

With every new protocol you need some more or some modified test cases in the specifications. And also maintenance is an important fact to keep the test cases up-to-date. Additionally, I will list also test specifications of other domains like IoT in the closer future.

So have a look at this page next time when you’re back on this blog.

Flattr this!

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,ICAO Logo
    • 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.

Flattr this!

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

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.ICAO Part 3 Cover

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

Flattr this!

First results of eMRTD Interoperability Test 2016

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:

Logo of SDW InteropTest

  • 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:

  1. There is a very good quality of the eMRTD samples.
  2. 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).

Flattr this!

Maintenance release of BSI TR-03105 Part 5.1

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.

Maintenance of TR-03105 for inspection systems, http://www.iconarchive.com/artist/oxygen-icons.org.html

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.

Flattr this!

Interoperability Test during SDW in May 2016

puzzle - interoperability test

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

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

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.

Flattr this!

Update of BSI TR-03105 Part 5.1 available (V1.4)

Introduction

There is an update of BSI technical guideline TR-03105 Part 5.1 available. The new version 1.4 of this test specification for inspection systems with EACv1 is focusing on PACE (including PACE-CAM) and LDS 1.8.

Cover of BSI TR-03105 Part 5.1

Cover of BSI TR-03105 Part 5.1

The new version of TR-03105 is now available in new BSI layout. Additionally, there are some minor editorial changes and updated references (e.g. new Doc9303 is referenced).

New test cases in TR-03105 Part 5.1

The Standard Inspection Procedure (SIP) includes now also PACE and there is a new configuration specified for default PACE passport.

New test cases for PACE/SAC

Here is a list of new test cases, added in TR-03105 5.1 to test PACE, including PACE-CAM:

  • ISO7816_G_01: Correct execution of PACE protocols
  • ISO7816_G_02: Check supported standardized domain parameters with Generic Mapping
  • ISO7816_G_03: Check supported standardized domain parameters with Integrated Mapping
  • ISO7816_G_04: Check supported algorithms
  • ISO7816_G_05: Check PACE with additional entries in SecurityInfos
  • ISO7816_G_06: Check selection of standardized Domain Parameters and algorithms
  • ISO7816_G_07: EF.CardAccess contains two PACEInfo and PACEDomainParameter
  • ISO7816_G_08: Abort PACE because of SW error code during MSE:Set AT
  • ISO7816_G_09: Error on the nonce – Value modifications after first General Authenticate
  • ISO7816_G_10: Error on General Authenticate step 1 command
  • ISO7816_G_11: Error on General Authenticate step 1 command – bad tag (use 90h instead of 80h)
  • ISO7816_G_12: Error on General Authenticate step 2 command
  • ISO7816_G_13: Error on General Authenticate step 2 command bad tag (use 92h instead of 82h)
  • ISO7816_G_14: Abort PACE because of error in GA step 2 (GM)
  • ISO7816_G_15: Abort PACE because of error in GA step 2 (IM)
  • ISO7816_G_16: Error in General Authenticate step 2 command – error on mapping data – all ECDH public key components
  • ISO7816_G_17: Error in General Authenticate step 2 command – error on mapping data – all DH public key components
  • ISO7816_G_18: Error in General Authenticate step 3 command
  • ISO7816_G_19: Error in General Authenticate step 3 command – bad tag (use 94h instead of 84h)
  • ISO7816_G_20: Abort PACE because of error in GA step 3
  • ISO7816_G_21: Error on General Authenticate step 3 command – error on ephemeral public key – all ECDH public key components
  • ISO7816_G_22: Error on General Authenticate step 3 command – error on ephemeral public key – all DH public key components
  • ISO7816_G_23: Abort PACE because of identical ephemeral public keys
  • ISO7816_G_24: Error on General Authenticate step 4 command
  • ISO7816_G_25: Error on General Authenticate step 4 command – bad tag (use 96h instead of 86h)
  • ISO7816_G_26: Abort PACE because of error in GA step 4
  • ISO7816_G_27: Abort PACE because of TLV error on EF.CardAccess
  • ISO7816_G_28: Abort PACE because of incorrect parameterId in PACEInfo
  • ISO7816_G_29: PACE-CAM with missing tag 8Ah but correct ECAD
  • ISO7816_G_30: PACE-CAM with incorrectly encoded tag ECAD (no octet string)
  • ISO7816_G_31: PACE-CAM with wrong tag ECAD
  • ISO7816_G_32: PACE-CAM with wrong tag 8Ah (use 8Bh) but correct ECAD
  • ISO7816_G_33: PACE-CAM with correct tag 8Ah but missing ECAD
  • ISO7816_G_34: PACE-CAM with Passive Authentication
  • ISO7816_G_35: Return additional tag 8Ah during PACE-GM
  • ISO7816_G_36: Use invalid OID for PACE-CAM in EF.CardAccess
  • ISO7816_G_37: Use EF.CardAccess with PACEInfo only for PACE-CAM (no GM or IM)
  • ISO7816_G_38: Use DG14 without SecurityInfo during PACE-CAM
  • ISO7816_G_39: Use EF.CardSecurity with wrong ChipAuthenticationPublicKeyInfo during PACE-CAM
  • ISO7816_G_40: Use EF.CardSecurity without ChipAuthenticationPublicKeyInfo during PACE-CAM
  • ISO7816_G_41: Check supported standardized domain parameters with Chip Authentication Mapping

New test cases for LDS 1.8

Here is a list of new test cases, added in TR-03105 5.1 to test LDS 1.8:

  • LDS_A_10: EF.COM with LDS Version 1.8
  • LDS_H_86: EF.SOD with LDS Version 1.8
  • LDS_H_87: Security Object with LDS Version 1.8 but with wrong version number
  • LDS_H_88: Security Object with LDS Version 1.7 but version number 1
  • LDS_H_89: EF.SOD with future LDS Version 1.9

Adapted test cases in TR-03105

Here is a list of modified test cases in TR-03105 5.1:

  • In chapter 7.1.2 the OIDs for plain signatures are corrected.
  • ISO7816_D_06: Added second public key with key reference FE in EF.DG14
  • ISO7816_D_15: Use configuration of D_06 to assure the use of wrong key reference
  • ISO7816_F_02: Added signature algorithm (ECDSA with SHA1) in EF.DG14 to fulfil requirements
  • ISO7816_F_08: Changed expected results in transfer interface: TA and CA might not be performed
  • LDS_A_06: Correction in EF.COM where Unicode Version 5 must be encoded
  • LDS_D_08: The referenced invalid format owner (0102) is used by JTC1/SC27 IT Security Techniques (see www.ibia.org/base/cbeff/biometric_org.phpx). So the referenced invalid format owner was changed to ’87 02 01 FF’.
  • LDS_E_07: The referenced invalid format owner (0102) is used by JTC1/SC27 IT Security Techniques (see www.ibia.org/base/cbeff/_biometric_org.phpx). So the referenced invalid format owner was changed to ’87 02 01 FF’.
  • LDS_H_04: Correction in EF.SOD where RSASSA-PKCS1_v15 must be used
  • LDS_H_50: The serial number is mandatory, so expected result was changed to “FAIL”

Next steps

The version 1.4 of BSI TR-03105 Part 5.1 is a backport of ISO18745-4. Until the ISO test specification is under construction and not released, TR-03105 can be used as an interims version for testing inspection systems using PACE/SAC.

 

Flattr this!

Mapping between protocols and test specifications

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

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.

Flattr this!

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

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.

Flattr this!

Testing ePassport Readers using TTCN-3

Currently you can find the well-known test tool Titan under the patronage of the Eclipse Foundation (proposal). This tool was developed by Ericsson several years ago to the test internet protocol (IP). Titan bases on TTCN-3, a test language focusing on communication protocols. This keeps me in mind an old project with ETSI where we used TTCN-3 to test ePassport readers concerning BSI TR-3105 part 5.1.

From end of 2009 to middle of 2011 ETSI has conducted a project to develop a test system prototype for conformance testing of ePassport readers. The objective of this project was to design, build and test a TTCN-3 (Testing and Test Control Notation, Version 3) based test system prototype for ePassport reader conformance testing. This project was a joint effort between the European Joint Research Centre (JRC) in Ispra (Italy) and ETSI in Sophia Antipolis (France). The test language TTCN-3 has already been widely used in many testing projects across different protocols and technologies. However, until this project TTCN-3 has not been applied in the area of contactless smart card testing.

The ETSI Specialists Task Force (STF) 400 with experts from the companies / organisations AMB Consulting, ARH, Comprion, ETSI, FSCOM, HJP Consulting, Masaryk University, Soliatis and Testing Technologies operated this project. The work of this STF has been split into three main phases:

  1. Design, implementation, and use of ePassport test system
  2. Development of ePassport testing framework
  3. Writing of the documentation and dissemination material

Scope of this project was to build a test system to test an inspection system typically used to read ePassports. To demonstrate the basic functionality and the feasibility, a subset of BSI TR-03105 Part 5.1 was specified and implemented in the test system.

The following image describes the architecture of the ePassport reader test system developed during this project:

System architecture of prototype to test ePassport Reader with TTCN-3

Architecture of test system based on TTCN-3 for ePassport readers (Source: ETSI White Paper No.7)

The most significant part in the architecture is “TTCN-3 Test Component”. This module simulates the ePassort behaviour  by receiving APDUs, react to these commands and send result in APDUs back to the SUT (here the ePassport reader).

The successful implementation of a TTCN-3 based test system shows that the use of TTCN-3 fits the requirements of conformance testing of eMRTD or other eID systems. The prototype demonstrates the feasibility of using such formal techniques for protocols which would improve the quality and repeatability of tests and reduce room for interpretation.

An overview of this project and the results were summarized by the colleagues Jean-Marc Chareau, Laurent Velez and Zdenek Riha in ETSI White Paper No 7.

 

 

Flattr this!

Author: .