New GlobalTester Release 3.1

GlobalTester is an Open Source tool to test (not only) smart cards. It’s developed with Eclipse. You can use the tool as an Eclipse plugin or standalone as Eclipse RCP. With the new release GlobalTester is not reduced to chip cards anymore. From now on you can test various protocols e.g. in context of Smart Home or IoT.

Here is a subset of the benefits of the new version:

  • Supports XML scheme according to BSI TR-03105 for test cases
  • Sample Configuration of¬† test objects allows switching between test objects and persistence of test information
  • Easy sharing with test houses and certification authorities
  • New, intuitive user interface, and handling
  • Extensive cheat sheets and new user guidance
  • Test Campaign allows easy reproduction of a test run and persistence of test results

The following video clip gives a first impression of the new user interface and the functionality (Video concept and recording by Anke Larkworthy).

If you are interested in the source code: we host the free available basic version of GlobalTester on the versioning system GitHub. Please feel free to download the code and to join the community. You are always welcome ūüôā

 

 

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.

 

Maintenance release of BSI TR-03105 Part 5.1

The German BSI has published a maintenance release of technical guideline TR-03105 Part 5.1 Version 1.41 for inspection systems with Extended Access Control (EAC).

Since last release of TR-03105 several (mostly editorial) comments were resolved and integrated in this maintenance release. Part 5.1 describes conformity tests for inspection systems with protocols like PACE, Terminal Authentication and Chip Authentication typically used at (automatic) border control, e.g. eGates.

Maintenance of TR-03105 for inspection systems, http://www.iconarchive.com/artist/oxygen-icons.org.html

Besides some editorial changes the new version 1.41 contains the following modifications:

  • ISO7816_G_36: If a EF.CardAccess contains an invalid OID for PACE-CAM, the inspection system shall use an alternative mapping protocol, that is supported by the chip.
  • ISO7816_G_37: This test case is deleted, because it’s not necessary for an inspection system to check that GM and IM are also supported by the chip besides PACE-CAM.
  • ISO7816_G_41: Curves with parameterID 0, 1 and 2 are based on DH and DH is not supported in context of PACE-CAM. So these curves are deleted.
  • LDS_H_86: Correction in expected result (PASS instead of FAIL).
  • Chapter 7: Relevant algorithms and OIDs for PACE, that must be supported by the inspection system, are added.
  • Chapter 7: Update of hashing algorithms.

For the next major update there should be a discussion how to handle fingerprints (data group 3, EF.DG3) and iris (data group 4, EF.DG4) of people who don’t have a finger or an iris. In this case these data groups should store an empty but valid data structure. Currently there are no test cases specified for these situations in TR-03105 Part 5.1. But inspection systems should be able to handle such cases also, of course.

So you can see, that test specifications in context of eMRTD (ePassports) and inspection systems are always in progress. If you have any comments concerning these test specifications or ideas of test cases, that should also be performed focusing on interoperability, please don’t hesitate to contact me or leave a comment.

Interoperability Test during SDW in May 2016

puzzle - interoperability test

Puzzle of InteropTest

Another interoperability test in context of ePassports (eMRTD) and inspection systems will be performed during SecurityDocumentWorld 2016 in London. The test will be focused on Supplemental Access Control (SAC) respective PACEv2, a security protocol to protect personal data stored in electronic ID documents.

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 is called crossover testing and allows all vendors to test their devices against other devices. The efforts to perform this kind of test increases very strongly with every ePassport and inspection system. Therefore these kind of tests can be performed only with a small number of devices under test.

Crossover Testing

Crossover Testing

Additionally, there is the opportunity besides this crossover tests to test the devices against conformity test suites implemented in test tools like open source tool GlobalTester. This procedure reduces efforts and allows comprehensive failure analyses of the devices like ePassports or inspection systems. To assure interoperability it is state of the art to set up test specifications. These specifications are implemented by the test labs respectively in the test tools they use.

Conformity Testing

Conformity Testing

There are well established test specifications available, both for ePassports and for inspection systems. Previous interoperability tests took place in Madrid (2014) and London (2013). Both events focused also on SAC/PACE.

If you are interested as a document provider, as a vendor of an inspection system, as a test lab or as an observer, you can register here.

Looking forward to seeing you in London during the InteropTest!

BTW: The EU article 6 group is preparing a document describing how to process an interoperability test and how to prepare such an event.

Update of BSI TR-03105 Part 5.1 available (V1.4)

Introduction

There is an update of BSI technical guideline TR-03105 Part 5.1 available. The new version 1.4 of this test specification for inspection systems with EACv1 is focusing on PACE (including PACE-CAM) and LDS 1.8.

Cover of BSI TR-03105 Part 5.1

Cover of BSI TR-03105 Part 5.1

The new version of TR-03105 is now available in new BSI layout. Additionally, there are some minor editorial changes and updated references (e.g. new Doc9303 is referenced).

New test cases in TR-03105 Part 5.1

The Standard Inspection Procedure (SIP) includes now also PACE and there is a new configuration specified for default PACE passport.

