PCI Watch

Tracking changes across the Payment Card Industry

Book C-6 Kernel Specification

v2.11 Specifications
Contactless Acceptance Device

EMV® Contactless Specifications for Payment Systems Book C-6 Kernel 6 Specification Version 2.11 June 2023

v2.11 Page i

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 NONINFRINGEMENT, 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.

v2.11

Revision Log – Version 2.11 This Revision Log applies to: EMV Contactless Specifications for Payment Systems, Book C-6, Kernel 6 Specification, Version 2.10, March 2021 [Book C-6] The following changes have been made to Book C-6 since the publication of Version 2.10. 1. TTQ byte 3 bit 4 in the data dictionary has be updated to RFU. TTQ Byte 3 bit 2 definition has also been updated for clarity. TTQ byte 3 bit 6 has been updated for CDCVM required for Transit MCC. 2. Application Selection Flag, DF62 has been added to the data dictionary. 3. In 3.10 Post Completion updated Online Processing description to describe the use of Online Request (Approved + Restart B) and Online Request (Declined + Restart B) to support issuer scripting. 4. Added a new Section 3.11.1 Post Completion, describing post-completion processing. 5. Update description of Figure 3 12: Read Application Data Process, step 5 to send an outcome End Application for Processing Error. 6. Added two new sections, B.4. and B5, to define new outcomes for Online Request (Approved + Restart B) and Online Request (Declined + Restart B) to support issuer scripting. 7. Updated Table 4 24: Minimum Data Items Recorded in Tearing Log such that AID Tag saved in Tearing Log changed to 84, the one from the Card.

v2.11

1. 1. 1. 1. 1. 1. 1. 2. 2.1. 2. 2. 2.3.1 2.3.2 2.3. 2. 2. 2.5.1 2.5.2 2.5.3 2.5.4 2.5. 2. 2. 2.7. 3. 3. 3. 3. 3. 3.

v2.11

3.6. 3.6. 3. 3. 3. 3. 3. 3.11. 3. 3. 4. 4. 4. 4.3. 4.3. 4. 4.4. 4.4. 4. 4.5. 4.5. 4. 4. 4. 4.8. 4.8. 4. 4.9. 4.9. 4. 4. B.2. B.3.

v2.11 Page v B.4. B.5. B.6. B.7. B.8. B.9. B.10. B.11. B.12. B.13. B.14. C.1. C.2. C.3. D.1. D.2. D.3. D.4. D.5. D.6. D.7. D.8. D.9. D.10. D.11. D.12. D.13. D.14. D.15. D.16. D.17. D.18. D.19.

v2.11

D.20. D.21. D.22. D.23. D.24. D.25. D.26. D.27. D.28. D.29. D.30. D.31. D.32. D.33. D.34. D.35. D.36. D.37. D.38. D.39. D.40. D.41. D.42. D.43. E.1. E.2.

v2.11

v2.11

v2.11

1

Introduction

This EMV Contactless Specifications for Payment Systems, Book C-6, Kernel 6 Specification (this Specification) addresses the requirements applicable to Kernel 6, including the:

  • Overview of Kernel 6 Approach
  • Terminal Transaction Processing Steps and
  • Application Protocol Data Unit (APDU) Command

Description

Baseline functionalities are addressed in [EMV Book B], which should be read as a companion document and is hereby incorporated into this specification by reference. These baseline functionalities include, but are not limited to:

  • Preliminary Transaction Processing (i.e., Pre-Processing)
  • Protocol Activation
  • Combination Selection
  • Kernel Activation
  • Outcome Processing and
  • Data Element Processing. 1.1

Scope

This Specification describes one of several Kernels defined for use with Entry Point.

1.2 Audience This Specification is intended for use by system designers in payment systems and financial institution staff responsible for implementing financial applications. Note: Throughout this Specification, Contactless Cards and Consumer Devices (such as mobiles) are referenced as Contactless Cards unless Contactless and Consumer Devices must be addressed separately.

1.3 Volumes of Contactless Specifications This Specification is part of an EMVCo eleven-volume set, including:

  • Book A: Architecture and General Requirements [EMV Book A]
  • Book B: Entry Point Specification [EMV Book B]
  • Book C-2: Kernel 2 Specification
  • Book C-3: Kernel 3 Specification
  • Book C-4: Kernel 4 Specification
  • Book C-5: Kernel 5 Specification
  • Book C-6: Kernel 6 Specification
  • Book C-7: Kernel 7 Specification
  • Book C-8: Kernel 8 Specification v2.11
  • Book E: Security and Key Management
  • Level 1 Specifications for Payment Systems, EMV Contactless Interface Specification 1.4 Reference Specifications In addition to the volumes cited in Section 1.3, the following specifications and standards contain provisions that are referenced in this Specification. The latest version shall apply unless a publication date is explicitly stated. If any provision or definition in this Specification differs from those in the listed specifications and standards, the provision or definition herein shall take precedence. Abbreviation [EMV Book 1] [EMV Book 2] [EMV Book 3] [EMV Book 4] [EMV Book A] [EMV Book B] [ISO/IEC 639-1] [ISO/IEC 3166-1] [ISO/IEC 4217] [ISO/IEC 7810] [ISO/IEC 7813] [ISO/IEC 7816-4] [ISO/IEC 7816-5] Table 1-1:

