ideas about modeling and testing of communication protocols

Tag Archives: interoperability

Currently in context of ePassports ICAO LDS 2.0 is a hot topic. Today I would like to tell you some interesting details about an interim version, called LDS 1.8. The Logical Data Structure (LDS) specifies the way to store and protect data on ePassports (eMRTDs). Especially in the context of ePassports, this specification is required for global interoperability. Current eMRTDs are using ICAO LDS 1.7 to organise and store the data. This post describes ICAO LDS 1.8, the difference to LDS 1.7 and the motivation to use this new data structure.

Summary of File Structure (Source: Doc 9303 Part 10)

The specification Doc 9303 Part 10 (‘Logical Data Structure (LDS) for Storage of Biometrics and Other Data in the Contactless Integrated Circuit (IC)’) describes all data groups and elementary files used in context of ePassports. The file EF.COM is a kind of directory where all data groups are listed. Additionally, there is a version number encoded that represents the version number of the local data structure and a Unicode Version that is used (typically 4.0.0).

So with the ‘directory’ of the ePassport, an inspection system should be able to read all relevant files of the chip. The procedure to read the information is explained in a previous posting. But addressing the files via EF.COM is risky because EF.COM cannot be trusted. EF.COM is not hashed and not signed and cannot be verified during Passive Authentication. This implies EF.COM can be manipulated easily and the manipulation in turn can be hidden easily. This way an attacker can downgrade a secure chip e.g. with Extended Access Control (EAC) to a simple chip with Basic Access Control (BAC) only by deleting the files in EF.COM. In other words, this way to detect a file on an ePassport is insecure and should be avoided.

By using the command SELECT FILE, one can also detect a file. With this command you can try to select a file in the file system of the chip and if the chip responds positively you might be sure that this file is available. This way involves the problem that some system integrators personalise the chip with empty data groups. So the chip responds positively to a SELECT FILE command, but the file does not really exist. To put it in a nutshell, this way is not sufficient either.

With ICAO LDS 1.8 all information stored in EF.COM has been duplicated now in file EF.SOD. This means that the EF.COM is deprecated and can be removed from the ePassport with the next LDS version after V1.8. By doing this a file can be detected by reading EF.SOD in a secure way. Without the file EF.COM the ePassport will be even more secure.

From a testing perspective a new logical data structure means some more tests. The ICAO test specification for ePassports is already prepared for the data structure, e.g. test suite LDS_D includes some tests for LDS 1.8, whereas the tests for inspection systems are currently missing.

Conclusion: With ICAO LDS 1.8 you can use a way to describe the content of your ePassport in a secure way. This way the insecure file EF.COM can be omitted in the future and the inspection procedure can use secure EF.SOD to get information about the stored data groups.

Update: You can find a discussion concerning LDS 1.8 on LinkedIn here.

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

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

During the ICAO Regional Seminar on Machine Readable Travel Documents (MRTD) in Madrid from 25th to 27th of June 2014 there will be also the opportunity of an interoperability test for ePassports with Supplemental Access Control (SAC). The protocol SAC is replacing Basic Access Control (BAC) used in ePassports and will be obligatory in EU from December 2014. SAC is a mechanism specified to ensure only authorized parties can wirelessly read information from the RFID chip of an ePassport. SAC is also known as PACE v2 (Password Authenticated Connection Establishment). PACE v1 is used as a basic protocol in the German ID card and was developed and specified by the German BSI.

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 allows all vendors to test their devices against other devices. Additionally, there is the opportunity besides this crossover tests to test the devices against conformity test suites implemented in test tools like GlobalTester. This procedure reduces efforts and allows comprehensive failure analyses of the devices like ePassports or inspection systems. There are well established test specifications available, both for ePassports and for inspection systems. Publishers of these test specifications are the German BSI (TR-03105) or ICAO (TR – RF and Protocol Testing Part 3).

You can find further information corresponding to this event on the ICAO website. The website will be updated frequently.

Back in office after three weeks holiday I would like to show you now one of the high level results doing all these interoperability tests in the domain of ePassports. Today a German consortium (i.a. Bundesdruckerei and Secunet) won a tender for biometric-based eGates rolled out across the country in the next years at several airports. These eGates use well-known protocols as Basic Access Control (BAC) or Supplemental Access Control (SAC) to establish a secure channel between reader and smart card of ePassport via ISO 14443 interface for contactless smart cards. An automatic border control (ABC) like this allows passengers in less than 30 seconds to pass the gate. Currently you can find an alternative of such systems at the airport in Heathrow.

The following figure shows a typical simplified workflow of such a border control system:

To reduce waiting time for passengers the system is using an automatic process. At the beginning the citizen is passing the gate by showing his ePassport. An inspection system scans the machine readable zone of the data page to derivate a cryptographic key to get access to the contactless smart card. As soon as all data groups of chip are read, the inspection system verifies the authenticity of the data to assure validity of the current ePassport chip. In the meantime the face recognition system scans the citizen to get a facial image of him. This image is being compared with the facial image of the chip (biometric verification). If both images are similar and the ePassport is not blacklisted, the citizen can pass the gate.

The results of the InterOp test 2013 concerning the new protocol SAC (Supplemental Access Control) are available. The test event was split into two slots – a conformity test (to test if the document conform to the latest ICAO standards) and a crossover test (to test, if each document can be read by the inspection system). A concluding test report is available here. Thanks to Mark Lockie and Michael Schlüter for organizing this successful event.

Next week another ePassport interoperability test takes place in London. The community will join to test their next generation smart cards in ePassports with the new protocol Supplemental Access Control (SAC) as a replacement of Basic Access Control (BAC). BAC was designed in the beginning of this century and will be replaced by SAC in December 2014 latest. The protocol SAC bases on the well known protocol Password Authenticated Connection Establishment (PACE) that was mainly developed by German BSI and that is also used in German ID cards issued since November 2010. PACE is specified in TR-03110.

During the interoperability test vendors of chips and inspections system will test their implementations against current conformity test suites of several test labs. More information can be found here: InterOp 2013.