SB n° 307: Revision of EMV® Contactless Book E Security and Key Management

EMV® Contactless Specifications for Payment Systems Book E Security and Key Management Version 1.01 June 2023 February 2025

Legal Notice

The EMV® Specifications are provided “AS IS” without warranties of any kind, and EMVCo neither assumes nor accepts any liability for any errors or omissions contained in these Specifications. EMVCO DISCLAIMS ALL REPRESENTATIONS AND WARRANTIES, EXPRESS OR IMPLIED, INCLUDING WITHOUT LIMITATION IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NON-INFRINGEMENT, AS TO THESE SPECIFICATIONS. EMVCo makes no representations or warranties with respect to intellectual property rights of any third parties in or in relation to the Specifications. EMVCo undertakes no responsibility to determine whether any implementation of the EMV® Specifications may violate, infringe, or otherwise exercise the patent, copyright, trademark, trade secret, know-how, or other intellectual property rights of third parties, and thus any person who implements any part of the EMV® Specifications should consult an intellectual property attorney before any such implementation. Without limiting the foregoing, the Specifications may provide for the use of public key encryption and other technology, which may be the subject matter of patents in several countries. Any party seeking to implement these Specifications is solely responsible for determining whether its activities require a license to any such technology, including for patents on public key encryption technology. EMVCo shall not be liable under any theory for any party’s infringement of any intellectual property rights in connection with the EMV® Specifications.

Revision Log – Version 1.1 Specification Bulletin 307, February 2025. The updates made to this specification since the publication of the EMV Book E – Security and Key Management v1.0, do not make any functional changes to Kernel 8 specification. The updates are mainly editorial corrections to improve the consistency and clarity of the document contents. The most significant updates are as follows:

• Reference to EMV Book 2 – Security and Key Management has been removed.
• Changes to the introductory text of sections 2 and 4.
• Change to Table 3.2 to note that padding bytes in the GENERATE AC Response Message (if any) are not included in the IAD-MAC Input Data.
• Changes to Table 4.1 and related text in relation to the IAD-MAC transmission to the Issuer.
• Changes to the introductory text of sections 5 and 6 in relation to the certificate format.
• Changes to sections 8.3 and 8.4 primarily to avoid the term “assigned”.
• Change to Table A.4 to note that padding bytes in the GENERATE AC Response Message (if any) and tag '77' and length are not included in the Transaction Data that is input to the generation of the Transaction Data Hash Code.
• Annex B – Reader Key Management has been added to allow future removal of the information on reader key management from EMV Book C-8 – Kernel 8 Specification v1.1. Contents 1 1.1 1.2 1.3 1.4 1.5 2 2.1 2.2 2.3 3 3.1 3.2 4 4.1 4.2 5 5.1 5.2 5.3 5.4 6 6.1 6.2 6.3 6. 7. 7. 7. 8. 8. 8. 8. 8. 8.5. 8.5. 8. 8.6. 8.6. 8.6. 8.6. 8.6. 8. 8.7. 8.7. 8. 8.8. 8.8. 8.8. 8.8. 8.8. 8.8. 8.8. A. A. A. 1.1 1.2 1.3 1.4 1.5 2 2.1 2.2 2.3 3 3.1 3.2 4 4.1 4.2 5 5.1 5.2 5.3 5.4 6 6.1 6.2 6.3 6.4 7 7.1 7.2 7. 8. 8. 8. 8. 8. 8.5. 8.5. 8. 8.6. 8.6. 8.6. 8.6. 8.6. 8. 8.7. 8.7. 8. 8.8. 8.8. 8.8. 8.8. 8.8. 8.8. 8.8. A. A. A. B. B. Tables Table 1. Table 1. Table 1. Table 1. Table 3. Table 3. Table 4. Table 5. Table 5. Table 6. Table 6. Table 6. Table 6. Table 6. Table 6. Table 8. Table 8. Table 8. Table 8. Table 8. Table 8. Table A. Table A. Table A. Table A. Table A. Table 1. Table 1. Table 1. Table 1. Table 3. Table 3. Table 4. Table 5. Table 5. Table 6. Table 6. Table 6. Table 6. Table 6. Table 6. Table 8. Table 8. Table 8. Table 8. Table 8. Table 8. Table A. Table A. Table A. Table A. Table A. Figures Figure 2. Figure 2. Figure 2. Figure 3. Figure 3. Figure 5. Figure 6. Figure A. Figure 2. Figure 2. Figure 2. Figure 3. Figure 3. Figure 5. Figure 6. Figure A. 1

Scope

This specification, EMV® Contactless Specifications for Payment Systems, Book E – Contactless Security, describes the security mechanisms of EMV contactless transactions contained in the Kernel 8 specification [EMV Book C-8] and non-C-8 EMV contactless Kernels.