New test cases for PACE/SAC

Here is a list of new test cases, added in TR-03105 5.1 to test PACE, including PACE-CAM:

  • ISO7816_G_01: Correct execution of PACE protocols
  • ISO7816_G_02: Check supported standardized domain parameters with Generic Mapping
  • ISO7816_G_03: Check supported standardized domain parameters with Integrated Mapping
  • ISO7816_G_04: Check supported algorithms
  • ISO7816_G_05: Check PACE with additional entries in SecurityInfos
  • ISO7816_G_06: Check selection of standardized Domain Parameters and algorithms
  • ISO7816_G_07: EF.CardAccess contains two PACEInfo and PACEDomainParameter
  • ISO7816_G_08: Abort PACE because of SW error code during MSE:Set AT
  • ISO7816_G_09: Error on the nonce ‚Äď Value modifications after first General Authenticate
  • ISO7816_G_10: Error on General Authenticate step 1 command
  • ISO7816_G_11: Error on General Authenticate step 1 command ‚Äď bad tag (use 90h instead of 80h)
  • ISO7816_G_12: Error on General Authenticate step 2 command
  • ISO7816_G_13: Error on General Authenticate step 2 command bad tag (use 92h instead of 82h)
  • ISO7816_G_14: Abort PACE because of error in GA step 2 (GM)
  • ISO7816_G_15: Abort PACE because of error in GA step 2 (IM)
  • ISO7816_G_16: Error in General Authenticate step 2 command ‚Äď error on mapping data ‚Äď all ECDH public key components
  • ISO7816_G_17: Error in General Authenticate step 2 command ‚Äď error on mapping data ‚Äď all DH public key components
  • ISO7816_G_18: Error in General Authenticate step 3 command
  • ISO7816_G_19: Error in General Authenticate step 3 command ‚Äď bad tag (use 94h instead of 84h)
  • ISO7816_G_20: Abort PACE because of error in GA step 3
  • ISO7816_G_21: Error on General Authenticate step 3 command ‚Äď error on ephemeral public key ‚Äď all ECDH public key components
  • ISO7816_G_22: Error on General Authenticate step 3 command ‚Äď error on ephemeral public key ‚Äď all DH public key components
  • ISO7816_G_23: Abort PACE because of identical ephemeral public keys
  • ISO7816_G_24: Error on General Authenticate step 4 command
  • ISO7816_G_25: Error on General Authenticate step 4 command ‚Äď bad tag (use 96h instead of 86h)
  • ISO7816_G_26: Abort PACE because of error in GA step 4
  • ISO7816_G_27: Abort PACE because of TLV error on EF.CardAccess
  • ISO7816_G_28: Abort PACE because of incorrect parameterId in PACEInfo
  • ISO7816_G_29: PACE-CAM with missing tag 8Ah but correct ECAD
  • ISO7816_G_30: PACE-CAM with incorrectly encoded tag ECAD (no octet string)
  • ISO7816_G_31: PACE-CAM with wrong tag ECAD
  • ISO7816_G_32: PACE-CAM with wrong tag 8Ah (use 8Bh) but correct ECAD
  • ISO7816_G_33: PACE-CAM with correct tag 8Ah but missing ECAD
  • ISO7816_G_34: PACE-CAM with Passive Authentication
  • ISO7816_G_35: Return additional tag 8Ah during PACE-GM
  • ISO7816_G_36: Use invalid OID for PACE-CAM in EF.CardAccess
  • ISO7816_G_37: Use EF.CardAccess with PACEInfo only for PACE-CAM (no GM or IM)
  • ISO7816_G_38: Use DG14 without SecurityInfo during PACE-CAM
  • ISO7816_G_39: Use EF.CardSecurity with wrong ChipAuthenticationPublicKeyInfo during PACE-CAM
  • ISO7816_G_40: Use EF.CardSecurity without ChipAuthenticationPublicKeyInfo during PACE-CAM
  • ISO7816_G_41: Check supported standardized domain parameters with Chip Authentication Mapping

New test cases for LDS 1.8

Here is a list of new test cases, added in TR-03105 5.1 to test LDS 1.8:

  • LDS_A_10: EF.COM with LDS Version 1.8
  • LDS_H_86: EF.SOD with LDS Version 1.8
  • LDS_H_87: Security Object with LDS Version 1.8 but with wrong version number
  • LDS_H_88: Security Object with LDS Version 1.7 but version number 1
  • LDS_H_89: EF.SOD with future LDS Version 1.9

Adapted test cases in TR-03105

