Monthly Archives: May 2016

First results of eMRTD Interoperability Test 2016

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:

Logo of SDW InteropTest

  • 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:

  1. There is a very good quality of the eMRTD samples.
  2. 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).

Sending EnOcean telegram

EnOcean is an energy harvesting wireless technology used primarily in building automation systems and smart homes. All modules based on this technology combine on the one hand micro energy converters with ultra low power electronics, and on the other hand enable wireless communications between battery-less wireless sensors, actors and even gateways. The communication is based on so called ‘EnOcean telegram’. Since 2012 the EnOcean standard is specified as the international standard ISO/IEC 14543-3-10.

The EnOcean Alliance is an association of several companies to develop and promote Logo of EnOCeanself-powered wireless monitoring and control systems for buildings by formalizing the interoperable wireless standard. On their website the alliance offers some of their technical specifications for everybody.

To send an EnOcean telegram you need a piece of hardware connected to your host, e.g. an EnOcean USB300 USB Stick for your personal computer or an EnOcean Pi SoC-Gateway TRX 8051 for your Raspberry Pi. In this sample we use the USB300 to send a telegram using a small piece of software implemented in Java. The following photography shows an USB300 stick:

EnOcean USB300 Stick used to send EnOcean telegram

EnOcean USB300 Stick

The EnOcean radio protocol (ERP) is optimised to transmit information using extremely little power generated e.g. by piezo elements. The information sent between two devices is called EnOcean telegram. Depending on the EnOcean telegram type and the function of the device the payload is defined in EnOcean Equipment Profiles (EEP). The technical properties of a device define three profile elements:

  1. The ERP radio telegram type: RORG (range: 00…FF, 8 Bit)
  2. Basic functionality of the data content: FUNC (range 00…3F, 6 Bit)
  3. Type of device in its individual characteristics: TYPE (range 00…7F, 7 Bit)

Since version 2.5 of EEP the various Radio-Telegram types are grouped ORGanisationally:

TelegramRORGDescription
RPSF6Repeated Switch Communication
1BSD51 Byte Communication
4BSA54 Byte Communication
VLDD2Variable Length Data
MSCD1Manufacturer Specific Communication
ADTA6Addressing Destination Telegram
SM_LRN_REQC6Smart Ack Learn Request
SM_LRN_ANSC7Smart Ack Learn Answer
SM_RECA7Smart Ack Reclaim
SYS_EXC5Remote Management
SEC30Secure Telegram
SEC_ENCAPS31Secure Telegram with RORG encapsulation

In this context we use the type VLD (Variable Length Data) to have a closer look to EnOcean telegrams. VLD telegrams can carry a variable payload of data. The following graphic shows the structure of on EnOcean telegram (based on EnOcean Serial Protocol 3, short: ESP3):

This graphic describes the structure of an EnOcean telegram

Structure of EnOcean telegram

ESP3 is a point-to-point protocol with a packet data structure. Every packet (or frame) consists of header, data and optional data. As you can see in the structure, the length of the complete telegram is encoded in the header with two bytes. This suggests a maximum telegram length of 65535 bytes. Unfortunately, the maximum length of such a telegram is reduced to 21 bytes (data) due to limitations of low power electronics. Reduced by overhead information wasted in field data, the resulting net payload has finally a size of 14 Bytes. The following code snippet demonstrates how to send a telegram with 14 bytes payload ’00 11 22 33 44 55 66 77 88 99 AA BB CC DD’. At first we have look at the telegram:

Telegram: 55 00 14 07 01 65 D2 00 11 22 33 44 55 66 77 88 99 AA BB CC DD 00 00 00 00 00 01 FF FF FF FF 44 00 0B
Sync. byte: 55
Header: 00 14 07 01
CRC8 Header 65
Length data: 20 (0x14)
Length optional data: 7 (0x07)
Packet Type: 01
Data: D2 00 11 22 33 44 55 66 77 88 99 AA BB CC DD 00 00 00 00 00
RORG: D2
ID: 00 00 00 00
Status: 00
Data Payload: 00 11 22 33 44 55 66 77 88 99 AA BB CC DD
Optional data: 01 FF FF FF FF 44 00
SubTelNumber: 01
Destination ID: FF FF FF FF
Security: 00
Dbm: 68 (0x44)
CRC8 Data 0B

The following Java code demonstrates one way to send this telegram via USB300. The code snippet uses the library of RXTX to access the serial port.

import java.io.OutputStream;

import gnu.io.CommPort;
import gnu.io.CommPortIdentifier;
import gnu.io.SerialPort;

public class EnOceanSample {
	
	static SerialPort serialPort;
	static String serialPortName = "COM3";

	public static void main(String[] args) {
		
		byte[] sampleTelegram = new byte[] { (byte) 0x55, (byte) 0x00, (byte) 0x14, (byte) 0x07, (byte) 0x01, (byte) 0x65, 
				(byte) 0xD2, (byte) 0x00, (byte) 0x11, (byte) 0x22, (byte) 0x33, (byte) 0x44, (byte) 0x55, (byte) 0x66, (byte) 0x77, (byte) 0x88, (byte) 0x99, (byte) 0xAA, (byte) 0xBB, (byte) 0xCC, (byte) 0xDD, 
				(byte) 0x00, (byte) 0x00, (byte) 0x00, (byte) 0x00, (byte) 0x00, (byte) 0x01, (byte) 0xFF, (byte) 0xFF, (byte) 0xFF, (byte) 0xFF, (byte) 0x44, (byte) 0x00, (byte) 0x0B};
		
		try {
			CommPortIdentifier portIdentifier = CommPortIdentifier
					.getPortIdentifier(serialPortName);
			if (portIdentifier.isCurrentlyOwned()) {
				System.err.println("Port is currently in use!");
			} else {
				CommPort commPort = portIdentifier.open("EnOceanSample", 3000);
	
				if (commPort instanceof SerialPort) {
					serialPort = (SerialPort) commPort;
	
					// settings for EnOcean:
					serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8,
							SerialPort.STOPBITS_1, SerialPort.PARITY_NONE);
					
					System.out.println("Sending Telegram...");
					OutputStream outputStream = serialPort.getOutputStream();
					outputStream.write(sampleTelegram);
					outputStream.flush();
					outputStream.close();
					serialPort.close();
					System.out.println("Telegram sent");
					
				} else {
					System.err.println("Only serial ports are handled!");
				}
			}
		}
		catch (Exception ex) {
		}
	}
}

On this way it’s not possible to send telegrams with a huge payload. If the information to be sent is longer than the described limit above, you can use a mechanism called ‘chaining’. To chain telegram a special sequence of telegrams is necessary. All protocol steps for chaining are specified in EO3000I_API.

Attention: In Europe EnOcean products are using the frequency 868,3 MHz. This frequency can be used by everybody for free but the traffic is limited, e.g. in Germany where it’s only allowed to send 36 seconds within one hour.

In one of my last blog posts I gave you the know how to receive EnOcean telegrams. Now, based on the information above, you can send your own EnOcean telegram in context of your Smart Home or your IoT environment.