1.1 Audience This specification is intended for use by manufacturers of contactless readers and terminals. It may also be of interest to manufacturers of contactless cards and to financial institution staff responsible for implementing financial applications in contactless cards.

1.2 Related Information The following references are used in this specification. It is noted that the latest version applies unless a publication date is explicitly stated. Table 1.1 – Related Information Reference [EMV Book C-8] [EMV Book 2] [ISO/IEC 9796-2] [ISO/IEC 9797-1] [ISO/IEC 10116] [ISO/IEC 10118-3] [ISO/IEC 11770-6] Document Title EMV® Contactless Specifications for Payment Systems, Book C-8 – Kernel 8 Specification EMV® Book 2: Security and Key Management Information technology – Security techniques – Digital signature schemes giving message recovery – Part 2: Integer factorization based mechanisms Information technology – Security techniques – Message Authentication Codes (MACs) – Part 1: Mechanisms using a block cipher Information technology – Security techniques – Modes of operation for an n-bit block cipher Information technology – Security techniques – Hash-functions – Part 3: Dedicated hash-functions Information technology – Security techniques – Key management – Part 6: Key derivation

Reference [ISO/IEC 14888-3] [ISO/IEC 15946-1] [ISO/IEC 15946-5] [ISO/IEC 18031] [ISO/IEC 18033-3] [NIST SP800-22A] [EMV SB144] Document Title Information technology – Security techniques – Digital signatures with appendix – Part 3: Discrete logarithm-based mechanisms IT Security techniques – Cryptographic techniques based on elliptic curves – Part 1: General IT Security techniques – Cryptographic techniques based on elliptic curves – Part 5: Elliptic curve generation Information technology – Security techniques – Random bit generation Information technology – Security techniques – Encryption algorithms – Part 3: Block ciphers A statistical test suite for random and pseudorandom number generators for cryptographic algorithms EMV® Specification Bulletin No. 144 – Terminal Unpredictable Number generation 1.3 Terminology The following terms are used in this specification, carrying specialised meanings as indicated. Table 1.2 – Terminology Term Application Cryptogram Card Cardholder Certification Authority Issuer

Description

The Application Cryptogram allows the authentication by the Issuer of a subset of the transaction data exchanged between the Reader and the Card. The Card, as used in these specifications, is a consumer device supporting contactless transactions. The Cardholder is the owner of the payment Card issued by the bank that holds the designated bank account. Trusted third party that establishes proof that links a public key and other related data to its owner via a certificate. The Issuer refers to the bank that holds the customer’s account, issuing the payment Card and accepting transactions with this Card.

Kernel Term Local Cryptogram Payment System Reader Description The Kernel contains the interface routines, security and control functions to interact with the payment Card. The Local Cryptogram (EDA-MAC) allows the authentication byto the Reader of the transaction data exchanged between the Reader and the Card. The Payment System refers to the entity responsible for the rules and infrastructure used to perform, process and settle financial transactions. The Reader is the part of the payment terminal that provides the interface to the Card, via the contactless Kernel.

1.4 Abbreviations The following abbreviations are used in this specification. Table 1.3 – Abbreviations Abbreviation 3DES AC AES AFL AID AIP ARQC ASI ATC BDH CA CDA CBC CDOL CID Description Triple DES Application Cryptogram Advanced Encryption Standard Application File Locator Application Identifier Application Interchange Profile Authorisation Request Cryptogram Algorithm Suite Indicator Application Transaction Counter Blinded Diffie-Hellman Certification Authority Combined Dynamic Data Authentication/Application Cryptogram Generation Cipher Block Chaining Card Risk Management Data Object List Cryptogram Information Data

Abbreviation CMAC CMC CRL CTR CVD CVM DDA DDOL DES ECC ECDH ECSDSAEC-SDSA EDA ERRD fDDA HSM IAD ICC ICCD IMK KMC LDD M MAC MK NC NCA NI NFIELD NHASH Description Cipher-based Message Authentication Code Card Message Counter Certification Revocation List CounTeR mode Cardholder Verification Decision Cardholder Verification Method Dynamic Data Authentication Dynamic Data Authentication Data Object List Data Encryption Standard Elliptic Curve Cryptography Elliptic Curve Diffie-Hellman Elliptic Curve Schnorr Digital Signature Algorithm Enhanced Data Authentication Exchange Relay Resistance Data fast Dynamic Data Authentication Hardware Security Module Issuer Application Data Integrated Circuit Card Issuer Certified Card Data Issuer Master Key Kernel Message Counter Length of the ICC Dynamic Data Mandatory Message Authentication Code Card Master Key Length of Card Public Key Modulus Length of Certification Authority Public Key Modulus Length of Issuer Public Key Modulus Elliptic Curve Field Size Length of the Hash Algorithm Output

