Tag Archives: eID

GSMA published requirements for SAM

The GSM Association (GSMA) has released a new requirement specification focusing on Secured Applications for Mobile (SAM). In this specification the capability allowing cellular connected devices (e.g. smartphones) to use a wide range of secured applets within an eUICC (embedded universal integrated circuit card) is described. Applets specified here can be managed by a service provider and are cooperating with applications running in the device itself. The focus of the specification is on the eUICC where the secured applets will operate independently and outside of any eUICC profile.


The requirement specification with the title SAM.01 is published on the GSMA website in the following link: https://www.gsma.com/newsroom/resources/sam-01-secured-applications-for-mobile-requirements

Use case: mobile eID as a secured applications for mobile

The usage of mobile devices for mobile services is one of the dominant trends we can see worldwide. Mobile devices replace the personal computer at home or at office. For access to online services the mobile device is getting more and more important. New applications are often only offered for mobile devices (mobile first). Based on this trend the mobile device is becoming the most common interface between the customer and the service providers.

For the digitalization of business process, the secure identification and authentication of end customers is a key requirement. The eIDAS regulation No 910/2014 of the EU is defining three levels of assurance (LoA) for electronic identification. The two highest levels “high” and “substantial” are demanding the usage of secure elements (see BSI Technical Guideline TR-03159 Mobile Identities). To achieve these levels the usage of an secure hardware token is essential. One of these token could be an eUICC and the usage is specified in SAM.

This secure hardware token is a central element for several mobile identities that are currently under development, like ICAO Digital Travel Credentials (DTC), mobile Driving License (mDL) specified in ISO/IEC 18013-5 or in general building blocks for mobile ID (ISO/IEC 23220). Last but not least the German identity card (ePA) will be derived to a smartphone to use the online identification directly on the device.

You can find a description of current mobile ID projects and standardisation work in my article “Digital and mobile identities” which was published in the context of Open Identity Summit 2020.

As soon as the eUICC is a well-specified secure platform, it is the perfect platform for hosting mobile ID applications which are offering high security for the service provider and also for the end user.

Architecture of SAM

The following figure describes the architecture of Secured Applications for Mobile (SAM) as specified by GSMA:

Architecture of Secured Applications for Mobile (SAM)
Architecture of Secured Applications for Mobile (SAM) (Source: GSMA SAM.01 v1.0)

On the left side you can find the service manager (SAM SM), which acts on behalf of the Application Service Provider (ASP) and is in charge of managing SAM Applets through SAM Commands. On the device itself you can see the device application (e.g. provided in an app store by the ASP), the local applet assistant (LAA) and – of course – the eUICC. The eUICC offers a security domain (SAM SD, also known as common security domain (CSD)) including an ASP SD where the SAM applets are located. The SAM applet can be used to assure the security of the device application by storing keys or holder data, performing encryption, signing etc.

Next steps

The work has not finished with the release of the requirement specification. All the requirements must be incorporated into a technical specification where all details are described on the level of bits and bytes. To assure that current developments in other working groups are also involved (and to assure that the wheel is not reinvented a second time) GSMA is working with external organizations like GlobalPlatform or ETSI. On this way we will see several interoperable applets running on eUICC allowing high security in the near future.

BSI released version 1.2 of TR-03105 Part 3.3

The German BSI has released a new version 1.2 of TR-03105 Part 3.3 for eIDAS token. This test specification for chip assures conformity and interoperability of eIDAS token like eID cards or residence permits. TR-03105 Part 3.3 contains tests for protocols that are summarized under EACv2 and corresponding data groups.

Front page of German ID card (Personalauswweis) compliant to TR-03105 Part 3.3
Front page of German ID card (Source: Wikipedia)

In TR-03105 Part 3.3 Version 1.2 new test cases are added to verify and assure the correct handling of authorization extensions. Authorization extensions are specified in TR-03110 and they are a special type of certificate extensions. These extensions convey authorizations additional to those in the Certificate Holder Authorization Template (CHAT) contained in the certificate. Additionally, authorization extensions contain exactly one discretionary data object that encodes the relative authorization. The main changes of version 1.2 are:

  • Test cases to verify correct handling of authorization extensions
  • New certificates to perform test cases with authorization extensions
  • The tests for command COMAPRE can now be performed in a more detailed way (see new table in ICS in annex A.1)
  • A new test case to verify the TA migration according to the manufacturer’s implementation conformance statement where the AT trust point are replaced
  • Some minor editorial changes and clarifications