References

Title EMV Integrated Circuit Card Specifications for Payment Systems. Book 1

  • Application Independent ICC to Terminal Interface Requirements. EMV Integrated Circuit Card Specifications for Payment Systems. Book 2
  • Security and Key Management. EMV Integrated Circuit Card Specifications for Payment Systems. Book 3
  • Application Specification. EMV 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 Codes for the representation of names of languages – Part 1: Alpha2 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 – Physical characteristics. Information technology – Identification cards – Financial transaction cards. Information technology – Identification cards – Integrated circuit cards – Part 4: Organization, security and commands for interchange. Identification cards – Integrated circuit cards – Part 5: Registration of application providers. v2.11 Abbreviation [ISO/IEC 8583-1] [ISO/IEC 8825-1] [ISO/IEC 8859-1] [ISO/IEC 9797-1] [ISO/IEC 10116] [ISO/IEC 13239] [ISO/IEC 14443-1] [ISO/IEC 14443-2] [ISO/IEC 14443-3] [ISO/IEC 14443-4] Title Financial transaction card originated messages – Interchange message specifications – Part 1: Messages, data elements and code values. Information technology – ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER). Information Technology – 8-bit single-byte coded graphic character sets – Part 1: Latin alphabet No. 1. 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 – Telecommunications and information exchange between systems – High-level data link control (HDLC) procedures. Identification cards – Contactless integrated circuit cards – Proximity cards – Part 1: Physical characteristics. Identification cards – Contactless integrated circuit cards – Proximity cards – Part 2: Radio frequency power and signal interface. Identification cards – Contactless integrated circuit cards – Proximity cards – Part 3: Initialization and anti-collision. Identification cards – Contactless integrated circuit cards – Proximity cards – Part 4: Transmission protocol.

1.5 Overview This document includes the following chapters and annexes:

  • Chapter 1: contains general information regarding this Specification.
  • Chapter 2: provides a high-level description of the Kernel 6 approach, including configuration, transaction processing flows, terminal and configuration requirements and options, and supported APDU commands.
  • Chapter 3: specifies detailed transaction processing flows for Kernel 6.
  • Chapter 4: lists and describes the APDU commands used by Kernel 6.
  • Annex A: is a glossary of terms and abbreviations used in this specification.
  • Annex B: contains Kernel 6 Transaction Parameters and Outcomes.
  • Annex C: lists data elements required for offline only, online only, and offline / online transactions.
  • Annex D: is a dictionary of data elements for Kernel 6.
  • Annex E: specifies the Track 2 Equivalent Data. v2.11
  • Annex F: provides guidance for Data Storage security.

1.6 Data Conventions The data conventions included in Table 1-2 are used throughout this Specification. Table 1-2: Data Conventions Convention ‘…’ […] A b n Var Description Single quotation marks surround a decimal or hexadecimal digit. For example: ‘3A’ or ‘9901’ Squared brackets surround a reference document. For example: [EMV Book A]. Alphanumeric Binary Numeric Variable length For data elements that have multiple bytes, the first byte or byte 1 is the left-most byte, while the last byte is the right-most byte.

1.7 Terminology The terminology used in this specification is presented in Table 1-3. Term Shall, must, or required Should May or optional Table 1-3: Terminology Definition Denotes a mandatory requirement Denotes a recommendation Denotes an optional feature

v2.11

2 Overview of Kernel 6 Approach A high-level description of the Kernel 6 approach is provided in the following sections:

  • 2.1: Configuration
  • 2.2: Transaction Processing Flows
  • 2.3: Configuration, Functionality, and APDU Command Support
  • 2.4: Deferred Authorization
  • 2.5: Data Storage
  • 2.6: Extended Logging
  • 2.7: Tearing Recovery 2.1 Configuration The Kernel 6 approach supports only EMV transactions and it allows the processing of transactions offline or online (based on Terminal capabilities). Access to configurations supporting EMV transactions are enabled by a designated Application Identifier (AID) of ‘A0000001523010’.