Abbreviation NSIG O ODA PAN PDOL PKI PSN RID RMAC RRP RSA SDA SHA SK SKD TC TLV UN var. Description Length of the ECC Digital Signature Optional Offline Data Authentication Primary Account Number Processing Options Data Object List Public Key Infrastructure PAN Sequence Number Registered Application Provider Identifier Retail Message Authentication Code Relay Resistance Protocol Rivest Shamir Adleman Algorithm Static Data to be Authenticated Secure Hash Algorithm Session Key Session Key Derivation Transaction Certificate Tag Length Value (of a data object) Unpredictable Number Variable 1.5 Notations The following conventions are used in this specification. Table 1.4 – Notations Notation '6B75' 1001b 27509 Description Hexadecimal notation. Values expressed in hexadecimal form are enclosed in straight single quotes. Binary notation. Values expressed in binary form are followed by a lower case ‘b’. Decimal notation. Values expressed in decimal form are not enclosed in single quotes.

Notation A mod n || A  B A · B Description The reduction of the integer A modulo the integer n, that is, the unique integer r, 0 ≤ r < n, for which there exists an integer d such that A = dn + r. Example: 54 mod 16 = 6. Two binary data objectsvalues are concatenated. Example: A = 'AB34' B = A || 'FFFF' means that B is assigned the value 'AB34FFFF'. A XOR B. Exclusive OR of A and B. Multiplication of A and B, which may be either a modular multiplication (if A and B are integers) or a scalar multiplication (if A is an integer and B is a point on an elliptic curve).

2 Secure Channel This section describes the security mechanisms to establish the secure channel established between the Reader and the Card for each transaction. The secure channel provides:

• Privacy protection
• Secure data storage
• Local authentication, described separately in section 3. Note that the local cryptogram (EDA-MAC) described in section 3.2 is always validated to provide functional assurance of the secure channel.

2.1 BDH Key Agreement The Blinded Diffie-Hellman (BDH) key agreement described in Figure 2.1 is a variant of the Elliptic Curve Diffie-Hellman (ECDH) protocol where the Reader generates an ephemeral ECC key pair while the Card uses a fixed key pair personalised by the Issuer. The Card public key is certified by the Issuer through the Card certificate. Figure 2.1 – BDH Key Agreement CARD Private key: dC Public key: QC = dC·G READER Ephemeral key pair Blinding factor: r (random) Blinded public key: PC = r·QC PC Private key: dK (random) Public key: QK = dK·G QK Shared secret: z z = r·dC·QK = dC·r·dK·G Such that z = z G is the generator point of the selected curve Shared secret: z z dK·PC = dK·r·dC·G Note that the Card public key and the Card certificate correspond to the ICC ECC Public Key and the ICC ECC Public Key Certificate data objects respectively.

As the Card public key is fixed, for privacy purposes, it needs to be anonymised for each transaction. This is achieved by multiplying the Card public key by a random integer, called the blinding factor, PC = r·QC. The result is called the Card blinded public key. Alternatively, the Card blinded public key may be calculated as PC = (r·dC)·G. As described in section 7, the Reader and Card exchange the Kernel public key and the Card blinded public key, compute a shared secret and then derive two session keys – one for confidentiality and one for integrity. The blinding factor, which is later sent encrypted by the Card, permits the Reader to authenticate the Card (in conjunction with the Issuer and Card certificatecertificates), if required.

2.2 Privacy Protection Once the secure channel is established between the Reader and the Card, sensitive data returned by the Card, as shown in Figure 2.2, is encrypted using AES-CTR with the session key for confidentiality SKC. Figure 2.2 – Data Encryption Card KMC = '0000' CMC = '8000' Encrypt blinding factor Increment CMC Encrypt record Increment CMC GET PROCESSING OPTIONS Encrypted blinding factor READ RECORD Encrypted record Reader KMC = '0000' CMC = '8000' Decrypt blinding factor Increment CMC Decrypt record Increment CMC Sensitive data includes the blinding factor returned by the GET PROCESSING OPTIONS command and any data returned by a READ RECORD command that uniquely identifies the Card – Application PAN, Track 2 Equivalent Data, Card public key certificate, Card ECC public key, Card RSA public key remainder for instance. Two message counters (MC) – in each device – are used with the message encryption: the Kernel Message Counter (KMC) for messages originated by the Reader, used in section 2.3, and the Card Message Counter (CMC) for messages originated by the Card.

The 2-byte counters KMC and CMC are initialised on each device to '0000' and '8000' respectively at the beginning of each transaction. CMC is incremented by the GET PROCESSING OPTIONS and READ RECORD (returning an encrypted record) commands. CMC is also incremented by the READ DATA and WRITE DATA commands, which together with KMC incrementation is described in section 2.3. The maximum values of KMC and CMC are '7FFF' and 'FFFF' respectively (an implementation may impose lower limits to increase protection against side channel attacks). For the GET PROCESSING OPTIONS and READ RECORD commands the message encryption is computed as follows: Ciphertext = AES-CTR (SKC) [CMC, Message] The message decryption is obtained by entering the ciphertext as the message. The READ RECORD command is performed after the GET PROCESSING OPTIONS command, once the Card has completed the BDH key agreement, and during normal operation before the GENERATE AC command.

