PCI Watch

Tracking changes across the Payment Card Industry

SB n° SB-74 : AES option in EMV® (Spec Change), revision of SU-74 1st Edition

v2.0 Specification Bulletins

Specification Update Bulletin No. 74 Second Edition July 2010 AES option in EMV®1 Specification update No. 74 provides the specification for the optional use of the AES block cipher algorithm in EMV for securing communications between issuers and their IC cards.

Applicability

Specification Update Bulletin No. 74 applies to:  EMV Integrated Circuit Card Specifications for Payment Systems Book 2 Security and Key Management, Version 4.2

Related Documents

None Changes from First Edition This Second Edition makes two corrections to the specification for session key derivation. The first change corrects the subscript of the final byte in R from n to n-1. The second change modifies the definition and usage of the blocks F1 and F2 so as to align the session key derivation method with the Common Session Key derivation method defined in  EMV Integrated Circuit Card Specifications for Payment Systems Book 2 Security and Key Management, Version 4.2 1 EMV is a registered trademark in the U.S. and other countries and an unregistered trademark elsewhere. The EMV trademark is owned by EMVCo.

http://www.emvco.com.

This ensures that the Triple DES Common Session Key derivation remains unchanged from Version 4.2 but it does modify the derivation method for AES using 192 and 256 bit keys. The session key derivation method for AES using 128 bit keys is unchanged from the First Edition of this Bulletin. Changes for this Second Edition are restricted to section A.1.3.1. Description for First Edition of this Bulletin This specification update provides the specification for the optional use of the AES block cipher algorithm in EMV for securing communications between issuers and their IC cards. There is no impact on terminals or network message formats. The only impact is on issuers choosing to use AES in their cards as an alternative to Triple DES. This option is not being introduced into EMV on account of any security concerns with the current symmetric cryptography but rather is being introduced for those issuers wishing to migrate to the new AES standard. Issuers may continue to use Triple DES. Extensions to the Common Core Definitions to include AES are not included in this bulletin but may be published at a later date.

http://www.emvco.com.

Specification Change Notice Please make the following changes to EMV Integrated Circuit Card Specifications for Payment Systems Book 2 Security and Key Management, Version 4.2. Insert the following reference in Section 2: NIST SP 38-B CMAC Replace Sections 8 and 9 and Annexes A.1, B.1 and D.2 with the following:

http://www.emvco.com.

8 Application Cryptogram and Issuer Authentication The aim of this section is to provide methods for the generation of the Application Cryptograms (TC, ARQC, or AAC) generated by the ICC and the Authorisation Response Cryptogram (ARPC) generated by the issuer and verified by the ICC. For more details on the role of these cryptograms in a transaction, see section 10.8 of Book 3. Note that the methods provided in this specification are not mandatory. Issuers may decide to adopt other methods for these functions.

8.1 Application Cryptogram Generation 8.1.1 Data Selection An Application Cryptogram consists of a Message Authentication Code (MAC) generated over data:

  • referenced in the ICC’s DOLs and transmitted from the terminal to the ICC in the GENERATE AC or other command, and
  • accessed internally by the ICC. The recommended minimum set of data elements to be included in Application Cryptogram generation is specified in Table 6. http://www.emvco.com. Value Amount, Authorised (Numeric) Amount, Other (Numeric) Terminal Country Code Terminal Verification Results Transaction Currency Code Transaction Date Transaction Type Unpredictable Number Application Interchange Profile Application Transaction Counter Source Terminal Terminal Terminal Terminal Terminal Terminal Terminal Terminal ICC ICC Table 6: Recommended Minimum Set of Data Elements for Application Cryptogram Generation 8.1.2 Application Cryptogram Algorithm The method for Application Cryptogram generation takes as input a unique 16-byte ICC Application Cryptogram Master Key MKAC and the data selected as described in section 8.1.1, and computes the 8-byte Application Cryptogram in the following two steps: 1. Use the session key derivation function specified in Annex A1.3 to derive an 16-byte Application Cryptogram Session Key SKAC from the ICC Application Cryptogram Master Key MKAC and the 2-byte Application Transaction Counter (ATC) of the ICC. 2. Generate the 8-byte Application Cryptogram by applying the MAC algorithm specified in Annex A1.2 to the data selected and using the 16-byte Application Cryptogram Session Key derived in the previous step. For AES the 8-byte Application Cryptogram is created by setting the parameter s to 8.