2.1.1 EMV Transactions (Offline, Online or Deferred Authorization Transactions) EMV transactions conform to the EMV requirements supporting offline and online capabilities including the functionalities and commands for:

  • Selecting the application, initializing transaction processing, and reading records to obtain the application data items
  • Performing Cardholder Verification and Offline Data Authentication (ODA) for offline transactions
  • Enabling Processing Restrictions, Terminal Action Analysis, Online Processing, and Issuer Update Processing for online transactions, and
  • Supporting security parameters, including an optimized cryptographic process that enables the generation of an Application Cryptogram (AC) or Combined Dynamic Data Authentication / Application Cryptogram Generation (CDA) using the Unpredictable Number (UN) provided by the reader in the Processing Data Objects List (PDOL). Kernel 6 may optionally be configured to support Deferred Authorization for EMV transactions in environments where real time online authorization is not possible. Kernel 6 supports optional capabilities for Data Storage, Extended Logging and Tearing Recovery, where supported by the card. Unlike contact EMV-based transactions, the reader performs certain checks before the card enters the Radio Frequency (RF) field as specified in [EMV Book B] and after the card has left the RF field. Additional information regarding EMV transaction processing is provided in Section 1 of this Specification. v2.11

2.2 EMV Transaction Processing Flows The Kernel will initiate the EMV transaction when EMV is supported by the card and the transaction passes the required PDOL checks. Terminal entry point shall perform the pre-processing prior to the activation of the contactless interface of the reader and before the cardholder is invited to present a Contactless Card. Combination Selection shall be processed after card presentment. Because the interaction (i.e., the command-response) between the card and the Terminal can only occur when the card is in the RF field, the process requires adaptations to permit the:

  • Reduction of the number of commands and adjustment of the transaction flow for both the first and second presentment processes
  • Definition of data elements taking into account events relevant for contactless transactions
  • Usage of Entry Point as defined for [EMV Book B], to select the application and activate the corresponding Contactless Kernel 6
  • Optional identification of and recovery for torn contactless transactions
  • Optional retrieval of data items from on-card Data Storage before transaction initiation
  • Optional writing of data items to on-card Data Storage or Extended Logging during transaction initiation
  • Generation of a CDA Cryptogram or an Application Cryptogram during the transaction initiation
  • Execution of Terminal Risk Management before the card is placed in the field and after the card is removed from the field, and
  • If required, execution of cardholder verification after the card is removed from the field. Issuers may allow a Contactless Card to be presented a second time (via a second presentment) for updating application data or Data Storage. The need for a second presentment is determined by the contactless reader by checking for the presence of Issuer scripts included in the authorization request response and / or Data Storage data prepared by the Terminal. The reader shall store the fields that are required for a second presentment in transient memory as specified in [EMV Book B]. Entry Point uses this transient memory to select the Combination used in the previous Final Combination Selection to deliver the Issuer Update Processing commands and / or Data Storage updates. The EMV configuration uses the Outcome parameters defined in Annex B and provides data for online messages and clearing records. The EMV transaction flow is illustrated in Figure 2-1. The EMV Mode transaction flow with optional Data Storage is illustrated in Figure 2-2, and with optional Tearing Recovery in Figure 2-3. v2.11 Figure 2-1: Kernel 6 Contactless EMV Transaction Flow CARD READER Pre-Processing First presentment (first tap) List of Supported Applications Transaction-Specific Application Data* Terminal File Records Card in RF Field Command/ Response Optional Process Mandatory Process Entry Point Process Protocol Activation SELECT PPSE SELECT AID GET PROCESSING OPTIONS READ RECORD Combination Selection Initiate Application Processing Read Application Data Offline Data Authenticaiton Cardholder Verification Processing Restrictions Terminal Action Analysis Try Another interface Terminate Processing Second presentment (second tap) Selected Application Offline Completion SELECT AID Online Completion Entry Point Selection START B Processing Updates/ Scripts Issuer Script Issuer Update Processing *Transaction-Specific Application Data are provided in Table 4-4. v2.11 Figure 2-2: Kernel 6 Contactless EMV Transaction Flow with Data Storage CARD READER Pre-Processing First presentment (first tap) List of Supported Applications Data Storage Directory and Data Container data SELECT PPSE SELECT AID GET DATA READ RECORD Protocol Activation Combination Selection Read Data Storage Operator Processing* Transaction-specific and Data Container data (DATA) GET PROCESSING OPTIONS Initiate Application Processing Terminal File Records READ RECORD Read Application Data Card in RF Field Command/ Response Optional Process Mandatory Process Data Storage Process Entry Point Process Offline Completion Offline Data Authenticaiton Cardholder Verification Processing Restrictions Terminal Action Analysis Try Another interface Terminate Processing Online Completion Second presentment (second tap) Selected Application Processing Updates/ Scripts Data Container data SELECT AID Issuer Script PUT DATA Operator Processing* Entry Point Selection START B Issuer Update Processing Write Data Storage *Operator-specific business logic (terminal functionality). v2.11 Figure 2-3: Kernel 6 Contactless EMV Transaction Flow with Tearing Recovery CARD READER Pre-Processing First presentment (first tap) List of Supported Applications Transaction-Specific Application Data Terminal File Records SELECT PPSE SELECT AID GET PROCESSING OPTIONS READ RECORD Protocol Activation Combination Selection Initiate Application Processing Read Application Data Tearing Detected Resume first presentment (second tap) Selected Application Transaction-Specific Application Data Terminal File Records SELECT AID RESUME GET PROCESSING OPTIONS READ RECORD Card in RF Field Command/ Response Optional Process Mandatory Process Entry Point Process Tearing Recovery No Supported? Yes Entry Point Selection START B Initiate Application Processing Read Application Data Terminate Offline Data Authenticaiton Cardholder Verification Processing Restrictions Terminal Action Analysis Try Another interface Terminate Processing Second presentment (third tap) Selected Application Offline Completion SELECT AID Online Completion Entry Point Selection START B Processing Updates/ Scripts Issuer Script Issuer Update Processing Note: Tearing Recovery is also supported for EMV transactions using Data Storage. v2.11