2.3 Secure Data Storage The privacy protection is extended to secure the Card data storage based on the READ DATA and WRITE DATA commands. This may be used for reading from and writing to one of ten TLV encoded data envelopes, as shown in Figure 2.3. Figure 2.3 – Data Encryption and AuthenticationMAC Card Encrypt data envelope Compute MAC on ciphertext Increment CMC Decrypt data envelope Increment KMC Compute MAC on plaintext Increment CMC READ DATA Encrypted data envelope, MAC WRITE DATA (Encrypted data envelope) MAC Reader Validate MAC Decrypt data envelope Increment CMC Encrypt data envelope Increment KMC Validate MAC Increment CMC As mentioned in section 2.2, the message counters CMC and KMC are initialised on each device at the beginning of each transaction. CMC is incremented by the READ DATA and WRITE DATA commands. KMC is incremented only by the WRITE DATA command.

For the READ DATA command the plaintext data envelope is encrypted by the Card as follows: Ciphertext = AES-CTR (SKC) [CMC, Input Data] For the WRITE DATA command the plaintext data envelope is encrypted by the Reader as follows: Ciphertext = AES-CTR (SKC) [KMC, Input Data] In both cases the decryption is obtained by entering the ciphertext (the encrypted data envelope) as the Input Data. The Card data storage also includes an authentication mechanism for the data sent or received by the Card. An 8-byte MAC is computed by the Card using AES-CMAC with the session key for integrity SKI. The READ DATA command response contains a MAC over the encrypted data envelope that is requested in the command message. The WRITE DATA command response contains a MAC over the plaintext data envelope decrypted by the Card. As only the Card is generating MACs to be validated by the Reader, the MAC is computed on the concatenation of CMC and the Input Data as follows: MAC = Leftmost 8 bytes of AES-CMAC (SKI) [CMC || Input Data] The READ DATA and WRITE DATA commands are performed after the GET PROCESSING OPTIONS command, once the Card has completed the BDH key agreement. During normal operation the READ DATA command is performed before the GENERATE AC command and the WRITE DATA command after, provided local authentication has been performed and is successful. Note that to prevent collision the IAD-MAC and EDA-MAC (see section 3.2) are computed using a fixed 2-byte value of '0000' as the message counter.

3 Local Authentication This section describes the local authentication of the Card by the Reader when performed during a transaction, it authenticates the transaction data and ensures that the Card is genuine.

3.1 Public Key Management Figure 3.1 describes the public key infrastructure (PKI) and local authentication of a Kernel 8 transaction. Every Card is personalised by the Issuer with a unique private/public key pair where the public key is certified by the Issuer. Figure 3.1 – Local Authentication Diagram Issuer Card Public Key Card Private Key Is suer Issuer Private Key Public Key St ati c Data SIGN Card PK Certificate Issuer PK Certificate Certification Authority SIGN Issuer PK Certificate Acquirer CA Private Key CA Public Key CA Public Key Card Reader Static Card PK Issuer PK Data Certificate Certificate VAL IDATE Valid CA PK Card Public Key Card Private Key BDH MAC VAL IDATE Valid Issuer PK Card Blinded Public Key* BDH Valid Card PK EDA-MAC Kernel Public key* Kernel Private Key* Transaction Data VAL IDATE Local Authentication *Ephemeral key A three-layer The local authentication is based on the following four-layer scheme allows the Reader to validate the Local Cryptogram (EDA-MAC) generated by the Card:

• The Issuer public key is authenticated by the Certification Authority (CA) public key stored in the Reader. database.
• The Card public key is authenticated by the Issuer public key which is signed by the Certification Authority in the Issuer certificate. As mentioned in section 2.1, the Card authentication includes the authentication of the blinding factor which is sent encrypted by the Card.
• The Card public key authentication includes the validation of the blinding factor which is sent by the Card encrypted with the session key for confidentiality.
• The Local Cryptogram (EDA-MAC) is authenticatedvalidated by the Reader using the session key for integrity SKI obtained during the BDH key agreement, as described in section 2.1.. Note that the EDA-MAC is always validated even if local authentication is not performed. If the validation of the Local Cryptogram and the Issuer and Card certificates (including the blinding factor validation) is successful, the local authentication is successful and the Card is considered as genuine. Issuer and Card certificates are personalised in the Card by the Issuer and transmitted by the Card to the Reader if local authentication is required. The Card typically holds a set of ECC certificates used to authenticate the Card ECC public key. For migration purposes, it is possible to use instead a set of RSA certificates where the Card RSA certificate is used to authenticate the Card ECC public key. In that case the Card ECC public key is added to the Card static data signed by the Issuer.