8.2 Issuer Authentication Two methods are supported for generation of the ARPC used for issuer authentication. Each method can use either Triple DES or AES.:

http://www.emvco.com.

8.2.1 ARPC Method 1 ARPC Method 1 for the generation of an 8-byte ARPC using Triple DES consists of applying the Triple-DES algorithm as specified in Annex B1.1 to:

  • the 8-byte ARQC generated by the ICC as described in section 8.1
  • the 2-byte Authorisation Response Code (ARC) using the16-byte Application Cryptogram Session Key SKAC (see section 8.1) in the following way: 1. Pad the 2-byte ARC with six zero bytes to obtain the 8-byte number X:= (ARC || '00'|| '00' || '00' || '00' || '00' || '00') 2. Compute Y: = ARQC ⊕ X. 3. The 8-byte ARPC is then obtained by ARPC:= DES3(SKAC)[Y] ARPC Method 1 for the generation of an 8-byte ARPC using AES is identical to the ARPC Method 1 using Triple DES (above) except that in step 3 the 8-byte ARPC is computed using AES as specified in Annex B1.2 and is defined to be the leftmost 8-bytes of: AES(SKAC)[Y || Y0 ] where Y0:= ('00' || '00' || '00' || '00' || '00' || '00' || '00' || '00'). http://www.emvco.com.

8.2.2 ARPC Method 2 ARPC Method 2 for the generation of a 4-byte ARPC using Triple DES consists of applying the MAC algorithm as specified in Annex A1.2 A1.2.1 to:

  • the 8-byte ARQC (generated by the ICC as described in section 8.1)
  • the 4-byte binary Card Status Update (CSU) 2
  • the 0-8 byte binary Proprietary Authentication Data using the 16-byte Application Cryptogram Session Key SKAC (see section 8.1) in the following way: 1. Concatenate the ARQC, the CSU, and the Proprietary Authentication Data.3 Y: = ARQC || CSU || Proprietary Authentication Data 2. Generate a MAC over the data Y by applying the MAC algorithm specified in Annex A1.2 to the data defined above using the 16-byte Application Cryptogram Session Key derived when computing the ARQC. For this application of the MAC algorithm, the MAC is computed according to ISO/IEC 9797-1 Algorithm 3, and the parameter s is set to 4, thereby yielding a 4-byte MAC. ARPC: = MAC: = MAC algorithm (SKAC)[Y] 3. The Issuer Authentication Data (tag '91') is formed by concatenating the resulting 4-byte ARPC, the 4-byte CSU, and the Proprietary Authentication Data. Issuer Authentication Data: = ARPC || CSU || Proprietary Authentication Data ARPC Method 2 for the generation of a 4-byte ARPC using AES is identical to the ARPC Method 2 using Triple DES (above) except that in step 2 the MAC is computed using AES and the NIST CMAC algorithm as specified in Annex A1.2.2. The parameter s is set to 4, thereby yielding a 4-byte MAC.

8.3 Key Management The mechanisms for Application Cryptogram and Issuer Authentication require the management by the issuer of the unique ICC Application Cryptogram Master 2 See Annex A of Book 3 for a definition of this data item. 3 For a cryptogram defined by the Common Core Definitions with a Cryptogram Version of '4', the Proprietary Authentication Data shall be 0 bytes long. The only Cryptogram Version currently defined for the Common Core Definitions is '4'.

http://www.emvco.com.

Keys. Annex A1.4 specifies two optional methods for the derivation of the ICC Application Cryptogram Master Keys from the Primary Account Number (PAN) and the PAN Sequence Number.

http://www.emvco.com.

9 Secure Messaging The objectives of secure messaging are to ensure data confidentiality, data integrity, and authentication of the sender. Data integrity and issuer authentication are achieved using a MAC. Data confidentiality is achieved using encipherment of the data field.