2.3 Configuration, Functionality, and APDU Command Support Section Summary:

  • 2.3.1: POS System Configuration Options
  • 2.3.2: Functionality
  • 2.3.3: APDU Command Support 2.3.1 POS System Configuration Options The POS System Configuration options are used by the Kernel and must be set as described in [EMV Book A] and [EMV Book B]. In addition, the following configuration options are specific to Kernel 6. 1. Acceptance Environment: Reader will be enabled to support the EMV transactions 2. Kernel AID: Discover AIDs will be configured to be used with Kernel 6.

2.3.2 Functionality Specific Contactless functionalities are included in Table 2-1 and classified based on the following definitions:

  • Mandatory: This functionality must be present and must conform to the behavior described in this Specification
  • Conditional: The presence of the functionality is dependent on another function
  • Optional: This functionality must be present in the Terminal application but the Acquirer may choose not to use the function. Table 2-1: Contactless Functionality Function Entry Point Processing based on [EMV Book B] Kernel 6 Terminal Support Mandatory Combination Selection Post Processing Tearing Recovery Read Data Storage Operator Processing Mandatory Mandatory Mandatory Mandatory Initiate Application Processing Mandatory

Notes

The Terminal shall support Entry Point processing as defined in [EMV Book B] See Section 3.1: Combination Selection Post Processing Invocation of proprietary business logic for Data Storage or Extended Logging. If a data requested by the PDOL is not present in the Terminal, then the Terminal shall set the value to zeroes.

v2.11

Function Cardholder Verification Method (CVM)

  • Online PIN
  • Signature
  • Consumer Device CVM
  • No CVM Read Application Data
  • EMV Data in Terminal File records, identified by Short File Identifier (SFI) and record number Offline Data Authentication (ODA)
  • CDA Kernel 6 Terminal Support Conditional Conditional Conditional Processing Restrictions
  • Application Expiration Date
  • Application

Effective Date

  • Application Version Number
  • Application Usage Control*
  • Exception List Terminal Action Analysis Online Processing Mandatory Mandatory Conditional Completion
  • Offline
  • Online Issuer Update Processing
  • Application Block
  • Application Unblock
  • Put Data
  • Update Record Write Data Storage Mandatory Conditional Mandatory Notes Mandatory for EMV transactions except as determined by the payment system. Mandatory for Offline capable EMV readers Mandatory for Offline capable readers and Data Storage (must be performed before Termination Action Analysis) *Conditional – Mandatory for offline transactions Mandatory for Online capable EMV readers Mandatory for Online capable EMV readers 2.3.3 APDU Command Support The APDU commands included in Table 2-2 are designated as “Mandatory”, “Conditional”, or “Not supported” by the Contactless Kernel 6 Terminal based on the following definitions: v2.11
  • Mandatory: The command must be supported.
  • Conditional: The command shall be supported if the corresponding functionality is enabled
  • Not supported: The command is not supported. Table 2-2: APDU Command Support Command APPLICATION BLOCK APPLICATION UNBLOCK CARD BLOCK DATA GET PROCESSING OPTIONS EXTERNAL AUTHENTICATE GENERATE APPLICATION CRYPTOGRAM (AC) GET CHALLENGE GET DATA GET PROCESSING OPTIONS INTERNAL AUTHENTICATE PIN CHANGE / UNBLOCK PUT DATA READ RECORD RESUME GET PROCESSING OPTIONS SELECT UPDATE RECORD Kernel 6 Support Mandatory1 Mandatory1 Not supported Conditional2 Not Supported Not Supported Not Supported Mandatory Mandatory Not Supported Not Supported Mandatory1 Mandatory Conditional3 Mandatory Mandatory1 Notes: 1. Terminal to only pass supported Issuer Script commands to card. 2. Mandatory if Data Storage is supported. 3. Mandatory if Tearing Recovery is supported.

