PCI Watch

Tracking changes across the Payment Card Industry

Book E: Security and Key Management

v1.0 Specifications
Contactless Acceptance Device

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

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.

Contents 1 1.1 1.2 1.3 1.4 1. 2 2.1 2.2 2. 3 3.1 3. 4 4.1 4. 5 5.1 5.2 5.3 5. 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.

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.

Figures 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 allows the authentication by 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 CBC CDOL CID CMAC CMC CTR 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 Cipher Block Chaining Card Risk Management Data Object List Cryptogram Information Data Cipher-based Message Authentication Code Card Message Counter CounTeR mode

Abbreviation CVD CVM DDOL DES ECC ECDH ECSDSA EDA ERRD fDDA HSM IAD ICC IMK KMC LDD M MAC MK NC NCA NI NFIELD NHASH NSIG O ODA PAN PDOL PKI Description Cardholder Verification Decision Cardholder Verification Method 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 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 Length of the ECC Digital Signature Optional Offline Data Authentication Primary Account Number Processing Options Data Object List Public Key Infrastructure

Abbreviation PSN RID RMAC RRP RSA SDA SHA SK SKD TC TLV UN var. Description 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 A mod n || A  B 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. 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 objects 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.

Notation A · B Description 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 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.

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 Card certificate), 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, 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 Authentication 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 authentication 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.
  • 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 Local Cryptogram is authenticated by the Reader using the session key for integrity SKI obtained during the BDH key agreement, as described in section 2.1. 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 verification, 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) 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 Length 6 6 2 5 2 Reference Transaction Date Transaction Type Unpredictable Number CVM Results Terminal Risk Management Data Length 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 Origin PDOL Values (Value field of PDOL Related Data) Reader CDOL1 Related Data Reader Terminal Relay Resistance Entropy (1) Reader Last ERRD Response (without tag '80' and length '0A') (1) Card GENERATE AC Response Message without:
  • Application Cryptogram
  • EDA-MAC
  • 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 || 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 computation. If this subset includes the IAD-MAC computed in section 3.2 then the Issuer also authenticates the local transaction data included in the IAD-MAC.

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 When using 128-bit keys, calculate MK as follows: MK = AES (IMK) [Y] When using 192-bit or 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 Length 6 Origin Reader Amount, Other 6 Reader Terminal Country Code 2 Reader Terminal Verification Results 5 Reader Transaction Currency Code 2 Reader Transaction Date 3 Reader Transaction Type 1 Reader Unpredictable Number 4 Reader Application Interchange Profile 2 Card Application Transaction Counter 2 Card Card Verification Results IAD-MAC computed in section 3.2 (1) (1) If IAD-MAC is provided to the Issuer var. Card 8 Card When the IAD-MAC is included in the AC computation and copied by the Reader in the IAD (or another data object transmitted to the Issuer), it contributes to the remote authentication of the transaction data by the Issuer. 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 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 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. An ECC certificate consists of the certificate plaintext and the certificate signature. In an ECSDSA signature the certificate plaintext of an arbitrary length is hashed, then the resulting hash is signed with the 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). Figure 5.1 – ECC Certificate Signature Private Key Certificate Plaintext Certificate Signature HASH SIGN The ECSDSA signature is verified with the signer’s public key. The entire certificate plaintext 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 Description Always Hex value '12' for this version of the specification. Length 1