9.1 Secure Messaging Format Secure messaging shall be according to one of the following two formats.

  • Format 1: Secure messaging format according to ISO/IEC 7816-4, where the data field of the affected command uses Basic Encoding Rules-Tag Length Value (BER-TLV) encoding and encoding rules of ASN.1/ISO 8825-1 apply strictly. This is explicitly specified in the lowest significant nibble of the class byte of the command, which is set to 'C'. This also implies that the command header is always integrated in MAC calculation.
  • Format 2: Secure messaging format where the data field of the affected command does not use BER-TLV encoding for secure messaging, but may use it for other purposes. In this case, the data objects contained in the data field and corresponding lengths of these data objects shall be known by the sender of a command using secure messaging and known by the currently selected application. In compliance with ISO/IEC 7816-4, secure messaging according to Format 2 is explicitly specified in the lowest significant nibble of the class byte of the command, which is set to '4'. http://www.emvco.com.

9.2 Secure Messaging for Integrity and Authentication 9.2.1 Command Data Field 9.2.1.1 Format 1 The data field of the secured command is composed of the following TLV data objects as shown in Figure 6. If the command to be secured has command data, this command data is carried in the first data object4 either as plaintext data or, if secure messaging for confidentiality is applied, as a cryptogram. If the command data is carried as plaintext data then:

  • If the unsecured command data is not BER-TLV encoded, then the data shall be encapsulated under tag '81'.
  • If the unsecured command data is BER-TLV encoded and if the tag of any data element lies in the context specific class (range '80' to 'BF') reserved for SM-related data objects, then the command data shall be encapsulated in a constructed data object under tag 'B3'.
  • If the unsecured command data is BER-TLV encoded and no tag lies in the context specific class (range '80' to 'BF') reserved for SM-related data objects, then ISO/IEC 7816-4 permits that the command data may be included without encapsulation. However if encapsulated then the command data shall be encapsulated in a constructed data object under tag 'B3'. Note: If it is not always apparent that the data is BER-TLV encoded then the data may be encapsulated under tag '81'. If the command data is carried as a cryptogram then it shall be encapsulated in a data object for confidentiality as described in section 9.3.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. 4 EMV anticipates one data object preceding the MAC data object. Depending on the command data of the unsecured command there could be more than one such data object. For these constructions please refer to ISO/IEC 7816-4. http://www.emvco.com. Tag 1 T Length 1 L Value 1 Value (L bytes) Tag 2 '8E' Length 2 '04'–'08' Value 2 MAC (4–8 bytes) Figure 6: Format 1 Command Data Field for Secure Messaging for Integrity and Authentication An example is provided in Annex D2.

9.2.1.2 Format 2 The data elements (including the MAC) contained in the data field and the corresponding lengths shall be known by the sender of a command using secure messaging and known by the currently selected application. The MAC is not BER-TLV coded and shall always be the last data element in the data field and its length shall be in the range of 4 to 8 bytes (see Figure 7). Value 1 Command data (if present) Value 2 MAC (4-8 bytes) Figure 7: Format 2 Command Data Field for Secure Messaging for Integrity and Authentication 9.2.2 MAC Session Key Derivation The first step of the MAC generation for secure messaging for integrity consists of deriving a unique 16-byte MAC Session Key from the ICC’s unique 16-byte MAC Master Key and card-controlled data unique to the transaction. A method to do this is specified in Annex A1.2.2A1.3.

9.2.3 MAC Computation The MAC is computed by applying the mechanism described in Annex A1.2 with the MAC Session Key derived as described in section 9.2.2 to the message to be protected. If secure messaging is according to Format 1, the message to be protected shall be constructed from the header of the command APDU (CLA INS P1 P2) and the command data (if present) according to the rules specified in ISO/IEC 7816-4.

http://www.emvco.com.

Note that for Format 1 the rules specified in ISO/IEC 7816-4 already define padding, so the padding of the first step of the MAC computation defined in Annex A1.2 shall be omitted. Specifically, the message MSG used in the MAC calculation is padded after the command header (CLA INS P1 P2 with CLA set to indicate secure messaging) and also after the data object carrying the command data if present. This data object is either a plaintext data object or, if secure messaging for confidentiality is applied, a data object for confidentiality (see section 9.3.1.1). The padding in each situation consists of one mandatory byte of '80' added to the right and then the smallest number of '00' bytes is added to the right so that the length of the resulting string is a number of bytes equal to a multiple of the block size (e.g. 8 bytes for DES or Triple DES and 16 bytes for AES)multiple of 8 bytes. If secure messaging is according to Format 2, the message to be protected shall be constructed according to the payment system proprietary specifications. It shall however always contain the header of the command APDU and the command data (if present). In all cases, if the MAC used for secure messaging has been specified as having a length s, then less than 8 bytes, the MAC is obtained by taking the leftmost (most significant) s bytes from the 8-byte result of the calculation described above.