2.4 Deferred Authorization Deferred Authorization enables POS Systems to be used in environments where real time online authorization is not possible. With Deferred Authorization, when an EMV transaction requires online authorization (and after successful Offline Data Authentication) the Kernel will provide an Approved Outcome. The POS System or back-office may then request authorization at a later time. Notes:

v2.11

  • Even though real time online authorization is not used, Terminals shall request online cryptograms from cards (by setting TTQ B2b8 = ‘1’). Consequently, Terminals must be configured as online capable, with TTQ B1b4 = ‘0’ (Online capable contactless reader) and a Terminal Type (tag ‘9F35’) of “Online only” or “Offline with online capabilities”
  • Online PIN cardholder verification is not supported. Readers must be configured with TTQ B1b3 = ‘0’ (Online PIN not supported)
  • The reader must be configured to support Offline Data Authentication, with TTQ B1b1 = ‘1’ (ODA for online authorization supported), and
  • Issuer Update Processing is not supported, the reader must be configured with TTQ B3b8 = ‘0’ (Issuer update processing not supported).

2.5 Data Storage Data Storage provides transit operators, merchants, and other business entities (referred to generically as operators herein) with the ability to read and write custom merchant data on cards during EMV contactless transactions. Data Storage is an optional feature for card and terminal applications, and may be used as part of an EMV transaction when supported by both.

2.5.1 General Features Data Storage has the following features:

  • Use of on-card Data Containers, in which operators can store their own data. Three types of Data Container are supported:
  • Transient Containers – freely readable and writable by any operator
  • Operator Containers – freely readable and with write access for the allocated operator only, and
  • Issuer Containers – freely readable with issuer-only write access.
  • Use of Container IDs to uniquely identify and address individual Data Containers
  • Use of an on-card Data Storage Directory that records the allocation of Data Containers on the card. The Data Storage Directory is a dynamic data object (comprising a sequence of Directory Entries, one for each allocated Data Container) that can be read by operators using the GET DATA command
  • Mapping of Data Containers to card file records, allowing the retrieval of their contents by operators using the READ RECORD command
  • Use of Data Exchange by Kernel to invoke operator-specific* processing in the Terminal prior to Initiate Application Processing
  • Use of the DATA GET PROCESSING OPTIONS command (which extends the GET PROCESSING OPTIONS command) to update Data Container content during Initiate Application Processing
  • Optional use of the PUT DATA command by operators and issuers to update Data Container content during card second presentment
  • The capability for issuers to allocate Operator Containers to operators, either during card personalization or via issuer scripting v2.11
  • Use of Offline Data Authentication, container Write Counters and Integrity Codes for operators to authenticate cards and to guard against skimming or replay of container content. * The use of operator-specific logic is proprietary and is outside the scope of this specification.

2.5.2 Data Structure Overview Figure 2-4 shows the logical data structure used by the card for data storage. Summary data storage information is passed from card application to terminal as part of the application selection response. This information includes the version number, the number and location of records in the data store, and the card application’s unique identity. The Kernel can retrieve public Data Storage Directory information from the card using the GET DATA command. This comprises a sequence of Directory Entries, one for each allocated Data Container. A container’s Directory Entry identifies its Container ID, the record holding its content and other attributes. The Kernel can read a Data Container’s content using the READ RECORD command.

v2.11 Figure 2-4: Logical Data Storage Data Structure Data Storage info passed in SELECT FCI response Card Feature Version Number (tag ‘DF3A’) Version Number Card Feature Descriptor (tag ‘DF3B’) SFI of Data Store Number of Data Containers in Data Store Card ID

Private Card Directory Data Directory Entry 1 Update Code Timestamp Directory Entry 2 Update Code Timestamp Directory Entry n Update Code Timestamp References Data Storage Data Directory (tag ‘DF3D’) – read using GET DATA Directory Entry 1 Container ID Record Number Container Type Write Counter Integrity Code Directory Entry 2 Container ID Record Number Container Type Write Counter Integrity Code Directory Entry n Container ID Record Number Container Type Write Counter Integrity Code References Data Containers – read using READ RECORD, update using PUT DATA or DATA GET PROCESING OPTIONS Data Container 1 Data Container 2 Data Container n Contents (0-160 bytes) Contents (0-160 bytes) Contents (0-160 bytes) References 2.5.3 Data Containers A Data Container is a logical unit of data storage, addressable by its Container ID. A Data Container must be allocated on a card before an operator can use it to store data. During allocation a mapping is created on the card between the Container ID and the file record that stores the container’s content. There are three types of Data Container, all are freely readable but each have differing writeaccess and allocation approaches, as shown in Table 2-3.