Name 2 Issuer Certificate Encoding Description Always Hex value '00' for this version of the specification. 3 Issuer Identifier Leftmost 3-10 digits from the PAN padded to the right with hex 'F's. 4 Issuer Public Key Algorithm Suite Indicator 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. 5 Issuer Certificate Expiration Date 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 1 5 1 4 3 5 1 NFIELD NSIG The Issuer Public Key Certificate Signature is the result of signing the Issuer certificate plaintext (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 and the hash algorithm SHA-256, 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 whether the length of the Issuer certificate is at least 21 bytes. 2. Check whether the Issuer Certificate Format is '12'. 3. Check whether the Issuer Certificate Encoding is '00'. 4. Check whether the Issuer Identifier matches the leftmost 3-10 digits from the Application PAN obtained from the Card. 5. Check whether the Issuer Public Key Algorithm Suite Indicator is '10'. 6. Check whether the Certificate Expiration Date is equal to or later than the current date. 7. Check whether the RID matches the RID in the first 5 bytes of AID obtained from the Card (DF Name). 8. Check whether the Certification Authority Public Key Index obtained from the Card is the same as the one in Table 5.1. 9. Check whether 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. 10. Check whether the length of the Issuer certificate is equal to NFIELD + NSIG + 21 bytes. 11. Check whether 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 Description 1 ICC Certificate Format Always Hex value '14' for this version of the specification. 2 ICC Certificate Encoding Always Hex value '00' for this version of the specification. 3 ICC Public Key Algorithm Suite Indicator 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. Length 1 1 1 4 2 6 1 1 NHASH NFIELD

Name Description 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 NSIG The ICC Public Key Certificate Signature is the result of signing the ICC certificate plaintext (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 and the hash algorithm SHA-256, the length of the Card certificate is 145 bytes. The ICCD Hash is a hash calculated over the Static Data to be Authenticated formed from the signed records identified by the AFL, followed by any data identified by the Extended SDA Tag List (including the tags and length) and the AIP value. Note that the ICC certificate does not contain the PAN which is added to a signed record in order to be authenticated by the ICC Public Key Certificate Signature.

5.4 ICC ECC Public Key Validation The Reader validates the ICC (or Card) Public Key with the Issuer Public Key validated in section 5.2 and the SDA Hash computed by the Kernel as follows: 1. Check whether the length of the ICC certificate described in Table 5.2 length is at least 17 bytes. 2. Check whether the ICC Certificate Format is '14'. 3. Check whether the ICC Certificate Encoding is '00'. 4. Check whether the ICC Certificate Expiration Date and ICC Certificate Expiration Time is equal to or later than the current date and time. 5. Check whether the ICC Public Key Algorithm Suite Indicator is '00'. 6. Check whether the ICCD Hash Encoding is '01'. 7. Check whether the ICCD Hash Algorithm Indicator is '02'. 8. Check whether the length of the ICC certificate described in Table 5.2 length is equal to NHASH + NFIELD + NSIG + 17 bytes. 9. Check whether the SDA Hash already computed by the Kernel is the same as the ICCD Hash recovered from the ICC certificate. 10. Check whether the ICC Public Key Certificate Signature is valid using the Issuer 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 ICC ECC Public Key is considered as genuine. The Reader recovers the y-coordinate of the ICC ECC Public Key from the x-coordinate in the ICC certificate using the function described in section 8.8.4.

6 RSA Certificates This section describes the security mechanisms to generate RSA certificates and authenticate RSA public keys. In this specification the term RSA certificate consists of the recoverable certificate plaintext, certificate related data and certificate signature. In [EMV Book 2] the term “certificate” corresponds to the certificate signature only. In an RSA signature, the length of the certificate signature is equal to the length of the public key modulus of the signer. In order to sign a certificate of an arbitrary length, the certificate plaintext and certificate related data are hashed, then the certificate plaintext and the resulting hash are signed with the signer’s private key. Figure 6.1 – RSA Certificate Signature Certificate Plaintext (recoverable) Private Key Certificate Related Data Certificate Signature HASH SIGN The certificate signature is verified with the signer’s public key so that the certificate plaintext and the hash value are recovered from the certificate signature. The certificate related data is required to verify the hash value and thereby the certificate signature.

6.1 Issuer RSA Public Key Certificate The Issuer RSA Public Key Certificate has the following format: Table 6.1 – Issuer RSA Public Key Certificate Name 1 Issuer Certificate Format 2 Issuer Identifier 3 Issuer Certificate Expiration Date 4 Issuer Certificate Serial Number 5 Issuer Hash Algorithm Indicator 6 Issuer Public Key Algorithm Indicator 7 Issuer Public Key Length 8 Issuer Public Key Exponent Length 9a Issuer Public Key Leftmost Digits Description Hex value '02'. Leftmost 3-8 digits from the PAN padded to the right with hex 'F's. MMYY after which this certificate is invalid. Binary number unique to this certificate assigned by the Certification Authority. Identifies the hash algorithm used to produce the hash value in the digital signature scheme. Hex value '01' identifying that SHA-1 is used. Identifies the digital signature algorithm to be used with the Issuer Public Key. Hex value '01' identifying that RSA is used. Identifies the length of the Issuer Public Key modulus in bytes. Identifies the length of the Issuer Public Key exponent in bytes. If NI ≤ NCA – 36, consists of the full Issuer Public Key padded to the right with NCA – 36 – NI bytes of value 'BB'. If NI > NCA – 36, consists of the NCA – 36 most significant bytes of the Issuer Public Key. Length 1 4 2 3 1 1 1 1 NCA – 36

Name 10 Issuer Certificate Signature Description A digital signature on items 1 to 9a in this table and certificate related data below. Verified using the Certification Authority Public Key and associated algorithms identified by the RID and the Certification Authority Public Key Index (obtained from the Card). Length NCA Issuer certificate related data also authenticated by the Issuer RSA Public Key Certificate: Table 6.2 – Issuer RSA Certificate Related Data Name 9b Issuer Public Key Remainder 9c Issuer Public Key Exponent Description Present only if NI > NCA – 36 and consists of the NI – NCA + 36 least significant bytes of the Issuer Public Key. Issuer Public Key exponent equal to 3 or 65537. Length 0 or NI – NCA + 36 1 or 3 NCA and NI are the lengths in bytes of the Certification Authority and Issuer Public Key moduli respectively. The Issuer Certificate Signature is the result of signing the concatenation of the Issuer certificate plaintext (items 1 to 9a in Table 6.1) and Issuer certificate related data (items 9b and 9c in Table 6.2) with the Certification Authority Private Key as described in section 8.7.2. Thus, the length of the Issuer Certificate Signature is equal to NCA.

6.2 Issuer RSA Public Key Validation The Reader first retrieves the Certification Authority Public Key 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 whether the length of the Issuer Certificate Signature is equal to the length of the Certification Authority Public Key modulus NCA.

2. Recover the Issuer certificate plaintext from the Issuer Certificate Signature as described in section 8.7.2. This includes checking that the hash computed over the concatenation of Table 6.3 – Recovered Issuer Certificate Plaintext and Table 6.2 – Issuer RSA Certificate Related Data obtained from the Card is the same as the hash value recovered from the Issuer Certificate Signature. Table 6.3 – Recovered Issuer Certificate Plaintext Reference Issuer Certificate Format Issuer Identifier Issuer Certificate Expiration Date Issuer Certificate Serial Number Issuer Hash Algorithm Indicator Issuer Public Key Algorithm Indicator Issuer Public Key Length Issuer Public Key Exponent Length Issuer Public Key Leftmost Digits (padded as described in Table 6.1) Length 1 4 2 3 1 1 1 1 NCA – 36 Value '02' Leftmost 3-8 digits from PAN MMYY – '01' '01' NI 1 or 3 – 3. Check whether the concatenation of the RID and Certification Authority Public Key Index obtained from the Card and the Issuer Certificate Serial Number is not present on the Certification Revocation List that lists the Issuer Public Key Certificates revoked by Payment Systems. 4. Check whether the Issuer Certificate Format is '02'. 5. Check whether the Issuer Identifier matches the leftmost 3-8 digits from the Application PAN obtained from the Card. 6. Check whether the last day of the month of the Issuer Certificate Expiration Date is equal or later than the current date. 7. Check whether the Issuer Hash Algorithm Indicator is '01'. 8. Check whether the Issuer Public Key Algorithm Indicator is '01'. If any step above fails, the validation is aborted. If all the steps were successful, the Issuer RSA Public Key is considered as genuine.

The Reader concatenates the Issuer Public Key Leftmost Digits (without padding) and Issuer Public Key Remainder (if present) to obtain the Issuer Public Key Modulus. The Reader verifies that the resulting length of the Issuer Public Key Modulus is equal to the recovered value of NI and that NI  NCA; if not, validation is aborted.

6.3 ICC RSA Public Key Certificate The ICC (or Card) RSA Public Key Certificate has the following format: Table 6.4 – ICC RSA Public Key Certificate Name Description 1 ICC Certificate Format Hex value '04'. 2 Application PAN PAN padded to the right with Hex 'F's. 3 ICC Certificate Expiration Date MMYY after which this certificate is invalid. 4 ICC Certificate Serial Binary number unique to this certificate Number assigned by the Issuer. 5 ICC Hash Algorithm Identifies the hash algorithm used to produce Indicator the hash value in the digital signature scheme. Hex value '01' identifying that SHA-1 is used. 6 ICC Public Key Identifies the digital signature algorithm to be Algorithm Indicator used with the ICC Public Key. Hex value '01' identifying that RSA is used. 7 ICC Public Key Length Identifies the length of the ICC Public Key modulus in bytes. 8 ICC Public Key Exponent Length Identifies the length of the ICC Public Key exponent in bytes. 9a ICC Public Key Leftmost Digits If NC ≤ NI – 42, consists of the full ICC Public Key padded to the right with NI – 42 – NC bytes of value 'BB'. If NC > NI – 42, consists of the NI – 42 most significant bytes of the ICC Public Key. Length 1 10 2 3 1 1 1 1 NI – 42

10 ICC Certificate Signature A digital signature on items 1 to 9a in this NI table and certificate related data below. Verified using the Issuer Public Key and associated algorithms identified by the Issuer Public Key Algorithm Indicator (in the Issuer Public Key Certificate). ICC certificate related data also authenticated by the ICC RSA Public Key Certificate: Table 6.5 – ICC RSA Certificate Related Data Name 9b ICC Public Key Remainder 9c ICC Public Key Exponent 9d SDA Description Length Present only if NC > NI – 42 and consists of the NC – NI + 42 least significant bytes of the ICC Public Key. 0 or NC – NI + 42 ICC Public Key exponent equal to 3 or 65537. 1 or 3 Static Data to be Authenticated formed from – the signed records identified by the AFL, any data identified by the Extended SDA Tag List, and the AIP value. NI and NC are the lengths in bytes of the Issuer and ICC Public Key moduli respectively. The ICC Certificate Signature is the result of signing the concatenation of the ICC certificate plaintext (items 1 to 9a in Table 6.4) and ICC certificate related data (items 9b to 9d in Table 6.5) with the Issuer RSA Private Key as described in section 8.7.2. Thus, the length of the ICC Certificate Signature is equal to NI. The ICC RSA Public Key Certificate is used to authenticate the ICC ECC Public Key. The ICC ECC Public Key (x-coordinate) is added to a record identified in the AFL as signed i.e. included in the Static Data to be Authenticated. Additional data objects that are not in records can be authenticated by adding the optional Extended SDA Tag List in a (preferably signed) record identified by the AFL. The Static Data to be Authenticated is then formed from the signed records identified by the AFL, followed by any data identified by the Extended SDA Tag List (including the tags and length) and the AIP value. For non-C-8 EMV contactless Kernels the Static Data to be Authenticated is formed from the signed records identified by the AFL, followed by the AIP value if identified by SDA Tag List. If present, the SDA Tag List only contains the tag '82' identifying the AIP.

6.4 ICC RSA Public Key Validation The Reader validates the ICC (or Card) Public Key with the Issuer Public Key validated in section 6.2 as follows: 1. Check whether the length of the ICC Certificate Signature is equal to the length of the Issuer Public Key modulus NI. 2. Recover the ICC certificate plaintext from the ICC Certificate Signature as described in section 8.7.2. This includes checking that the hash computed over the concatenation of Table 6.6 – Recovered ICC Certificate Plaintext and Table 6.5 – ICC RSA Certificate Related Data obtained from the Card is the same as the hash value recovered from the ICC Certificate Signature. 3. For non-C-8 EMV contactless Kernels, if the SDA Tag List is present in the Static Data to be Authenticated (item 9d of Table 6.5), check that the SDA Tag List only contains the tag '82'. Table 6.6 – Recovered ICC Certificate Plaintext Reference ICC Certificate Format Application PAN ICC Certificate Expiration Date ICC Certificate Serial Number ICC Hash Algorithm Indicator ICC Public Key Algorithm Indicator ICC Public Key Length ICC Public Key Exponent Length ICC Public Key Leftmost Digits (padded as described in Table 6.4) Length 1 10 2 3 1 1 1 1 NI – 42 Value '04' – MMYY – '01' '01' NC 1 or 3 – 4. Check whether the ICC Certificate Format is '04'. 5. Check whether the ICC Hash Algorithm Indicator is '01'. 6. Check whether the ICC Public Key Algorithm Indicator is '01'. 7. Check whether the Application PAN recovered from the ICC Public Key Certificate matches the PAN obtained from the Card. 8. Check whether the last day of the month of the ICC Certificate Expiration Date is equal to or later than current date.

If any step above fails, the validation is aborted. If all the steps were successful, both the ICC RSA Public Key and the ICC ECC Public Key (x-coordinate) contained in the Static Data to be Authenticated are considered as genuine. The Reader discards the ICC RSA Public Key and recovers the y-coordinate of the ICC ECC Public Key from the x-coordinate using the function described in section 8.8.4. For non-C-8 EMV contactless Kernels, the Reader concatenates the ICC Public Key Leftmost Digits (without padding) and ICC Public Key Remainder (if present) to obtain the ICC Public Key Modulus. The Reader verifies that the resulting length of the ICC Public Key Modulus is equal to the recovered value of NC and that NC  NI; if not, validation is aborted.

7 BDH Primitives In the following NFIELD is the length of the ECC public key (size of the field element).

7.1 BDH Initialisation The BDH initialisation is the process of computing and exchanging the Kernel public key and the Card blinded public key between the Reader and the Card as follows:

  • The Card being personalised with the ECC key pair (dC, QC) where QC = dC·G
  • The Reader generates a Kernel ECC key pair (dK, QK) on the curve as follows:
  • Generate a random integer dK (private key) where 1 &lt; dK &lt; n-1
  • Calculate the Kernel public key QK = dK·G
  • The Reader sends QK (x, y) coordinates to the Card in t

Shown in part. Read the original for the full text.