http://www.emvco.com.

9.2.3.1 Format 1 MAC Chaining If secure messaging is according to Format 1 and chaining of MACs from one command to the next is supported, the recommended method for chaining the MACs is as follows: An 8-byte value whose length is equal to the block size of the cipher (e.g. 8 bytes for DES or Triple DES and 16 bytes for AES) is inserted at the beginning of the message to be protected.5 This 8-byte value is:

  • for the first or only script command, the Application Cryptogram generated by the card for the first GENERATE AC command o for 8-byte block ciphers this is the 8-byte Application Cryptogram o for 16-byte block ciphers this is the 8-byte Application Cryptogram padded to the right with 8 bytes of hexadecimal zeros Application Cryptogram ||'00'||'00'||'00'||'00'||'00'||'00'||'00'||'00'
  • for subsequent script commands, the full cryptogram valueMAC generated by the MAC algorithm of the preceding script command (this is the full output (this is the full 8-byte block computed by the MAC algorithm prior to any truncation that occurs when shorter MACs are transmitted)). Note: Issuers should be aware that when multiple issuer scripts in a single response are supported, the failure of a command in one script may result in a gap in the MAC chain. This gap will cause MAC failures for commands in subsequent scripts. 5 In the terms of ISO/IEC 7816-4 and in the case that Algorithm 3 of ISO/IEC 9797-1 is used with Single DES, this is equivalent to using an auxiliary block in the initial stage where this auxiliary block is the single DES encryption of the Application Cryptogram or MAC of the preceding command. http://www.emvco.com.

9.3 Secure Messaging for Confidentiality 9.3.1 Command Data Field 9.3.1.1 Format 1 The format of a data object for confidentiality in the command data field of a secured command is shown in Figure 8. Tag Length Value T L Cryptogram (enciphered data field) or Padding Indicator Byte || Cryptogram (enciphered data field) Figure 8: Format 1 - Data Object for Confidentiality ISO/IEC 7816-4 specifies the tags which may be allocated to the cryptogram resulting from the encipherment of the data field of the unsecured command. An odd-numbered tag shall be used if the object is to be integrated in the computation of a MAC; an even-numbered tag shall be used otherwise. If tag '86' or '87' is allocated to the data object for confidentiality, the value field of the data object for confidentiality contains the padding indicator byte followed by the cryptogram. The padding indicator byte shall be encoded according to ISO/IEC 7816-4. If another tag is used, the value field of the data object for confidentiality contains the cryptogram only. An example is provided in Annex D2.

9.3.1.2 Format 2 Data encipherment is applied to the full plaintext command data field with the exception of a MAC (see Figure 9). Value1 Cryptogram (enciphered data) Value2 MAC (if present) Figure 9: Format 2 Command Data Field for Secure Messaging for Confidentiality

http://www.emvco.com.

9.3.2 Encipherment Session Key Derivation The first step of the encipherment/decipherment for secure messaging for confidentiality consists of deriving a unique 16-byte Encipherment Session Key from the ICC’s unique 16-byte Encipherment Master Key and card-controlled data unique to the transaction. A method to do this is specified in Annex A1.3.

9.3.3 Encipherment/Decipherment Encipherment/decipherment of the plain/enciphered command data field takes place according to the mechanism described in Annex A1.1 with the Encipherment Session Key derived as described in section 9.3.2.

9.4 Key Management The secure messaging mechanisms require the management by the issuer of the unique ICC MAC and Encipherment Master Keys. Annex A1.4 specifies methods for the derivation of the ICC MAC and Encipherment Master Keys from the Primary Account Number (PAN) and the PAN Sequence Number.

http://www.emvco.com.

