Category Archives: interoperability

ICAO LDS 1.8 or How to detect a file on an ePassport

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 eMRTD File Structure (ICAO LDS)

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.

The following code shows the extension in EF.SOD Version 1.8:

LDSSecurityObject ::= SEQUENCE {
  version LDSSecurityObjectVersion,
   hashAlgorithm DigestAlgorithmIdentifier,
   dataGroupHashValues SEQUENCE SIZE (2..ub-DataGroups) OF 
       DataGroupHash
   ldsVersionInfo LDSVersionInfo OPTIONAL
   -- If present, version MUST be V1 }

LDSVersionInfo ::= SEQUENCE {
   ldsVersion PRINTABLE STRING
   unicodeVersion PRINTABLE STRING }

 

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.

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.

Update of ICAO Doc 9303 Edition

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.

ICAO Doc 9303 Title page

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

Results SAC Interoperability Test in Madrid 2014

The European Commission (EC) and the International Civil Aviation Organization (ICAO) has organized a SAC interoperability test in Madrid end of June 2014. The objective of this interoperability test was to assure that European countries are ready to launch Supplemental Access Control (SAC) respective PACEv2 at the end of this year. The following countries participated in the test (in alphabetical order):

  • Australia
  • Austria
  • Belgium
  • Bosnia Herzegovina
  • Czech Republic
  • Finland
  • France
  • Germany
  • Iceland
  • Italy
  • Japan
  • Netherlands
  • Norway
  • Portugal
  • Slovenia
  • Spain
  • Sweden
  • Switzerland

The SAC interoperability test was also open for industry. The following vendors participated with their ePassport solutions (in alphabetical order):

  • 3M
  • Arjowiggins
  • Athena
  • De La Rue
  • EDAPS
  • Gemalto
  • Giesecke & Devrient
  • IRIS
  • Masktech
  • Oberthur
  • PWPW
  • Safran Morpho
  • Toshiba

Every participant had the chance to submit up to two different sets of ePassport with different implementations. Altogether there were 52 samples available during the test session. All ePassports were tested in two different test procedures: Crossover Test and Conformity Test. Here the Conformity Test is focused on, because protocols are in foreground in this kind of test. There were three test labs (Keolabs, TÜViT + HJP Consulting and UL) 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”. The subset includes the following test suites:

  • 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

During the conformity test, all three test labs performed 21.282 test cases altogether. Nearly 3% of these test cases failed during the conformity test.

The following diagram shows the results of the conformity test as part of the SAC interoperability test. There were five samples with zero failure, seven samples with 1 failure, twenty-seven samples with 2, 3 or 4 failures, five samples with 5 up to 20 failures and eight samples with more than twenty failures:

This diagram describes the number of failures per document

The following diagram shows the failures per sample:

This diagram shows the number of failures per document

All documents supported either Integrated Mapping (IM), Generic Mapping (GM) or both. The following diagram shows the distribution of the mapping protocols:

This diagram shows the relation between Generic Mapping and Integrated Mapping

In mapping protocol there is a possibility to choose either ECDH, DH or both of them. The samples of the SAC interoperability test supported mostly ECDH, as showed in the following diagram:

This diagram shows the relation between ECDH and DH in Mapping

The observations of the conformity test (part of SAC interoperability test) are:

  • the document quality varies from “close to release state” to “experimental state”
  • there are different interpretations of padding in EF.CardAccess and EF.DG14, encoding of TerminalAuthenticationInfo in EF.DG14, the use of DO84 in PACE and the use of parameter ID when proprietary or standardized domain parameters are used
  • certificates for EAC protocol (e.g. test case 7816_O_41) were missing or not usable
  • use of different versions of test specification of test labs (Version 2.01 vs. Version 2.06)

Update 1: You can find a discussion concerning the test results on LinkedIn here.

Update 2: You can find the slides of the presentation we hold at the end of the SAC Interoperability Test here.

Interoperability Test for Supplemental Access Control (SAC)

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.

Automatic border control (eGate)

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:
Border Control Process

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.

Results of SAC InterOp Test 2013 available

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.

ePassport Interoperability Test in London

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.

See you in London!