3.2 Local Cryptogram The Local Cryptogram is generated by the Card over the transaction data, including the Issuer Application Data, the Card Static Data to be Authenticated and the Application Cryptogram. The Application Cryptogram is generated over a subset of the transaction data as described in section 4.2. During local authentication the Reader validates the Local Cryptogram which ensures the authenticity of the transaction data, including the Application Cryptogram (which is validated by the Issuer during remote authentication). The Local Cryptogram is returned by the Card in the response message of the GENERATE AC command with the following Card transaction data:

• The Cryptogram Information Data (CID) that informs the Reader on the type of Application Cryptogram generated.
• The Application Transaction Counter (ATC) incremented by the Card for each transaction that ensures the freshness of the Application Cryptogram and Local Cryptogram on the Card side.
• The Cardholder Verification Decision (CVD) that indicates the Cardholder Verification Method (CVM) chosen by the Card, not the result of a Cardholder verification.
• Optional data objects authenticated by the Local Cryptogram.
• The Application Cryptogram (AC).
• The Issuer Application Data (IAD), including the results of the Card verificationprocessing, that informs the Issuer about the Card application during the remote authentication. The Local Cryptogram is an AES-CMAC called Enhanced Data Authentication MAC or EDAMAC. EDA-MAC is computed with the session key for integrity SKI in two steps; firstly the Issuer Application Data MAC or IAD-MAC is computed and then the EDA-MAC as shown in Figure 3.2. Figure 3.2 – Local Cryptogram Computation Transaction Data (incl. IAD) Static Data to be Authenticated Transaction Data Subset AES-CMAC+ (SKI) SDA Hash AC Generation IAD-MAC Application Cryptogram AES-CMAC (SKI) Transaction Data Subset EDA-MAC Transaction Data (incl. IAD) AES-CMAC+ (SKI) Static Data to be Authenticated SDA Hash AC Generation IAD-MAC Application Cryptogram AES-CMAC (SKI) EDA-MAC The Reader transaction data needed by the Card is specified in the Processing Options Data Object List (PDOL) and Card Risk Management Data Object List (CDOL1). PDOL indicates the data objects needed to initialise the Card application such as the Kernel Qualifier and Kernel Key Data. The Kernel Qualifier indicates the secure channel Algorithm Suite Indicator (ASI) supported by the Reader and whether the Reader supports local authentication or not. The Kernel Key Data is the Reader ephemeral ECC public key used in the BDH key agreement. CDOL1 in Table 3.1 indicates the recommended data objects needed by the Card application to complete the transaction. Data objects already specified in the PDOL are normally not repeated in CDOL1. Table 3.1 – Recommended CDOL1 Reference Amount, Authorised (Numeric) Amount, Other (Numeric) Terminal Country Code Terminal Verification Results Transaction Currency Code Transaction Date Transaction Type Unpredictable Number CVM Results Terminal Risk Management Data Length 6 6 2 5 2 3 1 4 3 8 The Unpredictable Number generated by the Reader for each transaction ensures the freshness of the Local Cryptogram on the Reader side. The PDOL may be signed by the Issuer through the Extended SDA Tag List as described in sections 5.3 and 6.3. Table 3.2 – IAD-MAC Input Data Reference PDOL Values (Value field of PDOL Related Data) CDOL1 Related Data Terminal Relay Resistance Entropy (1) Origin Reader Reader Reader Last ERRD Response (without tag '80' and length '0A') (1) Card GENERATE AC Response Message without:
• Application Cryptogram
• EDA-MAC
• TagPadding bytes (if any) and tag '77' and length Card SDA Hash (hash over the Card Static Data to be Authenticated) Card (1) If RRP performed The IAD-MAC authenticates the transaction data listed in Table 3.2. The 8-byte IAD-MAC is computed by the Card as follows:
• Concatenate '0000' with the IAD-MAC Input Data in Table 3.2. Note that the Card is personalised with SDA Hash which is the hash of at least the AIP value.
• Compute IAD-MAC by applying AES-CMAC+ over the concatenated data with the session key for integrity SKI (Card): IAD-MAC = Leftmost 8 bytes of AES-CMAC+ (SKI) [0000 || IAD-MAC Input Data] The EDA-MAC authenticates the Application Cryptogram and the IAD-MAC to the Reader. If the IAD-MAC is included in the AC computation it must be transmitted to the Issuer. The 8-byte EDA-MAC is computed by the Card as follows:
• Concatenate '0000' with the Application Cryptogram and the IAD-MAC (without tags and lengths).
• Compute EDA-MAC by applying AES-CMAC over the concatenated data with the session key for integrity SKI (Card): EDA-MAC = Leftmost 8 bytes of AES-CMAC (SKI) ['0000' || AC || IAD-MAC] To validate EDA-MAC the Reader computes IAD-MAC and EDA-MAC with its session key for integrity SKI (Reader) and compares the EDA-MAC with the one received from the Card. 4 Remote Authentication This section describes the remote authentication of the Card by the Issuer when performed during a transaction, it authenticates the transaction data and ensures that the Card is genuine. With remote authentication the Issuer validates the Application Cryptogram and by so doing authenticates the Card and a subset of transaction data that was included in the Application Cryptogram computationgeneration. If this subsetthe Card includes the IAD-MAC computed in section 3.2 thenin the Application Cryptogram generation, the IAD-MAC must be transmitted to the Issuer also authenticates the local by the Reader in the authorisation request. Then remote authentication provides a similar authentication of the transaction data included in the IAD-MAC to local authentication. The Reader performs the EDA-MAC validation before sending the authorisation request to the Issuer.