v2.11

Table 2-3: Data Container Properties Property Allocation Read-access Write-access Data Container Type Transient Container Operator Container Issuer Container By card application By issuer By issuer Any operator Any operator Any operator Any operator and the issuer Allocated operator (using Update Codes) and the issuer only Issuer only Transient Containers are allocated as needed by the card application during a transaction at an operator’s terminal. The card will persist the contents of Transient Containers between transactions and until overwritten, either by the same operator, a different operator, or the issuer. When allocating Transient Containers, the card application will select either an unallocated Transient Container (if one is free), or the oldest of its allocated Transient Containers (overwriting its current Container ID and content). Operator Containers are allocated by the issuer, either during card personalization or via issuer scripting. An Operator Container may only be updated by the operator to which it is allocated or the issuer. Operator write-access is enforced using Update Codes; the card will update container content only when the correct Update Code is used by the operator (see below). Issuer Containers are allocated by the issuer, either during card personalization or via issuer scripting. Issuer Containers may only be updated by the issuer (via secure messaging). Card applications implementing data storage must be personalized with a minimum of three Transient Containers.

2.5.4 Operator Container Update Codes The card holds a hidden Update Code for each Operator Container, and will only allow an update to an Operator Container if the terminal can prove that it knows the same Update Code. This works as follows:

  • To update an Operator Container, the operator computes a hash over the data to be updated, data provided by the card application, and its copy of the Update Code. This hash value is called the Update Code Hash. The computed Update Code Hash is sent to the card application as part of the update request
  • The card application computes a hash over the same data items, but uses its copy of the Update Code
  • The card application then compares its computed Update Code Hash with the given Update Code Hash. If they do not match, then the update request will be rejected, otherwise the card will:
  • Write the new content into the container’s file record
  • Update the container’s Write Counter, Integrity Code and Timestamp. Operators may also replace the stored Update Code with a new value as part of the update, if required. The operator is free to use any suitable strategy for managing its Update Codes (see Annex E for guidance). Initial Update Code values must be agreed between operators and issuers. v2.11

2.5.5 Container Identifiers Each allocated Data Container is uniquely identified on a card by its Container ID. Only one Data Container may be allocated per Container ID per card. An operator may be assigned one or more Container IDs by the Data Storage Registration Authority. Any operator requiring simultaneous use of multiple Data Containers will require multiple Container IDs, one for each Data Container needed. The Container ID of zero (‘00000000’) is reserved and is used by card and terminal to indicate an unallocated Data Container. The Data Storage Registration Authority can assign shared Container IDs between operators. This allows groups of two or more operators to share the same Data Container. For example, a group of co-operating transit operators may each be assigned a unique Container ID for their own individual use, plus a shared Container ID for use as a group. The card and terminal make no explicit distinction between unique and shared Container IDs.

2.6 Extended Logging Extended Logging provides merchants with a simple mechanism for recording custom data in a card’s transaction log during EMV contactless transactions. If Extended Logging is enabled, the Kernel will use Data Exchange to invoke operator-specific* processing in the Terminal prior to performing Initiate Application Processing. The Terminal response may provide an Extended Logging Data (tag ‘DF3C’) data element. This data element can contain up to 32 bytes of custom data and, if provided, is appended to the GET PROCESSING OPTIONS command data. The card will include the data in its own transaction log. The card’s cyclic transaction log can be read later at a special terminal using the READ RECORD command. Support for Extended Logging is optional for card and Kernel, and shall be used only when supported by both. * The use of operator-specific logic is proprietary and is outside the scope of this specification.

2.7 Tearing Recovery For contactless transactions, interaction between card and reader can be interrupted if the card is removed prematurely from the RF field or when a protocol error occurs. This can result in “transaction tearing”, where the card and terminal have differing transaction outcomes. With Tearing Recovery, if an EMV transaction tears, the Kernel can invite the cardholder to present the card again. The Kernel may then request the card resume the previous transaction, rather than starting a new transaction. Support for Tearing Recovery is optional for card and Kernel, and shall be used only when supported by both.

2.7.1 Process Overview At the start of transaction processing, the Kernel determines if it needs to recover from a previous torn transaction or begin a new transaction.

v2.11

