Category Archives: interoperability

Eclipse IoT overview

Introduction

A few days before the Eclipse Neon release, the Eclipse Foundation has released several projects in context of IoT (Internet of things). The Eclipse IoT working group is engaged in projects like SmartHome, Kura, Paho and OM2M.

The Internet of Things is all about connecting devices (sensors and actuators) to the internet. You can find these devices in automobiles, wearables, industrial factories, homes, etc. A key challenge is the complexity of implementing an IoT solution where you need to deal with various hardware platforms, manage the IoT gateways to connect the devices to the internet, manage the connectivity and interoperability, and integrate the data in the existing systems and databases.

An important way to reduce this complexity is to create reusable libraries and frameworks. As a result these frameworks are abstract and implement key features. Consequently right here is the approach of Eclipse IoT delivering several technologies combined in an open source stack with all key features and standards that you need to develop your own IoT solution. Furthermore the Eclipse Foundation set up a community with more than 200 contributors to assure the enhancement of the IoT stack.

The current release includes Eclipse SmartHome Version 0.8 and Eclipse Paho Version 1.2. The projects Eclipse Kura and Eclipse OM2M will be available later this month. Additionally, the foundation starts a new project proposal called Eclipse Kapua. Goal is to create a modular integration platform for IoT devices and smart sensors. On this way there will be a bridge between Operation Technology and Information Technology.

Eclipse IoT

The Eclipse IoT ecosystem contains standards, gateways and of course frameworks. The following paragraphs will describe these modules. In addition you can find a reference to an Eclipse project that is relevant in this domain. Please keep in mind that this list is not complete, there are currently 24 different projects available in context of Eclipse IoT.

IoT stack

The following graphic describes the structure of Eclipse IoT stack. The stack includes frameworks, open communication standards and a gateway to assure management services. Consequently most modules based on Java and OSGi. OSGi describes a modular system and service platform for Java that implements a complete and dynamic component model. Finally the Eclipse IoT stack with its components addresses all key requirements in IoT: interoperability, security and connectivity.

Eclipse Open IoT Stack

Open communication standards

It’s an elementary feature in context of IoT to provide several mechanisms for protocols used in this domain. All devices must be connected, secured and managed. On this way the Eclipse projects in the IoT ecosystem supports the relevant protocols and standards:

MQTT: Eclipse Paho delivers a MQTT client implementation (Java, C/C++, JavaScript). The corresponding MQTT broker is implemented in Eclipse Mosquito (implementation in C). MQTT (Message Queuing Telemetry Transport) is a light-weight publish and subscribe messaging protocol specified in ISO/IEC 20922. Almost the new version 1.2 of Paho includes for example WebSocket support for Java and Pythons clients.
CoAP: Eclipse Californium delivers the CoAP standard in Java, including DTLS support.
Lightweight M2M: The server side of LwM2M is delivered by Eclipse Wakaama (C/C++) and the client side by Eclipse Leshan (Java). Wakaama provides an API for server applications to send commands to registered LwM2M clients. Leshan relies on the Eclipse IoT Californium project for the CoAP and DTLS implementation.
DNSSEC: Eclipse Tiaki provides a DNSSEC implementation in Java. Domain Name System Security Extensions (DNSSEC) is specified by IETF for securing certain kinds of information provided by the Domain Name System (DNS).
DTLS: Eclipse TinyDTLS implements the Data Transport Layer Security (DTLS) standard in C. The implementation covers both the client and the server state machine. DTLS in general is a communication protocol that provides security also for datagram protocols like UDP.

Gateways

A gateway manages the connectivity between devices and provides a platform for the upper applications. Eclipse Kura offers a set of services that helps to manage the devices and applications deployed onto IoT gateways. Same to other Eclipse projects the gateway is based on Java and OSGi services. Kura manages the cloud connectivity, supports different protocols and configures the network.

Frameworks

Eclipse IoT provides a set of frameworks:

Eclipse SmartHome is a set of Java and OSGi services for building and running Smart Homes. It is designed to run on “simple” devices like Raspberry Pi, BeagleBone Black or Intel Edison. Additionally, this framework supports typical protocols with their diversity used in Smart Homes like EnOcean, KNX or ZigBee. Most of all this way allows the devices and systems to communicate with each other. Almost the new version 0.8 of Eclipse Smart Home contains now a new REST interface that allows easier interaction with the clients. Furthermore, new bindings are supported, e.g. for DigitalStrom.
Eclipse SCADA is a set of Java and OSGi services that implements nearly all of the services required to run a SCADA (supervisory control and data acquisition) system. As one type of an Industrial Control System (ICS) Eclipse SCADA delivers functions for data acquisition, monitoring, visualization, etc. Additionally, the framework supports typical industrial automation standards like ModBus, Siemens PLC, SNMP and OPC.
Eclipse OM2M is one implementation of ETSI’s MSM standard. This implementation provides a horizontal Service Capability Layer (SCL) to be deployed in a M2M network.

Summary

In conclusion Eclipse IoT provides an open source stack including all relevant frameworks, protocols and standards to develop your own IoT application. The stack allows you to develop new devices but also to modernise existing ‘legacy’ devices.

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.

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.

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

2 Replies

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

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.

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.

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

6 Replies

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

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.

Results SAC Interoperability Test in Madrid 2014

2 Replies

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:

The following diagram shows the failures per sample:

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

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:

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)

1 Reply

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)

5 Replies

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.

protocolbench

ideas about modeling and testing of communication protocols

Category Archives: interoperability

Eclipse IoT overview

Introduction

Eclipse IoT

IoT stack

Open communication standards

Gateways

Frameworks

Summary

First results of eMRTD Interoperability Test 2016

Maintenance release of BSI TR-03105 Part 5.1

Interoperability Test during SDW in May 2016

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

Introduction

New test cases in TR-03105 Part 5.1

New test cases for PACE/SAC

New test cases for LDS 1.8

Adapted test cases in TR-03105

Next steps

Mapping between protocols and test specifications

Introduction

Mapping between protocols and test specifications

Abbreviation of protocols referred here

Test Specifications referred here

Update (30.11.2015)

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

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

Update of ICAO Doc 9303 Edition

Results SAC Interoperability Test in Madrid 2014

Interoperability Test for Supplemental Access Control (SAC)

Automatic border control (eGate)