4.1 Master Key Management This section describes three recommended methods to derive a Card Master Key MK from an Issuer Master Key IMK and the Application PAN. A. When using 3DES with a PAN of any length, MK is computed as follows: Concatenate the PAN and PAN Sequence Number (PSN) to form X: X = PAN || PSN (if not present, PSN is replaced by a zero-byte) Pad X to the left with zero-digits to form a 16-digit number Y, if X is less than 16 digits long: Y = Rightmost 16 digits of X Calculate the 128-bit key MK using the 128-bit key IMK as follows: Let Y* be Y XORed with 8 'FF' bytes Z = 3DES (IMK) [Y] || 3DES (IMK) [Y*] MK = Z', where Z' is Z but with the least significant bit of each byte of Z set to a value that ensures that each of the 16 bytes of MK has an odd number of non-zero bits. B. When using 3DES with a PAN equal to 16 decimal digits or less apply method A; with a PAN greater than 16 decimal digits, MK is computed as follows: If the PAN has an odd number of digits, then pad the PAN to the left with a zero digit to have an even number of digits Concatenate the PAN (padded) and PAN Sequence Number (PSN) to form X: X = PAN (padded) || PSN (if not present, PSN is replaced by a zero byte) H = SHA-1 (X) gives a 20-byte hash result

If H does not contain 16 decimal digits, add the required number of non-decimal nibbles of H modulo 10 starting from the left side of H to obtain 16 decimal digits: Y = Leftmost 16 digits of {H decimal digits || H non-decimal nibbles mod 10} Calculate the 128-bit key MK using the 128-bit key IMK as follows: Let Y* be Y XORed with 8 'FF' bytes Z = 3DES (IMK) [Y] || 3DES (IMK) [Y*] MK = Z', where Z' is Z but with the least significant bit of each byte of Z set to a value that ensures that each of the 16 bytes of MK has an odd number of non-zero bits. C. When using AES, MK is computed as follows: Concatenate the PAN and PAN Sequence Number (PSN) to form X: X = PAN || PSN (if not present, PSN is replaced by a zero-byte) Pad X to the left with zero-digits to form a 16-byte number Y Let Y* be Y XORed with 16 'FF' bytes When using 128-bit keys, calculate MK as follows: MK = AES (IMK) [Y] When using 192-bit orkeys, calculate MK as follows: MK = Leftmost 24 bytes of AES (IMK) [Y] || AES (IMK) [Y*] When using 256-bit keys, calculate MK as follows: Let Y* be Y XORed with 16 'FF' bytes MK = Leftmost 24 or 32 bytes of AES (IMK) [Y] || AES (IMK) [Y*] At least one Card Master Key is used for the following purpose:

• MKAC for the Application Cryptogram, derived from Issuer Master Key IMKAC Additional Card Master Keys may be derived for other purposes. They are derived from the corresponding Issuer Master Keys. 3DES master keys are 128 bits long, i.e. two 64-bit keys. AES master keys are either 128, 192, or 256 bits long. The method to derive the corresponding 128-bit, 192-bit, or 256-bit session keys from the master key is described below when it applies. The session keys are derived by the Card application except for implementations where they are derived by the Issuer host (e.g. in the cloud).

4.2 Application Cryptogram The methods to generate the Application Cryptogram (AC) are defined by each Payment System. However, this section describes the recommended methods to generate an Application Cryptogram (the same methods are also defined in [EMV Book 2]).. AC is an 8-byte MAC generated by the Card over a subset of the transaction data in a way it can be verified by the Issuer to validate the transaction. AC is generated by applying DES-RMAC or AES-CMAC over the transaction data listed in Table 4.1 using the AC session key SKAC. SKAC is derived from the AC master key MKAC and the Application Transaction Counter (ATC). Table 4.1 – Recommended AC Input Data Reference Amount, Authorised Amount, Other Terminal Country Code Terminal Verification Results Transaction Currency Code Transaction Date Transaction Type Unpredictable Number Application Interchange Profile Application Transaction Counter Card Verification ResultsIssuer Application Data IAD-MAC computed in section 3.2 (1) (1) If IAD-MAC is provided to the Issuer Length 6 6 2 5 2 3 1 4 2 2 var. 8 Origin Reader Reader Reader Reader Reader Reader Reader Reader Card Card Card Card When the IAD-MAC is included in the AC computation and copied by If the Reader intransmits its value of the IAD (or another data object transmitted-MAC to the Issuer), by placing it contributes to the remotein the Issuer Application Data, then the Card must do the same when generating the Application Cryptogram. The Card must place its value of the IAD-MAC in the same location in the Issuer Application Data as used by the Reader. Note that bit 3 of byte 1 of Terminal Verification Results can be set unilaterally by the Reader after having received the GENERATE AC response to indicate that local authentication of the transaction data by the Issuerhas failed. Therefore, the Issuer must clear this bit before verifying the Application Cryptogram.