This begins with the Kernel examining the settings in the card’s optional Card Feature Descriptor to determine its support for Tearing Recovery and to extract its unique Card ID. To support Tearing Recovery, the Kernel keeps a record of transaction details in a Tearing Log; populating the log at the start of Initiate Application Processing, then emptying it at the end of successful Read Application Data processing. If the card supports Tearing Recovery and its Card ID matches that recorded in the Tearing Log, then:

  • The Kernel uses the transaction details recorded in the Tearing Log to send the RESUME GET PROCESSING OPTIONS (RESUME GPO) command to the card
  • The card compares the PDOL data with that of the previous GET PROCESSING OPTIONS (GPO) or DATA GET PROCESSING OPTIONS (DATA GPO) command (recorded in its own internal log), and:
  • If there is a match, the card returns the same response message as the previous GPO or DATA GPO command (without updating its CRM counters and accumulators, or incrementing ATC), or
  • If there is no match, the card processes the command as a new GPO or DATA GPO command (incrementing its ATC and updating CRM counters and accumulators). Else, the Kernel starts a new transaction, and:
  • Records the new transaction details in the Tearing Log (if Tearing Recovery enabled)
  • Sends the GPO or DATA GPO command to the card. If there is a timeout or transmission error during the Initiate Application Processing or Read Application Data processing steps, and the Tearing Log is not empty, then the Kernel can invite the cardholder to present the card again. Otherwise, the transaction can proceed and the Kernel can clear the Tearing Log. v2.11 3 Terminal Transaction Processing Steps This section addresses the Kernel 6 transaction processing requirements, including process flows, in the following sections:
  • 3.1: Combination Selection Post Processing
  • 3.2: Read Data Storage
  • 3.3: Initiate Application Processing
  • 3.4: Read Application Data
  • 3.5: Tearing Analysis
  • 3.6: Offline Data Authentication (ODA) for Offline Transactions
  • 3.7: Cardholder Verification
  • 3.8: Processing Restrictions
  • 3.9: Terminal Action Analysis
  • 3.10: Online Processing
  • 3.11: Completion
  • 3.12: Issuer Update Processing
  • 3.13: Write Data Storage Details on each APDU command referenced in this section are provided in Section 4, and additional information regarding Outcomes and Outcome Parameters are included in Annex B.

