PCI Watch

Tracking changes across the Payment Card Industry

SB nº 170: Errata for EMV® Book C-2 (Version 2.5) (Spec Change)

v1.0 Specification Bulletins
Contactless

Specification Bulletin No. 170 June 2015 Errata for EMV Book C-2 (Version 2.5) This Specification Bulletin contains modifications for EMV Book C-2.

Applicability

This Specification Bulletin applies to: EMV Contactless Specifications for Payment Systems, Book C-2, Kernel 2 Specification, Version 2.5, March 2015 This Specification Bulletin is an integral part of Book C-2 version 2.5 and is effective immediately.

Related Documents

None

Summary

This Specification Bulletin describes the following changes to EMV Book C-2: 1- a modification to the Kernel processing in several states, concerning the display of messages on the user interface 2- a modification to the default configuration data values found in the Kernel TLV database 3- a correction to the Kernel processing in State R1 (step SR1.5) to handle communication errors in the response from the cardholder device 4- a correction to the detailed processing description of State R1 (step SR1.15) to align with the state diagram regarding the parsing of the response from the cardholder device 5- a clarification concerning timing latency in State R1 (step SR1.18) 6- a correction to the state diagram of State R1 (steps SR1.24-27) to align with the detailed processing description regarding the starting of the RRP timer 7- a modification to the definition of the Relay Resistance Accuracy Threshold data object

http://www.emvco.com.

1. User Interface Display Messages When messages are sent to the reader display, a Hold Time is specified in the message signal sent by the Kernel. The Hold Time parameter ensures that the message is held on screen for a minimum length of time to allow it to be read by the cardholder before being over-written by a subsequent message. In certain error situations, the user is invited to attempt the transaction with another card through an appropriate message (e.g. "Try Another Card"). However in several cases the message is sent with a Hold Time of zero. The message is therefore almost immediately replaced as the Reader enters its removal sequence, displaying "Remove Card". This bulletin modifies the processing to ensure that the "Try Another Card" message is displayed for a sufficient length of time. The underlined sentence is added to the processing steps listed below: Message Identifier' in User Interface Request Data:= ERROR – OTHER CARD 'Status' in User Interface Request Data:= NOT READY 'Hold Time' in User Interface Request Data:= Message Hold Time

  • S910.50
  • S910.61
  • S11.90
  • S11.101
  • S13.32
  • S14.42 A similar change is made in the error handling for States 1, 2, 3, 4, 5, 6, 7, and 8 that is described in section 4.7: 'Message Identifier' in User Interface Request Data:= ERROR – OTHER CARD 'Status' in User Interface Request Data:= NOT READY 'Hold Time' in User Interface Request Data:= Message Hold Time 'Status' in Outcome Parameter Set:= END APPLICATION 'Msg On Error' in Error Indication:= ERROR – OTHER CARD Initialize(Discretionary Data) AddToList(GetTLV(TagOf(Error Indication)), Discretionary Data) SET 'UI Request on Outcome Present' in Outcome Parameter Set Send OUT(GetTLV(TagOf(Outcome Parameter Set)), GetTLV(TagOf(Discretionary Data)), GetTLV(TagOf(User Interface Request Data))) Signal http://www.emvco.com. 2. Configuration Data Default Values In Table 4.3—Configuration Data in TLV Database that Require Default Value, the default values indicated for the following data objects are changed as shown: Terminal Expected Transmission Time For Relay Resistance C-APDU Terminal Expected Transmission Time For Relay Resistance R-APDU '00120B' '00180D' http://www.emvco.com. 3. Communication Error in State R1 The Kernel processing in the event of a communication error in state SR1 is modified as follows: SR1 sR1 – waiting for exchange relay resistance data response 1 DET 9 RA 3 L1RSP 6 STOP 2 Update TLV Database 10 Stop Timer Compute Time Taken sR1 – waiting for exchange relay resistance data response 4 Stop Timer 5.1 Prepare UI Request (Try Again) 5.2 OUT (end application) 7 Stop Timer 8 OUT (end application) 11 SW12 = '9000' No Exit kernel Yes 14 Parse response Update TLV Database 12 Prepare UI Request (Other Card) 13 OUT (end application) 1 Exit kernel http://www.emvco.com. SR1.5 'Status' in Outcome Parameter Set:= TRY AGAIN 'Start' in Outcome Parameter Set:= B 'L1' in Error Indication:= Return Code CreateEMVDiscretionaryData () Send OUT(GetTLV(TagOf(Outcome Parameter Set)), GetTLV(TagOf(Discretionary Data))) Signal SR1.5.1 'Message Identifier' in User Interface Request Data:= TRY AGAIN 'Status' in User Interface Request Data:= READY TO READ 'Hold Time' in User Interface Request Data:= '000000' SR1.5.2 'Status' in Outcome Parameter Set:= END APPLICATION 'Start' in Outcome Parameter Set:= B SET 'UI Request on Restart Present' in Outcome Parameter Set 'L1' in Error Indication:= Return Code 'Msg On Error' in Error Indication:= TRY AGAIN CreateEMVDiscretionaryData () Send OUT(GetTLV(TagOf(Outcome Parameter Set)), GetTLV(TagOf(Discretionary Data)), GetTLV(TagOf(User Interface Request Data))) Signal http://www.emvco.com. 4. Parsing the Response to the Exchange Relay Resistance Data Command To align with the flow chart covering steps SR1.15-18, the detailed processing description is modified as follows: SR1.15 IF [Parsing Result] THEN GOTO SR1.16 SR1.18 ELSE GOTO SR1.18 SR1.16 ENDIF 5. Clarification of timing latency in State R1 The underlined text below is added to step SR1.18. SR1.18 Measured Relay Resistance Processing Time:= (Time Taken / 100) – Terminal Expected Transmission Time For Relay Resistance C-APDU – MIN (Device Estimated Transmission Time For Relay Resistance R-APDU, Terminal Expected Transmission Time For Relay Resistance R-APDU) Note that the implementation should compensate for any known fixed timing latency. All implementations will have some inevitable delay between starting the timer and sending the C-APDU and between receiving the R-APDU and stopping the timer. If this latency is predictable and can be compensated for by the implementation then it does not need to be compensated by increasing the maximum grace period. http://www.emvco.com. 6. Starting the RRP timer in State R1 To align with the detailed processing flow description, the flow chart covering steps SR1.24 to SR1.27 is replaced with the following: SR1 2 24 Increment RRP Counter 25 Prepare EXCHANGE RELAY RESISTANCE DATA command 26 Start Timer 27 CA (EXCHANGE RELAY RESISTANCE DATA) sR1 - waiting for exchange relay resistance data response http://www.emvco.com. 7. Definition of Relay Resistance Accuracy Threshold The definition of the Relay Resistance Accuracy Threshold in the Data Dictionary in Annex A is corrected as shown below: Relay Resistance Accuracy Threshold Tag: Template: Length: Format: Update: Description: 'DF8136' — 2 b K Represents the threshold above which the Kernel considers the variation between Measured Relay Resistance Processing Time and Max Min Time For Processing Relay Resistance APDU no longer acceptable. The Relay Resistance Accuracy Threshold is expressed in units of hundreds of microseconds. http://www.emvco.com.