The freshness of the Application Cryptogram is ensured by the Application Transaction Counter in the Card and the Unpredictable Number from the Reader.

• When using DES-RMAC, AC is computed as follows: Let R be ATC followed by 6 zero-bytes Calculate the 128-bit key SKAC as follows: R = R0 || R1 || R2 || R3 || R4 || R5 || R6 || R7 SKACL = 3DES (MKAC) [R0 || R1 || 'F0' || R3 || R4 || R5 || R6 || R7] SKACR = 3DES (MKAC) [R0 || R1 || '0F' || R3 || R4 || R5 || R6 || R7] SKAC = SKACL || SKACR Calculate the 8-byte number AC as follows: AC = DES-RMAC (SKAC) [AC Input Data]
• When using AES-CMAC, AC is computed as follows: Let R be ATC followed by 14 zero-bytes R = R0 || R1 || R2 || R3 || R4 || R5 || … || R15 When using 128-bit keys, calculate SKAC as follows: SKAC = AES (MKAC) [R] When using 192-bit or 256-bit keys, calculate SKAC as follows: R = R0 || R1 || R2 || R3 || R4 || R5 || … || R15 SKACL = AES (MKAC) [R0 || R1 || 'F0' || R3 || R4 || R5 || … || R15] SKACR = AES (MKAC) [R0 || R1 || '0F' || R3 || R4 || R5 || … || R15] SKAC = Leftmost 24 or 32 bytes of SKACL || SKACR When using 256-bit keys, calculate SKAC as follows: SKACL = AES (MKAC) [R0 || R1 || 'F0' || R3 || R4 || R5 || … || R15] SKACR = AES (MKAC) [R0 || R1 || '0F' || R3 || R4 || R5 || … || R15] SKAC = SKACL || SKACR Calculate the 8-byte number AC as follows: AC = Leftmost 8-bytes of AES-CMAC (SKAC) [AC Input Data] The Issuer validates the authorisation request by computing the Application Cryptogram and comparing it with the one received from the Card. 5 ECC Certificates This section describes the security mechanisms to generate ECC certificates and authenticate ECC public keys. The RSA certificate option is described in section 6. AnThe ECC certificate format consists of a prefix plaintext and a signature block. In [EMV Book C-8] the entire Issuer ECC certificate plaintextis contained in tag '90' and the entire ICC ECC certificate signatureis contained within tag '9F46'. In an ECSDSA EC-SDSA certificate signature the certificate plaintextprefix of an arbitrary length is included in the data that is hashed, then the resulting hash is when signed with theusing signer’s private key. The length of the certificate signature (NSIG) is equal to the length of the hash value (NHASH) plus the length of an element of the curve field (NFIELD).) of the algorithm suite used to create the signature. Figure 5.1 – ECC Certificate Signature Private Key Certificate Plaintext Certificate Signature HASH SIGN © 20232025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Contactless Book E Security and Key Management v1.01 Certificate Prefix Certificate Signature Private Key / 67 HASH SIGN The ECSDSAEC-SDSA signature is verified with the signer’s public key. The entire certificate plaintextprefix is required to verify the hash value and thereby the certificate signature.

5.1 Issuer ECC Public Key Certificate The Issuer ECC Public Key Certificate has the following format: Table 5.1 – Issuer ECC Public Key Certificate Name 1 Issuer Certificate Format 2 Issuer Certificate Encoding 3 Issuer Identifier 4 Issuer Public Key Algorithm Suite Indicator Description Always Hex value '12' for this version of the specification. Always Hex value '00' for this version of the specification. Leftmost 3-10 digits from the PAN padded to the right with hex 'F's. Identifies the algorithm suite to be used with the Issuer Public Key when verifying Issuer signatures as defined in Table 8.3. Always Hex value '10' for this version of the specification. Length 1 1 5 1