Modified test cases in version 1.2

  • EAC2_7816_L_36: Clarification in Purpose
  • EAC2_7816_N_1: Clarification in purpose
  • EAC2_7816_P_8: Added missing tag ‘7C’ in commands
  • EAC2_ISO7816_P9: Removed tag ‘97’ that is not necessary in command RESET RETRY COUNTER (step 6)
  • EAC2_7816_P_14: Added missing tag ‘7C’ in commands
  • EAC2_7816_P_14: Added missing tag ‘7C’ in commands
  • EAC2_7816_U_13: Expected results: Accept also a checking error in step 3 of preconditions
  • EAC2_7816_U_14: Expected results: Accept also a checking error in step 3 of preconditions
  • EAC2_DATA_B_11: Check a whitelist of SecurityInfos (PACEInfo, PACEDomainParameterInfo, PasswordInfo, ChipAuthenticationInfo, ChipAuthenticationDomainParameterInfo, PSAInfo, TerminalAuthenticationInfo, PSMInfo, CardInfo) and ignore PrivilegedTerminalInfos
  • EAC2_DATA_C_12: Editorial correction in Test-ID
  • EAC2_EIDDATA_B_6: Renamed data type ArtisticName by NomDePlume according to TR-03110

New test cases in version 1.2

  • EAC2_7816_L_38: Positive test with a valid terminal authentication process. The DV certificate and the terminal certificate grant access to an eID access function that is reserved for future use (RFU).
  • EAC2_7816_L_39: Positive test with a valid terminal authentication process. The DV certificate and the terminal certificate grant access to an eID special function that is reserved for future use (RFU).
  • EAC2_7816_L_40: Positive test with a valid terminal authentication process. The DV certificate and the terminal certificate contain a certificate extension (authentication terminals) extended by two empty bytes. The authorization extension in both certificates are extended with leading ‘00 00’ (56 bit instead of 40 bit).
  • EAC2_7816_L_41: Positive test with a valid terminal authentication process. The DV certificate and the terminal certificate contain a certificate extension (eID functions) extended by two empty bytes.
  • EAC2_7816_L_42: Positive test with a valid terminal authentication process. The DV certificate and the terminal certificate contain a certificate extension (special functions) extended by two empty bytes.
  • EAC2_7816_L_43: Positive test with a valid terminal authentication process. The DV certificate and the terminal certificate contain an unknown OID in CHA.
  • EAC2_7816_L_44: Positive test with a valid terminal authentication process. The DV certificate and the terminal certificate contain an unknown authorization extension OID in for eID access.
  • EAC2_7816_L_45: Positive test with a valid terminal authentication process. The DV certificate and the terminal certificate contain an unknown authorization extension OID in for special functions.
  • EAC2_ISO7816_M_9: Positive test to verify that a link certificate can activate a feature of the eID card. In this test case the right to read DG1 is used to verify that the eID card supports activation of features by link certificates.
  • EAC2_ISO7816_M_10: Positive test to verify that a link certificate can deactivate a feature of the eID card. In this test case the right to read DG1 is used to verify that the eID card supports deactivation of features by link certificates.
  • EAC2_ISO7816_M_11: Positive test to verify that rights are granted by the last link certificate and not a combination of all rights in the whole certificate chain. In this test case the right to read DG1 is used.
  • EAC2_ISO7816_M_12: Positive test to verify that a link certificate can activate a feature of the eID card. In this test case the right to compare DG8 is used to verify that the eID card supports activation of eID Access features by link certificates.
  • EAC2_ISO7816_M_13:  Positive test to verify that a link certificate can deactivate a feature of the eID card. In this test case the right to compare DG8 is used to verify that the eID card supports deactivation of eID Access features by link certificates.
  • EAC2_ISO7816_M_14: Positive test to verify that eID Access rights are granted by the last link certificate and not a combination of all rights in the whole certificate chain. In this test case the right to compare DG8 is used.
  • EAC2_7816_N_2: Positive test case to verify the TA mechanism migration according to the manufacturer’s implementation statement (replacement of the AT trust point)

As mentioned in my previous blog post describing latest version of TR-03105 Part 5.1, I’ve extended the focus of my blog from ePassports towards eID and eIDAS token. You can find a list of current test specifications here.

