Tag Archives: protocol

TR-03105 Part 3.2 V1.5.1 or How I met your master file

A few days ago German BSI has released a maintenance release of TR-03105 Part 3.2. Primarily, the new version 1.5.1 includes editorial changes. Tests of this specification are focusing on eMRTD and the data groups and protocols used there.

What’s new in TR-03105 Part 3.2 Version 1.5.1?

Reference documentation: Re-arranged documents of the same type are now in direct neighbourhood to make them easier to find
Reference documentation: Added ICAO Doc9303 Part 9 and ICAO Doc9303 Part 12
Added a new profile “Master File” for eMRTD supporting a Master File as root directory
Unit ISO7816_J: Clarification, that all test cases of this test unit which require the “Open ePassport Application” procedure must be performed twice (one test run with BAC and one with PACE) if the chip supports both protocols. If the chip only supports one of these protocols (BAC or PACE), only one test run has to be performed with the supported protocol used in the “Open ePassport Application” procedure
Test case ISO7816_J_12: Clarification in expected result (step 1)
Test case ISO7816_L_13: Added new profile “MF”
Test case ISO7816_L_14: Clarification in purpose
Test case ISO7816_L_15: Clarification in purpose
Test case ISO7816_L_16: Clarification in purpose
Some minor editorial changes

The one and only technical change in this version is test case ISO7816_L_13 where the new specified profile “MF” is added. This profile assures that this test case is only performed if the chip supports a Master File. Why is this profile needed? In the field there are several eMRTD without a MF. In case of PACE you need a MF to store files like EF.CadAccess or EF.ATR/INFO. But in the case of BAC a MF is not necessary. In clause 4 of ICAO Doc9303 Part 9 (7th edition) you can find the information “An optional master file (MF) may be the root of the file system” and further on “The need for a master file is determined by the choice of operating systems and optional access conditions”.

Characteristics of smart card file systems

All information of an eMRTD is stored in a file system defined in ISO 7816-4. A usual file system is organized hierarchically into dedicated files (DFs) and elementary files (EFs). Dedicated files can contain elementary files or other dedicated files. Applications are special variants of dedicated files (Application DF) and have to be selected by their DF name indicating the application identifier (AID). After the selection of an application, the file within this application can be accessed. On this way a smart card file system has a typical tree structure, as described in the following figure:

Example for smart card file structure (Source ISO/IEC 7816-4:2013)

Additionally, ICAO Doc 9303 describes in part 10 another sample file strucure with focus on eMRTD. Also in this case the master file is the root of the file system and all aditional files or applications are nodes or leafs of the tree For instance, following figure visuals a sample eMRTD file system including a master file:

Example for eMRTD file system (Source: ICAO Doc 9303 , Part 10 (7th edition, 2015)

Likewise, the eMRTD Application in the figure is the Application DF mentioned above in the ISO 7816 file structure. Both EF and DF can be selected with the APDU called SELECT. Compared to an EF, that is selected with the command ’00 A4 02 0C <Lc> <FID>’, an application is selected by the following APDU: ’00 A4 04 0C <Lc> <AID>’ (where <Lc> length of command, <FID> means File ID and <AID> means Application ID. The difference is in parameter P1 of the APDU: 04 indicates a ‘Select by DF name’ and 02 indicates a ‘Select EF under the current DF’.

Characteristics of a Master File

You can address the master file in almost the same manner as a EF or DF. A master file has s special file identifier, which is reserved only for master files: ‘3F 00′. This FID can be used to select the MF. Therefore ISO 7816 specifies the APDU ’00 A4 00 0C 02 3F 00′ to select the MF. On the other hand ICAO Doc 9303 part 10 (clause 3.9.1.1) specifies an alternative APDU to select MF: ’00 A4 00 0C’. In short: both commands are valid and select the MF. Beyond that, Doc 9303 recommends in the same clause in a note not to use the SELECT MF command. Why might this APDU cause problems? You can find the answer in ISO 7816 (clause 11.1.1): “If the current DF is neither a descendant of, nor identical to the previously selected DF, then the security status specific to the previously selected DF shall be revoked”. To sum up: changing the directory during Secure Messaging results in closing the secure channel and losing the secure session.

BSI released version 1.2 of TR-03105 Part 3.3

Leave a reply

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.

Version 1.5 of BSI TR-03105 Part 5.1 available

1 Reply

Introduction

The German BSI has released a new version 1.5 of TR-03105 Part 5.1. This technical guideline specifies conformity test cases for inspection system that are used in context of border control.

This new version replaces previous maintenance version 1.41, that was released in 2016. Most changes of the current release are based on comments of BSI, G+D Mobile Security and secunet Scurity Networks. This blog post decribes the changes, that took effect over the last months and were finalizied in version 1.5.

Important changes in version 1.5 of TR-03105 Part 5.1:

Several test cases are moved to ICAO Test Specification Part 4 for inspection systems
Removed transfer interface: specification deleted and test cases adopted.
Added new configuration for default EAC+PACE passport
Added new test suite for EF.CardSecurity (test suite LDS_J)
Added new test suite for EF.ATR/INFO (test suite LDS_K)
Added new test cases to verify trust anchor updates
Certificates:
- Generic encoding of Certificate Holder Reference (CHR)
- New certificates: DV_Cert_16, IS_Cert_16, CVCA_Link_Cert_16, CVCA_Link_Cert_17
New profile ‘DPRCTD-SHA1‘ for deprecated SHA-1 algorithm, including updated reference documents: several test cases require that an inspection system successfully validates any CSCA and DS certificate as well as SOD signed with RSA / DSA / ECDSA and SHA-1. This includes certificates and SOD signed 2019 or later. Doc9303 6th edition allowed for the usage of SHA-1, but Doc9303-12 7th edition (2015) clause 4.4.4 does not allow for the usage of these algorithms any longer: “SHA-224, SHA-256, SHA-384 and SHA-512, are the only permitted hashing algorithms”. There are plenty of eMRTDs with CSCA and DS certificates in circulation that follow the 6th edition and make use of SHA-1, i.e. an inspection system shall still support SHA-1. But the test specification should not explicitly require that an inspection system successfully validates a CSCA certificate, the corresponding DS certificate and the eMRTD’s SOD issued recently (or later during the life-time of the test specification) which are signed with RSA / DSA / ECDSA and SHA-1.
Deprecated algorithm SHA-1 is replaced by alternative hash algorithm if applicable:
- Modified test cases: LDS_H_74, LDS_H_75, LDS_H_76, LDS_H_77, LDS_I_01, LDS_I_02, LDS_I_03
Updated list of abbreviations and reference documentation
Consistent wording of OID (ICAO guide lines and BSI guide lines)
Clarification concerning the usage of PACE (test suite ISO7816_G)
Updated and re-organised list of algorithms to be supported by inspection systems (chapter 7)
Updated list of abbreviations and reference documentation
Minor editorial changes

Moved test cases

ISO7816_A_01: moved to ICAO ISO7816_A_01
ISO7816_A_02: moved to ICAO ISO7816_A_02
ISO7816_A_03: moved to ICAO ISO7816_A_04
ISO7816_B_01: moved to ICAO ISO7816_B_01
ISO7816_B_02: moved to ICAO ISO7816_B_02
ISO7816_B_03: moved to ICAO ISO7816_B_03
ISO7816_B_04: moved to ICAO ISO7816_D_01
ISO7816_B_05: moved to ICAO ISO7816_D_02
ISO7816_B_06: moved to ICAO ISO7816_D_03
ISO7816_B_07: moved to ICAO ISO7816_D_04
ISO7816_B_08: moved to ICAO ISO7816_D_05
ISO7816_B_09: moved to ICAO ISO7816_D_06
ISO7816_B_10: moved to ICAO LDS_D32
ISO7816_C_01: moved to ICAO ISO7816_F_01
ISO7816_C_02: moved to ICAO ISO7816_F_02
ISO7816_C_03: moved to ICAO ISO7816_F_03
ISO7816_C_04: moved to ICAO ISO7816_F_04
ISO7816_C_05: moved to ICAO ISO7816_F_05
ISO7816_C_06: moved to ICAO ISO7816_F_06
ISO7816_C_07: moved to ICAO ISO7816_F_07
ISO7816_C_08: moved to ICAO ISO7816_F_08
ISO7816_D_01: moved to ICAO ISO7816_G_01
ISO7816_D_02: moved to ICAO ISO7816_G_02
ISO7816_D_03: moved to ICAO ISO7816_G_03
ISO7816_D_04: moved to ICAO ISO7816_G_04
ISO7816_D_05: moved to ICAO ISO7816_G_05
ISO7816_D_06: moved to ICAO ISO7816_G_06
ISO7816_D_07: moved to ICAO ISO7816_G_07
ISO7816_D_08: moved to ICAO ISO7816_G_08
ISO7816_D_09: moved to ICAO ISO7816_G_09
ISO7816_D_10: moved to ICAO ISO7816_G_10
ISO7816_D_11: moved to ICAO ISO7816_G_11
ISO7816_D_12: moved to ICAO ISO7816_G_12
ISO7816_D_13: moved to ICAO ISO7816_G_13
ISO7816_D_14: moved to ICAO ISO7816_G_14
ISO7816_D_15: moved to ICAO ISO7816_G_15
ISO7816_F_01: moved to ICAO ISO7816_E_01
ISO7816_F_02: moved to ICAO ISO7816_E_02
ISO7816_F_04: moved to ICAO ISO7816_E_03
ISO7816_F_05: moved to ICAO ISO7816_E_04
ISO7816_F_06: moved to ICAO ISO7816_E_05
ISO7816_F_07: moved to ICAO ISO7816_E_06
ISO7816_F_08: moved to ICAO ISO7816_E_07
ISO7816_F_09: moved to ICAO ISO7816_E_08
ISO7816_G_01: moved to ICAO ISO7816_C_01
ISO7816_G_02: moved to ICAO ISO7816_C_02
ISO7816_G_03: moved to ICAO ISO7816_C_03
ISO7816_G_04: moved to ICAO ISO7816_C_04
ISO7816_G_05: moved to ICAO ISO7816_C_05
ISO7816_G_06: moved to ICAO ISO7816_C_06
ISO7816_G_07: moved to ICAO ISO7816_C_07
ISO7816_G_08: moved to ICAO ISO7816_C_08
ISO7816_G_09: moved to ICAO ISO7816_C_09
ISO7816_G_10: moved to ICAO ISO7816_C_10
ISO7816_G_11: moved to ICAO ISO7816_C_11
ISO7816_G_12: moved to ICAO ISO7816_C_12
ISO7816_G_13: moved to ICAO ISO7816_C_13
ISO7816_G_14: moved to ICAO ISO7816_C_14
ISO7816_G_15: moved to ICAO ISO7816_C_15
ISO7816_G_16: moved to ICAO ISO7816_C_16
ISO7816_G_17: moved to ICAO ISO7816_C_17
ISO7816_G_18: moved to ICAO ISO7816_C_18
ISO7816_G_19: moved to ICAO ISO7816_C_19
ISO7816_G_20: moved to ICAO ISO7816_C_20
ISO7816_G_21: moved to ICAO ISO7816_C_21
ISO7816_G_22: moved to ICAO ISO7816_C_22
ISO7816_G_23: moved to ICAO ISO7816_C_23
ISO7816_G_24: moved to ICAO ISO7816_C_24
ISO7816_G_25: moved to ICAO ISO7816_C_25
ISO7816_G_26: moved to ICAO ISO7816_C_26
ISO7816_G_27: moved to ICAO ISO7816_C_27
ISO7816_G_28: moved to ICAO ISO7816_C_28
ISO7816_G_29: moved to ICAO ISO7816_C_29
ISO7816_G_30: moved to ICAO ISO7816_C_30
ISO7816_G_31: moved to ICAO ISO7816_C_31
ISO7816_G_32: moved to ICAO ISO7816_C_32
ISO7816_G_33: moved to ICAO ISO7816_C_33
ISO7816_G_34: moved to ICAO ISO7816_C_34
ISO7816_G_35: moved to ICAO ISO7816_C_35
ISO7816_G_38: moved to ICAO ISO7816_C_36
ISO7816_G_39: moved to ICAO ISO7816_C_37
ISO7816_G_40: moved to ICAO ISO7816_C_38
ISO7816_G_41: moved to ICAO ISO7816_C_39
LDS_A_01: moved to ICAO LDS_A_01
LDS_A_02: moved to ICAO LDS_A_02
LDS_A_03: moved to ICAO LDS_A_03
LDS_A_04: moved to ICAO LDS_A_04
LDS_A_05: moved to ICAO LDS_A_05
LDS_A_06: moved to ICAO LDS_A_06
LDS_A_07: moved to ICAO LDS_A_07
LDS_A_08: moved to ICAO LDS_A_08
LDS_A_09: moved to ICAO LDS_A_09
LDS_A_10: moved to ICAO LDS_A_10
LDS_B_01: moved to ICAO LDS_B_01
LDS_B_02: moved to ICAO LDS_B_02
LDS_B_03: moved to ICAO LDS_B_03
LDS_B_04: moved to ICAO LDS_B_04
LDS_B_05: moved to ICAO LDS_B_05
LDS_B_06: moved to ICAO LDS_B_06
LDS_B_07: moved to ICAO LDS_B_07
LDS_B_08: moved to ICAO LDS_B_08
LDS_B_09: moved to ICAO LDS_B_09
LDS_B_10: moved to ICAO LDS_B_10
LDS_B_11: moved to ICAO LDS_B_11
LDS_B_12: moved to ICAO LDS_B_12
LDS_B_13: moved to ICAO LDS_B_13
LDS_B_14: moved to ICAO LDS_B_14
LDS_B_15: moved to ICAO LDS_B_15
LDS_B_16: moved to ICAO LDS_B_16
LDS_B_17: moved to ICAO LDS_B_17
LDS_B_18: moved to ICAO LDS_B_18
LDS_B_19: moved to ICAO LDS_B_19
LDS_B_20: moved to ICAO LDS_B_20
LDS_B_21: moved to ICAO LDS_B_21
LDS_B_22: moved to ICAO LDS_B_22
LDS_B_23: moved to ICAO LDS_B_23
LDS_B_24: moved to ICAO LDS_B_24
LDS_B_25: moved to ICAO LDS_B_25
LDS_B_26: moved to ICAO LDS_B_26
LDS_B_27: moved to ICAO LDS_B_27
LDS_B_28: moved to ICAO LDS_B_28
LDS_C_01: moved to ICAO LDS_C_01
LDS_C_02: moved to ICAO LDS_C_02
LDS_C_03: moved to ICAO LDS_C_03
LDS_C_04: moved to ICAO LDS_C_04
LDS_C_05: moved to ICAO LDS_C_05
LDS_C_06: moved to ICAO LDS_C_06
LDS_C_07: moved to ICAO LDS_C_07
LDS_C_08: moved to ICAO LDS_C_08
LDS_C_09: moved to ICAO LDS_C_09
LDS_C_10: moved to ICAO LDS_C_10
LDS_C_11: moved to ICAO LDS_C_11
LDS_C_12: moved to ICAO LDS_C_12
LDS_C_13: moved to ICAO LDS_C_13
LDS_C_14: moved to ICAO LDS_C_14
LDS_C_15: moved to ICAO LDS_C_15
LDS_C_16: moved to ICAO LDS_C_16
LDS_C_17: moved to ICAO LDS_C_17
LDS_C_18: moved to ICAO LDS_C_18
LDS_C_19: moved to ICAO LDS_C_19
LDS_C_20: moved to ICAO LDS_C_20
LDS_C_21: moved to ICAO LDS_C_21
LDS_C_22: moved to ICAO LDS_C_22
LDS_C_23: moved to ICAO LDS_C_23
LDS_C_24: moved to ICAO LDS_C_24
LDS_C_25: moved to ICAO LDS_C_25
LDS_C_26: moved to ICAO LDS_C_26
LDS_C_27: moved to ICAO LDS_C_27
LDS_C_28: moved to ICAO LDS_C_28
LDS_H_17: moved to ICAO LDS_D_02
LDS_H_18: moved to ICAO LDS_D_03
LDS_H_19: moved to ICAO LDS_D_04
LDS_H_20: moved to ICAO LDS_D_05
LDS_H_21: moved to ICAO LDS_D_06
LDS_H_22: moved to ICAO LDS_D_07
LDS_H_23: moved to ICAO LDS_D_08
LDS_H_24: moved to ICAO LDS_D_09
LDS_H_25: moved to ICAO LDS_D_10
LDS_H_26: moved to ICAO LDS_D_11
LDS_H_27: moved to ICAO LDS_D_12
LDS_H_28: moved to ICAO LDS_D_13
LDS_H_29: moved to ICAO LDS_D_14
LDS_H_30: moved to ICAO LDS_D_15
LDS_H_31: moved to ICAO LDS_D_16
LDS_H_32: moved to ICAO LDS_D_17
LDS_H_33: moved to ICAO LDS_D_18
LDS_H_37: moved to ICAO LDS_D_19
LDS_H_38: moved to ICAO LDS_D_20
LDS_H_39: moved to ICAO LDS_D_21
LDS_H_40: moved to ICAO LDS_D_22
LDS_H_41: moved to ICAO LDS_D_23
LDS_H_42: moved to ICAO LDS_D_24
LDS_H_43: moved to ICAO LDS_D_25
LDS_H_44: moved to ICAO LDS_D_26
LDS_H_48: moved to ICAO LDS_D_27
LDS_H_49: moved to ICAO LDS_D_28
LDS_H_53: moved to ICAO LDS_D_29
LDS_H_67: moved to ICAO LDS_D_30
LDS_H_68: moved to ICAO LDS_D_31
LDS_H_86: moved to ICAO LDS_D_35
LDS_H_87: moved to ICAO LDS_D_36
LDS_H_88: moved to ICAO LDS_D_37
LDS_H_89: moved to ICAO LDS_D_38

New test cases

ISO7816_E_31: New test case to check dynamic binding between protocols
ISO7816_E_32: New test case to check TA including trust anchor update
ISO7816_E_33: New test case to check TA with two different trust anchors
ISO7816_E_34: New test case to check TA with offered but not needed trust anchor update
ISO7816_E_35: New test case to verify that the inspection system performs terminal authentication successfully with id-TA-RSA-v1-5-SHA-512 algorithm
ISO7816_E_36: New test case to verify that the inspection system performs terminal authentication successfully with id-TA-RSA-PSS-SHA-512 algorithm
ISO7816_E_37: New test case to verify that the inspection system performs terminal authentication successfully with id-TA-ECDSA-SHA-384 algorithm
ISO7816_E_38: New test case to verify that the inspection system performs terminal authentication successfully with id-TA-ECDSA-SHA-512 algorithm
LDS_H_90: New test case with EF.SOD inconsistent with EF.COM (more data groups)
LDS_H_91: New test case with EF.SOD inconsistent with EF.COM (less data groups)
LDS_H_92: New test case with EF.SOD inconsistent with EF.COM (different data groups)
LDS_H_93: New test case with EF.SOD with missing checksum of EF.CardAccess
LDS_H_94: New test case to verify that the inspection system performs correctly if EF.SOD contains RSASSA-PSS with SHA224, SHA224 DG hash, DS stored inside SOD
LDS_H_95: New test case to verify that the inspection system performs correctly if EF.SOD contains RSASSA-PSS with SHA384, SHA384 DG hash, DS stored inside SOD
LDS_H_96: New test case to verify that the inspection system performs correctly if EF.SOD contains RSASSA-PSS with SHA512, SHA512 DG hash, DS stored inside SOD
LDS_H_97: New test case to verify that the inspection system performs correctly if EF.SOD contains DSA with SHA224, SHA224 DG hash, DS stored inside SOD
LDS_H_98: New test case to verify that the inspection system performs correctly if EF.SOD contains DSA with SHA256, SHA256 DG hash, DS stored inside SOD
LDS_J_01: New test case with CardSecurity inconsistent with EF.CardAccess (more SecurityInfos)
LDS_J_02: New test case with CardSecurity inconsistent with EF.CardAccess (less SecurityInfos)
LDS_J_03: New test case with CardSecurity inconsistent with EF.CardAccess (different SecurityInfos)
LDS_J_03: New test case with an incorrect ChipAuthenticationPublicKeyInfo for PACE-CAM in EF.CardSecurity
LDS_J_04: New test case with an incorrect ChipAuthenticationPublicKeyInfo in EF.CardSecurity
LDS_K_01: New test case with valid encoding with two bytes length for APDU
LDS_K_02: New test case with valid encoding with three bytes length for APDU
LDS_K_03: New test case with only one valid value for command length
LDS_K_04: New test case with wrong tag 7F66

Modified test cases

ISO7816_E_01: Added profile ‚DPRCTD-SHA1‘
ISO7816_E_03: Added profile ‚DPRCTD-SHA1‘
ISO7816_E_05: Added profile ‚DPRCTD-SHA1‘
ISO7816_E_19: Clarification in purpose
LDS_H_01: Added profile ‚DPRCTD-SHA1 ‘
LDS_H_02: Added profile ‚DPRCTD-SHA1 ‘
LDS_H_08: Added profile ‚DPRCTD-SHA1 ‘
LDS_H_09: Added profile ‚DPRCTD-SHA1 ‘
LDS_H_10: Added profile ‚DPRCTD-SHA1 ‘
LDS_H_15: importance of test case changed form ‘Mandatory’ to ‘Optional’
LDS_H_79: Added profile ‚DPRCTD-SHA1‘
LDS_I_01: Clarification in purpose of test case

Deleted test cases

ISO7816_F_03: Test case deleted in version 1.5
LDS_H_16: Test case deleted in version 1.5

Focus extension of this blog to eIDAS token

Leave a reply

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.

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.

Update of BSI TR-03105 Part 3.2 available

1 Reply

Introduction

The German BSI has released new versions of their test specifications TR-03105 Part 3. These test specifications covers the protocols in the context of chips used in eID documents. Part 3.2 covers security protocols used in common eMRTDs. This blog post describes the changes of this new version 1.5. The last version was released in 2014 and since this time some changes were necessary.

Beside several editorial changes and maintenance the most important changes of TR-03105 Part 3.2 Version 1.5 are the move of both test suites concerning Chip Authentication to the ICAO test specification part 3 and the new test suite for EF.ATR/INFO. The file EF.ATR/INFO is recommended by ICAO to store the buffer sizes that should be used by the terminal to read the chip content in a performant way. Maintenance includes updating the referenced documents and a consistent wording (e.g. ‘Data Group’ or ‘FID’) in the whole specification.

Certificates are specified now in a more comfortable way similar to the way used in TR-03105 Part 3.3: Certificate Holder Reference (CHR) and Certification Authority Reference (CAR) are now specified in the parameter block in a human-readable way and not in hex as before.

The specified security status – described in chapter 3.2.1 – was updated: A Secure Messaging session SHOULD (instead of MUST in the previous version) be aborted if and only if a secure messaging error occurs.

The list of abbreviations in chapter 1.1 was updated (e.g. FID or SFI) and corrected (e.g. CAR).

Profiles were adapted to handle the optional Basic Access Control (BAC) protocol and the optional file EF.ATR/INFO. Additionally all profiles for Chip Authentication (CA_KAT, CA_ATGA and KeyRef) are deleted or rather moved to ICAO part 3.

Note: TR-03105 Part 3.1 Version 1.2.1 contains a new requirement for test laboratories: “During the certification process the test laboratory must ensure that the features quoted by the applicant in his Implementation Conformance Statement (ICS) are in fact in coincidence with the features supported and accordingly not supported by the chip”.

New test cases in version 1.5

BSI TR-03105 Part 3.2 contains the following new test cases / test units:

7816_L_15: Test that the chip rejects an additional BAC run or resets extended access rights after successful PACE run (PACE, CA1, TA1, BAC)
7816_L_16: Test that the chip rejects an additional PACE run or resets extended access rights after successful BAC run (BAC, CA1, TA1, PACE)
LDS_L: Test suite to verify the conformity of file EF.ATR/INFO

Modified test cases in version 1.5

BSI TR-03105 Part 3.2 contains the following modified test cases / test units / certificates:

DV_Cert_10c: Corrected CHR in certificate
DV_Cert_10d: Corrected CHR in certificate
DV_Cert_11b: Corrected CHR in certificate
7816_H_xx: Used <Lc> instead of fixed encoded length of command in step 1
7816_I and 7816_II: Test suites moved to ICAO Part 3
7816_J_12: Accept also ’90 00′ as valid status word in step 1
7816_K_1a: Added profile BAC
7816_L_13: Added conditional step 10 to verify that access to data group 3 has NOT been granted
7816_L_14: Corrected encoding of SELECT command in step 8
7816_M_xx: Used <Lc> instead of fixed encoded length of command
LDS_E: Moved test cases LDS_E_1- LDS_E_4 (Chip Authentication) to ICAO part 3 and renumbering of test cases

It took more than a year to update this test specification in combination with Part 3.3 which handles eIDAS protocols and EACv2 used by eID cards. Several stake holders and members of ‘Deutsches Industrie Forum’ (DIF) commented both versions and at the end this version is a consensus of all participated bodies.

Update of ICAO RF and Protocol Test Specification

2 Replies

Introduction

Simultaneously the ICAO released updated and new versions of their ICAO test specifications for eMRTD and corresponding inspection systems. While the Technical Advisory Group (TAG) of ICAO endorsed the update on the ICAO website, from now on these test specifications can be referenced officially and can also be used for certification. Additionally, there is also a new test specification part 5 available focusing on PKI objects like certificates and revocation lists.

ICAO Test Specification Part 3 (eMRTD)

Finally version 2.11 of the ICAO test specification for eMRTDs is a result of two ISO SC17 WG3 TF4 meetings 2017 in Paris and 2018 in Tokyo and also a result of the interoperability test in Ispra 2017. First of all there are some interesting modifications compared with the previous version 2.10 released in 2016:

Test cases and ICS adoption for Chip Authentication Version 1 (test cases are moved from BSI TR-03105 Part 3.2)
Test of command robustness with invalid class bytes are removed
Clarifications concerning PACE test cases
Clarification concerning ISO execution errors
Clarification concerning extended length APDUs used during Active Authentication
Some corrections concerning LDS version 1.8
Additionally, there are some clarifications and minor editorial changes

New test cases in Version 2.11

Most noteworthy the ICAO test specification part 3 contains the following new test cases:

ISO7816_P_79: Negative test case to verify the Secure Messaging handling while PACE access is granted for the SELECT application command (bad send sequence counter)
ISO7816_R_07: Positive test case to verify the behavior of a PACE-protected eMRTD in response to the INTERNAL AUTHENTICATE
Test suite ISO7816_T: New test cases for Chip Authentication (this tests were moved from BSI TR-03105 Part 3.2 with minor corrections and remove robustness test of invalid class bytes)
LDS_E_01: Test the LDS tag of the DG14 object
LDS_E_02: Test the ASN.1 encoding of the SecurityInfos for Chip Authentication
LDS_E_03: Test the ASN.1 encoding of the ChipAuthenticationPublicKeyInfo
LDS_E_04: Test the ASN.1 encoding of the ChipAuthenticationInfo
LDS_K_05: Test the ASN.1 encoding of a PCKS#7 signedData object
LDS_K_06: Test the value that is encoded into the signedData element
LDS_K_07: Test the SignerInfo element of the signedData structure
LDS_K_08: Test the signing certificate used to verify the EF.CardSecurity object

Modified test cases in Version 2.11

The ICAO test specification part 3 contains the following modified test cases:

ISO7816_A_2: SELECT Application command with CLA byte ‘8F’ is removed
ISO7816_C_15: Test case removed (invalid CLA byte)
ISO7816_C_19: Test case removed (invalid CLA byte)
ISO7816_D_2: Test case removed (invalid CLA byte)
ISO7816_E_2: Test case removed (invalid CLA byte)
ISO7816_F_2: Test case removed (invalid CLA byte)
ISO7816_G_2: Test case removed (invalid CLA byte)
ISO7816_P_04: Test case removed (invalid CLA byte)
ISO7816_P_18: Test case removed
ISO7816_P_37: Test case removed (invalid CLA byte)
ISO7816_P_38: Test case removed (invalid CLA byte)
ISO7816_P_39: Test case removed (invalid CLA byte)
ISO7816_P_40: Test case removed (invalid CLA byte)
ISO7816_P_66: Hint, that in test scenario step 1 the length encoding of DO ’80’ must be correct
ISO7816_P_67: Hint, that in test scenario step 1 the length encoding of DO ’80’ must be correct
ISO7816_R_01: Generic length encoding of APDU
ISO7816_R_02: Generic use of DO ’97’ and length encoding of APDU
ISO7816_R_03: Hint, that INTERNAL AUTHENTICATE command must use Secure Messaging if access control mechanism is supported
ISO7816_R_04: Hint, that INTERNAL AUTHENTICATE command must use Secure Messaging if access control mechanism is supported
ISO781_S_03: Padding indicator ’01’ in DO ’85’ is removed (odd ins)
ISO781_S_04: Padding indicator ’01’ in DO ’85’ is removed (odd ins)
LDS_A_03: In EF.COM there is also LDS version 1.8 accepted
LDS_A_05: Purpose of test case is corrected
LDS_C_04: Check that the number of Biometric Information Group Templates (BIGT) is one
LDS_D_04: Check also the LDS security object version in test scenario step 4; a future version of Doc9303 part 10 requires that the signedData certificates field in LDS v1.8
SHALL include the Document Signer Certificate (CDS)
LDS_D_06: Check that LDS Version Info element does not exist in test scenario step 8 and handle also LDS version 1.8 in this test case
LDS_D_07: Check that the validity period of the signing certificate MUST be within the validity period of the country signing certificate in test scenario step 4
Test suite LDS_E: Numbering of test cases has changed
LDS_E_07: Check also the hash algorithm output length of the signatureAlgorithm
LDS_J_05: ECDSA is also be handled in test scenario step 3 from now on

ICAO Test Specification Part 4 (Inspection Systems)

Also ICAO test specification part 4 version 2.11 is the result of a typical ISO process finalized by the same meetings in Paris and Tokyo of ISO SC17 WG3 TF4 mentioned above. Finally this specification contains also some interesting changes compared with the previous version 2.10 released in 2016:

Configuration of default EAC MRTD specifies EF.DG15
Specification of a default PACE-CAM protected eMRTD
Clarifications concerning PACE and PACE-CAM
Additionally, there are some clarifications and minor editorial changes.
Added profile AA.B4 to test signature generation scheme specified in ISO/IEC 9796-2 paragraph B.4.

New test cases in Version 2.11

The ICAO test specification part 4 contains the following new test cases:

ISO7816_E_11: Test case verifies that the inspection system performs the Active Authentication with RSA algorithm in the signature function and B.4 method
ISO7816_B_04: Positive test with BAC protected eMRTD and three line MRZ
ISO7816_G_16: Check correct execution of the Chip Authentication protocol
LDS_B_29: Test verifies that the test object can detect a mismatch between MRZ and EF.DG1 where MRZ uses TD2 format and EF.DG1 uses TD1 format
LDS_B_30: Test verifies that the test object can detect a mismatch between MRZ and EF.DG1 where MRZ uses TD1 format and EF.DG1 uses TD2 format
LDS_D_01: Added test cases for missing algorithm and signature combinations
LDS_D_19: Added test cases for DSA with various SHA algorithms
LDS_D_39: Test case verifies that the inspection system checks the signature in EF.CardSecurity and detects an invalid signature

Modified test cases in Version 2.11

The ICAO test specification part 4 contains the following modified test cases:

ISO7816_C_01: Test case include three line MRZ from now on
ISO7816_C_03: Editorial correction of protocol name
ISO7816_C_29: Use new configuration for PACE CAM protected eMRTD
ISO7816_C_30: Use new configuration for PACE CAM protected eMRTD
ISO7816_C_31: Use new configuration for PACE CAM protected eMRTD
ISO7816_C_32: Use new configuration for PACE CAM protected eMRTD
ISO7816_C_33: Use new configuration for PACE CAM protected eMRTD
ISO7816_C_34: Use a special configuration to indicate that the IS performs Passive Authentication
ISO7816_C_36: Change context form PACE-CAM to PACE (CAM -> GM)
ISO7816_C_39: Use new configuration for PACE CAM protected eMRTD
ISO7816_E_01: Use signature production function B.6
ISO7816_E_02: Clarification of EF.DG14 and specification of EF.DG15 and using of signature production function B.6
ISO7816_E_03: Use signature production function B.6
ISO7816_E_04: Use signature production function B.6
ISO7816_E_05: Use signature production function B.6
ISO7816_E_06: Use signature production function B.6
ISO7816_E_07: Use signature production function B.6
ISO7816_E_08: Use signature production function B.6
ISO7816_E_09: Perform Active Authentication with B.6 method of ISO/IEC 9796-2 and use RSA-SHA1; Hint, that the RSA operation during AA must result in a value bigger than n/2 with n being the modulus to ensure that method B6 is really used in this test case
ISO7816_E_10: Use signature production function B.6
ISO7816_F_03: Test case removed
ISO7816_G_07: Correction of key agreement algorithm (id-CA-DH-3DES-CBC-CBC)
ISO7816_G_11: Correction of key agreement algorithm (id-CA-DH-3DES-CBC-CBC)
ISO7816_G_15: Use default EAC configuration in this test case
LDS_A_01: Correction in EF.COM (removed data groups)
LDS_A_02: Correction in EF.COM (removed data groups)
LDS_A_03: Correction in EF.COM (removed data groups and correction of increased length)
LDS_A_04: Correction in EF.COM (removed data groups)
LDS_A_05: Correction in EF.COM (removed data groups)
LDS_A_06: Correction in EF.COM (removed data groups)
LDS_A_07: Correction in EF.COM (removed data groups)
LDS_A_08: Correction in EF.COM (removed data groups)
LDS_A_09: Correction in EF.COM (removed data groups)
LDS_A_10: Correction in EF.COM (removed data groups)
LDS_C_14: Access condition of EF.DG2 changed from BAC to PACE
LDS_C_17: Corrected ID of configuration
LDS_D_26: Access condition of EF.SOD changed from BAC to PACE
LDS_D_35: Corrected wording in specification of EF.SOD
LDS_D_36: Corrected wording in specification of EF.SOD and corrected title of test case
LDS_D_37: Corrected wording in specification of EF.SOD and corrected title of test case
LDS_D_38: Test case removed
LDS_E_01: Access condition of EF.DG15 changed from BAC to PACE
LDS_E_02: Access condition of EF.DG15 changed from BAC to PACE
LDS_E_03: Access condition of EF.DG15 changed from BAC to PACE
LDS_F_01: Correction in content of EF.DG14 (generic length)
LDS_F_02: Correction in content of EF.DG14 (generic length)
LDS_F_03: Correction in content of EF.DG14 (generic length)

New and noteworthy ICAO documents and updates

As mentioned in the introduction ICAO has release a new test specification for PKI objects. The new part 5 of ICAO test specifications is focusing on various things used in this context like certificates, certificate revocation lists (CRL) as well as master and deviation lists. Furthermore, there is a new version 1.7 of the technical report Visible Digital Seals for Non-Electronic Documents available. Technical report Portrait Quality is released in version 1.0 where reference facial images for eMRTD are specified. Concerning LDS2 the technical report LDS2 – PKI specifies the PKI to support the ICAO LDS2 project including travel records, visa records and additional biometrics. Last but not least there is also a new version of technical report Logical Data Structure (LDS) for Storage of Data in the Contactless IC, Doc 9303-10 LDS 2 – New Applications available at the ICAO website.

First results of eMRTD Interoperability Test 2017 in Ispra

6 Replies

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

The following diagram describes the relation of the 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 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

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

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

Security risk Smart Home – The Lives of Others

Leave a reply

During IT Flash Paderborn #3 I gave a short presentation and demo concerning security risk smart home. With the described passive attack you can profile all residents of the smart home. And with the described active attack you can manipulate the smart home and the devices used there.

Picture of the film 'The Lives of Others'

From the movie ‘The Lives of Others’

In one of my previous blog post I described how to run a passive attack on a smart home in context of the protocol EnOcean. With the collected information you can set up a profile of all people living in this home.

For the passive attack I used a new tool that I own for a few weeks now: HackRF One. It’s an typical piece of hardware that you can use in context of Software Defined Radio (SDR). You can see this helpful tool on the following picture (Source: Great Scott Gadgets):

HackRF One

HackRF One was initiated as a Kickstarter project a few years ago and is used by a large community in the area of reengineering protocols. In my demonstration I used HackRF One on the one hand to find the exact frequency that is used by the EnOcean devices that I used. And on the other hand I used HackRF One to capture and replay the EnOcean telegram.

In a first step you need the exact frequency that is used by your EnOcean stuff. To find this frequency I used the tool gqrx. Gqrx is an open source software defined radio receiver powered by the project GNU Radio. The tool allows visualizing frequencies that are used in your environment. For example: EnOcean is works on 868 MHz, but gqrx helps you to find the exact frequency of this protocol, in my case: 868,290 MHz. The following screenshot shows the way gqrx works (Source gqrx-website):

Screenshot of gqrx

As soon as you have found the exact frequency, you can use the software distributed with HackRF one to capture and to replay the messages in your smart home. In the demonstration I used a pushed button and a light actuator adapter to visualize the attack.

In case of EnOcean there are mechanisms to protect against these attacks available. One of these mechanisms is called ‘Rolling Code’ where telegrams are encrypted which makes the capture and replay attack above useless. The following command stores the traffic in a file:

hackrf_transfer -t switch.raw -f 869290000

Once the traffic is stored in a file, you can send this information again (capture and replay) with your HackRF One with the following command:

hackrf_transfer -t switch.raw -f 869290000 -x 47

You can find some more information in the slides of presentation. As you can see, smart home devices should be used carefully if you want to protect your privacy. Today it’s very easy to collect and manipulate a smart home. So always keep in mind the security risk smart home when you plan your smart home.

Call for Participation: Interoperability Test 2017 in Ispra

1 Reply

The European Commission will organize conformity and interoperability tests for eMRTDs together with a conference on 25th and 26th September 2017. It will be held in the European Commission Joint Research Centre (JRC) premises in Ispra, Italy. The tests will focus on the latest access control specifications (e.g. the operation of the PACE protocol with Chip Authentication Mapping). This security mechanism, known as “Password Authenticated Connection Establishment with Chip Authentication Mapping” (PACE-CAM) is specified in Technical Report BSI TR-03110 “Advanced Security Mechanisms for Machine Readable Travel Documents and eIDAS token” and it combines PACE and Chip Authentication (CA) into one protocol leading to faster ID document verification.

Logo JRC

The conference will take place on the second day (26/09/2017) and will include speakers from the EU Commission, ICAO (requested) and Member States (requested). At its end, the high-level aggregate results of the tests will be presented.

The main beneficiaries of these tests are EU Member States. Depending on the number of EU Member States that will participate in the event, and provided that it is possible from an organisational perspective, a limited number of non-EU ICAO Member States and private sector travel document manufacturers will be allowed to participate in the test (on a first come first serve basis).

The test will focus on the implementation of PACE as specified in the Technical Report “Radio Frequency Protocol and Application Test Standard for eMRTD Part 3 Tests for Application Protocol and Logical Data Structure“, Version: 2.10, July 2016.

You can find the Call for Participation for the interoperability test here with more information concerning preregistration etc. See you in Ispra!

Apple adds NFC support to iOS 11

Leave a reply

During Apple’s Word Wide Developer Conference (WWDC) this week the company shared the latest information concerning support of Near Field Communication (NFC) protocol in iOS 11. Developers coding for iOS 11 will be able to create apps that can read NFC tags. This opens the door for wireless exchange of information between an iPhone and various connected devices in a user’s environment.

Apple and NFC (Wikipedia)

Currently the NFC chip in the iPhone is only used to handle contactless Apple Pay transactions. But in the new framework called Core NFC the company provide the foundation for multiple use cases by third-party apps. Using Core NFC, you can read tags of types 1 through 5 that contain data in the NFC Data Exchange Format (NDEF). At present the API supports only read access for the tags. Hopefully in the future there will be also the possibility integrated to write to the tags. With the new framework Apple could let third-party developers make use of NFC in new ways, or it could simply expand NFC functions beyond Apple Pay for use in its own apps and services. The specification says, “For example, your app might give users information about products they find in a store or exhibits they visit in a museum”.

There are also first code samples available, e.g. iOS11-NFC-Example implemented by Hans Knöchel. In his GitHub repository Hans describes a quick example showing how to use the API in iOS 11 and Swift 4. The new framework requires at least XCode 9, iOS 11 and an iPhone 7 or iPhone 7 Plus.

However, the possibilities for NFC outside of banking area look set to expand with Apple’s next-generation mobile operating systems. So I’m looking forward to blogging of an additional version of iOS, which also allows complex contactless protocols we know in the context of eID like Chip Authentication Mapping (PACE-CAM). This would enable the iPhone to read ID cards of ePassports using ISO 14443 for contactless communication. Nevertheless this first step in iOS opens a world of possibilities for new apps on iPhones.

Happy New Year and summary of 2016

Leave a reply

I wish you a happy and prosperous new year 2017. Thanks for visiting my blog in 2016 and thanks for your feedback in various forms like comments and discussions. In 2016 I published several articles on this blog and I plan to continue writing about my activities in the area of protocols and testing also in 2017. Before I start with new blog posts in the next weeks, I give a short summary of 2016.

Most read articles in 2016

Article	#
Home Page	1
Java Sample Code to access Smart Card	2
First results of eMRTD Interoperability Test 2016	3
Chip Authentication Mapping	4
ICAO LDS 1.8 or How to detect a file on an ePassport	5
Sending EnOcean telegram	6
Chip Authentication Version 3 (CAv3)	7
Update of BSI TR-03105 Part 5.1 available (V1.4)	8
eMRTD Test Specifications Overview	9
Eclipse IoT overview	10

First time visiting CeBIT as a blogger in 2016

In 2016 it was the first time that I visited the CeBIT in Hanover as an accredited blogger. There were several companies supporting bloggers and also the CeBIT itself established rooms and areas in the exhibition to work and refresh. ePassports were not focused in the exhibition but several companies and organisations demonstrated their ideas concerning IoT and the protocols used there.

Blogger Press Card CeBIT 2016

protocolbench is now a registered trade mark

Last year I decided to protect the name of this blog. so I’ve registered the word mark ‘protocolbench’ at the German Patent and Trade Mark Office (DPMA). Under register number 302015219473 you can find more information about the trade mark.

Certificate of word mark ‘protocolbench’

Support this blog

In middle of December I decided to use Flattr and Patreon on my blog. These organisations allow visitors and readers to support my blog in an easy way. If you like this blog, please support my work by donating via Flattr.

New job at secunet

And last but not least, I’m working for a new company. Since September 2016 I’m working as a Principal at secunet Security Networks AG in the division ‘Homeland Security’. My area of responsibility is similar to the one before, like testing, eID and standardisation and of course GlobalTester. With the new facilities in Paderborn secunet has established the ninth location in Germany.

Conclusion and summary

So, also in 2017 I will publish new blog posts here in context of protocols and testing. One of the next articles for example will describe the digitalisation of ePassports. If you have ideas of subjects you are interested in or subjects you work on and you would like to get more visibility, just contact me.

How to assure interoperability?

Leave a reply

Motivation

Typically protocols are connecting two different systems. In an open system with several stakeholders interoperability between these systems is a fundamental requirement. To assure this interoperability there are various way. In this blog post I present you two popular approaches in cooperation with my colleague Dr. Guido Frank who works at the German Federal Office for Information Security (BSI).

Interoperability

Interoperability is a characteristic of a product or system, whose interfaces are completely understood, to work with other products or systems, present or future, in either implementation or access, without any restrictions (Source: Wikipedia).

From a system perspective, this means that all implementations need to comply to the same technical specifications. Interoperability is essential because these systems are open systems with different stakeholders. It refers to the collaboration ability of cross-system protocols.

Crossover Testing vs. Conformity Testing

To ensure interoperability, implementations need to be tested. In general, there are different approaches to test systems or implementations.

Crossover Testing

The scope of a crossover test is to test every system component with all other system components. This procedure allows to detect incompatibilities between existing implementations with a fixed release status.

The efforts to perform this kind of test increases disproportionately with every additional instance of the system. Therefore these kinds of tests can practically be performed only with a small number of involved test partners. The following figure illustrates the interaction between different systems in a crossover test.

Crossover Testing

Another problem of crossover testing is maintenance: every new implementation or any new version of existing implementations must be tested with every corresponding system, which again increases the testing efforts significantly. A benefit of crossover testing can be found in the early phase of developing when crossover testing helps the developer to implement their own system and can be used as an indicator to use the right way. On the other side, this kind of testing only indicates a positive test case with two correct systems to test (“smoke test”). The behaviour of the systems in bad cases is not tested. Additionally, with two different systems to be tested in a crossover test it’s difficult to decide which system behaves correctly in case of a failure and which implementation has to be changed.

Conformity Testing

The purpose of conformity tests is to verify that a system implements the specifications correctly (i.e. it “conforms” to the specifications). These specifications need to be defined by stakeholders and finally implemented e.g. by test labs to run their conformity test tools.

This way these test suites verify the implementation under test with protocol data units which mimic both “correct” and “incorrect” behaviour of the system. The figure below illustrates the interactions between the test suite implementation and the system in a conformity test. The test definitions have to be tested with regard to harmonised interpretation among test participants.

Conformity Testing

Conclusion

Both approaches of testing allow assuring interoperability to other systems components to a certain extent. But with increasing complexity of the systems to be tested and the increasing number of systems at all the crossover testing is getting more and more extensive. Only conformity testing scales well with the complexity and the number of systems in an adequate way. The following diagram illustrates the increasing efforts of crossover tests in relation to conformity test.

Compared efforts of crossover testing and conformity testing

Direct tests between a subset of implementations are be useful during implementation or integration phase of a node. Such tests could also be performed via bilateral appointment between different stakeholders, e.g. via pilots. Experience from such test could also be used as additional input for conformity tests. Crossover testing or a central coordination of such tests would not be necessary for this purpose. As soon as there are several system components to be tested, conformity testing should be chosen.

The benefits of such an approach of interoperability testing can also be seen in several so called ‘InterOp tests‘ that have been performed for more than a decade in context of eMRTD. Detailed failure analysis allows to improve the stability of the whole eMRTD system. Additionally, the results of ‘InterOp tests’ helps not only to improve the stability of ePassports and inspection systems but also to improve the quality of (test) specifications and test tools.

Another open system with several vendors is banking. All cash cards or credit cards must fulfill international test specifications. This way of interoperability testing allows customers to use their cards worldwide at cash machines of various banks.

To assure systematic interoperability, it is necessary to set up conformity test specifications that systematically test the requirements as defined in the technical specifications. The tests should not only define good cases but also bad cases that mirror the pitfalls typically occurring in a system. Only this way allows to assure real system-wide interoperability.

Setup of test specification

Important components of a conformance test specifications are:

Description of general test requirements
Test setup / Testing environment
Definition of suitable test profiles / implementation profiles
Implementation Conformance Statement (ICS)
Definition of testing or configuration data
Definition of test cases according to a unified data structure
Each test case should concentrate on a single feature to be tested

The following structure of a test specification has been established since the beginning of eMRTD testing in 2005. It is based on the ISO/OSI layer model where data is tested on layer 7 and protocols are tested on layer 6.

Typical structure of a test case in this context:

Test case ID: unique identifier for each test case
Purpose: objective of the test case
Version: current version of this test case independent from the test specification
Reference: where is this feature / behaviour specified
Preconditions: setup of test case
Test scenario: description of test case, step by step
Postconditions: setdown of test case

Test cases can be combined in test suites to cluster test cases of similar topics or objectives. As the test specifications need to be implemented in suitable testing tools, it is useful to define the test cases already in a way, that eases their implementation, e.g. via XML using a suitable XML scheme.