Book C-8 Kernel Specification

EMV® Contactless Specifications for Payment Systems Book C-8 Kernel 8 Specification Version 1.1 June 2023

/ 303

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.

/ 303 Revision Log – Version 1.1 This section outlines notable updates that have been made to this specification since the publication of the EMV Contactless Specifications for Payment Systems, Book C-8 Kernel 8 Specification v1.0. Information about cryptographic algorithms and implementations has been moved to EMV Contactless Specifications for Payment Systems, Book E – Security and Key Management. The following sections have been moved from Book C-8 to Book E: Chapter 8: Security Algorithms Annex B: ECC Certificate Format Annex C: Algorithm Suite Indicators Annex D: Curve P-256 Security related functions that have been moved to Book E include: Secure channel use for Privacy protection. Unpredictable number generation. Checks on the Certification Authority Public Key type. Definitions of Certificate Algorithm Suite Indicators and Secure Channel Algorithm Suite Indicators. Generation of ECC public and private key pairs and recovery of the blinded public key. Derivation of Session Keys for Confidentiality and Integrity. Changes to data management handling include: Updates to how the TLV Database is instantiated and populated. Improved definitions of some data types and how they are handled in the TLV Database. ParseAndStoreCardResponse service updates to align with changes to data types and TLV Database operation. Variables scope changes from local to global – Start Time, Response Message Data Field. Improved DOL handling rules. Clean up of how proprietary tags are handled and general data management and handling. Constructing Extended SDA Tag List Related Data clarified to improve length handling.

/ 303 List handling has been updated. List encoding has been clarified. Tag Length Checking has been clarified. ACT Signal (i.e. the transaction data items signal) now has a minimum set of data. Removal of redundant data Removed unused subfields of the User interface Request Data. TVR Unrecognised CVM bit removed as it was not used. Other changes include: Clarifications of some terminology and definitions. Token Requestor ID added to the data dictionary. The IAD MAC is now stored in the TLV Database once calculated. General corrections, typographical error corrections, and formatting adjustments.

1. 1. 1. 1. 1. 1.5. 1.5. 1.5. 1. 2. 2. 2.2. 2.2. 2.2. 2.2. 2.2. 2.2. 2. 3. 3. 3. 3. 3.4. 3.4. 3.4. 3. 3.

/ 303 3. 3. 3. 4. 4.1. 4.1. 4.1. 4.1. 4. 4. 4. 4. 4. 4. 4.7. 4.7. 4. 5. 5. 5.2. 5.2. 5.2. 5.2. 5. 5.3. 5.3. 5.3. 5.3. 5. 5.4. 5.4. 5.4.

/ 303 5.4. 5. 5.5. 5.5. 5.5. 5.5. 5. 5.6. 5.6. 5.6. 5.6. 5. 5.7. 5.7. 5.7. 5.7. 6. 6. 6. 6.3. 6.3. 6.3. 6.3. 6.3. 6.3. 6.3. 6.3. 6.3. 6.3. 6.3. 6.3. 6.3. 6.3. 6.3. 6.3.

/ 303 6.3.17 6.3.18 6.3. 6. 6.4. 6.4. 7. 7. 7.2. 7.2. 7.2. 7.2. 7.2. 7.2. 7.2. 7.2. 7.2. 7.2. 7.2. A. A.1. A.1. A.1. A.1. A.1. A.1. A.1. A.1. A.1. A.1. A.1. A.1.

/ 303 A.1.13 A.1.14 A.1.15 A.1.16 A.1.17 A.1.18 A.1.19 A.1.20 A.1.21 A.1.22 A.1.23 A.1.24 A.1.25 A.1.26 A.1.27 A.1.28 A.1.29 A.1.30 A.1.31 A.1.32 A.1.33 A.1.34 A.1.35 A.1.36 A.1.37 A.1.38 A.1.39 A.1.40 A.1.41 A.1.42 A.1.43 A.1.44 A.1.45 A.1.46 A.1.47 A.1.48 A.1.

/ 303 A.1.50 A.1.51 A.1.52 A.1.53 A.1.54 A.1.55 A.1.56 A.1.57 A.1.58 A.1.59 A.1.60 A.1.61 A.1.62 A.1.63 A.1.64 A.1.65 A.1.66 A.1.67 A.1.68 A.1.69 A.1.70 A.1.71 A.1.72 A.1.73 A.1.74 A.1.75 A.1.76 A.1.77 A.1.78 A.1.79 A.1.80 A.1.81 A.1.82 A.1.83 A.1.84 A.1.85 A.1.

/ 303 A.1. A.1. A.1. A.1. A.1. A.1. A.1. A.1. A.1. A.1. A.1. A.1. A.1. A.1. A.1. A.1. A.1. A.1. A.1. A.1. A.1. A.1. A.1. A.1. A.1. A.1. A.1. A.1. A.1. A.1. A.1. A.1. A.1. A.1. A.1. A.1. A.1.