Focus extension of this blog to eIDAS token

Until today the focus of this blog was limited to ePassports or eMRTDs specified by BSI and ICAO. From now on this focus will be extended also to eIDAS token.

eIDAS Logo

An eIDAS token is specified also in BSI TR-03110. The technical guideline specifies a set of different algorithms and protocols that can be used in the area of identification and authorisation. One representative for a token like this is for example the German ID card (Personalausweis).

Additionally, a first prototype of an eIDAS token was implemented during a project called PersoSim on behalf of BSI. Goal of this project was to implement the functionality of a German ID card in a simulator including a virtual smart card reader.

Protocols specified in TR-03110 beyond eMRTD are:

  • Restricted Identification (RI)
  • Pseudonymous Signatures (PS)
  • Chip Authentication Version 2
  • Chip Authentication Version 3
  • Terminal Authentication Version 3
  • Enhanced Role Authentication (ERA)
  • Authorization Extension for additional attributes

From now on you can find test specifications for eIDAS token at the overview of test specifications. There are more and more eID documents using the protocols specified in in TR-03110 (e.g. Authorization Extension for LDS2 where entry and exit stamps are stored on the chip) and at the end of the day the corresponding test specifications are getting more and more important. That’s the reason why I decided to blog also about eIDAS token at this blog from now on.

First results of eMRTD Interoperability Test 2017 in Ispra

The European Commission (EC) organised another eMRTD interoperability test. This time the event took place in Ispra at the Joint Research Center of the European Union. The objective of this interoperability test was to assure that countries and companies have established a stable PACE protocol in their eMRTD, respective ePassports, and ID cards.

Test setup of eMRTD interoperability test

Every participant had the chance to submit up to two different sets of documents with different implementations. Altogether there were 42 different samples available at the beginning of the event. 2 samples didn’t pass the smoke test and one sample was not suitable to be tested by the labs. All remaining samples were tested in two different test procedures: crossover test and conformity test. Twelve document verification system providers with 16 different solutions took part in the crossover test. And 23 document providers threw 42 sets in the ring (28 countries, 14 industries).

In this blog post the conformity test is focused on, because protocols are in foreground in this kind of test. There were three test labs (Keolabs, UL and secunet) 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” (Version 2.10). The subset includes the following test suites and test cases:

  • 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
  • LDS_K: Structure of EF.CardSecurity
  • LDS_D_06: Test case to perform Passive Authentication

Information concerning documents

The document providers describe in the implementation conformance statement (ICS) the features of their chips. Not all ICS were fulfilled consistently, so the following information concerning the documents should be read carefully. Concerning the LDS version 16 providers reported version 1.7 to be used in their documents. And three reported version 1.8, while all others don’t deliver any information concerning the version number.

The following diagram describes the relation between DH and ECDH in PACE:

PACE algorithms

PACE algorithms

The following diagram describes the relation of the mapping protocols in PACE:

Mapping protocols in PACE

Mapping protocols

16 documents supported besides the MRZ also a CAN as a password to get access to the stored data.

Again, the number of PACEInfos store in EF.CardAccess varied:

  • 28 documents stored one PACEInfo,
  • Eight documents stored two PACEInfos,
  • One stored each three, seven or ten PACEInfos.

Investigations concerning EF.ATR/INFO in documents

The file EF.ATR/INFO allows storing some information about the chip, that allows the reader to handle the chip optimally. On this way the chip can offer the ideal buffer size used with extended length during reading and writing. In context of the event I had a closer look at EF.ATR/INFO. 26 documents of 42 stored an EF.ATR/INFO but 5 of them don’t offer information concerning extended length and buffer sizes there. So at the end I’ve investigated the reading buffer sizes of 21 documents of the eMRTD interoperability test with the following result:

  • Seven documents support buffer sizes between 1 and 1.5 KByte,
  • Three documents support buffer sizes between 1.5 and 2 KByte,
  • Eleven documents support buffer sizes of ~64 KByte.

Buffer sizes for reading in EF.ATR/INFO

Buffer sizes in EF.ATR/INFO (reading)

With these large buffer sizes data groups like DG2 storing the facial image or DG3 storing the finger prints can be read in only one command. This allows the inspection system to read the content of the chip faster and improves the reading time at eGates.