3.1 Combination Selection Post Processing The transaction starts in the Kernel at the handover from Entry Point, which has performed EMV transaction Pre-Processing, Protocol Activation, Combination Selection, and Kernel Activation), or After Kernel Activation, the selected Kernel must check the response sent by the card to the SELECT command. The operations to be performed to validate the answer sent by the card are illustrated in the following figures:

  • Figure 3-1: Processing Flow (Format Analysis)
  • Figure 3-2: Processing Flow (PDOL Mandatory Check)
  • Figure 3-3: Processing Flow (PDOL Optional Check)
  • Figure 3-4: Processing Flow (Optional Checks)
  • Figure 3-5: Processing Flow (Optional Feature Checks)
  • Figure 3-6: Processing Flow (Tearing Recovery Check) v2.11 Figure 3-1: EMV Application Selection – Processing Flow (Format Analysis) Answer to Final SELECT (1) Reset Data Storage Enabled, Extended Logging Enabled, and Tearing Recovery Enabled flags to false (2) Answer has No tag 84 ? Yes (3) Answer has No tag A5 ? Yes (4) Answer has No tag 50 ? Yes (5) Answer has No PDOL? Yes (7) Deferred Yes Authorization Supported ? No (6) Send Try Another Interface Outcome (8) Set TTQ B2b8 = 1 (Online cryptogram required) (9) PDOL Analysis # Description 1 Kernel shall reset its transient Data Storage Enabled, Extended Logging Enabled, and Tearing Recovery Enabled flags to false. 2 The Kernel shall begin the checks on the response received for the final SELECT command. Kernel shall check if “DF name” (tag ‘84’) of the application is provided by the card. If the tag is not present, then go to Step 6. Else continue. v2.11 # Description 3 Kernel shall check if FCI Proprietary Template (tag ‘A5’) is present. If the tag is not present, then go to Step 6. Else continue. 4 Kernel shall check if Application Label (tag ‘50’) is present in the answer provided by the card and is under tag ‘A5’. If the tag is not present as specified, then go to Step 6. Else continue. 5 Kernel shall check if Processing Options Data Object List (PDOL) (tag ‘9F38’) is present in the answer provided by the card and is under tag ‘A5’. If the tag is not present as specified, then go to Step 6. Else go to Step 7. 6 Kernel shall send the Outcome as ‘Try Another Interface’ to request the use of another interface (if one is supported) to the Entry Point. 7 Kernel shall check if it is configured for Deferred Authorizations (true if ‘Deferred Authorization Supported’ flag is present and set to ‘1’). If yes, go to Step 8. Else go to Step 9. 8 Terminal shall indicate in the TTQ that it wishes to process the transaction online (by setting the TTQ B2b8 = ‘1’) 9 Kernel shall go to Figure 3-2 to perform PDOL Analysis. v2.11 Figure 3-2: EMV Application Selection – Processing Flow (PDOL Mandatory Check) PDOL Analysis (1) TTQ requested and length = Yes (2) Amount Authorized requested and length = Yes (3) Amount Others requested and length = Yes (4) Terminal Country code requested and length = Yes (5) Transaction Currency Code requested and length = Yes (6) Transaction Date requested and length = Yes (7) Transaction Type requested and length = Yes (8a) UN requested No No No No No No No No Yes (9) Other Interface Supported? No Terminate Yes (10) Send a Try Another Interface Outcome No (8b) UN length = Optional Yes PDOL checks v2.11 # Description 1 Kernel shall check if the card requests a TTQ (tag ‘9F66’) with a length of 4 bytes. If the TTQ is not requested or the TTQ length is different from 4, then the Kernel shall go to Step 9. 2 Kernel shall check if the card requests Amount Authorized (tag ‘9F02’) with a length of 6 bytes. If Amount Authorized is not requested or the Amount Authorized length is not equal to 6, then the Kernel shall go to Step 9. 3 Kernel shall check if the card requests Amount Other (tag ‘9F03’) with a length of 6 bytes. If Amount Others is not requested or the Amount Others length is not equal to 6, then the Kernel shall go to Step 9. 4 Kernel shall check if the card requests Terminal Country Code (tag ‘9F1A’) with a length of 2 bytes. If Terminal Country Code is not requested or the Terminal Country Code length is not equal to 2, then the Kernel shall go to Step 9. 5 Kernel shall check if the card requests Transaction Currency Code (tag ‘5F2A’) with a length of 2 bytes. If the transaction Currency Code is not requested or the Transaction Currency Code length is not equal to 2, then the Kernel shall go to Step 9. 6 Kernel shall check if the card requests Transaction Date (tag ‘9A’) with a length of 3 bytes. If the Transaction Date is not requested or the Transaction Date length is not equal to 3, then the Kernel shall go to Step 9. 7 Kernel shall check if the card requests Transaction Type (tag ‘9C’) with a length of 1 byte. If the Transaction Type is not requested or the Transaction Type length is not equal to 1, then the Kernel shall go to Step 9. 8 a. Kernel shall check if the card requests Unpredictable Number (UN) (tag ‘9F37’). If not present, the Kernel shall go to Step 9. b. Kernel will check for UN length of ‘04’ bytes. If yes, the Transaction will go to Figure 3-3 to perform optional PDOL checks. If no, go to Step 9. Note: If the UN is not requested or the UN length is not correct, then the Kernel shall go to Step 9. 9 Kernel shall check if it supports another interface.
  • If Terminal does not support another interface, the Terminal shall terminate the transaction with ‘End Application’ (for Processing Error) Outcome. ELSE go to Step 10. 10 If another interface is supported by the Terminal, the Kernel shall provide the Outcome ‘Try Another Interface’ to Entry Point. v2.11 Figure 3-3: EMV Application Selection – Processing Flow (PDOL Optional Check) Optional PDOL checks (1) Additional PDOL No element? Yes (3) Fill in PDOL with length of ‘00’ No (2) Known tag? requested by card Optional checks Yes (5) Fill in PDOL (4) Length = with data found Yes length available? No (7) Add padding bytes to reach the Yes length requested (6) Length > length available No (8) Fill in PDOL with truncated bytes to fit the length requested # Description 1 Kernel shall check if the PDOL requested by the card contains additional data to be sent with the GET PROCESSING OPTION. If… Then… Yes Go to Step 2. No Go to Figure 3-4 to perform optional checks. 2 Kernel verifies if the data element requested by the card is a Discover D-PAS tag or EMV tag. If… Then… Yes Go to Step 4. No Go to Step 3. v2.11 # Description 3 If the requested data is unknown by the Kernel, the Kernel shall add the number of ‘00’ bytes requested by the card to data that will be sent to the card. Then, go to Step 1. 4 Kernel shall check If the length requested by the card concerning the known element is equal to the length available in the Kernel. If… Then… Yes Go to Step 5. No Go to Step 6. 5 Kernel inserts requested data into the PDOL that will be sent to the card. Then, go to Step 1. 6 Kernel checks if the length requested by the PDOL entry is greater than the length of available data inside the Kernel. If… Then… Yes Go to Step 7. No Go to Step 8. 7 Kernel shall add padding bytes (as per [EMV Book 3] Section 5.4 pa

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