PCI Watch

Tracking changes across the Payment Card Industry

SB nº 237: Update for EMV® Book C-2 (Version 2.8) – CDA

v1.0 Specification Bulletins
Contactless Acceptance Device

EMV<sup>®</sup> Specification Bulletin No. 237 First Edition February 2020 Update for EMV Book C-2 (Version 2.8) – CDA This Specification Bulletin contains modifications for Book C-2 to optimize transactions without CDA.

Applicability

This Specification Bulletin applies to:

  • EMV Contactless Specifications for Payment Systems, Book C-2, Kernel 2 Specification, Version 2.8, March 2019

Related Documents

None

Effective Date

April 1st, 2020

Description

This Specification Bulletin describes the following updates to EMV Book C-2: 1. Optimize performance of State 4 in case CDA is not performed. Processing has been changed to read only records that are necessary for completing the transaction without CDA. Activation or not of the optimisation is configurable. 2. Change Procedure – Prepare Generate AC Command to no longer automatically request an AAC when CDCVM is performed without CDA.

countries.

Proposed Specification Changes Change 3.2 Kernel configuration Options Change second paragraph as follows: Kernel 2 supports seven eight configuration options. Add new row to Table 3.2 as follows: Deactivate optimisation when no CDA The Kernel always reads all the records referenced in the AFL for transactions without CDA. Through the setting of 'Read all records even when no CDA' in Kernel Configuration.

countries.

Change New section 3.11 Add new section as follows:

3.11 Optimisation For Transactions Without CDA 3.11.1

Introduction

When CDA is not used for a transaction, the transaction may be sped up if the public key certificates are not read from the card. If CDA is not used for a transaction, the Kernel stops reading records from the Card as soon as the minimum data required for the transaction are retrieved. If the Card data are carefully stored in the records, then reading the public key certificates is avoided, speeding up the transaction. However, in some circumstances, it may be desirable to always read all the records referenced in the AFL. So, this optimisation can be deactivated by configuration.

3.11.2 Activation/Deactivation When 'Read all records even when no CDA' is set in the Kernel Configuration, the Kernel always reads all the records referenced in the AFL. When 'Read all records even when no CDA' is not set in the Kernel Configuration and if the transaction is without CDA, the Kernel stops reading the records referenced in the AFL as soon as the minimum data required for the transaction are retrieved.

countries.

