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. To 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.
Supplemental Access Control (SAC) is a set of security protocols published by ICAO to protect personal data stored in electronic travel documents like ePassports and ID cards. One protocol of SAC is the well known Password Authenticated Connection Establishment (PACE) protocol, which supplements and enhances Basic Access Control (BAC). PACE was developed originally by the German Federal Office for Information Security (BSI) to provide a cryptographic protocol for the German ID card (Personalausweis).
Currently PACE supports three different kinds of mapping as part of the security protocol execution:
Generic Mapping (GM) based on a Diffie-Hellman Key Agreement,
Integrated Mapping (IM) based on a direct mapping of a field element to the cryptographic group,
Since Version 1.1 of ICAO technical report TR – Supplemental Access Control for MRTDs there is a specification of a third mapping procedure for PACE, the Chip Authentication Mapping (CAM), which extends established Generic Mapping. This third mapping protocol combines PACE and Chip Authentication into only one protocol PACE-CAM. On this way it is possible to perform Chip Authentication Mapping faster than both separate protocols.
The chip indicates the support of Chip Authentication Mapping by the presence of a corresponding PACEInfo structure in the file EF.CardAccess. The Object Identifier (OID) defines the cryptographic parameters that must be used during the mapping. CAM supports AES with key length of 128, 192 and 256. But in contrast to GM and IM there is no support of 3DES (for security reasons) and only support of ECDH.
The mapping phase of the CAM itself is 100% identical to the mapping phase of GM. The ephemeral public keys are encoded as elliptic curve points.
To perform PACE a chain of GENERAL AUTHENTICATE commands is used. For CAM there is a deviation in step 4 when Mutual Authentication is performed. In this step the terminal sends the authentication token of the terminal (tag 0x85) and expects the authentication token of the chip (tag 0x86). Additionally, in CAM the chip sends also encrypted chip authentication data with tag 0x8A to the terminal.
If GENERAL AUTHENTICATION procedure was performed successfully, the terminal must perform the following two steps to authenticate the chip:
Read and verify EF.CardSecurity,
Use the public key of EF.CardSecurity in combination with the mapping data and the encrypted chip authentication data received during CAM to authenticate the chip.
It is necessary to perform Passive Authentication in combination with Chip Authentication Mapping to consider that the chip is genuine.
The benefit of Chip Authentication Mapping is the combination of PACE and Chip Authentication. The combination of both protocols saves time and allows a faster performance than the execution of both protocol separately.
You can find interesting information concerning CAM in the patent of Dr. Dennis Kügler and Dr. Jens Bender in the corresponding document of the German Patent and Trademark Office.
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.
Update 1: We have released an article in The VAULT (magazine of Silicon Trust) concerning PersoSim in English Language. You can find the article here for free in The VAULT #14.
Update 2: We have released the source code of the simulator and using github as repository. You can find all relevant information on the PersoSim project website. Please feel free to fork the code and extend the project with new features.