Category Archives: TR-03105

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

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

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.

Cover of TR-03105 Part 5.1 Version 1.5
Cover of TR-03105 Part 5.1 Version 1.5

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

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

eIDAS Logo

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

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

Protocols specified in TR-03110 beyond eMRTD are:

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

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

Update of BSI TR-03105 Part 3.2 available

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.

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.

 

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.

Testing ePassport Readers using TTCN-3

Currently you can find the well-known test tool Titan under the patronage of the Eclipse Foundation (proposal). This tool was developed by Ericsson several years ago to the test internet protocol (IP). Titan bases on TTCN-3, a test language focusing on communication protocols. This keeps me in mind an old project with ETSI where we used TTCN-3 to test ePassport readers concerning BSI TR-3105 part 5.1.

From end of 2009 to middle of 2011 ETSI has conducted a project to develop a test system prototype for conformance testing of ePassport readers. The objective of this project was to design, build and test a TTCN-3 (Testing and Test Control Notation, Version 3) based test system prototype for ePassport reader conformance testing. This project was a joint effort between the European Joint Research Centre (JRC) in Ispra (Italy) and ETSI in Sophia Antipolis (France). The test language TTCN-3 has already been widely used in many testing projects across different protocols and technologies. However, until this project TTCN-3 has not been applied in the area of contactless smart card testing.

The ETSI Specialists Task Force (STF) 400 with experts from the companies / organisations AMB Consulting, ARH, Comprion, ETSI, FSCOM, HJP Consulting, Masaryk University, Soliatis and Testing Technologies operated this project. The work of this STF has been split into three main phases:

  1. Design, implementation, and use of ePassport test system
  2. Development of ePassport testing framework
  3. Writing of the documentation and dissemination material

Scope of this project was to build a test system to test an inspection system typically used to read ePassports. To demonstrate the basic functionality and the feasibility, a subset of BSI TR-03105 Part 5.1 was specified and implemented in the test system.

The following image describes the architecture of the ePassport reader test system developed during this project:

System architecture of prototype to test ePassport Reader with TTCN-3

Architecture of test system based on TTCN-3 for ePassport readers (Source: ETSI White Paper No.7)

The most significant part in the architecture is “TTCN-3 Test Component”. This module simulates the ePassort behaviour  by receiving APDUs, react to these commands and send result in APDUs back to the SUT (here the ePassport reader).

The successful implementation of a TTCN-3 based test system shows that the use of TTCN-3 fits the requirements of conformance testing of eMRTD or other eID systems. The prototype demonstrates the feasibility of using such formal techniques for protocols which would improve the quality and repeatability of tests and reduce room for interpretation.

An overview of this project and the results were summarized by the colleagues Jean-Marc Chareau, Laurent Velez and Zdenek Riha in ETSI White Paper No 7.

 

 

Update of RF and Protocol Testing Part 3 V2.06 online

The MRTD group of ICAO has released an update (version 2.06) with clarifications of their technical report RF and Protocol Testing Part 3 focusing on conformity test and protocol testing for ePassports implementing protocols like BAC and Supplemetal Access Control (SAC) respective PACEv1.

The new version 2.06 of TR-03105 Part 3.2 focusing on protocol testing includes the following changes:

  • General: Several test cases accept now additionally also an Execution Error in expected results.
  • General: Instead of ePassports we are talking now about eMRTD.
  • General: An additional profile was added: “EAC or PACE or AA-ECDSA”.
  • General: The profiles of several test cases were extended.
  • General: Compatibility to both PACE and BAC in most test cases of ISO_D and ISO_E.
  • General: Use CAR from DV certificate during Terminal Authentication instead of reading CAR from file EF.CVCA.
  • ISO7816_C_04: The command GET CHALLENGE must not have been performed.
  • ISO7816_P_10: This test case was deleted.
  • ISO7816_P_73: Allows multiple PACEInfo if just one parameter ID is being used.
  • ISO7816_P_74: Allows multiple PACEInfo if just one parameter ID is being used.
  • ISO7816_P_75: Requires two PACEInfo elements using the same OID and different parameter IDs.
  • LDS_A_03: Now LDS version 1.8 is also accepted.
  • LDS_B_13: Added new assertions on the date (day and month).
  • LDS_D_06: Additional test step checking the LDS info object.

In the past I have missed such a list for every new released version of test specifications, like BSI TR-03105 or ICAO technical reports. You can find a list of modifiied test cases for protocol testing in the last version of BSI TR-03105 Part 3.2 in a previous post.

So I hope, this list of modified test cases is helpful for your work in context of ePassport testing. If you are interested, please leave a comment and I will update this list with every new version of test specifications in context of smart cards used in ePassports and ID cards.

Update of BSI TR-03105 Part 3.2 available (V1.4.1)

The German BSI and French AFNOR have released an update with minor clarifications of their technical guideline BSI TR-03105 Part 3.2 focusing on conformity tests for ePassports implementing protocols like PACE and SAC (EACv1).

The new version 1.4.1of TR-03105 Part 3.2 includes changes in the following test cases:

  • ISO7816_II_2: The missing profile ‘ECDH’ is added to the profile of this test case according to the corresponding test case ISO7816_I_2 in test suite I.
  • ISO7816_II_3: There is a new test step added (step 3) to perform the additional command GENERAL AUTHENTICATE to perform key agreement correctly.
  • ISO7816_K_19: There are several meanings how to handle the ‘presence’ of a data group. A simple command SELECT to detect a data group of the chip is insufficient and may cause problems. In this test case the presence of data group EF.DG15 should be used as an indicator to perform Active Authentication. In the new version of this test case the wording is adapted to TR-03110 and is changed from “is present” to “if available”. On this way the discussion is moved from TR-03105 to TR-03110. From my point of view it makes sense to check if the relevant data group is listed in file EF.SOD. The information in EF.COM is note secured by Passive Authentication and may be corrupted. Instead of that, EF.SOD is secure and can be used as an indicator of the existence of a file on the chip.
  • ISO7816_L_13: In step 9 of this test case the command MUTUAL AUTHENTICATE is performed. In the old version of the specification this command was not complete. The missing Le byte is now added, so the command expects now 40 bytes (or 28 in hex) as response.
  • ISO7816_L_14: In the previous version of TR-03105 in step 8 of this test case a SELECT MF with parameter P2 = ‘0C’ is performed. ISO7816-4 specifies for bytes b4=1 and b3 =1 that no response data is expected if Le field is absent. This command causes problems on some COS implementations and so the command is replaced by a SELECT with P2 = ’00’ and Le = ’00’.

In the past I have missed such a list for every new released version of test specifications, like BSI TR-03105 or ICAO technical reports. So I hope, this list of modified test cases is helpful for your work in context of ePassport testing. If you are interested, please leave a comment and I will update this list with every new version of test specifications in context of smart cards used in ePassports and ID cards.