Results of conformity testing

During the conformity test, all three test labs performed 18.135 test cases altogether. Less than 1 percent of these test cases failed during the conformity test.

Overall results (layer 6 and layer 7):

  • Passed: 11.563
  • Failed: 155 (0,86%)
  • Not applicable: 6.417

Layer 6 (16.614 test cases performed):

  • Passed: 10.885
  • Failed: 124 (0,74%)

Layer 7 (1.521 test cases performed):

  • Passed: 679
  • Failed: 32 (2,10%)

The following diagram shows failed test cases per document during the eMRTD interoperability test:

Number of failures per document

Number of failures per document

The diagram below shows the number of failure per test case during the eMRTD interoperability test:

Failures per test case

Failures per test case

Observations during conformity testing

  • There are minor differences between implementation conformance statement (ICS) and chip.
  • Test results differ between test labs in some test cases.
  • There are differences in handling errors at the test tools and labs (e.g. no CAN causes a failure at the one lab and a ‘not applicable’ at the other lab).
  • Relatively more failures on layer 7 (personalisation) than on layer 6 (COS).
  • Very good quality of chip and personalisation.
  • Improvements during the last interoperability tests in London 2016 and Madrid 2014.
  • Stable specifications (BSI TR-03110, ICAO Doc 9303) and test specifications (BSI TR-03105, ICAO TR Part 3).

eMRTD Test Specification Overview

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.
Keep calm and continue testingTo 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.

Chip Authentication Version 3 (CAv3)

This post describes a new version 3 of well-known protocol Chip Authentication, which is used in context of eID to authenticate the chip and to establish a strong secure channel between chip and terminal.

In context of the European eIDAS regulation, the German BSI and the French ANSSI have specified in TR-03110 a new version 3 of protocol Chip Authentication (CAv3). It bases on ephemeral-static Diffie-Hellman key agreement, that provides both secure communication and also unilateral authentication of the chip. This new protocol is an alternative to Chip Authentication Version 2 and Restricted Identification (RI) providing additional features. CAv3 provides the following benefits (see TR-03110 part 2):

  • message-deniable strong explicit authentication of the eIDAS token and of the provided sector-specific identifiers towards the terminal,
  • pseudonymity of the eIDAS token without the need of using the same keys on several chips,
  • possibility of whitelisting eIDAS token (even in case of a compromised group key),
  • implicit authentication of stored data by performing Secure Messaging using new session keys derived during CAv3.

Before CAv3 is started the well-known protocol Terminal Authentication Version 2 (TAv2) must performed because the terminal’s ephemeral key pair generated during TAv2 is used during CAv3. It is also recommend that Passive Authentication is performed before CAv3 to assure the authenticity of chip’s public key.

Following table describes the command during CAv3 respective PSA (Source ISO/IEC 19286):

Command description of Chip Authentication V3 (CAv3) protocol (Source ISO/IEC 19286)

Command description of CAv3 protocol (Source ISO/IEC 19286)

The protocol CAv3 consists of the following two steps (where terminal and eIDAS token are involved):

  1. Perform Key Agreement (based on Anonymous Diffie Hellman (ADH))
    • Kee Agreement is performed in this step of the protocol:
      • MSE:SET AT with CA-OID and reference to private key
      • GENERAL AUTHENTICATE with dynamic authentication data (ephemeral public key)
  2. Perform Pseudonymous Signature Authentication (PSA)
    • Pseudonymous Signature is computed in this step of the protocol:
      • MSE:SET AT with PSA-OID and reference to private key
      • GENERAL AUTHENTICATE with dynamic authentication data (public key for domain-specific identifier)

Additionally, the received sector-specific identifier can be checked if it is black-listed (or white-listed).

On this way the new protocol CAv3 can be used in addition to sign data under a chip and sector specific pseudonym as an alternative to Restricted Identification.


Mapping between protocols and test specifications


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

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

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 
   ldsVersionInfo LDSVersionInfo OPTIONAL
   -- If present, version MUST be V1 }

LDSVersionInfo ::= SEQUENCE {
   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 ICAO Doc 9303 Edition

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.

ICAO Doc 9303 Title page

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 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 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.

Chip Authentication Mapping

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:

  1. Read and verify EF.CardSecurity,
  2. 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.


PersoSim – an open source eID simulator

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.