SB nº AN-29 : Format 1 Secure Messaging (Clarification)

v1.0 Specification Bulletins

Application Note Bulletin No. 29 First Edition: August 2005 This Application Note clarifies the description of Format 1 Secure Messaging that appears in Section 9 and Annex D2 of Book 2. Format 1 Secure Messaging

Applicability

This Application Note applies to:

  • EMV Integrated Circuit Card Specifications for Payment Systems Version 4.1 Book 2 Security and Key Management

Related Documents

  • None This Application Note clarifies the description of Format 1 Secure Messaging in EMV Version 4.1 Book 2, Section 9 and Section D2. It clarifies the notation used for the length and data of unsecured and secured commands and it clarifies that
  • when there is no command data then the only data in the secured command is a MAC, and
  • when command data is enciphered it is always padded with at least one padding byte even if the length of the unsecured command data is a multiple of 8. These clarifications are detailed below. The use of underscore denotes new text inserted; strikethrough denotes old text deleted; sidebars denote a formatting change. Specification Clarification Notice In the next release of the EMV Specifications the following addition will be made to EMV Book 2 Security and Key Management, the 5th paragraph of Section 9.2.1.1: “The second data object is the MAC. Its tag is '8E', and its length shall be in the range of four to eight bytes. Note that if the command to be secured has no command data (e.g. Application Block) then this MAC is the first and only data object of the secured command.” In the next release of the EMV Specifications the following changes will be made to EMV Book 2 Security and Key Management, Annex D2: “D2 Format 1 Secure Messaging Illustration Below is an illustration of Format 1 Secure Messaging as defined in Section 9 using a command where the command data of the unsecured command is not considered to be BERTLV encoded. The command data is included in the computation of the MAC as a data object in accordance with Section 9.2.3. This is either the plaintext data object with tag '81' or, if secure messaging for confidentiality is applied, the data object for confidentiality with tag '87'. D2.1 Securing the Command APDU Before application of secure messaging a command APDU is called an ‘unsecured’ command. After secure messaging is applied a command APDU is called a ‘secured’ command. Throughout this section, Lc is the length of the unsecured command data field; that is, the length of the command data before encipherment, BER-TLV encoding or inclusion of a MAC. New Lc is the length of the secured command data field; that is, the command data length after encipherment (if applied), BER-TLV encoding and inclusion of the MAC. The unsecured command APDU has either the following structure: 'X0' INS P1 P2 Lc Unsecured command data field data field or, if there is no data (e.g. Application Block command), the following structure: 'X0' INS P1 P2 The secured command APDU has the following structure: 'XC' INS P1 P2 New Lc Lc’ Secured command data field data field' The following sections describe the construction of the secured command data field and the value of New Lc. Firstly for the case where integrity1 (only) is required and secondly for the case where both confidentiality and integrity are required. 1 For the purposes of this Annex the term ‘integrity’ represents the combination of integrity and authentication. D2.1.1 Secure Messaging for Integrity The secured command data field: If secure messaging for integrity (only) is applied confidentiality is not applied, the secured command data field data field' is TLV-coded in the following way: Tag 1 '81' Length 1 L Lc Value 1 Unsecured command data field data field Tag 2 '8E' Length 2 '04' - '08' Value 2 MAC (4-8 bytes) In this case L has the same value as Lc. The value of New Lc: Lc is always coded on one byte, whereas L is coded on one or two bytes, depending on the length of the unsecured command data.
  • If L Length 1 is coded on one byte, the value of New Lc Lc’ will may range from 8+ Lc to 12+ Lc depending on the length of the MAC.
  • If L Length 1 is coded on two bytes, the value of New Lc Lc’ will may range from 9+ Lc to 13+ Lc depending on the length of the MAC. If the command to be secured has no command data (e.g. Application Block) then the only data in the secured command is the MAC. In this case the secured command data field is TLV-coded in the following way: Tag 1 Length 1 Value 1 '8E' '04' - '08' MAC (4-8 bytes) and the value of New Lc will range from 6 to 10 depending on the length of the MAC. D2.1.2 Secure Messaging for Confidentiality and Integrity The secured command data field: If secure messaging for both confidentiality and integrity is applied, the secured command data field data field' is TLV-coded in the following way: Tag 1 '87' Length 1 L 2+Lc to 9+Lc Value 1 '01' || enciphered data field Tag 2 '8E' Length 2 '04' - '08' Value 2 MAC (4-8 bytes) In this case:
  • The first byte in the value field of the cryptogram data object for confidentiality with tag '87' is the padding indicator byte. The value '01' indicates that the plaintext data field is padded according to ISO/IEC 7816-4 before encipherment.
  • Since The length of the enciphered the plaintext data field is padded to be a multiple of 8 bytes (see D2.2), the resulting. Because of the padding the length of the enciphered data field will may range from 1+Lc to 8+Lc. Consequently L will may range from 2+Lc to 9+Lc. The value of New Lc: Lc is always coded on one byte, whereas L is coded on one or two bytes, depending on the length of the unsecured command data.
  • If L Length 1 is coded on one byte, the value of New Lc Lc’ will may range from 10+Lc to 21+Lc, depending on Lc the length of padding appended to the unsecured command data field and on the length of the MAC.
  • If L Length 1 is coded on two bytes, the value of New Lc Lc’ will may range from 11+Lc to 22+ Lc, depending on Lc the length of padding appended to the unsecured command data field and on the length of the MAC. If the command to be secured has no command data (e.g. Application Block) then there is no data to be enciphered and so secure messaging for integrity (only) is applied. Notes 1. The plaintext data field is transported in the value field of a plaintext data object with tag '81'. The enciphered data field is transported in the value field of a cryptogram data object for confidentiality with tag '87'. 2. The fact that the tag of the data object (whether plaintext or cryptogram) is odd-numbered indicates that the data object is included in the MAC computation. 3. The padding indicator byte is the mandatory first byte in the value field of a cryptogram data object for confidentiality with tag '87' (see ISO/IEC 7816-4). D2.2 Encipherment If secure messaging for confidentiality is applied to the command message, the unsecured command data field of the unsecured command message is enciphered in the following way:
  • Padding and blocking of the data field is performed according to step 1 of Annex A1.1. A value of '01' of the padding indicator indicates that padding according to ISO/IEC 7816-4 always takes place even if the data field is a multiple of 8 bytes. Thus the unsecured command data field is always padded to a multiple of 8 bytes prior to encipherment with a minimum of one byte of padding always present; if the length of the unsecured command data field is a multiple of 8 bytes, it is padded with 8 bytes (‘80 00 00 00 00 00 00 00’) prior to encipherment.
  • The padded data is enciphered according to step 2 of Annex A1.1 using the Encipherment Session Key derived according to Section 9.3.2. D2.3 MAC Computation MAC computation is performed in two steps:
  • Padding of the input data (for use in this computation)
  • Applying a MAC algorithm to the padded input data. D2.3.1 Padding of the Input Data Padding of the input data is performed according to ISO/IEC 7816-4:
  • The command header of the secured command APDU 'XC' INS P1 P2 is padded with '80 00 00 00'.
  • If the unsecured command APDU contains a data field, a mandatory '80' byte is added to the right of ƒ ƒ the plaintext data object (tag '81') or the cryptogram data object for confidentiality (tag '87') that will be contained in the data field' of the secured command data field APDU. Then the smallest number of '00' bytes is added to the right such that the length of the resulting string is a multiple of 8 bytes. The padded input data consists of the concatenation of the padded command header and the padded plaintext data object or the padded cryptogram data object for confidentiality (if present). If MAC chaining is implemented then an 8-byte value is inserted to the left of the padded input data. This 8-byte value is:
  • The Application Cryptogram generated by the card for the first or only script command,
  • The MAC (the full 8 bytes prior to any optional truncation) of the preceding script command for all following script commands. If MAC chaining is not implemented then the 8-byte Application Cryptogram generated by the card is inserted to the left of the padded input data. D2.3.2 Cryptogram computation A MAC is computed over the padded input data according to step 3 of Annex A1.2 using the MAC Session Key derived according to Section 9.2.2.” The following text is the same as the updated Annex D2 shown above except that inserted text is not underlined and deleted text has been removed rather than crossed out. This unmarked version of the text is provided for clarity. “D2 Format 1 Secure Messaging Illustration Below is an illustration of Format 1 Secure Messaging as defined in Section 9 using a command where the command data of the unsecured command is not considered to be BERTLV encoded. The command data is included in the computation of the MAC as a data object in accordance with Section 9.2.3. This is either the plaintext data object with tag '81' or, if secure messaging for confidentiality is applied, the data object for confidentiality with tag '87'. D2.1 Securing the Command APDU Before application of secure messaging a command APDU is called an ‘unsecured’ command. After secure messaging is applied a command APDU is called a ‘secured’ command. Throughout this section, Lc is the length of the unsecured command data field; that is, the length of the command data before encipherment, BER-TLV encoding or inclusion of a MAC. New Lc is the length of the secured command data field; that is, the command data length after encipherment (if applied), BER-TLV encoding and inclusion of the MAC. The unsecured command APDU has either the following structure: 'X0' INS P1 P2 Lc Unsecured command data field or, if there is no data (e.g. Application Block command), the following structure: 'X0' INS P1 P2 The secured command APDU has the following structure: 'XC' INS P1 P2 New Lc Secured command data field The following sections describe the construction of the secured command data field and the value of New Lc. Firstly for the case where integrity2 (only) is required and secondly for the case where both confidentiality and integrity are required. D2.1.1 Secure Messaging for Integrity The secured command data field: If secure messaging for integrity (only) is applied, the secured command data field is TLV-coded in the following way: Tag 1 '81' Length 1 L Value 1 Unsecured command data field Tag 2 '8E' Length 2 '04' - '08' Value 2 MAC (4-8 bytes) In this case L has the same value as Lc. The value of New Lc: Lc is always coded on one byte, whereas L is coded on one or two bytes, depending on the length of the unsecured command data.
  • If L is coded on one byte, the value of New Lc will range from 8+ Lc to 12+ Lc depending on the length of the MAC.
  • If L is coded on two bytes, the value of New Lc will range from 9+ Lc to 13+ Lc depending on the length of the MAC. If the command to be secured has no command data (e.g. Application Block) then the only data in the secured command is the MAC. In this case the secured command data field is TLV-coded in the following way: Tag 1 Length 1 Value 1 '8E' '04' - '08' MAC (4-8 bytes) and the value of New Lc will range from 6 to 10 depending on the length of the MAC. D2.1.2 Secure Messaging for Confidentiality and Integrity The secured command data field: If secure messaging for both confidentiality and integrity is applied, the secured command data field is TLV-coded in the following way: 2 For the purposes of this Annex the term ‘integrity’ represents the combination of integrity and authentication. Tag 1 '87' Length 1 L Value 1 '01' || enciphered data field Tag 2 '8E' Length 2 '04' - '08' Value 2 MAC (4-8 bytes) In this case:
  • The first byte in the value field of the cryptogram data object for confidentiality with tag '87' is the padding indicator byte. The value '01' indicates that the plaintext data is padded according to ISO/IEC 7816-4 before encipherment.
  • Since the plaintext data is padded to be a multiple of 8 bytes (see D2.2), the resulting enciphered data field will range from 1+Lc to 8+Lc. Consequently L will range from 2+Lc to 9+Lc. The value of New Lc: Lc is always coded on one byte, whereas L is coded on one or two bytes, depending on the length of the unsecured command data.
  • If L is coded on one byte, the value of New Lc will range from 10+Lc to 21+Lc, depending on the length of padding appended to the unsecured command data and on the length of the MAC.
  • If L is coded on two bytes, the value of New Lc will range from 11+Lc to 22+ Lc, depending on the length of padding appended to the unsecured command data and on the length of the MAC. If the command to be secured has no command data (e.g. Application Block) then there is no data to be enciphered and so secure messaging for integrity (only) is applied. Notes 1. The plaintext data is transported in the value field of a plaintext data object with tag '81'. The enciphered data is transported in the value field of a cryptogram data object for confidentiality with tag '87'. 2. The fact that the tag of the data object (whether plaintext or cryptogram) is odd-numbered indicates that the data object is included in the MAC computation. 3. The padding indicator byte is the mandatory first byte in the value field of a cryptogram data object for confidentiality with tag '87' (see ISO/IEC 7816-4). D2.2 Encipherment If secure messaging for confidentiality is applied to the command, the unsecured command data field is enciphered in the following way:
  • Padding and blocking of the data field is performed according to step 1 of Annex A1.1. A value of '01' of the padding indicator indicates that padding according to ISO/IEC 7816-4 always takes place even if the data field is a multiple of 8 bytes. Thus the unsecured command data field is always padded to a multiple of 8 bytes prior to encipherment with a minimum of one byte of padding always present; if the length of the unsecured command data field is a multiple of 8 bytes, it is padded with 8 bytes (‘80 00 00 00 00 00 00 00’) prior to encipherment.
  • The padded data is enciphered according to step 2 of Annex A1.1 using the Encipherment Session Key derived according to Section 9.3.2. D2.3 MAC Computation MAC computation is performed in two steps:
  • Padding of the input data (for use in this computation)
  • Applying a MAC algorithm to the padded input data. D2.3.1 Padding of the Input Data Padding of the input data is performed according to ISO/IEC 7816-4:
  • The command header of the secured command APDU 'XC' INS P1 P2 is padded with '80 00 00 00'.
  • If the unsecured command APDU contains a data field, a mandatory '80' byte is added to the right of ƒ ƒ the plaintext data object (tag '81') or the cryptogram data object for confidentiality (tag '87') that will be contained in the secured command data field. Then the smallest number of '00' bytes is added to the right such that the length of the resulting string is a multiple of 8 bytes. The padded input data consists of the concatenation of the padded command header and the padded plaintext data object or the padded cryptogram data object for confidentiality (if present). If MAC chaining is implemented then an 8-byte value is inserted to the left of the padded input data. This 8-byte value is:
  • The Application Cryptogram generated by the card for the first or only script command,
  • The MAC (the full 8 bytes prior to any optional truncation) of the preceding script command for all following script commands. If MAC chaining is not implemented then the 8-byte Application Cryptogram generated by the card is inserted to the left of the padded input data. D2.3.2 Cryptogram computation A MAC is computed over the padded input data according to step 3 of Annex A1.2 using the MAC Session Key derived according to Section 9.2.2.”