Name 5 Issuer Certificate Expiration Date Description YYYYMMDD (UTC) after which this certificate is invalid. 6 Issuer Certificate Serial Number Number unique to the Certification Authority that signs the Issuer certificate. 7 RID Identifies the Payment System to which the Issuer Public Key is associated. 8 Certification Authority In conjunction with the RID, identifies which Public Key Index Certification Authority Public Key and associated algorithms to use when verifying the Issuer certificate. 9 Issuer Public Key Representation of Issuer Public Key (x-coordinate of Issuer Public Key point) on the curve identified by Issuer Public Key Algorithm Suite Indicator. 10 Issuer Public Key A digital signature on items 1 to 9 in this Certificate Signature table. Verified using the Certification Authority Public Key and associated algorithms identified by the Certification Authority Public Key Index (in this table). Length 4 3 5 1 NFIELD NSIG The Issuer Public Key Certificate Signature is the result of signing the Issuer certificate plaintextprefix (items 1 to 9 in Table 5.1) with the Certification Authority Private Key as described in section 8.8.7. When using the P-256 curve for the Issuer Public Key and the P-256 curve with SHA-256 hash algorithm SHA-256for the CA algorithm suite, the length of the Issuer certificate is 117 bytes.

5.2 Issuer ECC Public Key Validation The Reader first retrieves the Certification Authority Public Key (x, y) coordinates from the RID and the Certification Authority Public Key Index obtained from the Card, the Issuer Public Key validation is aborted if the Reader does not have the associated key. If the Certification Authority Public Key is present the Reader validates the Issuer Public Key as follows: 1. Check whetherthat the length of the Issuer certificate is at least 21 bytes. 2. Check whetherthat the Issuer Certificate Format is '12'.

3. Check whetherthat the Issuer Certificate Encoding is '00'. 4. Check whetherthat the Issuer Identifier matches the leftmost 3-10 digits from the Application PAN obtained from the Card. 5. Check whetherthat the Issuer Public Key Algorithm Suite Indicator is '10'. 6. Check whetherthat the Certificate Expiration Date is equal to or later than the current date. 7. Check whetherthat the RID matches the RID in the first 5 bytes of AID obtained from the Card (DF Name). 8. Check whetherthat the Certification Authority Public Key Index obtained from the Card is the same as the one in Table 5.1. 9. Check whetherthat the concatenation of the RID, Certification Authority Public Key Index, and Issuer Certificate Serial Number is not present on the Certification Revocation List that lists the Issuer Public Key Certificates revoked by Payment Systems.described in Annex B.2. 10. Check whetherthat the length of the Issuer certificate is equal to NFIELD + NSIG + 21 bytes. 11. Check whetherthat the Issuer Public Key Certificate Signature is valid using the Certification Authority Public Key as described in section 8.8.7. If any step above fails, the validation is aborted. If all the steps were successful, the Issuer ECC Public Key is considered as genuine. The Reader recovers the y-coordinate of the Issuer ECC Public Key from the x-coordinate in the Issuer certificate using the function described in section 8.8.4.

5.3 ICC ECC Public Key Certificate The ICC (or Card) ECC Public Key Certificate has the following format: Table 5.2 – ICC ECC Public Key Certificate Name 1 ICC Certificate Format 2 ICC Certificate Encoding Description Always Hex value '14' for this version of the specification. Always Hex value '00' for this version of the specification. Length 1 1

Name 3 ICC Public Key Algorithm Suite Indicator Description Identifies the algorithm suite to be used with the certified ICC Public Key when establishing the secure channel as defined in Table 8.4. Always Hex value '00' for this version of the specification. 4 ICC Certificate Expiration Date YYYYMMDD (UTC) after which this certificate is invalid. 5 ICC Certificate Expiration Time HHMM (UTC) after which this certificate is invalid. 6 ICC Certificate Serial Number unique to the Issuer that signs the Number Card certificate. 7 ICCD Hash Encoding Always Hex value '01' for this version of the specification, identifying TLV encoding of the input (except for the AIP where just the value is included) is used when computing the ICCD Hash. 8 ICCD Hash Algorithm Identifies the hash algorithm used to compute Indicator the ICCD Hash. Hex value '02' identifying that SHA-256 is used. 9 ICCD Hash Hash over the Static Data to be Authenticated using the hash algorithm identified by the ICCD Hash Algorithm Indicator. 10 ICC Public Key Representation of ICC Public Key (x-coordinate of ICC Public Key point) on the curve identified by the ICC Public Key Algorithm Suite Indicator. 11 ICC Public Key A digital signature on items 1 to 10 in this Certificate Signature table. Verified using the Issuer Public Key and associated algorithms identified by the Issuer Public Key Algorithm Suite Indicator (in the Issuer certificate). Length 1 4 2 6 1 1 NHASH NFIELD NSIG The ICC Public Key Certificate Signature is the result of signing the ICC certificate plaintextprefix (items 1 to 10 in Table 5.2) with the Issuer ECC private key as described in section 8.8.7.

When using the P-256 curve for the ICC Public Key and the P-256 curve with SHA-256 hash algorithm SHA-