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):
- Bosnia Herzegovina
- Czech Republic
The SAC interoperability test was also open for industry. The following vendors participated with their ePassport solutions (in alphabetical order):
- De La Rue
- Giesecke & Devrient
- Safran Morpho
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: CrossoverTest 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 include 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)
The German BSI and French AFNOR has released an update with minor clarifications of their technical guideline BSI TR-03105 Part 3.2 focusing on conformity tests for ePassports implementing protocols like PACE and SAC (EACv1).
The new version 1.4.1of TR-03105 Part 3.2 includes changes in the following test cases:
- ISO7816_II_2: The missing profile ‘ECDH’ is added to the profile of this test case according to the corresponding test case ISO7816_I_2 in test suite I.
- ISO7816_II_3: There is a new test step added (step 3) to perform the additional command GENERAL AUTHENTICATE to perform key agreement correctly.
- ISO7816_K_19: There are several meanings how to handle the ‘presence’ of a data group. A simple command SELECT to detect a data group of the chip is insufficient and may cause problems. In this test case the presence of data group EF.DG15 should be used as an indicator to perform Active Authentication. In the new version of this test case the wording is adapted to TR-03110 and is changed from “is present” to “if available”. On this way the discussion is moved from TR-03105 to TR-03110. From my point of view it makes sense to check if the relevant data group is listed in file EF.SOD. The information in EF.COM is note secured by Passive Authentication and may be corrupted. Instead of that, EF.SOD is secure and can be used as an indicator of the existence of a file on the chip.
- ISO7816_L_13: In step 9 of this test case the command MUTUAL AUTHENTICATE is performed. In the old version of the specification this command was not complete. The missing Le byte is now added, so the command expects now 40 bytes (or 28 in hex) as response.
- ISO7816_L_14: In the previous version of TR-03105 in step 8 of this test case a SELECT MF with parameter P2 = ’0C’ is performed. ISO7816-4 specifies for bytes b4=1 and b3 =1 that no response data is expected if Le field is absent. This command causes problems on some COS implementations and so the command is replaced by a SELECT with P2 = ’00′ and Le = ’00′.
In the past I have missed such a list for every new released version of test specifications, like BSI TR-03105 or ICAO technical reports. So I hope, this list of modified test cases is helpful for your work in context of ePassport testing. If you are interested, please leave a comment and I will update this list with every new version of test specifications in context of smart cards used in ePassports and ID cards.
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.
The German Federal Office for Information Security (BSI) started a project for an open source eID simulator. The simulator allows a wide range of personalisation, is more flexible than a real card and is free to use.
There is a rising need of test cards for developers of eID clients and companies which want to offer services by using the eID functions of the German ID card (nPA, elektronischer Personalausweis). Today it is difficult to get test cards for developers who want to evaluate the eID functions in their systems. Also for improvements and development of new protocols – but also for tests of established protocols – an open implementation of eID functions would be helpful. Therefore the German BSI started a project with HJP Consulting for an implementation of an open source eID simulator which provides all logical functions of the German ID card.
The website of the project is www.persosim.de (site is in German only) and the first version of the simulator is ready for download there. There is also a virtual driver available, that simulates a card reader. On this way you can simulate card and reader for testing purposes.
Usually smart card applications base on international standards and norms. Also protocols mentioned here in this blog in context of ePassports, like Supplemental Access Control (SAC) or Password Authenticated Connection Establishment (PACE) are based on international ISO standards. The following figure shows the relevant ISO standards for contacted smart cards on the one side and contactless smart cards on the other side:
Smart Cards in context of ISO/OSI Layer Model
The main standard for contacted smart cards is ISO 7816, the main standard for contactless smart cards is ISO 14443. On application level both types of smart cards are using ISO 7816, where all commands (Application Protocol Data Unit, APDU) and files systems are described. Protocols are composed by these commands and using access rights and file systems specified in this standard. The standard ISO 7816-4 (Integrated circuit cards – Part 4: Organization, security and commands for interchange) is important for nearly all smart card applications. Using this standard enable applications to interoperate in various open environments, e.g. a credit card can be read by different terminals all over the world because credit card and terminal are using the same standard.
ISO 14443 specifies contactless mechanisms of smart cards. Smart cards may be type A or type B, both of them communicate via radio at 13.56 MHz. The main differences between these two types concern modulation methods, coding schemes (ISO 14443-2) and protocol initialization procedures (ISO 14443-3). Both types are using the same transmission protocol, described in ISO 14443-4. The transmission protocol specifies mechanisms like data block exchange and waiting time extension. In the contactless world a reader is called proximity coupling device (PCD) and the card itself is
called proximity integrated circuit card (PICC).
During the last months I spent some hours in the specifications of EnOcean telegrams. These telegrams are used in domain of home automation. The EnOcean Alliance publishes all necessary specification on their website. One of the relevant specifications is EnOcean Serial Protocol 3 (ESP3). In this description you can find all information to understand the protocol used by EnOcean.The specification of this protocol is also standardized and published as ISO/IEC 14543-3-10.
If you are interested in collecting telegrams to analyze them and to understand the protocol behind them, the following project may be interesting for you: EnOceanSpy. I’ve hosted this small piece of software on GitHub. It’s written in C and there is a binary version available for Raspberry Pi (RasPi). On this way you can use your RasPi in combination with an USB300 stick. The following photo demonstrates a buildup including a WakaWaka as power source.
EnOcean allows on the one hand one-way and on the other hand bidirectional communication between devices. Currently most of this communication is not decrypted, so you can read all information communicated via air. There is a first specification to use cryptography for EnOcean protocol. I will give you an overview on this way of encryption in the next time.
Have fun to seek your environment after EnOcean devices
The colleagues of testevents.com set up a list of upcoming test events all over the world (testing in general and not only focussing on protocols). You can filter for several countries or categories and get information concerning corresponding call for papers. The calendar lists various test events, e.g. German Testing Day taking place in November 2013 in Munich or EuroStar Software Testing Conference taking place in November 2013 in Gothenburg, Sweden.
This list may help you to plan your attendance at important conferences and to keep the deadlines of CfP in mind. On their website you can also find some book references and magazine references, all focusing on testing. Thanks to the team of testevents.com for this useful service!