Here is a list of modified test cases in TR-03105 5.1:

  • In chapter 7.1.2 the OIDs for plain signatures are corrected.
  • ISO7816_D_06: Added second public key with key reference FE in EF.DG14
  • ISO7816_D_15: Use configuration of D_06 to assure the use of wrong key reference
  • ISO7816_F_02: Added signature algorithm (ECDSA with SHA1) in EF.DG14 to fulfil requirements
  • ISO7816_F_08: Changed expected results in transfer interface: TA and CA might not be performed
  • LDS_A_06: Correction in EF.COM where Unicode Version 5 must be encoded
  • LDS_D_08: The referenced invalid format owner (0102) is used by JTC1/SC27 IT Security Techniques (see www.ibia.org/base/cbeff/biometric_org.phpx). So the referenced invalid format owner was changed to ’87 02 01 FF’.
  • LDS_E_07: The referenced invalid format owner (0102) is used by JTC1/SC27 IT Security Techniques (see www.ibia.org/base/cbeff/_biometric_org.phpx). So the referenced invalid format owner was changed to ’87 02 01 FF’.
  • LDS_H_04: Correction in EF.SOD where RSASSA-PKCS1_v15 must be used
  • LDS_H_50: The serial number is mandatory, so expected result was changed to “FAIL”

Next steps

The version 1.4 of BSI TR-03105 Part 5.1 is a backport of ISO18745-4. Until the ISO test specification is under construction and not released, TR-03105 can be used as an interims version for testing inspection systems using PACE/SAC.

 

EnOceanSpy as Java version available

In 2013 I’ve released a small tool called EnOceanSpy on github. This tool can be used on a Raspberry Pi (RasPi) to log all incoming EnOcean telegrams and was implemented in C. The following photography describes the composition of Raspberry Pi, EnOcean USB300 stick (and a WakaWaka as a portable power bank):

Raspberry Pi with EnOcean USB300

Raspberry Pi with EnOcean USB300

The post at that time described the usage of this composition.

Now I’ve release a Java implementation of EnOceanSpy also on github: https://github.com/hfunke/org.protocolbench.enoceanspy. This tool logs all incoming EnOcean telegrams as well, but this time in Java. You can set the used <com port name at> the command line and EnOceanSpy logs all incoming telegrams.

And here is a Java code snippet where you can find a way to connect the USB300 stick with RXTX:

    void connect(String portName) throws Exception {
        CommPortIdentifier portIdentifier = CommPortIdentifier
                .getPortIdentifier(portName);
        if (portIdentifier.isCurrentlyOwned()) {
            System.err.println("Port is currently in use!");
        } else {
            CommPort commPort = portIdentifier.open(this.getClass().getName(),
                    3000);

            if (commPort instanceof SerialPort) {
                serialPort = (SerialPort) commPort;

                // settings for EnOcean:
                serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8,
                        SerialPort.STOPBITS_1, SerialPort.PARITY_NONE);

                InputStream in = serialPort.getInputStream();
            
                serialPort.addEventListener(new SerialReader(in));
                serialPort.notifyOnDataAvailable(true);
                
            } else {
                System.err.println("Only serial ports are handled!");
            }
        }
    }

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 ūüôā

 

Mapping between protocols and test specifications

Introduction

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

LDSVersionInfo ::= SEQUENCE {
   ldsVersion PRINTABLE STRING
   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 RF and Protocol Testing Part 3 V2.07 online

There is an maintenance update of ICAO’s test specification ‘RF and Protocol Testing Part 3‘ available since today. The specification is¬†focusing on conformity testing and protocol testing for ePassports implementing protocols like¬†BAC¬†and Supplemetal Access Control (SAC) respective PACE v2.

The Techinal Advisory Group (TAG) of ICAO endorsed the release on the ICAO website, so from now on the test specification can be referenced officially. In version 2.07 of the test specification there are no technical or fundamental changes, but editorial changes. The following test cases are modified in the new release 2.07:

  • ISO7816_B_16: Profile corrected
  • ISO7816_B_26: Added version
  • ISO7816_B_34: Profile corrected
  • ISO7816_B_52: Profile corrected
  • ISO7816_D_06: Updated version
  • ISO7816_D_09 – ISO7816_D_22: Profile corrected and version updated
  • ISO7816_E_09 – ISO7816_E_22: Profile corrected and version updated
  • ISO7816_F_20: Profile corrected and version updated
  • ISO7816_G_20: Profile corrected and version updated
  • ISO7816_O_12: Deleted obsolete Test-ID
  • ISO7816_O_13: Corrected sequence tags
  • ISO7816_O_31: Deleted obsolete Test-ID
  • ISO7816_O_35: Added missing caption
  • ISO7816_P_xx:¬† Deleted sample in description of step 1 (‘i.e. more than one set of
    domain parameters are available for PACE’)
  • ISO7816_P_04: Corrected numbering in expected results
  • ISO7816_P_06: Corrected numbering in expected results
  • ISO7816_P_07: Corrected numbering in expected results
  • ISO7816_P_14: Updated version
  • ISO7816_P_74: In preconditions step 3 concretized concerning PACEInfos in EF.CardAccess
  • ISO7816_Q_03: Added missing reference TR-SAC
  • LDS_D_06: Corrected typos in step 8

 

With the new edition of Doc 9303 several technical reports are now obsolete except the test specifications. Theses specifications are still independent documents.

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.

 

Java Sample Code to access Smart Card

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:
card.disconnect(false);

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_Properties_JavaCard

Eclipse – Project properties to access Java Card API for Java code sample