/ 303 A.1. A.1. A.1. A.1. A.1. A.1. A.1. A.1. A.1. A.1. A.1. A.1. A.1. A.1. A.1. A.1. A.1. A.1. A.1. A.1. A.1. A.1. A. A.

/ 303 Tables Table 1. Table 1. Table 1. Table 1. Table 2. Table 2. Table 2. Table 2. Table 2. Table 2. Table 2. Table 3. Table 3. Table 3. Table 4. Table 4. Table 4. Table 4. Table 5. Table 5. Table 5. Table 5. Table 5. Table 5. Table 5. Table 5. Table 5. Table 5. Table 5. Table 5. Table 5. Table 5. Table 5. Table 5. Table 5. Table 5. Table 5. Table 5. Table 5. Table 5.

/ 303 Table 6.0—State KS. Table 6. Table 6. Table 6. Table 6. Table 6. Table 6. Table 6. Table 6. Table 6. Table 6. Table 6. Table 6. Table 6. Table 7. Table A. Table A. Table A. Table A. Table A. Table A. Table A. Table A. Table A. Table A. Table A. Table A. Table A. Table A. Table A. Table A. Table A. Table A. Table A. Table A. Table A. Table A. Table A. Table A. Table A. Table A. Table A. Table A.

/ 303 Table A. Table A. Table A. Table A. Table A. Table A. Table A. Table A. Table A. Table A. Table A. Table E.

/ 303 Figures Figure 1. Figure 1. Figure 1. Figure 2. Figure 2. Figure 2. Figure 6. Figure 6. Figure 6. Figure 6. Figure 6. Figure 6. Figure 6. Figure 6. Figure 6. Figure 6. Figure 6. Figure 6. Figure 6. Figure 6. Figure 6. Figure 6. Figure 6. Figure 6. Figure 6. Figure 6. Figure 6. Figure 6. Figure 7. Figure 7. Figure 7. Figure 7. Figure 7. Figure 7. Figure 7. Figure 7. Figure 7. Figure 7. Figure 7.

/ 303 1 Using This Manual 1.1

Purpose

This document, EMV® Contactless Specifications for Payment Systems, Book C-8 – Kernel 8 Specification, should be read in conjunction with:

• EMV Contactless Specifications for Payment Systems, Book A – Architecture and General Requirements, hereafter referred to as [EMV Book A]
• EMV Contactless Specifications for Payment Systems, Book B – Entry Point Specification, hereafter referred to as [EMV Book B]
• EMV Contactless Specifications for Payment Systems, Book E – Security and Key Management, hereafter referred to as [EMV Book E] This document defines the behaviour of the Kernel used in combination with cards having a Kernel Identifier indicating Kernel 8, as defined in [EMV Book B]. Note: While this kernel is compatible with any Entry Point version, payment systems may specify a minimum Entry Point version that they require. For example, if the Kernel Identifier–Terminal (tag '96') data object is to be used, then the minimum version of Entry Point is Version 2.10 with Specification Bulletin 268.

1.2 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.3 Related Information The following references are used in this document

It is noted that the latest version applies unless a publication date is explicitly stated. Reference [EMV Book 1] Table 1.1—Related Information Document Title Integrated Circuit Card Specifications for Payment Systems – Book 1, Application Independent ICC to Terminal Interface Requirements

/ 303 Reference [EMV Book 2] [EMV Book 3] [EMV Book 4] [EMV Book A] [EMV Book B] [EMV Book E] [EMV CL L1] [EMV Token] [ISO 639-1] [ISO 3166-1] [ISO 4217] [ISO/IEC 7813] [ISO/IEC 7816-4] [ISO/IEC 7816-5] [ISO 8583:1987] [ISO 8583:1993] Document Title Integrated Circuit Card Specifications for Payment Systems – Book 2, Security and Key Management Integrated Circuit Card Specifications for Payment Systems – Book 3, Application Specification Integrated Circuit Card Specifications for Payment Systems – Book 4, Cardholder, Attendant, and Acquirer Interface Requirements EMV® Contactless Specifications for Payment Systems, Book A – Architecture and General Requirements EMV® Contactless Specifications for Payment Systems, Book B – Entry Point Specification EMV® Contactless Specifications for Payment Systems, Book E – Security and Key Management EMV® Level 1 Specifications for Payment Systems, EMV Contactless Interface Specification EMV® Payment Tokenisation Specification, Technical Framework Codes for the representation of names of languages – Part 1: Alpha-2 Code Codes for the representation of names of countries and their subdivisions – Part 1: Country codes Codes for the representation of currencies and funds Information technology — Identification cards — Financial transaction cards Identification cards — Integrated circuit(s) cards with contacts — Part 4: Organization, security and commands for interchange Registration of application providers Financial transaction card originated messages – Interchange message specifications Financial transaction card originated messages – Interchange message specifications

