PCI Watch

Tracking changes across the Payment Card Industry

SB nº 310: Updates to Contactless Book C-8

v1.0 Specification Bulletins
Contactless Acceptance Device

EMV® Specification Bulletin No. 310 First Edition, March 2025 Updates to EMV® Contactless Book C-8 – Kernel 8 Specification

Applicability

This Specification Bulletin applies to:

  • EMV Contactless Specifications for Payment Systems, Book C-8, Kernel 8 Specification, version 1.1, June 2023

Related Documents

  • EMV Specification Bulletin No. 302

Effective Date

  • 2 June 2025

Description

This specification bulletin contains clarifications and corrections to Book C-8, Kernel 8 Specification. (These are in addition to clarifications and corrections published in SB 302.) Details of Changes This specification bulletin discusses changes to the following topics: A. B. C. D. E. F. G. H. I. J. Key Yellow highlights existing text with areas of addition or change. Blue highlights existing text to be deleted. Red text indicates final text; that is, text that has been changed or inserted.

First Edition A. Version In section 1.6, Version: Change: Kernel and Card both maintain a version number, coded as 'Version' in Kernel Qualifier and in Card Qualifier respectively. The lowest version number of the two determines the functionality that can be used for the transaction. Two versions are defined, VERSION 1 and VERSION 2, with details on the corresponding functionality provided in Table 1.4. A Kernel implementing this version of the specification must set 'Version' to VERSION 2 in the Kernel Qualifier and must support Cards that provide 'Version' with value VERSION 1 or VERSION 2 in the Card Qualifier. Table 1.4—Versions and Corresponding Functionality Version VERSION 1 Functionality The generation of the Issuer Application Data MAC does not use the Issuer Application Data as input. The Issuer Application Data MAC is inserted in the Issuer Application Data before using the Issuer Application Data as input for the generation of the Enhanced Data Authentication MAC. VERSION 2 The generation of the Issuer Application Data MAC uses the Issuer Application Data as input. The Issuer Application Data MAC is used as input for the generation of the Enhanced Data Authentication MAC. The Issuer Application Data MAC is (optionally) included in the Issuer Application Data by the Kernel before including the Issuer Application Data in the Data Record. [EMV Book E] section 3.2 describes the generation of the Issuer Application Data MAC (IAD MAC) for VERSION 2; for VERSION 1, the Kernel must provide IAD MAC input data as specified in this document and compute IAD MAC with the same process as VERSION 2.

First Edition To: Kernel and Card both maintain a version number, coded as 'Version' in Kernel Qualifier and in Card Qualifier respectively. The lowest version number of the two determines the functionality that can be used for the transaction. A Kernel implementing this version of the specification must set 'Version' to VERSION 2 in the Kernel Qualifier and must support Cards that provide 'Version' with value VERSION 2 in the Card Qualifier. [EMV Book E] section 3.2 describes the generation of the Issuer Application Data MAC (IAD MAC) for VERSION 2. In section 6.3.15, States 26 and 27 – Common Processing, both topics 2627.11 and 2627.12: Change: 4 Modify GENERATE AC Response Message Data Field as follows:

  • Maintain the order of the data objects as returned in the response to the GENERATE AC
  • Remove tag '77' and length
  • Remove Application Cryptogram, Enhanced Data Authentication MAC
  • If 'Version' in Card Qualifier = VERSION 1, remove Issuer Application Data To: Modify GENERATE AC Response Message Data Field as follows:
  • Maintain the order of the data objects as returned in the response to the GENERATE AC
  • Remove padding bytes (if any), remove tag '77' and length
  • Remove Application Cryptogram, Enhanced Data Authentication MAC 4 The change to the second bullet is unrelated to Version, which is the topic of the other changes in this section. First Edition In section 6.3.16, State 28 – Waiting for IAD MAC Results: Change:

28.14 IF ['Version' in Card Qualifier = VERSION 1] THEN Send PROCESS EDA MAC( Enhanced Data Authentication MAC, Application Cryptogram || Issuer Application Data) Signal ELSE Send PROCESS EDA MAC( Enhanced Data Authentication MAC, Application Cryptogram || Issuer Application Data MAC) Signal ENDIF To:

28.14 Send PROCESS EDA MAC( Enhanced Data Authentication MAC, Application Cryptogram || Issuer Application Data MAC) Signal In Table A.6—Card Qualifier: Change: Byte Byte 1 Bit b8-1 Meaning Version '00': Not allowed '01': VERSION 1 '02': VERSION 2 Other values RFU To: Byte Bit Meaning Byte 1 b8-1 Version '00': Not allowed '01': Not allowed '02': VERSION 2 Other values RFU

First Edition B. Transaction Flow In section 3.3, Transaction Flow, change the final bullet as follows: Change:

  • If both Card and Kernel are configured to support local authentication, then the Kernel validates the Card and issuer certificates and the blinding factor. To:
  • If both Card and Kernel are configured to support local authentication, then the Kernel validates the Card and issuer certificates, the blinding factor, and the EDA-MAC; this ensures the authenticity of the transaction data, including the Application Cryptogram (which is validated by the Issuer during remote authentication). Note that EDA-MAC processing is always performed even if local authentication is not supported by either the card or the Kernel. First Edition C. Mandatory Configuration Data Objects Presence Check In section 6.3.1, Kernel Started, change the KS.2 as follows: Change: KS.2: Initialise User Interface Request Data 1 as follows: User Interface Request Data 1:= '0000 … 00' 'Message Identifier' in User Interface Request Data 1:= N/A 'Status' in User Interface Request Data 1:= N/A 'Hold Time' in User Interface Request Data 1:= Message Hold Time 'Language Preference' in User Interface Request Data 1:= '0000000000000000': To: KS.2: Initialise User Interface Request Data 1 as follows: User Interface Request Data 1:= '0000 … 00' 'Message Identifier' in User Interface Request Data 1:= N/A 'Status' in User Interface Request Data 1:= N/A 'Hold Time' in User Interface Request Data 1:= '000000' 'Language Preference' in User Interface Request Data 1:= '0000000000000000': First Edition In Figure 6.2 – Kernel Started Flow Diagram, added the new action KS.7 as follows: Change: To: D. Incorrect Counter Incremented On the sixth page of Figure 6.8: Change:

22.56 Crypto Read Record Counter:= Crypto Read Record Counter - 1 First Edition S22 – Waiting for Read Record Response To:

22.56 Crypto Read Data Counter:= Crypto Read Data Counter - 1 S22 – Waiting for Read Record Response On the fourth page of Figure 6.9: Change: TRUE 23.26 Crypto Read Record Counter:= Crypto Read Record Counter + 1 To: TRUE 23.26 Crypto Read Data Counter:= Crypto Read Data Counter + 1

On the sixth page of Figure 6.9: Change:

23.39 Crypto Read Record Counter:= Crypto Read Record Counter - 1 First Edition S23 – Waiting for Read Data Response To:

23.39 Crypto Read Data Counter:= Crypto Read Data Counter - 1 S23 – Waiting for Read Data Response On the third page of Figure 6.12: Change:

25.18 Crypto Read Record Counter:= Crypto Read Record Counter - 1 S202122232425 - A To:

25.18 Crypto Read Data Counter:= Crypto Read Data Counter - 1 S202122232425

  • A First Edition E. States 20, 21, 22, 23, and 24 – Common Processing Change the third page of Figure 6.10—States 20, 21, 22, 23, and 24 – Common Processing – Flow Diagram as shown: Change: S2021222324
  • D IsNotEmptyList(TagOf(Amount, Authorised (Numeric))) AND IsNotEmpty(TagOf(Transaction Date)) ? 2021222324.14 FALSE To: S2021222324
  • D 2021222324.15 TRUE OUT (END APPLICATION) IsNotEmpty(TagOf(Amount, Authorised (Numeric))) AND IsNotEmpty(TagOf(Transaction Date)) ? 2021222324.14 FALSE S202122232425
  • A Exit Kernel 2021222324.15 TRUE OUT (END APPLICATION) S202122232425
  • A Exit Kernel First Edition F. Alignment with EMV Contactless Book B
  • Entry Point Specification On the first page of Figure 6.13, States 20, 21, 22, 23, 24, and 25 – Common Processing – Flow Diagram: Change: TRUE Amount, Authorised (Numeric) > Reader CVM Required Limit ? 202122232425.7 FALSE TRUE To: TRUE Amount, Authorised (Numeric) >= Reader CVM Required Limit ? 202122232425.7 FALSE TRUE G. ICC ECC Public Key (for RSA Certificates) In section A.1.64 ICC ECC Public Key (for RSA Certificates): Change: Length: 32 or 66 To: Length: 32 First Edition In Table A.37—Data Objects by Tag: Change: '9F810B' ICC ECC Public Key To: '9F810B' ICC ECC Public Key (for RSA Certificates) H. Issuer RSA Public Key Remainder In section A.1.76 Issuer RSA Public Key Remainder: Change: Length: NI – NCA + 36 To: Length: var. First Edition First Edition I. Terminal Risk Management Data In section A.1.129, Terminal Risk Management Data: Change: Description: Application-specific value used by the Card for risk management purposes. To: Description: Indicates reader capabilities, requirements, and preferences to the Card. Byte 1 bits 7, 6, 4, 3 and Byte 2 bit 8 are transient values, and reset to zero at the beginning of the transaction (see Figure 6.2, step KS.7). All other bits are static configuration values, and not modified based on transaction conditions. First Edition J. Minor Typos/Corrections The text of symbol S23 was incorrect on the first, second, and fifth pages of Figure 6.9. Change: S23 – Waiting for Read Record Response To: S23 – Waiting for Read Data Response The closing parenthesis was missing in the 202122232425.16. Change:

202122232425.16 AID (Configuration Data) matches DF Name ?: n:= GetLength(TagOf(Application Identifier (Configuration Data))) [(n ≤ GetLength(TagOf(DF Name)) AND (DF Name[1:n] = Application Identifier (Configuration Data))] To:

202122232425.16 AID (Configuration Data) matches DF Name ?: n:= GetLength(TagOf(Application Identifier (Configuration Data))) [(n ≤ GetLength(TagOf(DF Name))) AND (DF Name[1:n] = Application Identifier (Configuration Data))]

The text of Connector was incorrect on the fourth pages of Figure 6.18. Change: First Edition To: The text of symbol S30 was incorrect on the third page of Figure 6.19. Change: S29 – Waiting for Write Data Response To: S30 – Waiting for Write Data Response

An extraneous word was included on the fourth page of Figure 6.20. Change: TRUE ONLINE 2930.19 'Status' in Outcome Parameter Set:= ONLINE REQUEST To: TRUE First Edition 2930.19 'Status' in Outcome Parameter Set:= ONLINE REQUEST An extraneous word was included on the fifth page of Figure 6.20. Change: To:

Service Code was included in the Data Dictionary but is not used in Book C-8. Replace section A.1.116 with: A.1.116 [deleted] First Edition The parameter name of A.1.133 was incorrect. Change: A.1.133 Token Requester ID To: A.1.133 Token Requestor ID

First Edition

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 © 2025 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.