Change 6.8 State 4 – Waiting for EMV Read Record Response Change the diagram of s4 – waiting for EMV read record response in Figure 6.7 as follows:

  • Introduce new symbols S4.36, S4.37 and S4.38.
  • Move symbols S4.15 to S4.23 to the end of the diagram after S4.38.
  • Delete symbol S4.26
  • Delete State 4' countries. Figure 6.7—State 4 Flow Diagram S4 1 14 Update Active AFL 24 Parse response Update TLV Database Yes 29 Parse CDOL1 Update Data Needed 25 Parsing OK? No Yes 28 CDOL1 included in record? No 2 27.1 Prepare UI Request (Other Card) 27.2 OUT (end application) Exit kernel - countries. S4 - 2 30 DSDOL included in record? No No Yes Yes 31 IDS Read Flag set ? Yes 32 Slot locked ? No 33 Parse DSDOL Update Data Needed 34 CDA Flag set AND Signed Flag set? No Yes 35 Include record in Static Data To Be Authenticated 3 countries. S4 3 36 CDA Flag set OR Yes 'Read all records even when no CDA' in Kernel Configuration is set ? No 37 All data present No to continue without CDA? Yes 38 Set Active AFL equal to empty AFL 4 - countries. S4 4 Yes 16 Prepare GET DATA 17 CA (GET DATA) 18 Next Cmd:= GET DATA 15 GET DATA to be done? No 19 Active AFL empty? Yes 20 Next Cmd:= NONE No 21 Prepare READ RECORD 22 CA (READ RECORD) 23 Next Cmd:= READ RECORD A S456 countries. Change processing of State 4 in section 6.8.3 as follows: […] S4.14 Sfi:= SFI of first record in Active AFL Remove first record from Active AFL S4.15 Active Tag:= GetNextGetDataTagFromList (Tags To Read Yet) IF [Active Tag is not NULL] THEN GOTO S4.16 ELSE GOTO S4.19 ENDIF S4.16 Prepare GET DATA command for Active Tag as specified in section 5.5 S4.17 Send CA(GET DATA command) Signal S4.18 'Next Cmd' in Next Cmd:= GET DATA S4.19 IF [Active AFL is empty] THEN GOTO S4.20 ELSE GOTO S4.21 ENDIF S4.20 'Next Cmd' in Next Cmd:= NONE S4.21 Prepare READ RECORD command for first record in Active AFL as specified in section 5.8 S4.22 Send CA(READ RECORD command) Signal S4.23 'Next Cmd' in Next Cmd:= READ RECORD countries. S4.24 IF [Sfi ≤ 10] THEN IF [(Length of Record &gt; 0) AND (Record[1] = '70')] THEN Parsing Result:= ParseAndStoreCardResponse(Record) ELSE Parsing Result:= FALSE ENDIF ELSE Processing of records in proprietary files is beyond the scope of this specification ENDIF S4.25 IF [Parsing Result] THEN GOTO S4.28 ELSE GOTO S4.26S4.27.1 ENDIF S4.26 IF ['Next Cmd' in Next Cmd = NONE] THEN GOTO S4.27.1 ELSE GOTO s4' – terminate on next RA ENDIF S4.27.1 'Message Identifier' in User Interface Request Data:= ERROR – OTHER CARD 'Status' in User Interface Request Data:= NOT READY […] S4.36 IF ['CDA' in ODA Status is set OR 'Read all records even when no CDA' in Kernel Configuration is set] THEN GOTO S4.15 ELSE GOTO S4.37 ENDIF countries. S4.37 IF [IsNotEmpty(TagOf(Application Expiration Date)) AND IsNotEmpty(TagOf(Application PAN)) AND IsNotEmpty(TagOf(Application PAN Sequence Number)) AND IsNotEmpty(TagOf(Application Usage Control)) AND IsNotEmpty(TagOf(CVM List)) AND IsNotEmpty(TagOf(Issuer Action Code – Default)) AND IsNotEmpty(TagOf(Issuer Action Code – Denial)) AND IsNotEmpty(TagOf(Issuer Action Code – Online)) AND IsNotEmpty(TagOf(Issuer Country Code)) AND IsNotEmpty(TagOf(Track 2 Equivalent Data)) AND IsNotEmpty(TagOf(CDOL1))] THEN GOTO S4.38 ELSE GOTO S4.15 ENDIF S4.38 Set Active AFL equal to empty AFL S4.15 Active Tag:= GetNextGetDataTagFromList (Tags To Read Yet) IF [Active Tag is not NULL] THEN GOTO S4.16 ELSE GOTO S4.19 ENDIF S4.16 Prepare GET DATA command for Active Tag as specified in section 5.5 S4.17 Send CA(GET DATA command) Signal S4.18 'Next Cmd' in Next Cmd:= GET DATA GOTO S456.1 S4.19 IF [Active AFL is empty] THEN GOTO S4.20 ELSE GOTO S4.21 ENDIF S4.20 'Next Cmd' in Next Cmd:= NONE GOTO S456.1 S4.21 Prepare READ RECORD command for first record in Active AFL as specified in section 5.8 countries. S4.22 Send CA(READ RECORD command) Signal S4.23 'Next Cmd' in Next Cmd:= READ RECORD GOTO S456.1 countries. Change 7.6 Procedure – Prepare Generate AC Command Change symbol GAC.20 from the diagram of Prepare Generate AC Command in Figure 7.6 as follows: Figure 7.6—Prepare Generate AC Command Flow Diagram GAC No IDS B IDS Read only C 20 No CDA Flag set? CDA Failed Yes 21 D CDA failed in No TVR set? Yes 22 On device No cardholder verification supported? Yes 23 AC Type:= AAC 26 Set AC Type in Ref Control Param Do not request CDA in Ref Control Param 24 AC Type = AAC? No Yes 25 CDA supported over TC, ARQC and Yes AAC? No 27 Set AC Type in Ref Control Param Request CDA in Ref Control Param 3 countries. Change processing of Prepare Generate AC command in section 7.6.3 as follows: […] GAC.20 IF ['CDA' in ODA Status is set] THEN GOTO GAC.21 ELSE GOTO GAC.26GAC.22 ENDIF […] countries. Change Add new configuration option in Kernel Configuration in Annex A Data Dictionary (section A.1.91) as follows: Byte 1 b8 b7 b6 b5 b4 b3 b2-1 Kernel Configuration Mag-stripe mode contactless transactions not supported EMV mode contactless transactions not supported On device cardholder verification supported Relay resistance protocol supported Reserved for Payment system Read all records even when no CDA Each bit RFU Change Add new bit definition in Terminal Risk Management Data in Annex A Data Dictionary (section A.1.167) as follows: Byte 3 8 Mag-stripe mode contactless transactions not supported 7 EMV mode contactless transactions not supported 6 CDCVM without CDA supported 5-1 RFU countries.

Legal Notice

Unless the user has an applicable separate agreement with EMVCo or with the applicable payment system, any and all uses of these Specifications is subject to the terms and conditions of the EMVCo Terms of Use agreement available at www.emvco.com and the following supplemental terms and conditions. Except as otherwise may be expressly provided in a separate agreement with EMVCo, the license granted in the EMVCo Terms of Use specifically excludes (a) the right to disclose, distribute or publicly display these Specifications or otherwise make these Specifications available to any third party, and (b) the right to make, use, sell, offer for sale, or import any software or hardware that practices, in whole or in part, these Specifications. Further, EMVCo does not grant any right to use the Kernel Specifications to develop contactless payment applications designed for use on a Card (or components of such applications). As used in these supplemental terms and conditions, the term "Card" means a proximity integrated circuit card or other device containing an integrated circuit chip designed to facilitate contactless payment transactions. Additionally, a Card may include a contact interface and/or magnetic stripe used to facilitate payment transactions. To use the Specifications to develop contactless payment applications designed for use on a Card (or components of such applications), please contact the applicable payment system. To use the Specifications to develop or manufacture products, or in any other manner not provided in the EMVCo Terms of Use, please contact EMVCo. These 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 these 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 these 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 these Specifications.

countries.