Annex A Security Mechanisms A1 Symmetric Mechanisms A1.1 Encipherment Encipherment of data uses an n-byte64-bit block cipher ALG either in Electronic Codebook (ECB) Mode or in Cipher Block Chaining (CBC) mode according to ISO/IEC 10116. Encipherment of a message MSG of arbitrary length with Encipherment Session Key KS takes place in the following steps. 1. Padding and Blocking

  • If the message MSG has a length that is not a multiple of n8 bytes, add one '80' byte to the right of MSG, and then add the smallest number of '00' bytes to the right such that the length of resulting message MSG:= (MSG || '80' || '00' || '00' ||... || '00') is a multiple of n8 bytes.
  • If the message MSG has a length that is a multiple of n8 bytes, the following two cases can occur depending on pre-defined rules.  No padding takes place: MSG:= MSG.  MSG is padded to the right with the n8-byte block ('80' || '00' || '00' ||...'00' || '00' || '00' || '00' || '00') to obtain MSG. MSG is then divided into n8-byte blocks X1, X2,..., XkB. http://www.emvco.com. 2. Cryptogram Computation ECB Mode Encipher the blocks X1, X2,..., XkB into the n8-byte blocks Y1, Y2,..., YkB with the block cipher algorithm in ECB mode using the Encipherment Session Key KS. Hence compute for i = 1, 2,..., kB: Yi:= ALG(KS)[Xi] CBC Mode Encipher the blocks X1, X2,..., XkB into the n8-byte blocks Y1, Y2,..., YkB with the block cipher algorithm in CBC mode using the Encipherment Session Key KS. Hence compute for i = 1, 2,..., kB: Yi:= ALG(KS)[Xi ⊕ Yi-1] with n-byte initial value Y0:= ('00' || '00' || '00' ||...'00' || '00' || '00' || '00' || '00'). Notation: Y:= (Y1 || Y2 ||... || YkB) = ENC(KS)[MSG] Decipherment is as follows. 1. Cryptogram Decipherment ECB Mode Compute for i = 1, 2,..., kB: Xi:= ALG-1(KS)[Yi ] CBC Mode Compute for i = 1, 2,..., kB: Xi:= ALG-1(KS)[Yi ] ⊕ Yi-1 with n-byte initial value Y0:= ('00' || '00' || '00' ||...'00' || '00' || '00' || '00' || '00'). 2. To obtain the original message MSG, concatenate the blocks X1, X2,..., XkB and if padding has been used (see above) remove the trailing ('80' || '00' || '00' ||... || '00') byte-string from the last block XkB. Notation: MSG = DEC(KS)[Y] http://www.emvco.com. A1.2 Message Authentication Code A1.2.1 MAC Algorithms using an 8-byte block cipher The computation of an s-byte MAC (4 ≤ s ≤ 8) is according to ISO/IEC 9797-1 using an 8-byte (64-bit) block cipher algorithm (ALG) such as Triple DES in CBC mode. More precisely, the computation of a MAC S over a message MSG consisting of an arbitrary number of bytes with a MAC Session Key KS takes place in the following steps. 1. Padding and Blocking Pad the message MSG according to ISO/IEC 7816-4 (which is equivalent to method 2 of ISO/IEC 9797-1); hence add a mandatory '80' byte to the right of MSG, and then add the smallest number of '00' bytes to the right such that the length of resulting message MSG:= (MSG || '80' || '00' || '00' ||... || '00') is a multiple of 8 bytes. MSG is then divided into 8-byte blocks X1, X2,..., XkB. 2. MAC Session Key The MAC Session Key KS consists of either only a leftmost key block KS = KSL or the concatenation of a leftmost and a rightmost key block KS = (KSL || KSR). 3. Cryptogram Computation Process the 8-byte blocks X1, X2,..., XkB with the block cipher in CBC mode using the leftmost MAC Session Key block KSL: Hi:= ALG(KSL)[Xi ⊕ Hi-1], for i = 1, 2,..., kB with initial value H0:= ('00' || '00' || '00' || '00' || '00' || '00' || '00' || '00').6 Compute the 8 byte block HkB+1 in one of the following two ways.  According to ISO/IEC 9797-1 Algorithm 1: HkB+1:= HkB  According to ISO/IEC 9797-1 Algorithm 3: HkB+1:= ALG(KSL)[ALG-1(KSR)[HkB]] 6 Note that pre-pending the MSG with the previous MAC (8 bytes) as a chaining block (see section 9.2.39.2.3) is equivalent to using an initial value equal to the previous MAC processed by Triple DES (Algorithm 1) or Single DES (Algorithm 3). http://www.emvco.com. The MAC S is then equal to the s most significant bytes of HkB+1. A1.2.2 MAC Algorithms using a 16-byte block cipher The computation of an s-byte MAC (4 ≤ s ≤ 8) is according to NIST CMAC using a 128-bit (16-byte) block cipher algorithm (ALG) such as AES in CBC mode. More precisely, the computation of a MAC S over a message MSG consisting of an arbitrary number of bytes with a MAC Session Key KS takes place in the following steps. 1. Padding and Blocking If the length of the message MSG is a multiple of 16-bytes then no padding is added7. If the length of the message MSG is not a multiple of 16-bytes then add a mandatory '80' padding byte to the right of MSG, and then add the smallest number of '00' bytes to the right such that the length of resulting message MSG:= (MSG || '80' || '00' || '00' ||... || '00') is a multiple of 16 bytes. MSG is then divided into 16-byte blocks X1, X2,..., XB. 2. MAC Session Key The MAC Session Key KS consists of a k -bit block (see Annex B1). In accordance with NIST CMAC defined in NIST SP 38-B, two k -bit sub-keys K1 and K2 are also derived. Let Z be 16-bytes set to zero and let C be equal to Z except with its least significant bits set to ‘10000111b’ (C is a CMAC-defined constant for a 16-byte block cipher). L:= ALG(KS)[Z] K1 = L &lt;&lt; 1. If msb(L) = 1 then K1:= K1 ⊕ C K2 = K1 &lt;&lt; 1. If msb(K1) = 1 then K2:= K2 ⊕ C Where the following notation is used: &quot;&lt;< 1" means left-shift 1 bit (i.e. the new k-bit string comprises the k-1 rightmost bits of the old string, appended with a zero bit) "msb" means the most significant bit (i.e. the leftmost bit) Note that all intermediate values must be kept secret (e.g. not used by the card as an unpredictable number). 3. Cryptogram Computation 7 Note that this will always be the case with Format 1 Secure Messaging as the message is padded prior to MACing. http://www.emvco.com. Mask the final block with sub-key K1 if no padding was added XB:= XB ⊕ K1. and with sub-key K2 if padding was added XB:= XB ⊕ K2. Process the 16-byte blocks X1, X2,..., XB with the block cipher in CBC mode using the MAC Session Key KS: Hi:= ALG(KS)[Xi ⊕ Hi-1], for i = 1, 2,..., B with 16-byte initial value H0:= ('00' || '00' ||... || '00' || '00' || '00' || '00' || '00').8 The MAC S is then equal to the s most significant bytes of HB. A1.3 Session Key Derivation Session keys KS are derived from unique Master Keys KM using diversification data R as follows KS:= F(KM)[R]. To prevent replay attacks, the diversification data R should have a high probability of being different for each session key derivation. An important requirement for the diversification function F is that the number of possible outputs of the function is sufficiently large and uniformly distributed to prevent an exhaustive key search on the session key. Annex A1.3.1 specifies a method for the derivation of session keys for Application Cryptogram generation, issuer authentication, and secure messaging (see sections 8 and 9) from ICC Master Keys. This session key derivation method ensures that different transactions use different session keys Note that the session key derivation method provided in Annex A1.3.1 is not mandatory. Issuers may decide to adopt another method for this function. A1.3.1 Common Session Key Derivation Option 8 Note that pre-pending the MSG with the previous MAC (16 bytes) as a chaining block (see section 9.2.39.2.3) is equivalent to using an initial value equal to the previous MAC. http://www.emvco.com. The common session key derivation option generates a unique session key for each transaction performed by the application. It does this by enciphering an nbyte diversification value with the k-bit ICC Master Key (MK) to produce a k-bit ICC Session Key (SK) using an n-byte block cipher algorithm ALG in ECB mode. The n-byte diversification value is represented as R = R0 || R1 || R2 || … || Rn-1. For the session key used to generate and verify the Application Cryptogram and the ARPC, the diversification value is the ATC followed by n - 2 bytes of '00'. R:= ATC || '00' || '00' || … || '00' || '00' || '00' For the session keys used for secure messaging, the diversification value R is the Application Cryptogram returned in the response to the first GENERATE AC command followed by n-8 bytes of '00'. R: = Application Cryptogram … || '00' || '00' || '00' For an n -byte block cipher ALG using a k -bit key where k = 8n (AES with k=128) the derivation function F is computed as follows: SK:= ALG (MK) [ R ] For an n -byte block cipher ALG using a k -bit key where 16n ≥ k > 8n (Triple DES with k=128 or AES with k=192 or 256) R is used to create two n-byte blocks as follows: F1 = R0 || R1 || 'F0' || … || Rn-1. F2 = R0 || R1 || '0F' || … || Rn-1. and SK:= Leftmost k -bits of {ALG (MK) [F1] || ALG (MK) [F2] } The same session key is used for all commands in a single transaction. The common session key derivation option generates a unique session key for each transaction performed by the application. It does this by enciphering an n8byte diversification value with the k-bit16-byte ICC Master Key (MK) to produce a k-bit16-byte ICC Session Key (SK) using an n-byte block cipher algorithm ALG in ECB mode. http://www.emvco.com. The n8-byte diversification value is represented as R = R0 || R1 || R2 || …R3 || R4 || R5 || R6 || R7 Rn. and two n-byte format blocks are defined as follows: F1 = '00' || '00' || 'F0' || '00' || … || '00' F2 = '00' || '00' || '0F' || '00' || … || '00' For an n16 -byte block cipher ALG using a k -bit key the derivation function F is computed as follows: In the case k = 8n: SK:= ALG (MK) [ R ] In the case 16n ≥ k > 8n: SK:= Leftmost k -bits of {ALG (MK) [ R ⊕ F1] || ALG (MK) [R ⊕ F2] } For the session key used to generate and verify the Application Cryptogram and the ARPC, the diversification value is the ATC followed by n - 2six bytes of '00'.: R:= ATC || '00' || '00' || …'00' || '00' || '00' || '00' For the session keys used for secure messaging, the diversification value R is the Application Cryptogram returned in the response to the first GENERATE AC command: R: = Application Cryptogram The same session key is used for all commands in a single transaction. http://www.emvco.com. A1.4 Master Key Derivation This annex specifies threewo optional methods for the derivation by the issuer of a k-bit16-byte ICC Master Key used for Application Cryptogram generation, issuer authentication, and secure messaging. The first two methods use the 8byte block cipher Triple DES in ECB mode and the third method uses the 16-byte block cipher AES in ECB mode. The AES method supports 128-bit, 192-bit and 256-bit keys. Note that none of these methods are neither method is mandatory. Issuers may decide to adopt an alternative methods for this function. These methods take as input the PAN and PAN Sequence Number, plus a kbit16-byte Issuer Master Key IMK, and produce the k-bit16-byte ICC Master Key MK in the following way: A1.4.1 Option A Option A is only applicable when the block cipher is Triple DES. 1. Concatenate from left to right the decimal digits of the Application PAN with the PAN Sequence Number (if the PAN Sequence Number is not present, then it is replaced by a '00' byte). If the result X is less than 16 digits long, pad it to the left with hexadecimal zeros in order to obtain an 8-byte number Y in numeric format. If X is at least 16 digits long, then Y consists of the 16 rightmost digits of X in numeric format. 2. Compute the two 8-byte numbers ZL:= DES3(IMK)[Y] and ZR:= DES3(IMK)[Y ⊕ ('FF'||'FF'||'FF'||'FF'||'FF'||'FF'||'FF'||'FF')] and define Z:= (ZL || ZR) The 128-bit16-byte ICC Master Key MK is then equal to Z, with the exception of the least significant bit of each byte of Z which is set to a value that ensures that each of the 16 bytes of MK has an odd number of nonzero bits (this to conform with the odd parity requirements for DES keys). A1.4.2 Option B Option B is only applicable when the block cipher is Triple DES. http://www.emvco.com. If the Application PAN is equal to or less than 16 decimal digits, use Option A. If the Application PAN is greater than 16 decimal digits, do the following: 1. Concatenate from left to right the decimal digits of the Application PAN and the PAN Sequence Number (if the PAN Sequence Number is not present, it is replaced by a '00' byte). If the Application PAN has an odd number of decimal digits then concatenate a ‘0’ padding digit to the left thereby ensuring that the result is an even number of digits. 2. Hash the result of the concatenation using the SHA-1 hashing algorithm to obtain the 20-byte hash result X. 3. Select the first 16 decimal digits (0 to 9) starting from the left side of the 20-byte (40-nibble) hash result X and use as the value Y. If this does not provide for 16 decimal digits in Y, convert the non-decimal nibbles in X to decimal digits by means of the following decimalization table: Input nibble of X Decimalized nibble A B C D E F 0 1 2 3 4 5 Figure 14: Decimalization for Master Key Derivation Add the converted digits starting from the left side of X to the end of Y until Y contains 16 digits. Example 1: Hash result X contains 16 or more decimal digits X = '12 30 AB CD 56 78 42 D4 B1 79 F2 CA 34 5D 67 89 A1 7B 64 BB' Y = first 16 decimal digits of X = '12 30 56 78 42 41 79 23' Example 2: Hash result X contains less than 16 decimal digits X = '1B 3C AB CD D6 E8 FA D4 B1 CD F2 CA D4 FD C7 8F A1 7B 6E BB' Y = decimal digits from X = '13 68 41 24 78 17 6' plus the required number of converted digits '1 20' (from 'B', 'C', and 'A'), giving: Y = '13 68 41 24 78 17 61 20' 4. Continue with the processing specified for Option A starting at Step 2. A1.4.3 Option C Option C is only applicable when the n-byte block cipher is AES. Concatenate from left to right the decimal digits of the Application PAN with the PAN Sequence Number (if the PAN Sequence Number is not present, then it is replaced by a '00' byte). Pad it to the left with hexadecimal zeros in order to obtain a 16-byte number Y in numeric format. http://www.emvco.com. The k-bit ICC Master Key MK is then equal to
  • In the case k = 8n: MK:= AES(IMK)[Y]
  • In the case 16n ≥ k > 8n: MK:= Leftmost k –bits of {AES(IMK)[Y] || AES(IMK)[Y*]}, where Y* = Y ⊕ ('FF'||'FF'||'FF'||'FF'||'FF'||'FF'||'FF'||'FF'). http://www.emvco.com. Annex B Approved Cryptographic Algorithms B1 Symmetric Algorithms These specifications use block cipher algorithms with key size k and block size n. For various reasons the key size is expressed in bits and the block size in bytes. Note that the mechanisms specified in Annex A only support block cipher algorithms satisfying 16n ≥ k ≥ 8n. B1.1 Data Encryption Standard (DES) 8-byte block cipher The double-length key triple DES encipherment algorithm (see ISO/IEC 18033-3) is the approved cryptographic algorithm to be used in the encipherment and MAC mechanisms specified in Annex A1 where an 8-byte block cipher is used. The algorithm is based on the (single) DES algorithm standardised in ISO 16609. Triple DES encipherment involves enciphering an 8-byte plaintext block in an 8-byte ciphertext block with a double-length (128-bit16-byte) secret key K = (KL || KR) as follows: Y = DES3(K)[X] = DES(KL)[DES-1(KR)[DES(KL)[X]]] Decipherment takes place as follows: X = DES-1(KL)[DES(KR)[DES-1(KL)[Y]]] Single DES is only approved for usage with the version of the MAC mechanism specified in Annex A1 using Algorithm 3 of ISO/IEC 9797-1 (Ttriple DES applied to the last block). B1.2 Advanced Encryption Standard (AES) 16-byte block cipher The AES encipherment algorithm (see ISO/IEC 18033-3) is the approved cryptographic algorithm to be used in the encipherment and MAC mechanisms specified in Annex A1 where a 16-byte block cipher is used. 128-bit, 192-bit and 256-bit key length versions of AES are supported, but the key length should be fixed for a given implementation. http://www.emvco.com. http://www.emvco.com. 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 BER-TLV encoded and using an 8-byte block cipher. 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'. http://www.emvco.com.