/ 303 Reference [ISO/IEC 8825-1] Document Title Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER) [ISO/IEC 8859] Information technology – 8-bit single-byte coded graphic character sets [ISO/IEC 9797-1] Information technology – Security techniques – Message Authentication Codes (MACs) — Part 1: Mechanisms using a block cipher [ISO/IEC 10116] Information technology — Security techniques — Modes of operation for an n-bit block cipher [ISO/IEC 14888-3] Information technology — Security techniques — Digital signatures with appendix — Part 3: Discrete logarithm based mechanisms [ISO/IEC 18031:2005] Information technology – Security techniques – Random bit generation [NIST SP800-22A] A statistical test suite for random and pseudorandom number generators for cryptographic algorithms

/ 303 1.4 Terminology The following terms are used in this document, carrying specialised meanings as indicated. Card Term Table 1.2—Terminology

Description

Card, as used in these specifications, is a consumer device supporting contactless transactions. Combination Combination is the combination of an AID and a Kernel ID. Configuration Option A Configuration Option allows activation or deactivation of the Kernel software behind this option. The Configuration Option may change the execution path of the software but it does not change the software itself. A Configuration Option is set in the Kernel database per AID and Transaction Type. Implementation Option An Implementation Option allows the vendor to select whether the functionality behind the option will be implemented in a particular installation. Kernel The Kernel contains the interface routines, security and control functions, and logic to manage a set of commands and responses to retrieve all the necessary data from the Card to complete a transaction. The Kernel processing covers the interaction with the Card between the selection of the card application (excluded) and the processing of the transaction’s outcome (excluded). NULL The state of a data object of a given type with no value. POS System The POS System is the collective term given to the payment infrastructure present at the merchant. It is made up of the Terminal and Reader. Process A Process is a logical component within a Reader that has one or more Queues to receive Signals. The processing of Signals, in combination with the carried data, may then generate other Signals to be sent. Processing can continue until all the Queues of a Process are empty, or until the Process terminates.

/ 303 Queue Term Reader Signal String Terminal Description A Queue is a buffer that stores events to be processed. The events are stored in the order received. The Reader is the device that supports the Kernel(s) and provides the contactless interface used by the Card. In this specification, the Reader is considered as a separate logical entity, although it can be an integral part of the POS System. A Signal is an asynchronous event that is placed in a Queue. A Signal can convey data as parameters, and the data provided in this way is used in the processing of the Signal. A sequence of bytes. The Terminal is the device that connects to the authorisation and/or clearing network and that together with the Reader makes up the POS System. The Terminal and the Reader may exist in a single integrated device. However, in this specification, they are considered separate logical entities.

/ 303 1.5 Notations 1.5.1 State Machine This document specifies the Kernel processing as a state machine that is triggered by Signals that cause state transitions. The application states of the Kernel are written in a specific format to distinguish them from the rest of the text: State Example: S22 – Waiting for Read Record Response The state machine of the Kernel is represented using a state diagram. Example: Figure 1.1 depicts the transitions for state S26 – Waiting for Generate AC Response. Upon receiving the Signal RECORD DECRYPTED, the state machine remains in state S26 – Waiting for Generate AC Response. The state machine leaves state S26 – Waiting for Generate AC Response upon receiving an RA Signal. In this case, the state machine goes to S28 – Waiting for IAD MAC Results if Crypto Read Record Counter = 0 and to S27 – Waiting for Decrypted Records if Crypto Read Record Counter ≠ 0. Figure 1.1—Example of State Diagram Notation RECORD DECRYPTED S26 – Waiting for Generate AC Response RA/CRYPTO READ RECORD COUNTER != 0 S27 – Waiting for Decrypted Records RA/CRYPTO READ RECORD COUNTER = 0 S28 – Waiting for IAD MAC Results This document uses a combination of flow diagrams and textual description to describe the state transitions in the state machine of the Kernel. Figure 1.2 depicts the symbols used in the flow diagrams.

Figure 1.2—Symbols Used in Flow Diagrams

/ 303 X - State Procedure CALL State Procedure Start Call Procedure () Label High-Level Action Description Label Detailed Action Description Action With Detailed Description as Described in Text Action With Detailed Description Included in the Flow Diagram Connectors Test ? Label TRUE FALSE Decision SIGNAL Signal Received Action SIGNAL Signal Sent Action DE/ NO DS YES Implementation Option Test

/ 303 On the Kernel behaviour, the combination of the flow diagrams and the corresponding textual descriptions constitutes the requirements:

• Each diagram in this specification has a unique label.
• Each symbol in a diagram has a unique identifier that is the concatenation of the diagram label with the symbol number.
• The textual description corresponding to a symbol may be included in the diagram or it may be a detailed textual description included in the text below the diagram. The flow diagrams are read from top to bottom and define the order of execution of the processing steps. The textual description specifies the behaviour of the individual steps but bears no information on the order of execution. An example of a flow diagram is given in Figure 1.3 in combination with the detailed textual description below. Figure 1.3—Example of Flow Diagram IsNotEmpty(TagOf(DF Name)) AND IsNotEmpty(TagOf(Card Qualifier)) AND 'Version' in Card Qualifier ≠ '00' ? 1.8 FALSE TRUE 1.10 Set Language Preference 1.9 'L2' in Error Indication:= CARD DATA MISSING 'Msg On Error' in Error Indication:= N/A 1.10 If the Language Preference is returned from the Card, then copy it to 'Language Preference' in User Interface Request Data 1 and User Interface Request Data 2: IF [IsNotEmpty(TagOf(Language Preference))] THEN 'Language Preference' in User Interface Request Data 1:= Language Preference 'Language Preference' in User Interface Request Data 2:= Language Preference If the length of Language Preference is less than 8 bytes, then pad 'Language Preference' in User Interface Request Data 1 and User Interface Request Data 2 with trailing hexadecimal zeroes to 8 bytes. ENDIF / 303 Only symbol 1.10 has a detailed textual description. The textual descriptions of symbols 1.9 and 1.8 are included in the flow diagram. The requirements are related to the behaviour of the Kernel, while leaving flexibility in the actual implementation. The implementation must behave in a way that is indistinguishable from the behaviour specified in this document, in that it creates the output as predicted by this specification for a given input. There is no requirement that the implementation realises the behaviour through a state machine as described in this document.

1.5.2 Data Object Notation Data objects used for this specification are capitalised: Data Object Name Example: Application File Locator To refer to a sub-element of a data object (i.e. a specific bit, set of bits, or byte of a multi-byte data object), the following notational convention is used: Named sub-element If the sub-element is defined in the data dictionary (Annex A), with each possible value of the sub-element having a name, then the following conventions apply:

• The reference to the sub-element is 'Name of Sub-element' in Data Object Name.
• The reference to the value is VALUE OF SUB-ELEMENT. Examples: 'CVM Limit exceeded' in Terminal Risk Management Data refers to bit 8 of byte 2 in Terminal Risk Management Data. 'CVM' in Outcome Parameter Set:= ONLINE PIN means the same as bits 8 to 5 of byte 4 of Outcome Parameter Set are set to 0010b. Sub-element identified by index Alternatively, an index may be used to identify a sub-element of a data object. In this case the following notational conventions apply:
• To refer to a specific byte of a multi-byte data object, a byte index is used within brackets (i.e. [ ]). The first byte (leftmost or most significant) of a data object has index 1. For example, Terminal Verification Results[2] represents byte 2 of Terminal Verification Results. / 303
• To refer to a specific bit of a single byte multi-bit data object, a bit index is used within brackets [ ]. The first bit (rightmost or least significant) of a data object has index 1. For example, Cryptogram Information Data[7] represents bit 7 of the Cryptogram Information Data.
• To refer to a specific bit of a multi-byte data object, a byte index and a bit index are used within brackets (i.e. [ ][ ]). For example, Terminal Verification Results[2][4] represents bit 4 of byte 2 of the Terminal Verification Results.
• Ranges of bytes are expressed using the x:y notational convention: For example, Terminal Verification Results[1:4] represents bytes 1, 2, 3, and 4 of the Terminal Verification Results.
• Ranges of bits are expressed using the y:x notational convention: For example, Cryptogram Information Data[5:1] represents bits 5, 4, 3, 2, and 1 of the Cryptogram Information Data. For example, Application File Locator [1][8:4] represents bits 4 to 8 of byte 1 of AFL. / 303 1.5.3 Other Notational Conventions Notations for processing data and managing memory are described in Table 1.3. Notation '0' to '9' and 'A' to 'F' 1001b 340 C-APDU SET CLEAR:= = OR Table 1.3—Other Notational Conventions Meaning Hexadecimal notation. Values expressed in hexadecimal form are enclosed in straight single quotes. Example 27509 decimal is expressed in hexadecimal as '6B75'. Binary notation. Values expressed in binary form are followed by the letter b. '08' hexadecimal is expressed in binary as 00001000b. Decimal notation. Values expressed in decimal form are not enclosed in single quotes. '0C' hexadecimal is expressed in decimal as 12. C-APDUs are written in all caps to distinguish them from the text GET PROCESSING OPTIONS A specific bit in a data object is set to the value 1b SET 'Kernel 8 processing and TV