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 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.
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,
- Chip Authentication Mapping (CAM) extends Generic Mapping and integrates Chip Authentication.
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.
This Java sample code describes the Java Smart Card I/O API used to get access to a common smart card. It demonstrates the communication with smart cards using APDUs specified in ISO/IEC 7816-4. It thereby allows Java applications to interact with applications running on the smart card.
The Application Programming Interface (API) for the Java Card technology defines the communication protocol conventions by which an application accesses the Java Card Runtime Environment and native services. To assure interoperability, the Java Card API is compatible with formal international standards, such as ISO/IEC 7816, and industry-specific standards, such as EMVCo’s EMV standards for payment, and ESI/3GPP standards for UICC/SIM cards.
In this Java sample code the command GET CHALLENGE is used to demonstrate a simple command sent to smart card. At the beginning of the communication protocol all registered card readers (terminals) are listed and the first one is selected to get connected with the smart card. Once the connection is established the command GET CHALLENGE is sent to the card and a random sequence of 8 bytes is returned as response.
And here is the code snippet of this sample:
// Show the list of all available card readers:
TerminalFactory factory = TerminalFactory.getDefault();
List<CardTerminal> terminals = factory.terminals().list();
System.out.println("Reader: " + terminals);
// Use the first card reader:
CardTerminal terminal = terminals.get(0);
// Establish a connection with the card:
Card card = terminal.connect("*");
System.out.println("Card: " + card);
CardChannel channel = card.getBasicChannel();
ResponseAPDU r = channel.transmit(new CommandAPDU(0x00, 0x84, 0x00, 0x00, 0x08));
String hex = DatatypeConverter.printHexBinary(r.getBytes());
System.out.println("Response: " + hex);
// disconnect card:
If you want to use this sample in your IDE, e.g. Eclipse, keep in mind that you must access the Java Card API in a manually way. In Eclipse you can do this in project properties. Add the following access rule to the java build path: javax/smartcardio/** This allows you do access additional methods for smart cards in Java. You can find this adjustment in the following screenshot (Eclipse):
Eclipse – Project properties to access Java Card API for Java code sample
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 :)
In search of books concerning protocols I found the following ones:
Both books describe general functions of protocols focussing especially communication protocols. Are there some other books concerning protocols and also focussing modeling and testing? Robert Binder discusses the topic of testing in his standard work “Testing object-oriented systems” in an early stage.
Welcome to my blog. You will find here some ideas about testing of protocols and about modeling these protocols also. At the beginning the primary focus is limited to the domain of electronic document like ePassport and eID.
I’m looking forward to getting your feedbacks and to discussing topics around modelling and testing protocols.