PayPass M/Chip Flex - cardzone.czdata.cardzone.cz/contactless/PayPass - MChip Flex... · PayPass – M/Chip Flex application on a card or acceptance device. This document is also

PayPass – M/Chip Flex Technical Specifications

Version 1.1 – October 2006

Version 1.1 - October 2006 © 2006 MasterCard 2 PayPass – M/Chip Flex Technical Specifications

Proprietary and Confidential

Copyright The information contained in this manual is proprietary and

confidential to MasterCard and its members.

This material may not be duplicated, published, or disclosed, in whole or in part, without the prior written permission of MasterCard.

Media This document is available in both electronic and printed format.

MasterCard Worldwide - CCOE

Chaussée de Tervuren, 198A B-1410 Waterloo Belgium E-mail: [email protected]

Table of Contents

© 2006 MasterCard Version 1.1 - October 2006 PayPass – M/Chip Flex Technical Specifications 3 Proprietary and Confidential

Using this Manual ................................................................................. 9

Scope ...........................................................................................................................9

Audience......................................................................................................................9

Related Publications ....................................................................................................9

Abbreviations ............................................................................................................11

Notational Conventions .............................................................................................12

Specification Principles .............................................................................................13

1 Introduction .............................................................................. 15

1.1 Overview..........................................................................................................15

1.2 Offline Counters...............................................................................................16

1.3 Co-application..................................................................................................16

2 Co-application Interface .......................................................... 17

2.1 Overview..........................................................................................................17

2.2 PayPass Options Indicator ..............................................................................17

2.3 Co-application Interoperability Requirements.................................................19 2.3.1 POI Control.......................................................................................................19 2.3.2 Update Limits of Offline Counters....................................................................20

3 State Machine........................................................................... 21

3.1 Signals and Transitions ....................................................................................21

3.2 Application States ............................................................................................22

3.3 Variables ..........................................................................................................24

4 Signal Processing.................................................................... 27

4.1 Overview..........................................................................................................27

4.2 C-APDU Recognition ......................................................................................32 4.2.1 Input ..................................................................................................................32 4.2.2 Processing .........................................................................................................33 4.2.3 Output................................................................................................................34

4.3 C-APDU Acceptance .......................................................................................35 4.3.1 Input ..................................................................................................................35 4.3.2 Processing .........................................................................................................36 4.3.3 Output................................................................................................................37

4.4 Rejected C-APDU Processing .........................................................................37 4.4.1 Input ..................................................................................................................37

Table of Contents



4.4.2 Processing .........................................................................................................38 4.4.3 Data Field Returned in the Response Message .................................................39 4.4.4 Destination State ...............................................................................................39

4.5 SELECT Signal Processing .............................................................................40 4.5.1 Processing .........................................................................................................40 4.5.2 Data Field Returned in the Response Message .................................................44 4.5.3 Destination State ...............................................................................................44

4.6 UNSELECT Processing...................................................................................45 4.6.1 Processing .........................................................................................................45 4.6.2 Destination State ...............................................................................................46

4.7 C-APDU Processing ........................................................................................47

5 C-APDU Processing................................................................. 49

5.1 COMPUTE CRYPTOGRAPHIC CHECKSUM ...........................................................49 5.1.1 Command Message ...........................................................................................49 5.1.2 Processing .........................................................................................................49 5.1.3 Data Field Returned in the Response Message .................................................51 5.1.4 Destination State ...............................................................................................51

5.2 GENERATE APPLICATION CRYPTOGRAM...........................................................52 5.2.1 Command Message ...........................................................................................52 5.2.2 Processing .........................................................................................................53 5.2.3 Data Field Returned in the Response Message .................................................75 5.2.4 Destination State ...............................................................................................75

5.3 GET DATA.........................................................................................................76 5.3.1 Command Message ...........................................................................................76 5.3.2 Processing .........................................................................................................77 5.3.3 Data Field Returned in the Response Message .................................................79 5.3.4 Destination State ...............................................................................................79

5.4 GET PROCESSING OPTIONS ...............................................................................80 5.4.1 Command Message ...........................................................................................80 5.4.2 Processing .........................................................................................................81 5.4.3 Data Field Returned in the Response Message .................................................83 5.4.4 Destination State ...............................................................................................83

5.5 READ RECORD ..................................................................................................84 5.5.1 Command Message ...........................................................................................84 5.5.2 Processing .........................................................................................................85 5.5.3 Data Field Returned in the Response Message .................................................87 5.5.4 Destination State ...............................................................................................87

5.6 SELECT .............................................................................................................88 5.6.1 Command Message ...........................................................................................88 5.6.2 Processing .........................................................................................................89

Table of Contents


5.6.3 Data Field Returned in the Response Message .................................................89 5.6.4 Destination State ...............................................................................................89

6 Cryptographic Algorithms and Key Management................. 91

6.1 Application Cryptogram Generation................................................................91

6.2 Dynamic CVC3 Generation.............................................................................92

6.3 IVCVC3 Generation .........................................................................................93

6.4 Symmetric Keys for Application Cryptogram Generation ..............................93 6.4.1 M/Chip 2.05, M/Chip Lite 2.1...........................................................................93 6.4.2 CCD ..................................................................................................................94 6.4.3 UKIS .................................................................................................................94

6.5 ICC Derived Key for CVC3 Generation (KDCVC3)..........................................95

6.6 MAC Algorithm...............................................................................................95

7 Data Elements Location .......................................................... 97

7.1 Transient Data Elements that Exist Beyond a Single C-APDU ......................97

7.2 Persistent Data Elements..................................................................................99

7.3 Secret Keys ....................................................................................................103

8 Personalization ...................................................................... 105

8.1 Application Selection Data Elements ............................................................105

8.2 COMPUTE CRYPTOGRAPHIC CHECKSUM Data Objects ...................................105

8.3 Persistent Data Referenced in the AFL ..........................................................106

8.4 Persistent Data Elements for GPO Response.................................................108

8.5 Persistent Data Elements for CRM................................................................109

8.6 Secret Keys ....................................................................................................109

8.7 Miscellaneous ................................................................................................110

8.8 Counters and Previous Transaction History ..................................................110

8.9 Data Elements with a Fixed Initial Value ......................................................111

Annex A : Data Elements Dictionary ............................................... 113

A.1 AC Session Key Counter ...............................................................................113

A.2 AC Session Key Counter Limit .....................................................................113

A.3 Additional Check Table .................................................................................113

A.4 Application Control .......................................................................................114

A.5 Application Life Cycle Data ..........................................................................116

Table of Contents



A.6 Application Transaction Counter...................................................................117

A.7 Application Transaction Counter Limit .........................................................117

A.8 Card Issuer Action Code – Decline, Default, Online.....................................117

A.9 Card Verification Results...............................................................................120

A.10 CDOL 1..........................................................................................................125

A.11 CDOL 1 Related Data Length........................................................................125

A.12 Co-application Indicator ................................................................................126

A.13 Consecutive Offline Transactions Number....................................................126

A.14 Counters .........................................................................................................126

A.15 CRM Country Code .......................................................................................127

A.16 CRM Currency Code .....................................................................................127

A.17 Cryptogram Information Data........................................................................127

A.18 Cryptogram Version Number ........................................................................127

A.19 Cumulative Offline Transaction Amount ......................................................128

A.20 Currency Conversion Parameters ..................................................................128

A.21 Currency Conversion Table ...........................................................................128

A.22 CVR – CCD ...................................................................................................129

A.23 CVR - M/Chip 2.05 .......................................................................................132

A.24 CVR - M/Chip Lite 2.1 ..................................................................................135

A.25 CVR - UKIS...................................................................................................138

A.26 File Control Information ................................................................................140

A.27 Issuer Application Data (CCD)......................................................................141

A.28 Issuer Application Data (M/Chip 2.05) .........................................................141

A.29 Issuer Application Data (M/Chip Lite 2.1) ....................................................142

A.30 Issuer Application Data (UKIS).....................................................................142

A.31 IVCVC3TRACK1...............................................................................................143

A.32 IVCVC3TRACK2...............................................................................................143

A.33 Key Derivation Index.....................................................................................143

A.34 Lower Consecutive Offline Limit ..................................................................143

A.35 Lower Cumulative Offline Transaction Amount...........................................143

A.36 Offline Balance ..............................................................................................144

A.37 Offline Consecutive Transactions Remaining ...............................................144

A.38 Previous Transaction History.........................................................................144

Table of Contents


A.39 Security Limits...............................................................................................145

A.40 Security Limits Status ....................................................................................146

A.41 Static CVC3TRACK1.........................................................................................146

A.42 Static CVC3TRACK2.........................................................................................146

A.43 Upper Consecutive Offline Limit ..................................................................147

A.44 Upper Cumulative Offline Transaction Amount ...........................................147

Annex B : Currency Conversion...................................................... 149

B.1 Currency Conversion Process ........................................................................149

B.2 Currency Conversion Parameters ..................................................................150

B.3 Currency Conversion Algorithm....................................................................151

Annex C : CVR Mapping Tables....................................................... 153

C.1 CVR Mapping Table for M/Chip 2.05...........................................................154

C.2 CVR Mapping Table for M/Chip Lite 2.1 .....................................................155

C.3 CVR Mapping Table for CCD.......................................................................156

C.4 CVR Mapping Table for UKIS......................................................................157

Annex D : Additional Check Table................................................... 159

Table of Contents



Using this Manual Scope


Using this Manual This chapter contains information that helps you understand and use this document.

Scope MasterCard PayPass™ technology enables fast, easy and globally accepted payments through the use of contactless chip technology on the traditional MasterCard card platform. PayPass – M/Chip Flex is designed specifically for authorization networks that presently support chip card authorizations for credit or debit applications.

PayPass – M/Chip Flex is an independent contactless application intended to reside on a dual interface card together with an implementation of a choice of several supported contact-based EMV applications (M/Chip 2.05, M/Chip Lite 2.1, CCD, UKIS Compliant Payment Application).

Audience This document is intended for use by vendors that want to implement the MasterCard PayPass – M/Chip Flex application on a card or acceptance device.

This document is also intended for type approval services, which would test the actual implementations against this specification.

It is assumed that the audience already has an understanding of chip card technology in general and of M/Chip 4 and ISO/IEC 14443 in particular.

Related Publications The following publications contain information directly related to the contents of this specification.

[PAYPASS MCHIP] PayPass – M/Chip Technical Specification

[PAYPASS ISO/IEC 14443] PayPass – ISO/IEC 14443 Implementation Specification

[M/CHIP4] M/Chip 4 Card Application Specifications for Credit and Debit

[SECURITY] M/Chip 4 Cryptography & Key Management v4.0

Using this Manual Related Publications



[ISO/IEC 8825:1990] Information technology – Open systems interconnection – Specification of basic encoding rules for abstract syntax notation one (ASN.1)

[ISO/IEC 7811/2] Identification cards – Recording technique – Part 2: Magnetic stripe

[ISO/IEC 7813:1995] Identification cards – Financial transaction cards

[ISO/IEC 7816-4:1995] Information technology – Identification cards – Integrated circuit(s) cards with contacts - Part 4: Interindustry commands for interchange

[ISO/IEC 7816-5:1993] Identification cards – Integrated circuit(s) cards with contacts – Part 5: Numbering system and registration procedure for application identifiers

[ISO/IEC 7816-6:1996] Identification cards – Integrated circuit(s) cards with contacts – Part 6: Interindustry data elements

[EMV BOOK 1] Integrated Circuit Card Specification for Payment Systems: Application Independent ICC to Terminal Interface Requirements. Version 4.1, May 2004

[EMV BOOK 2] Integrated Circuit Card Specification for Payment Systems: Security and Key Management. Version 4.1, May 2004

[EMV BOOK 3] Integrated Circuit Card Specification for Payment Systems: Application Specification. Version 4.1, May 2004

[EMV BOOK 4] Integrated Circuit Card Specification for Payment Systems: Cardholder, Attendant and Acquirer Interface Requirements. Version 4.1, May 2004

Using this Manual Abbreviations


Abbreviations The following abbreviations are used in this specification:

Abbreviation Description AAC Application Authentication Cryptogram

AC Application Cryptogram

ADF Application Definition File

AFL Application File Locator

AID Application Identifier

AIP Application Interchange Profile

an Alphanumeric characters

ans Alphanumeric and Special characters

APDU Application Protocol Data Unit

ARQC Authorization Request Cryptogram

ATC Application Transaction Counter

b Binary

BER Basic Encoding Rules

CDA Combined DDA / Application Cryptogram Generation

CDOL Card Risk Management Data Object List

CIAC Card Issuer Action Code

CID Cryptogram Information Data

CRM Card Risk Management

CVR Card Verification Results

DDA Dynamic Data Authentication

DDOL Dynamic Data Authentication Data Object List

DEA Data Encryption Algorithm

DES Data Encryption Standard

EMV Europay MasterCard Visa

FCI File Control Information

IAD Issuer Application Data

ICC Integrated Circuit Card

MAC Message Authentication Code

MKAC AC Master Key

MKIDN ICC Dynamic Number Master Key

n Numeric characters NIC Length of the ICC Public Key Modulus

PAN Primary Account Number

PDOL Processing Options Data Object List

PIN Personal Identification Number

Using this Manual Notational Conventions



Abbreviation Description POI PayPass Options Indicator

RFU Reserved for Future Use

SDA Static Data Authentication

SFI Short File Identifier

SHA Secure Hash Algorithm

SW1- SW2, SW12 Status bytes 1-2

TC Transaction Certificate

TLV Tag Length Value

TVR Terminal Verification Results

var. Variable

Notational Conventions The following notations apply:

Notation Description ‘0’ to ‘9’ and ‘A’ to ‘F’ Hexadecimal notation. Values expressed in hexadecimal form are

enclosed in single quotes (i.e. ‘_’). 1001b Binary notation. Values expressed in binary form are followed by a

lower case “b”. “abcd” an or ans string digit Any of the ten Arabic numerals from 0 to 9 […] Optional part xx Any value A := B A is assigned the value of B. C := (A || B) The concatenation of an n-bit number A and an m bit number B,

which is defined as C = 2mA + B. Y := ALG(K)[X] Encipherment of a 64-bit data block X with a 64-bit block cipher

using a secret key K. X & Y The bit-wise and of the data blocks X and Y X | Y The bit-wise or of the data blocks X and Y Application File Locator Data elements used for this specification are written in italics to

distinguish them from the text.

STATE States are written in COURIER FONT to distinguish them from the text.

GENERATE AC Command APDUs used for this specification are written in SMALL CAPITALS to distinguish them from the text.

Using this Manual Specification Principles


Specification Principles In this document, the PayPass – M/Chip Flex application is specified according to the following principles:

• The application is a state machine.

• The processing of an external signal (e.g. C-APDU) causes a transition between states.

Note These principles are used in order to present the application concepts. These principles do not need to be followed in the implementation. However, the implementation must behave in a way that is indistinguishable from the behavior specified in this document.

The Type Approval service tests an implementation against the behavior specified in this document. The Type Approval service treats the card application as a black box and validates the output signals that the application generates as a result of processing of input signals, against the output signals defined by these specifications.

Using this Manual Specification Principles



IntroductionOverview


1 Introduction

1.1 Overview PayPass – M/Chip Flex is a contactless chip card application which resides on a dual interface card which also carries a second payment application. The second application (referred to in this document as the ‘co-application’) uses the contact interface. Only co-applications from an approved list can be used with PayPass – M/Chip Flex.

PayPass – M/Chip Flex has the following characteristics:

• It only uses the contactless interface of the dual-interface card.

• It has an internal interface to the co-application in order to exchange information.

• It supports the PayPass – Mag Stripe functionality to ensure acceptance on a PayPass – Mag Stripe only terminal.

• It supports only one co-application at a time. The PayPass – M/Chip Flex application must be configured for a specific co-application during personalization.

• It is able to store a complete set of cryptographic keys to perform transactions compatible with any supported co-application.

• It supports all the cryptographic algorithms and key derivation mechanisms used by any supported co-application.

• It provides a mechanism for selecting the appropriate cryptographic algorithm or key derivation mechanism, depending on the co-application.

• It supports SDA and (optionally) CDA. The support of CDA is an implementation option.

• It performs Card Risk Management using the Card Verification Results as specified for the M/Chip 4 application. Additionally, for each supported co-application the relevant CVR is added to the PayPass – M/Chip Flex application. During processing of the first GENERATE AC command, the Card Verification Results of the PayPass – M/Chip Flex application is mapped on the CVR of the active co-application.

PayPass – M/Chip Flex does not support the following: • Transaction logging • Encryption of counters • DDA • Application Cryptograms of type AAR • PDOL processing • Issuer-to-card script processing • Second GENERATE AC command.

Introduction Offline Counters



1.2 Offline Counters The Consecutive Offline Transactions Number and the Cumulative Offline Transaction Amount are referred to as offline counters in this specification.

These counters are used to monitor and control offline spending, and in EMV payment cards they are reset when the application receives a valid issuer response to an online authorization request.

The PayPass – M/Chip Flex application does not support the second GENERATE AC command which would normally reset the offline counters, because during a PayPass – M/Chip Flex transaction, the card is removed after the first GENERATE AC command. The offline counters can therefore only be reset by the co-application using the contact interface.

Additionally, the PayPass – M/Chip Flex application provides a mechanism to force the co-application to go online at the next contact transaction whenever one of the offline counters exceeds its lower limit. The issuer is then able to reset the offline counters for both applications.

1.3 Co-application The interface between the PayPass – M/Chip Flex application and the issuer host is controlled by the co-application. PayPass – M/Chip Flex properties which are dependant on the co-application are fixed during personalization by defining the Co-application Indicator. By checking the Co-application Indicator, the PayPass – M/Chip Flex application can recognize the active co-application, and can then create responses compliant with the issuer host interface.

The following co-applications are supported:

• M/Chip 2.05

• M/Chip Lite 2.1

• CCD-compliant application

• UKIS Compliant Payment Application

Co-application InterfaceOverview


2 Co-application Interface

2.1 Overview A PayPass – M/Chip Flex transaction is completed by returning a response to the first GENERATE AC command or to the COMPUTE CRYPTOGRAPHIC CHECKSUM command. As neither online processing nor issuer-to-card script processing is supported, there is a mechanism to allow issuers to control PayPass – M/Chip Flex offline counters by using the co-application. The offline counters must be reset by the issuer after exceeding their predefined limits, in order to allow the card to continue to make offline transactions.

2.2 PayPass Options Indicator A new data element, PayPass Options Indicator (POI), has been added to the card data.

In order to ensure security and integrity of the application data, direct exchange of data between applications on a single card is not recommended. The new data element therefore belongs neither to the PayPass – M/Chip Flex application nor to the co-application. The POI may only be accessed by the PayPass – M/Chip Flex application and the co-application, and not by any other application which may be present on the card.

The coding of the PayPass Options Indicator is shown in Table 2.1.

Table 2.1—PayPass Options Indicator Coding

b8 b7 b6 b5 b4 b3 b2 b1 Meaning

x x x x x RFU

1 Block PayPass – M/Chip Flex application

1 Go online on next transaction

1 Reset PayPass – M/Chip Flex offline counters

Note The details of the mechanism for accessing and protecting the POI are proprietary to the card implementer. MasterCard will perform a security evaluation of the access mechanism as part of the CAST program.

Co-application Interface PayPass Options Indicator



Instructions from the issuer to reset PayPass – M/Chip Flex offline counters are transmitted during an online contact transaction using the second GENERATE AC command. Figure 2.1 shows an overview of this offline counters reset mechanism.

Figure 2.1—Offline Counters Reset Mechanism Overview

Issuer Host

Terminal

T=0/T=1 T=CL

Dual Interface Card

POI

Co-application PayPass – M/Chip Flex Application

Offline CountersOffline Counters

Read/Write Read/WriteReset Offline

Counters

2nd GENERATE AC

Co-application InterfaceCo-application Interoperability Requirements


2.3 Co-application Interoperability Requirements

2.3.1 POI Control Before responding to the first GENERATE AC command, the co-application must read the 'Go online on next transaction' indicator (POI [2]):

If POI [2] = 1b, then:

• If the terminal is online capable, then the co-application must request to go online.

• If the terminal is offline only, then no further action is required by the co-application.

To reset the offline counters of the PayPass – M/Chip Flex application, the following must be performed by the co-application:

• Set the 'Reset PayPass – M/Chip Flex offline counters' bit in the POI:

SAVE POI [1] (1b)

• Reset the 'Go online on next transaction' bit in the POI:

SAVE POI [2] (0b)

Note How the co-application decides to reset the offline counters of the PayPass – M/Chip Flex application depends on the rules defined by the individual payment products and is outside the scope of this specification.

If the co-application receives the script command APPLICATION BLOCK, then the co-application must set the 'Block PayPass – M/Chip Flex application' bit in the POI:

SAVE POI [3] (1b)

If the co-application receives the script command UNBLOCK APPLICATION, then the co-application must reset the 'Block PayPass – M/Chip Flex application' bit in the POI:

SAVE POI [3] (0b)

Note The POI mechanism specified in this chapter follows a set of general design principles. Implementers deviating from these principles must make sure that their implementation behaves in a way that is indistinguishable from the behavior specified in this document.

Co-application Interface Co-application Interoperability Requirements



2.3.2 Update Limits of Offline Counters Updating the limits of the offline counters of the PayPass – M/Chip Flex application must be done by sending script commands to the co-application. The actual script commands are proprietary to the co-application (e.g. PUT DATA, UPDATE RECORD).

The limits of the offline counters of the PayPass – M/Chip Flex application must be identified to the co-application by the following tag values:

Table 2.2—Tag Values for Updating Limits of Offline Counters

Tag Limit

‘DF0A’ Lower Consecutive Offline Limit

‘DF0B’ Lower Cumulative Offline Transaction Amount

‘DF0C’ Upper Consecutive Offline Limit

‘DF0D’ Upper Cumulative Offline Transaction Amount

If the co-application receives a script command to update a limit of an offline counter of the PayPass – M/Chip Flex application, then the co-application must map the tag received in the script command on the tag that is used by the PayPass – M/Chip Flex application to identify this offline counter limit, and then the co-application must update the limit.

How the co-application obtains access to the limits of the offline counters of the PayPass – M/Chip Flex application is implementation specific.

State MachineSignals and Transitions


3 State Machine

3.1 Signals and Transitions When the application has been personalized and is being used in live operation, its behavior can be specified as an Extended Finite State Machine (EFSM). Using this model, transitions between states are triggered by the reception of signals which may convey values.

Signals conveying values are used to represent the reception of C-APDUs, i.e. of application-layer data units. When the ICC receives a C-APDU in the input buffer, an internal application-layer signal is sent to the PayPass – M/Chip Flex application, which then processes the C-APDU.

As a result of C-APDU processing the application generates a response. The model for sending responses is also that of transmitting application-layer signals, i.e. of R-APDUs.

Apart from C-APDUs, there are also external signals which do not convey values but which change the application state. These are the SELECT and UNSELECT signals:

• The SELECT signal is used to activate the PayPass – M/Chip Flex application.

• The UNSELECT signal is used to de-activate the PayPass – M/Chip Flex application.

Conditions which trigger the UNSELECT signal and thereby lead to the de-activation of the PayPass – M/Chip Flex application, are:

1. Selection of another application, in the case of a multi-application card

2. Reset

3. Power off of the ICC

When processing triggered by reception of an application-layer signal is completed, the application reaches a destination state.

State Machine Application States



3.2 Application States The application states of the PayPass – M/Chip Flex application are listed in Table 3.1.

Table 3.1—Application States of the PayPass – M/Chip Flex Application

State Description IDLE Application is not currently selected SELECTED Application is selected INITIATED Transaction is initiated

The PayPass – M/Chip Flex application is in state IDLE if it is not currently activated. In a multi-application card for instance, the application may be in state IDLE if another application is activated. The application also goes to the state IDLE when the card is reset or powered off.

In the state IDLE the application does not process C-APDUs, but is only waiting for an external SELECT signal. The technical signal processing mechanism depends on card platform and card operating system and is outside the scope of this specification. Successful processing of the SELECT signal changes the application state from IDLE to SELECTED.

Every transaction starts in the state SELECTED. There are four C-APDUs handled by the PayPass – M/Chip Flex application in this state:

• GET PROCESSING OPTIONS

• GET DATA

• READ RECORD

• SELECT

The PayPass – M/Chip Flex application goes to state INITIATED after the successful processing of the GET PROCESSING OPTIONS command. In this state, a new transaction is initiated. There are five C-APDUs handled by the PayPass – M/Chip Flex application in the INITIATED state:

• GET DATA

• READ RECORD

• SELECT

• COMPUTE CRYPTOGRAPHIC CHECKSUM

• GENERATE AC

The GET DATA and the READ RECORD command do not modify the application state, whether used in the state SELECTED or in the state INITIATED. The SELECT command is only present for compatibility reasons. Refer to Section 5.6 for details.

State MachineApplication States


The PayPass – M/Chip Flex application goes back from the state INITIATED to the state SELECTED:

• After the successful processing of the COMPUTE CRYPTOGRAPHIC CHECKSUM command

• After the successful processing of the first GENERATE AC command. The second GENERATE AC command is not supported by the PayPass – M/Chip Flex application.

Figure 3.1 illustrates the state transitions supported by the PayPass – M/Chip Flex application.

Figure 3.1—State Machine of the PayPass – M/Chip Flex Application

SELECTED

IDLE ERROR

SELECT signal processing

SELECTREAD RECORDGET DATAERROR

GET PROCESSING OPTIONS

SELECT

COMPUTE CRYPTOGRAPHIC CHECKSUM

GENERATE ACERROR

READ RECORDGET DATA

INITIATED

State Machine Variables



3.3 Variables An Extended Finite State Machine uses state variables for maintaining its history. In this specification state variables are called “data elements”. There are two kinds of data elements described in this document:

• Data elements with a lifetime exceeding a single card session (“persistent” data elements)

• Data elements with a lifetime that does not exceed a single card session (“transient” data elements)

Persistent data elements must be stored in non-volatile memory (e.g. EEPROM). Transient data elements are generally stored in volatile memory (e.g. RAM), although this is not mandated.

Refer to Section 7.2 for an identification of persistent data elements. Any modification of the value of a persistent data element is explicitly specified with the word SAVE. For instance

SAVE Var1(new value)

means that the new value of Var1 is written in non-volatile memory.

The other data elements used in this specification are transient. The lifetime of a transient data element is defined as the period where the value of the data element is accessible, in either read or write mode.

The “creation” of a transient data element is explicitly specified with the word NEW. The initial value is then specified. For instance

NEW Var1(’00…000’)

means that the data element Var1 becomes accessible and has its initial value set to all zeros. Only one instance of a data element exists at a time in the PayPass – M/Chip Flex application.

When a specific value is assigned to a transient data element, it is specified with the words SET or RESET or the symbol ‘:=’. The value is then specified. For instance

SET Var1(’00…000’)

means that the zero value is assigned to the data element Var1.

There is no difference between SET, RESET or ‘:=’. The RESET is only used to emphasize that the data element takes back its initial value. This is generally a value of all zeros. In figures the symbol ‘:=’ is used for convenience.

The destruction of a transient data element is explicitly specified with the word FREE. For instance

FREE Var1

means that the value of Var1 will no longer be used.

State MachineVariables


This specification identifies two types of transient data elements:

• Transient data elements with a lifetime that does not exceed the processing of a single C-APDU. For brevity, these data elements are not explicitly created or killed (using NEW and FREE) in this document.

• Transient data elements with a lifetime that does exceed the processing of a single C-APDU. Their creation and destruction using NEW and FREE are shown explicitly in this document.

It is acceptable to create and kill transient data elements at other points in time, as far as the external behavior of the application is indistinguishable from the behavior specified in this document.

Section 7.1 specifies the use of transient data elements with a lifetime spanning a single C-APDU processing throughout the application. This information can be used to decide when to create and kill the data elements in the implementation.

Table 3.2 lists the conventions used for data element manipulation.

Table 3.2—Conventions used for Data Element Manipulation

Operation Persistent Transient

create - NEW

kill - FREE

assign SAVE SET, RESET, ‘:=’

State Machine Variables



Signal ProcessingOverview


4 Signal Processing

4.1 Overview The PayPass – M/Chip Flex application can reside in either a multi-application environment or in a mono-application environment without changing its behavior. Depending on the ICC platform there will be an internal interface between the PayPass – M/Chip Flex application and a 'lower level' ICC processing unit. This unit can be the card operating system or a sub-unit controlled by the card operating system, e.g. a multi-application manager. For ease of use a common term - card manager - has been chosen for this entity.

The card manager controls the PayPass – M/Chip Flex application by sending signals via the internal interface. The application state determines which signals are accepted by the PayPass – M/Chip Flex application.

When the PayPass – M/Chip Flex application is in the state IDLE, the only signal accepted from the card manager is the SELECT signal.

When the PayPass – M/Chip Flex application is active (i.e. the application state is SELECTED or INITIATED), the signals that it accepts from the card manager are:

1. The SELECT signal After successful processing of an incoming SELECT signal the PayPass – M/Chip Flex application is activated, i.e. the application goes from the state IDLE to the state SELECTED. If the application receives the SELECT signal in a state other than IDLE, the application, already activated, stays in or goes back to the state SELECTED.

2. A string of bytes representing a card command (i.e. a C-APDU) Any C-APDU received by the card when the PayPass – M/Chip Flex application is active will lead to one of the following behaviors:

• If the C-APDU is recognized by the card manager as a SELECT command of the PayPass – M/Chip Flex application, the card manager sends the SELECT signal to the PayPass – M/Chip Flex application.

• If the C-APDU leads to the selection of another application on the card (in the case of a multi-application environment), the UNSELECT signal is sent to the PayPass – M/Chip Flex application.

• If the C-APDU is not a SELECT command, and does not lead to the selection of an application on the card, then the C-APDU is sent to the PayPass – M/Chip Flex application as a CARD COMMAND.

It is assumed in this specification that the card manager would not send a C-APDU to the application if the bytes received do not contain a valid C-APDU header, so a CARD COMMAND has the following characteristic:

Length (CARD COMMAND) >= 4.

Signal Processing Overview



3. The UNSELECT signal The PayPass – M/Chip Flex application is de-activated through the UNSELECT signal. Any event leading to an application state transition with destination state IDLE triggers the UNSELECT signal.

Table 4.1 lists the valid signals depending on the application state.

Table 4.1—Signals sent by the Card Manager

Application State IDLE SELECTED, INITIATED

Valid signals SELECT SELECT, CARD COMMAND, UNSELECT

Note The use of the SELECT, CARD COMMAND, UNSELECT signals is an abstraction which, in a real card, can be implemented in various ways.

Figure 4.1 illustrates the overall processing of signals. The following sections of this chapter describe in more detail the different functions referenced in Figure 4.1.



Figure 4.1—Processing Signals

42'

5

0

initial state

signal1

C-APDU Recognition

4

signal reception

signal analysis

C-APDU Acceptance

other

4

blocked ?

2CARD

COMMAND signal

blocked ?

2''

SELECT signal

UNSELECT signal

6

BAD CLABAD INS

BAD LENGTH

6'

accepted

3

initial stateno no no

yes

yes

yes

no

yes

C-APDU Processing

8

UNSELECTProcessing

11

RejectedC-APDU Processing

7

10

response

12

final state

SELECTProcessing

9signal processing

yes

Signal Processing Overview



Symbol 0, 1 The application receives external signals in any of its states. The current application state determines which signals are accepted by the PayPass – M/Chip Flex application, as shown in Table 4.1.

Symbol 2 This type of signal carries a string of bytes called CARD COMMAND or C-APDU. A CARD COMMAND has the following characteristic: Length (CARD COMMAND) >= 4. It is assumed in this specification that the card manager will not send a C-APDU to the application if the bytes received do not contain a valid C-APDU header. A CARD COMMAND will pass a recognition process called C-APDU Recognition. C-APDU Recognition transforms input bytes sent by the card manager into C-APDU literals recognized by the PayPass – M/Chip Flex application. Basically, the application checks that the bytes received represent a C-APDU supported by the application. C-APDU Recognition for PayPass – M/Chip Flex is specified as a procedure and described in Section 4.2.

Symbol 2' To activate the PayPass – M/Chip Flex application, the card manager sends a SELECT signal. The activation of the PayPass – M/Chip Flex application (i.e. the processing triggered by the SELECT signal) is specified in Section 4.5.

Symbol 2'' The PayPass – M/Chip Flex application can be de-activated by the card manager, e.g. if another application is selected in a multi-application environment. The PayPass – M/Chip Flex application is also de-activated if the card is reset or powered off. The signals resulting from these events are gathered under the generic name UNSELECT.

Symbol 3 Any other signal is ignored. The PayPass – M/Chip Flex application returns to the state IDLE.

Symbol 4 C-APDUs received from the card manager are first checked against recognized C-APDUs. This is specified in Section 4.2.

Symbol 5 Further processing depends on the results of the C-APDU Recognition procedure.

Symbol 6 C-APDUs are only accepted if the PayPass – M/Chip Flex application is in a state where the C-APDU is allowed to be processed. The C-APDU Acceptance procedure is specified in Section 4.3.

Symbol 6' Further processing depends on the results of the C-APDU Acceptance procedure.



Symbol 7 C-APDUs not supported or C-APDUs received when the PayPass – M/Chip Flex application is in an inconsistent state are rejected by the application. The processing of rejected C-APDUs is specified in Section 4.4.

Symbol 8 An accepted C-APDU is processed by the application. The processing of accepted C-APDUs is specified in Section 4.7.

Symbol 9 SELECT Processing is specified in Section 4.5.

Symbol 10 The application response may be either an R-APDU, or may consist only of SW1-SW2.

Symbol 11 When the PayPass – M/Chip Flex application is de-activated, the transient data elements are destroyed. UNSELECT processing is specified in Section 4.6.

Symbol 12 When the processing of an external signal is terminated, the application goes to a destination state. The destination state depends on both the signal that has been processed and the original state (i.e. the application state when the signal was received). The destination state is specified in the sections dedicated to the processing of each signal.

Signal Processing C-APDU Recognition



4.2 C-APDU Recognition The C-APDU Recognition procedure identifies the C-APDU transmitted by the terminal to the PayPass – M/Chip Flex application via the card manager. Recognition is based on the CLA and INS byte. The PayPass – M/Chip Flex application only supports the CLA and INS bytes specified in Table 4.2.

The C-APDU Recognition procedure takes the CLA and INS bytes as input and produces as output the literals specified in the third column of Table 4.2.

If the CLA byte of the C-APDU is not one of those listed in Table 4.2, then the C-APDU Recognition procedure returns BAD CLA.

If the CLA byte is listed in Table 4.2, but the combination of the CLA and INS byte is not, then the C-APDU Recognition procedure returns BAD INS.

Table 4.2—C-APDU Recognition

CLA INS C-APDU ‘80’ ‘2A’ COMPUTE CRYPTOGRAPHIC CHECKSUM ‘80’ ‘AE’ GENERATE AC ‘80’ ‘CA’ GET DATA ‘80’ ‘A8’ GET PROCESSING OPTIONS ‘00’ ‘B2’ READ RECORD ‘00’ ‘A4’ SELECT

Furthermore, when the application has recognized the C-APDU, it must perform a validity check on the following: • Consistency between Lc and the length of data sent • Le

These checks are protocol dependent and cannot be specified independently from the transport layer. As a result, they are not described in the C-APDU Recognition processing flow. However, when the validity check detects an error in the lengths, the output of the procedure C-APDU Recognition is BAD LENGTH.

If the output of the C-APDU Recognition is BAD CLA, BAD INS or BAD LENGTH, the C-APDU is not supported by the PayPass – M/Chip Flex application.

4.2.1 Input Input to the procedure C-APDU Recognition is a string of bytes - CARD COMMAND - with the following characteristics:

Length (CARD COMMAND) >= 4.

Signal ProcessingC-APDU Recognition


4.2.2 Processing C-APDU Recognition processing is performed according to Figure 4.2.

Figure 4.2—C-APDU Recognition Processing

2

CLA = '00'

4

READ RECORD

3

INS = 'A8'4

GET PROC.. OPT.

4

GEN. AC

4

GET DATA

2

CLA = '80'

4

BAD INS

4

BAD INS

4

BAD CLA

4

SELECT

4

COMP. CRYPT. CHECKSUM

3

INS = 'AE'

3

INS = 'CA'

3

INS = '2A'

3

INS = 'B2'

3

INS = 'A4'

yes

yes

yes

yes

yes

else

no

yes

yes

yes

else

else

Symbol 2

The CLA byte is checked.

Symbol 3

The INS byte is checked.

Symbol 4

The result of the CLA byte check and INS byte check is mapped on an output literal.

Signal Processing C-APDU Recognition



4.2.3 Output The output of the procedure can be one of the following literals:

READ RECORD



GENERATE AC

SELECT

GET DATA

BAD CLA

BAD INS

BAD LENGTH

Signal ProcessingC-APDU Acceptance


4.3 C-APDU Acceptance The C-APDU Acceptance procedure checks whether the PayPass – M/Chip Flex application is in a valid state to process the C-APDU currently received. Acceptance or rejection of a C-APDU is specified in Table 4.3.

If the C-APDU is accepted in the current application state (P: Processed), then the C-APDU is processed as specified in the particular section of Chapter 5 dedicated to the C-APDU.

If the C-APDU is rejected in the current state (R/CNS: Rejected, Conditions Not Satisfied), then further processing is specified in Section 4.4.

Table 4.3—Acceptance Matrix

COMMAND SELECTED INITIATED COMPUTE CRYPTOGRAPHIC CHECKSUM R/CNS P GENERATE AC R/CNS P GET PROCESSING OPTIONS P R/CNS READ RECORD P P SELECT P P GET DATA P P

4.3.1 Input Input to this procedure is the result of the C-APDU Recognition procedure, i.e. one of the following literals:

READ RECORD



GENERATE AC

SELECT

GET DATA

Signal Processing C-APDU Acceptance



4.3.2 Processing C-APDU Acceptance processing is performed according to Figure 4.3.

Figure 4.3—C-APDU Acceptance Processing

2state =

INITIATED

3C-APDU =

READ RECORD

2state =

SELECTED

R / CNS

3C-APDU = GET DATA

3C-APDU =

GPO

3C-APDU =

SELECT

yes

yes

yes

yes

yes

else

no

yes

P

3C-APDU =

READ RECORD

R / CNS

3C-APDU =GET DATA

3C-APDU =

CCC

3C-APDU =

GENERATE AC

yes

yes

yes

yes

else

P

3C-APDU =

SELECTyes

R / CNS

else

Signal ProcessingRejected C-APDU Processing


Symbol 2

The PayPass – M/Chip Flex application checks whether it is in a valid state to process C-APDUs.

Symbol 3

The C-APDU currently received is compared to the C-APDUs accepted for processing in the current application state. Depending on the result the decision is P (Process) or R/CNS (Reject, Conditions Not Satisfied).

4.3.3 Output Output of the procedure can be one of the following literals:

P (Process)

R/CNS (Reject, Conditions Not Satisfied)

4.4 Rejected C-APDU Processing A C-APDU can be rejected for the following two reasons:

1. The bytes received are not recognized as a supported C-APDU, for one of the following reasons:

• The CLA and INS bytes do not correspond to a C-APDU supported by the PayPass – M/Chip Flex application. In this case the C-APDU is rejected in the procedure C-APDU Recognition, with one of the following reasons: BAD CLA or BAD INS.

• There is an error relating to the lengths of the data. In this case the C-APDU is rejected in the procedure C-APDU Recognition, with the reason BAD LENGTH.

2. The C-APDU is supported by the PayPass – M/Chip Flex application, but the application is in a state where the C-APDU is not accepted. In this case the C-APDU is rejected in the procedure C-APDU Acceptance, with the reason R/CNS.

4.4.1 Input Input to the procedure is one of the following literals:

BAD CLA

BAD INS

BAD LENGTH

R/CNS (Rejected, Conditions not Satisfied)

Signal Processing Rejected C-APDU Processing



4.4.2 Processing Rejected C-APDU Processing is performed according to Figure 4.4.

Figure 4.4—Rejected C-APDU Processing

3

BAD CLA

3

BAD INS

3BAD

LENGTH

yes

yes

yes

else

reset transient data

2

R / CNS

SW1-SW2='6E00'

SW1-SW2='6D00'

SW1-SW2='6700'

SW1-SW2='6985'

Symbol 2

The transaction related transient data elements are reset:

• RESET CDOL 1 Related Data (‘00..00’)

• RESET Card Verification Results (‘00...00’)

• RESET Amount, Authorised (‘00...00’)

• RESET Amount, Other (‘00…00’)

• RESET Terminal Country Code (‘0000’)

• RESET Transaction Currency Code (‘0000’)

• RESET Transaction Date (‘00...00’)

• RESET Transaction Type (‘00’)

• RESET Data Authentication Code (’0000’)

Signal ProcessingRejected C-APDU Processing


• RESET First AC (‘00...00’)

• RESET AC Session Key (’00…00’)

• RESET ICC Dynamic Number(‘00...00’) (if CDA supported)

• If Co-application Indicator [2-1] = 10b (co-application UKIS is active), then RESET CVR-UKIS (‘00...00’)

• If Co-application Indicator [2-1] = 11b (co-application CCD-compliant is active), then RESET CVR-CCD (‘00...00’)

• If Co-application Indicator [2-1] = 01b (co-application M/Chip 2.05 is active), then RESET CVR-M/Chip 2.05 (‘00...00’)

• If Co-application Indicator [2-1] = 00b (co-application M/Chip Lite 2.1 is active), then RESET CVR-M/Chip Lite 2.1 (‘00...00’)

Symbol 3

The error literal ( the reason for performing Rejected C-APDU Processing) is converted to the appropriate values of SW1-SW2.

4.4.3 Data Field Returned in the Response Message Response consists only of SW1-SW2.

4.4.4 Destination State Table 4.4 lists the destination states after Rejected C-APDU Processing.

Table 4.4—Destination State after Rejected C-APDU Processing

SW1 SW2 SELECTED INITIATED ‘6E’ ‘00’ SELECTED SELECTED ‘6D’ ‘00’ SELECTED SELECTED ‘67’ ‘00’ SELECTED SELECTED ‘69’ ‘85’ SELECTED SELECTED

Other SELECTED SELECTED

Signal Processing SELECT Signal Processing



4.5 SELECT Signal Processing

4.5.1 Processing The processing of the PayPass – M/Chip Flex application when a SELECT signal is received varies depending on the application state. If the application is in state IDLE, then the application behavior is specified in Section 4.5.1.1. If the application is in any other state (SELECTED, INITIATED), then its behavior is specified in Section 4.5.1.2.

Note Do not confuse the terms 'SELECT signal' and ' SELECT command'. The SELECT signal is a card level trigger signal whereas the SELECT command is processed by the application during C-APDU processing.

4.5.1.1 Flow, SELECT Processing, Application in State IDLE

Figure 4.5—SELECT Processing, Application in State IDLE

resp:=FCIsw12:=' 6283'

5

blocked ?


new transient data

4

1

POI [1] = 1b

reset offline counters

2

no

yes

yes no

update PTH

3

Signal ProcessingSELECT Signal Processing


Symbol 1

The 'Reset PayPass – M/Chip Flex offline counters' bit in the POI is checked.

Symbol 2

If the 'Reset PayPass – M/Chip Flex offline counters' bit in the POI is set (i.e. if POI [1] = 1b), then first the offline counters are reset in non-volatile memory:

• SAVE Cumulative Offline Transaction Amount (’00…00’)

• SAVE Consecutive Offline Transactions Number (’00’)

Secondly, the 'Reset PayPass – M/Chip Flex offline counters' bit in the POI is reset:

• SAVE POI [1] (0b)

Symbol 3

Copy the 'Block PayPass – M/Chip Flex application' bit in the POI (i.e. PayPass Options Indicator [3]) to the 'Block application' bit in the Previous Transaction History:

SAVE Previous Transaction History [5] (PayPass Options Indicator [3])

Symbol 4

The transaction related transient data elements are created:

• NEW CDOL 1 Related Data (‘00..00’)

• NEW Card Verification Results (‘00...00’)

• NEW Amount, Authorised (‘00...00’)

• NEW Amount, Other (‘00…00’)

• NEW Terminal Country Code (‘0000’)

• NEW Transaction Currency Code (‘0000’)

• NEW Transaction Date (‘00...00’)

• NEW Transaction Type (‘00’)

• NEW Data Authentication Code (’0000’)

• NEW ICC Dynamic Number (’00…00’) (if CDA supported)

• NEW First AC (‘00...00’)

• NEW AC Session Key (’00…00’)

• If Co-application Indicator [2-1] = 10b (co-application UKIS is active), then NEW CVR-UKIS (‘00...00’)

• If Co-application Indicator [2-1] = 11b (co-application CCD-compliant is active), then NEW CVR-CCD (‘00...00’)

• If Co-application Indicator [2-1] = 01b (co-application M/Chip 2.05 is active), then NEW CVR-M/Chip 2.05 (‘00...00’)

• If Co-application Indicator [2-1] = 00b (co-application M/Chip Lite 2.1 is active), then NEW CVR-M/Chip Lite 2.1 (‘00...00’)




Note This step corresponds to the creation of all the transient data elements whose existence extends beyond the processing of a single C-APDU. It is possible to create these data elements during the processing of other C-APDUs, without changing the external behavior of the PayPass – M/Chip Flex application. This is allowed since it is undetectable by Type Approval services. Section 7.1 gives information about the usage of these transient data elements throughout the PayPass – M/Chip Flex application.

Symbol 5

If the application is blocked (i.e. if Previous Transaction History [5] =1b), then the application will return with the FCI and SW1-SW2=’6283’, otherwise (i.e. if Previous Transaction History [5] = 0b), the application will return with the FCI and SW1-SW2=’9000’.

4.5.1.2 Flow, SELECT Processing, Application in State SELECTED or INITIATED

Figure 4.6—SELECT Processing, Application in State SELECTED or INITIATED

yes


1

blocked?no



0

Signal ProcessingSELECT Signal Processing


Symbol 0











• RESET ICC Dynamic Number (’00…00’) (if CDA supported)







Note This step corresponds to the resetting of all the transient data elements whose existence extends beyond the processing of a single C-APDU. It is possible to reset these data elements during the processing of other C-APDUs, without changing the external behavior of the PayPass – M/Chip Flex application. This is allowed since it is undetectable by Type Approval services. Section 7.1 gives information about the usage of these transient data elements throughout the PayPass – M/Chip Flex application.

Symbol 1

If the application is blocked (i.e. if Previous Transaction History [5] =1b), then the application will return with the FCI and SW1-SW2=’6283’, otherwise (i.e. if Previous Transaction History [5] = 0b), the application will return with the FCI and SW1-SW2=’9000’.




4.5.2 Data Field Returned in the Response Message The response to the SELECT signal is the FCI corresponding to the ADF selected.

Table 4.5—SELECT Signal Response Message

Data Element Tag FCI Template ‘6F’

4.5.3 Destination State Table 4.6 lists the application states after SELECT Processing.

Table 4.6—Destination State for SELECT Processing

SW1 SW2 IDLE SELECTED INITIATED ‘90’ ‘00’ SELECTED SELECTED SELECTED ‘62’ ‘83’ SELECTED SELECTED SELECTED

Other IDLE SELECTED SELECTED

Signal ProcessingUNSELECT Processing


4.6 UNSELECT Processing When the PayPass – M/Chip Flex application is de-selected, the application goes to the state IDLE. All transient data elements are deleted.

4.6.1 Processing UNSELECT Processing is performed according to Figure 4.7.

Figure 4.7—UNSELECT Processing

free transient data

1

Symbol 1

The transaction related transient data elements are destroyed:

• FREE CDOL 1 Related Data

• FREE Card Verification Results

• FREE Amount Authorised

• FREE Amount, Other

• FREE Terminal Country Code

• FREE Transaction Currency Code

• FREE Transaction Date

• FREE Transaction Type

• FREE Data Authentication Code

• FREE ICC Dynamic Number (if CDA supported)

• FREE First AC

• FREE AC Session Key

Signal Processing UNSELECT Processing



• If Co-application Indicator [2-1] = 10b (co-application UKIS is active), then FREE CVR-UKIS

• If Co-application Indicator [2-1] = 11b (co-application CCD-compliant is active), then FREE CVR-CCD

• If Co-application Indicator [2-1] = 01b (co-application M/Chip 2.05 is active), then FREE CVR-M/Chip 2.05

• If Co-application Indicator [2-1] = 00b (co-application M/Chip Lite 2.1 is active), then FREE CVR-M/Chip Lite 2.1

4.6.2 Destination State Table 4.7 lists the application states accepting the UNSELECT signal, together with the resulting destination states.

Table 4.7—Destination States for UNSELECT Processing

SELECTED INITIATED IDLE IDLE

Signal ProcessingC-APDU Processing


4.7 C-APDU Processing Figure 4.8 illustrates the actions taken by the PayPass – M/Chip Flex application when a C-APDU is processed.

Figure 4.8—Processing a C-APDU

SPECIFIC PROCESSING

DESTINATION STATE

ACCEPTED

RESPONSE

A C-APDU is processed if the C-APDU acceptance procedure has determined that the C-APDU can be accepted in the current application state. The processing that is specific to the C-APDU, the R-APDU resulting from the processing of a C-APDU, and the destination state of the application when the C-APDU has been processed is specified in the section dedicated to the C-APDU.

The way the response is sent depends on the protocol and is outside the scope of this specification.

The processing that is specific to the C-APDU is specified Chapter 5.

Signal Processing C-APDU Processing



C-APDU ProcessingCompute Cryptographic Checksum


5 C-APDU Processing This chapter specifies the processing specific to each C-APDU supported by the PayPass – M/Chip Flex application.

5.1 COMPUTE CRYPTOGRAPHIC CHECKSUM

5.1.1 Command Message The COMPUTE CRYPTOGRAPHIC CHECKSUM command message coding is shown in Table 5.1.

Table 5.1—COMPUTE CRYPTOGRAPHIC CHECKSUM Command Message

Code Value CLA ‘80’ INS ‘2A’ P1 ‘8E’ P2 ‘80’ Lc ‘04’ Data Unpredictable Number (Numeric) Le ‘00’

As the UDOL is not provided by the PayPass – M/Chip Flex application, the data field of the command message is the value field of the Unpredictable Number (Numeric) data object.

5.1.2 Processing Figure 5.1 specifies the flow of the COMPUTE CRYPTOGRAPHIC CHECKSUM command processing.

C-APDU Processing Compute Cryptographic Checksum



Figure 5.1—COMPUTE CRYPTOGRAPHIC CHECKSUM Processing

SW1-SW2='9000'

OK

OK

SW1-SW2='6A86'

SW1-SW2='6700'

NOK

NOK

0

P1-P2

1

Lc

6

RESPONSE = CVC3TRACK1, CVC3TRACK2 , ATC

GENERATE CVC3TRACK1 and CVC3TRACK2

NO3

USE STATIC CVC3?

4

CVC3TRACK1 = Static CVC3TRACK1

CVC3TRACK2 = Static CVC3TRACK2

YES

5

OK SW1-SW2='6985'

NOK2

BLOCKED?

Symbol 0

If P1 ≠ ‘8E’ or P2 ≠ ‘80’, then the C-APDU is rejected (SW1-SW2 = ‘6A86’).

Symbol 1

If Lc ≠ 4, then the C-APDU is rejected (SW1-SW2 = ’6700’).

Symbol 2

If the application is blocked (i.e. if Previous Transaction History[5] = 1b), then the C-APDU is rejected (SW1-SW2=’6985’).

Symbol 3

The PayPass – M/Chip Flex application checks if the Static CVC3 must be used (i.e. if Application Control[3][8] = 1b).

C-APDU ProcessingCompute Cryptographic Checksum


Symbol 4

If Static CVC3 must be used, then the PayPass – M/Chip Flex application sets CVC3TRACK1 equal to Static CVC3TRACK1 and CVC3TRACK2 equal to Static CVC3TRACK2.

Symbol 5

The PayPass – M/Chip Flex application generates CVC3TRACK1 and CVC3TRACK2 as specified in Section6.2.

Symbol 6

The PayPass – M/Chip Flex application generates the response message template containing the CVC3TRACK1, the CVC3TRACK2 and the ATC.

5.1.3 Data Field Returned in the Response Message The data field of the response message is a constructed data object with tag ‘77’. As shown in Table 5.2, the value field of the constructed data object includes the CVC3TRACK1, the CVC3TRACK2 and the ATC.

Table 5.2—COMPUTE CRYPTOGRAPHIC CHECKSUM Response Message

Data Element Tag Length Response Message Template ‘77’ 15 CVC3TRACK2 ‘9F61’ 2 CVC3TRACK1 ‘9F60’ 2 ATC ‘9F36’ 2

The CVC3TRACK2 and the CVC3TRACK1 are cryptograms generated by the PayPass – M/Chip Flex application according the algorithm specified in Sections 6.2, 6.3 and 6.5. Both cryptograms are generated with the same dynamic data (UN and ATC) and with the same secret key (ICC Derived Key for CVC3 Generation), but with a different initialization vector (IVCVC3TRACK1 for CVC3TRACK1 and IVCVC3TRACK2 for CVC3TRACK2).

5.1.4 Destination State The destination states for the COMPUTE CRYPTOGRAPHIC CHECKSUM command are listed in Table 5.3.

Table 5.3—Destination State for COMPUTE CRYPTOGRAPHIC CHECKSUM Command

SW1 SW2 INITIATED ‘67’ ‘00’ SELECTED ‘69’ ‘85’ SELECTED ‘6A’ ‘86’ SELECTED ‘90’ ‘00’ SELECTED

Other SELECTED

C-APDU Processing Generate Application Cryptogram



5.2 GENERATE APPLICATION CRYPTOGRAM

5.2.1 Command Message The GENERATE AC command message is coded according to Table 5.4.

Table 5.4—GENERATE AC Command Message

Code Value CLA ‘80’ INS ‘AE’ P1 Reference Control Parameter P2 ‘00’ Lc var. Data Transaction Related Data Le ‘00’

Table 5.5 specifies the coding of the Reference Control Parameter.

Table 5.5—Reference Control Parameter Coding for the GENERATE AC

b8 b7 b6 b5 b4 b3 b2 b1 Meaning x x Cryptogram Type 0 0 AAC 0 1 TC 1 0 ARQC 1 1 RFU x RFU 0 Other values RFU x Combined DDA/AC Generation Requested 0 Combined DDA/AC Generation Not Requested 1 Combined DDA/AC Generation Requested x x x x RFU 0 0 0 0 Other values RFU

C-APDU ProcessingGenerate Application Cryptogram


5.2.2 Processing

5.2.2.1 Flow, First Generate AC, Starting Diagram

Figure 5.2—First GENERATE AC Processing – Starting Diagram

OK

KO sw12:='6A86'

1

P1-P2

2

Lc KO sw12:='6700'

5

application blocked?

no

9

decision AAC

6

AC requested?

8

TC requested

7

ARQC requested

ARQC

TC

update CVR

4

retrieve transaction related data values from C-APDU

3

yes

AAC

OK




Symbol 1

If CDA supported: (P1[8-7] = 00b or 01b or 10b) and P2=’00’, otherwise the C-APDU is rejected (SW1-SW2 = ‘6A86’).

If CDA not supported: (P1[8-7] = 00b or 01b or 10b) and P1[5] = 0b and P2=’00’, otherwise the C-APDU is rejected (SW1-SW2 = ‘6A86’).

Symbol 2

32 <= Lc and Lc = CDOL 1 Related Data Length, otherwise the C-APDU is rejected (SW1-SW2 = ‘6700’).

Symbol 3

The transaction related transient data elements are filled with the values given in the Transaction Related Data (GENERATE AC command message data):

• SET CDOL 1 Related Data (CDOL 1 Related Data Length bytes from the Transaction Related Data)

• SET Amount, Authorised (Numeric) (6 bytes from the Transaction Related Data)

• SET Amount, Other (6 bytes from the Transaction Related Data)

• SET Terminal Country Code (2 bytes from the Transaction Related Data)

• SET Terminal Verification Results (5 bytes from the Transaction Related Data)

• SET Transaction Currency Code (2 bytes from the Transaction Related Data)

• SET Transaction Date (3 bytes from the Transaction Related Data)

• SET Transaction Type (1 byte from the Transaction Related Data)

• SET Unpredictable Number (4 bytes from the Transaction Related Data)

• SET Terminal Type (1 byte from the Transaction Related Data)

• SET Data Authentication Code (2 bytes from the Transaction Related Data)

• SET CDOL1 Extension (CDOL 1 Related Data Length – 32 remaining bytes from the Transaction Related Data)

Note Note that it is possible to keep only the value of CDOL 1 Related Data and to work with offsets to access the values corresponding to the variables in CDOL 1 Related Data. In this case, no assignation is required.

Note also that the application does not use the CDOL1 Extension as an individual element, but always as part of the CDOL 1 Related Data.



Symbol 4

The Card Verification Results is updated:

• If (Terminal Country Code = CRM Country Code), then the ‘Domestic Transaction’ bit in the Card Verification Results is set to 1b: SET Card Verification Results [4][2] (1b)

otherwise the ‘International Transaction’ bit is set to 1b: SET Card Verification Results [4][3] (1b)

• Byte 5 bits 8 to 5 in the Card Verification Results are updated to reflect the values of the offline counters:

If (Consecutive Offline Transactions Number > Lower Consecutive Offline Limit), then the ‘Lower Consecutive Offline Limit Exceeded’ bit in the Card Verification Results is set to 1b:

SET Card Verification Results [5][8] (1b)

If (Consecutive Offline Transactions Number > Upper Consecutive Offline Limit), then the ‘Upper Consecutive Offline Limit Exceeded’ bit in the Card Verification Results is set to 1b:


If (Cumulative Offline Transaction Amount > Lower Cumulative Offline Transaction Amount), then the ‘Lower Cumulative Offline Limit Exceeded’ bit in the Card Verification Results is set to 1b:


If (Cumulative Offline Transaction Amount > Upper Cumulative Offline Transaction Amount), then the ‘Upper Cumulative Offline Limit Exceeded’ bit in the Card Verification Results is set to 1b:


• The Card Verification Results is mapped on the CVR of the active co-application:

If Co-application Indicator [2-1] = 10b (co-application UKIS is active), then

If (Card Verification Results [5][8] = 1b or Card Verification Results [5][7] = 1b or Card Verification Results [5][6] = 1b or Card Verification Results [5][5] = 1b), then

SET CVR-UKIS [3][6] (1b)




If Co-application Indicator [2-1] = 11b (co-application CCD-compliant is active), then

If (Card Verification Results [5][8] = 1b), then SET CVR-CCD [3][8] (1b)




If Co-application Indicator [2-1] = 01b (co-application M/Chip 2.05 is active), then

If (Card Verification Results [5][8] = 1b or Card Verification Results [5][7] = 1b), then SET CVR-M/Chip 2.05 [3][6] (1b)



If Co-application Indicator [2-1] = 00b (co-application M/Chip Lite 2.1 is active), then

If (Card Verification Results [5][8] = 1b or Card Verification Results [5][7] = 1b), then SET CVR-M/Chip Lite 2.1 [3][6] (1b)



• If 'Activate additional check table' is set in the Application Control (i.e. if Application Control [2][3] = 1b), then the application performs the additional check on CDOL 1 Related Data with the Additional Check Table.

If (Position in CDOL 1 Related Data = ‘00’), then the check with the Additional Check Table is terminated (the application goes to Symbol 5 without setting bits in the Card Verification Results [6]).

If (Position in CDOL 1 Related Data + Length in CDOL 1 Related Data –1 > CDOL 1 Related Data Length), then the check with the Additional Check Table is terminated (the application goes to Symbol 5 without setting bits in the Card Verification Results [6]).

If (Length in CDOL 1 Related Data * Number of Entries > 15), then the check with the Additional Check Table is terminated (the application goes to Symbol 5 without setting bits in the Card Verification Results [6]).

Masked Value = CDOL 1 Related Data [Position in CDOL 1 Related Data to Position in CDOL 1 Related Data + Length in CDOL 1 Related Data - 1] & Bit Mask



for (i = 2; i <= Number of Entries, i++) { Entry i = Additional Check Table [4 + (i-1) * Length in CDOL 1 Related Data to 4 + i * Length in CDOL 1 Related Data - 1] if (Masked Value = Entry i), then • SET Card Verification Results [6][2](1b) (match found in Additional Check

Table) • Exit loop and terminate check with the Additional Check Table (the application

goes to Symbol 5) }

SET Card Verification Results [6][1](1b) (no match found in Additional Check Table)

Terminate check with the Additional Check Table (the application goes to Symbol 5).

Note This is the first time bits from the Card Verification Results are set since they were reset to 0b. Therefore, all bits that are not set in this step have a value of 0b.

Symbol 5

If the application is blocked (i.e. if Previous Transaction History[5] =1b), then the PayPass – M/Chip Flex application generates an AAC.

Symbols 6-7-8-9

If the application is not blocked (i.e. if Previous Transaction History[5] = 0b), then the process depends on the terminal request.

If the terminal requests an ARQC (i.e. if Reference Control Parameter [8-7] = 10b), then the terminal asks for an online transaction. This PayPass – M/Chip Flex application process is specified in Section 5.2.2.2.

If the terminal requests a TC (i.e. if Reference Control Parameter [8-7] = 01b), then the terminal asks for an offline transaction. This PayPass – M/Chip Flex application process is specified in Section 5.2.2.3.

If the terminal requests an AAC (i.e. if Reference Control Parameter [8-7] = 00b), then the terminal declines the transaction. The PayPass – M/Chip Flex application generates an AAC. The computation of an AAC is specified in Section 5.2.2.4 (if CDA supported) and Section 5.2.2.5 (if CDA not supported).




5.2.2.2 Flow, First Generate AC, ARQC Requested

Figure 5.3—First GENERATE AC Processing – ARQC Requested

10

7 ARQC requested

9

decision AAC

11

decision ARQC

do not decline

CVR and CIACs decline

10'

Offline-only?

decline

yes

no

Symbol 10'

If the ’Offline-only’ bit is set in the Application Control (i.e. Application Control[1][6] = 1b), then the PayPass – M/Chip Flex application will decline the transaction and compute an AAC, otherwise the PayPass – M/Chip Flex application will check the Card Issuer Action Code – Decline.

Symbol 10 The decisional part of the Card Verification Results is checked against the Card Issuer Action Code – Decline:

If ((Card Verification Results[4-6] & Card Issuer Action Code – Decline) <> ‘000000’), then the PayPass – M/Chip Flex application declines the transaction and will compute an AAC, otherwise the PayPass – M/Chip Flex application will compute an ARQC.

Symbol 9 The computation of an AAC is specified in Section 5.2.2.4 (if CDA supported) and Section 5.2.2.5 (if CDA not supported).

Symbol 11 The computation of an ARQC is specified in Section 5.2.2.4 (if CDA supported) and Section 5.2.2.5 (if CDA not supported).



5.2.2.3 Flow, First GENERATE AC, TC Requested

Figure 5.4—First GENERATE AC Processing – TC Requested-1

do not decline

decline

12CVRand CIACs

decline

8

TC requested

9

decision AAC

13

transaction currency

application currency

convertible currency

update cumulative offline limit exceeded in CVR

18

16 '

OK

KO

KO

OK

update consecutive offline limit exceeded in CVR

19

convert amount in

app . currency

15

add amount to cumulative

amount

14

add amount in app . currency to

cumulative amount

16

KO add to consecutive transaction number

17

14'

15 '

other

OK

see next flow diagram

18'

always updatecons nr

NO

add to consecutivetransaction number

update consecutive offline limit exceeded in CVR

19

YES 17




Figure 5.5—First GENERATE AC Processing – TC Requested-2

11

decision ARQC

20

offline only terminal

22

CAT3 and skip CRM for CAT3

21

27

decision TC

online

no

25

23

9

decision AAC

decline

see previous flow diagram

yes

offlineoffline

offline only

CVR andCIACs default

CVR and CIACs online

online capable

yes20'

offline-only?

no

update counters

20'’

update POI



Symbol 12

The decisional part of the Card Verification Results is checked against the Card Issuer Action Code – Decline:

If ((Card Verification Results[4-6] & Card Issuer Action Code – Decline) <> ‘000000’), then the PayPass – M/Chip Flex application declines the transaction and will compute an AAC.

Symbol 9

The computation of an AAC is specified in Section 5.2.2.4 (if CDA supported) and Section 5.2.2.5 (if CDA not supported).

Symbol 13

The Transaction Currency Code is checked against the CRM Currency Code and the Currency Conversion Parameters 1 to 5:

If (Transaction Currency Code = CRM Currency Code), then the Amount, Authorised will be added to the Cumulative Offline Transaction Amount without conversion,

otherwise the Transaction Currency Code is checked against the Currency Code in the Currency Conversion Parameters 1 to 51:

for (i=1; i<=5, i++) { If (Transaction Currency Code = Currency Conversion Parameters i [1-2]), then exit loop to convert the Amount, Authorised into the Amount in Counter Currency, using the Currency Conversion Parameters i }

If ((Transaction Currency Code <> CRM Currency Code ) and (Transaction Currency Code <> Currency Code for Currency Conversion Parameters 1 to 5)), then the Consecutive Offline Transactions Number will be incremented.

Symbols 14, 14’

The value of the Cumulative Offline Transaction Amount is computed and stored in a temporary variable:

Temp Cumulative Offline Transaction Amount := Cumulative Offline Transaction Amount + Amount, Authorised.

If an overflow happens during the addition (i.e. the result exceeds 999999999999), then the C-APDU is rejected (SW1-SW2 = ‘6985’).

Note The result of the addition is not stored in non-volatile memory at this point (i.e. Cumulative Offline Transaction Amount in non-volatile memory is not yet impacted by the addition) as the addition is performed on a transient data element.

Note The Temp Cumulative Offline Transaction Amount does not exist beyond a single C-APDU processing, as it is not mentioned in Section 7.1.

1 Currency Code is stored in byte 1-2 of the Currency Conversion Parameters.




Symbols 15, 15’

The Amount, Authorised is converted into the Amount in Counter Currency, using the Currency Conversion Parameters 1 to 5. This process is specified in Annex B.

If an overflow happens during the conversion, then the C-APDU is rejected (SW1-SW2 = ‘6985’).

Symbol 16, 16’

The value of the Cumulative Offline Transaction Amount is computed and stored in a temporary variable:

Temp Cumulative Offline Transaction Amount := Cumulative Offline Transaction Amount + Amount in Counter Currency.

If an overflow happens during the addition (i.e. the result exceeds 999999999999), then the C-APDU is rejected (SW1-SW2 = ‘6985’).

Symbol 17

The value of the Consecutive Offline Transactions Number is computed and stored in a temporary variable:

Temp Consecutive Offline Transactions Number := Consecutive Offline Transactions Number +1.

If an overflow happens during the addition (i.e. the result exceeds ‘FF’), then the counter remains at ‘FF’ (i.e. ‘FF’+1=’FF’ for this operation).

Note The result of the increment is not stored in non-volatile memory at this point (i.e. Consecutive Offline Transactions Number in non-volatile memory is not yet impacted by the addition) as addition is performed on a transient data element.

Note The Temp Consecutive Offline Transactions Number does exist beyond a single C-APDU processing, since it is not mentioned in Section 7.1.

Symbols 18’

If the ‘always add to consecutive transaction number’ bit is set in the Application Control (i.e. if Application Control [2][4] = 1b), then the current transaction is added to the Consecutive Offline Transactions Number.

Symbol 18

• The Card Verification Results is updated:

If (Temp Cumulative Offline Transaction Amount > Lower Cumulative Offline Transaction Amount), then the ‘Lower Cumulative Offline Limit Exceeded’ bit in the Card Verification Results is set to 1b:




If (Temp Cumulative Offline Transaction Amount > Upper Cumulative Offline Transaction Amount), then the ‘Upper Cumulative Offline Limit Exceeded’ bit in the Card Verification Results is set to 1b:




If (Card Verification Results [5][6] = 1b or Card Verification Results [5][5] = 1b), then SET CVR-UKIS [3][6] (1b)





If (Card Verification Results [5][6] = 1b), then SET CVR-M/Chip 2.05 [4][3] (1b)

If (Card Verification Results [5][5] = 1b) , then SET CVR-M/Chip 2.05 [4][2] (1b)


If (Card Verification Results [5][6] = 1b) , then SET CVR-M/Chip Lite 2.1 [4][3] (1b)

If (Card Verification Results [5][5] = 1b), then SET CVR-M/Chip Lite 2.1 [4][2] (1b)

Symbol 19

• The Card Verification Results is updated:

If (Temp Consecutive Offline Transactions Number > Lower Consecutive Offline Limit), then the ‘Lower Consecutive Offline Limit Exceeded’ bit in the Card Verification Results is set to 1b:


If (Temp Consecutive Offline Transactions Number > Upper Consecutive Offline Limit), then the ‘Upper Consecutive Offline Limit Exceeded’ bit in the Card Verification Results is set to 1b:




If (Card Verification Results [5][8] = 1b or Card Verification Results [5][7] = 1b), then SET CVR-UKIS [3][6] (1b)








If (Card Verification Results [5][8] = 1b), then SET CVR-M/Chip 2.05 [3][6] (1b) SET CVR-M/Chip 2.05 [4][3] (1b)

If (Card Verification Results [5][7] = 1b), then SET CVR-M/Chip 2.05 [3][6] (1b) SET CVR-M/Chip 2.05 [4][2] (1b)


If (Card Verification Results [5][8] = 1b), then SET CVR-M/Chip Lite 2.1 [3][6] (1b) SET CVR-M/Chip Lite 2.1 [4][3] (1b)

If (Card Verification Results [5][7] = 1b), then SET CVR-M/Chip Lite 2.1 [3][6] (1b) SET CVR-M/Chip Lite 2.1 [4][2] (1b)

Symbol 20’’

Update the ‘Go online on next transaction’ bit in the POI. If one of the offline counters exceeds the lower limit, then the bit is set, otherwise the bit is reset:

SAVE POI [2] (Card Verification Results [5][8] | Card Verification Results [5][6])

Symbol 20’

If the ’Offline-only’ bit is set in the Application Control (i.e. Application Control[1][6] = 1b), then the PayPass – M/Chip Flex application will not check the Card Issuer Action Code – Online, otherwise the PayPass – M/Chip Flex application will check if the terminal is online capable.

Symbol 20

If the terminal is offline only (i.e. if Terminal Type = ‘23’ or ‘26’ or ‘36’), then the PayPass – M/Chip Flex application will not check the Card Issuer Action Code – Online, otherwise the PayPass – M/Chip Flex application will check the Card Issuer Action Code – Online.



Symbol 21

If the terminal is online capable, then the PayPass – M/Chip Flex application checks the Card Issuer Action Code – Online:

If ((Card Verification Results[4-6] & Card Issuer Action Code – Online) <> ‘000000’), then the PayPass – M/Chip Flex application will compute an ARQC, otherwise the PayPass – M/Chip Flex application will approve the transaction and compute a TC.

Symbol 22

If the terminal is offline only, then the PayPass – M/Chip Flex application checks if the Card Issuer Action Code – Default is to be used:

If (the terminal is a CAT3 terminal (i.e. if the Terminal Type = ‘26’) and the ’Skip CIAC-Default on CAT3’ bit is set in the Application Control (i.e. if Application Control[1][7] = 1b)), then the PayPass – M/Chip Flex application will approve the transaction without checking the Card Issuer Action Code – Default and will compute a TC, otherwise the PayPass – M/Chip Flex application will check the Card Issuer Action Code – Default.

Symbol 23

The PayPass – M/Chip Flex application checks the Card Issuer Action Code – Default:

If ((Card Verification Results[4-6] & Card Issuer Action Code – Default) <> ‘000000’), then the PayPass – M/Chip Flex application will decline the transaction and compute an AAC, otherwise the PayPass – M/Chip Flex application will approve the transaction and compute a TC.

Symbol 25

If modified, then the Cumulative Offline Transaction Amount is updated in non-volatile memory:

SAVE Cumulative Offline Transaction Amount (Temp Cumulative Offline Transaction Amount)

If modified, then the Consecutive Offline Transactions Number is updated in non-volatile memory:

SAVE Consecutive Offline Transactions Number (Temp Consecutive Offline Transactions Number)

Symbol 27

The computation of a TC is specified in Section 5.2.2.4 (if CDA supported) and Section 5.2.2.5 (if CDA not supported).




5.2.2.4 Flow, GENERATE AC, Decision AAC, TC or ARQC (CDA Supported)

This section specifies how the AAC, TC and ARQC are computed by the PayPass – M/Chip Flex application. It also specifies how the PayPass – M/Chip Flex application calculates the corresponding response message to the GENERATE AC when CDA is supported.

Figure 5.6—AAC, TC, ARQC Generation and Corresponding Response Message for GENERATE AC – 1 (CDA Supported)

27

decision TC

set ARQC in CVR and CID

102

103

combined

11

decision ARQC

set combined returned in

CVR

104

combined

set TC in CVR and CID

101

9

decision AAC

set AAC in CVR and CID

100

see next diagram

103

combined

not combined

set combined returned in

CVR

104

combined

not combined



Figure 5.7—AAC, TC, ARQC Generation and Corresponding Response Message for GENERATE AC – 2 (CDA Supported)

not combined

build response

117

118

resp., sw12='9000'

111

combined and TC/ARQC

compute hash result

112

118

build ICC Dynamic Data

113

114

compute RSA signature

115

build response

116

compute AAC/TC/ARQC

107

compute Issuer App. Data

108

previous diagram

combined

compute hash on Dynamic Application Data to be Signed




Symbol 100

• The Card Verification Results is updated (the ‘AC Returned in First Generate AC’ bits are set to AAC, the ‘AC Returned in Second Generate AC’ bits are set to not requested):

SET Card Verification Results [1][8-5] (1000b)


If Co-application Indicator [2-1] = 10b (co-application UKIS is active), then SET CVR-UKIS [2][8-5] (1000b)

If Co-application Indicator [2-1] = 11b (co-application CCD-compliant is active), then SET CVR-CCD [1][8-5] (1000b)

If Co-application Indicator [2-1] = 01b (co-application M/Chip 2.05 is active), then SET CVR-M/Chip 2.05 [2][8-5] (1000b)

If Co-application Indicator [2-1] = 00b (co-application M/Chip Lite 2.1 is active), then SET CVR-M/Chip Lite 2.1 [2][8-5] (1000b)

• The Cryptogram Information Data is set to AAC:

SET Cryptogram Information Data (’00’)

Symbol 101

• The Card Verification Results is updated (the ‘AC Returned in First Generate AC’ bits are set to TC, the ‘AC Returned in Second Generate AC’ bits are set to not requested):







• The Cryptogram Information Data is set to TC:




Symbol 102

• The Card Verification Results is updated (the ‘AC Returned in First Generate AC’ bits are set to ARQC, the ‘AC Returned in Second Generate AC’ bits are set to not requested):







• The Cryptogram Information Data is set to ARQC:


Symbol 103

If the terminal asks for combined DDA/AC generation (i.e. if Reference Control Parameter[5] = 1b), then the Card Verification Results is updated.

Symbol 104

The ‘Combined DDA/AC Generation Returned in First Generate AC’ bit is set in the Card Verification Results:

SET Card Verification Results[2][7] (1b)

If Co-application Indicator [2-1] = 11b (co-application CCD-compliant is active), then the ‘CDA performed’ bit is set in the CVR-CCD:

SET CVR-CCD [1][4] (1b)

Symbol 107

The PayPass – M/Chip Flex application computes the AAC, TC or ARQC using the algorithm determined in Section 6.1.

Symbol 108

The PayPass – M/Chip Flex application computes the Issuer Application Data. For values refer to Annex A.




Symbol 111

If the terminal asks for combined DDA/AC generation (i.e. if Reference Control Parameter[5] = 1b) and the decision is to compute a TC or ARQC, then the PayPass – M/Chip Flex application will wrap the TC/ARQC in a RSA envelope.

If the terminal does not ask for combined DDA/AC generation (i.e. if Reference Control Parameter[5] = 0b) or the decision is to compute an AAC, then the PayPass – M/Chip Flex application will build the response.

Symbol 112

The PayPass – M/Chip Flex application computes the Hash Result on CDOL 1 Related Data and Generate AC Response Data (except the Signed Dynamic Application Data). See [EMV BOOK 2], Section 6.6.1, for details.

Symbol 113

The PayPass – M/Chip Flex application builds the ICC Dynamic Data. See [EMV BOOK 2], Section 6.6.1, for details.

Symbol 114

The PayPass – M/Chip Flex application computes the Hash of the Dynamic Application Data and its Related Information. See [EMV BOOK 2], Section 6.6.1, for details.

Symbol 115

The PayPass – M/Chip Flex application computes the RSA signature. See [EMV BOOK 2], Section 6.6.1, for details.

Symbol 116

If Combined DDA/Application Cryptogram Generation (CDA) has been chosen for the current transaction and the ICC returns a TC or ARQC, then the GENERATE AC response message data field is an EMV Format 2 constructed data object with tag equal to '77' containing the BER-TLV coded objects specified in Table 5.6.

If the ICC returns an AAC, then the GENERATE AC response message data field is an EMV Format 2 constructed data object with tag equal to '77' containing the BER-TLV coded objects specified in Table 5.7.

Table 5.6— GENERATE AC Response Message Data Field (CDA)

Tag Length Description ‘9F27’ 1 Cryptogram Information Data ‘9F36’ 2 Application Transaction Counter ‘9F4B’ NIC Signed Dynamic Application Data ‘9F10’ up to 32 Issuer Application Data (coded according to the active co-application)



Symbol 117

If Static Data Authentication has been chosen for the current transaction (i.e. AC generation is not combined with DDA), then the GENERATE AC response message data field for an AAC, TC or ARQC is an EMV Format 2 constructed data object with tag equal to '77' containing the BER-TLV coded objects specified in Table 5.7.

Table 5.7— GENERATE AC Response Message Data Field (SDA)

Tag Length Description ‘9F27’ 1 Cryptogram Information Data ‘9F36’ 2 Application Transaction Counter ‘9F26’ 8 Application Cryptogram ‘9F10’ up to 32 Issuer Application Data (coded according to the active co-application)




5.2.2.5 Flow, GENERATE AC, Decision AAC, TC or ARQC (CDA Not Supported)

This section specifies how the AAC, TC and ARQC are computed by the PayPass – M/Chip Flex application, as well as the corresponding response message to the first GENERATE AC when CDA is not supported.

Figure 5.8—AAC, TC, ARQC Generation and Corresponding Response Message for GENERATE AC (CDA not supported)

27

decision TC

set ARQC in CVR and CID

102

11

decision ARQC

set TC in CVR and CID

101

9

decision AAC

set AAC in CVR and CID

100

compute AAC/TC/ARQC

build Issuer App. Data

103

103'

build response

104

105



Symbol 100

• The Card Verification Results is updated (the ‘AC Returned in First Generate AC’ bits are set to AAC, the ‘AC Returned in Second Generate AC’ bits are set to not requested):







• The Cryptogram Information Data is set to AAC:


Symbol 101

• The Card Verification Results is updated (the ‘AC Returned in First Generate AC’ bits are set to TC, the ‘AC Returned in Second Generate AC’ bits are set to not requested):







• The Cryptogram Information Data is set to TC:





Symbol 102

• The Card Verification Results is updated (the ‘AC Returned in First Generate AC’ bits are set to ARQC, the ‘AC Returned in Second Generate AC’ bits are set to not requested):







• The Cryptogram Information Data is set to ARQC:


Symbol 103

The PayPass – M/Chip Flex application computes the AAC, TC or ARQC using the algorithm determined in Section 6.1.

Symbol 103'

The PayPass – M/Chip Flex application builds the Issuer Application Data. For values refer to Annex A.

Symbol 104

The GENERATE AC response message data field for an AAC, TC or ARQC is an EMV Format 2 constructed data object with tag equal to '77' containing the BER-TLV coded objects specified in Table 5.8.

Table 5.8— GENERATE AC Response Message Data Field (SDA)

Tag Length Description ‘9F27’ 1 Cryptogram Information Data ‘9F36’ 2 Application Transaction Counter ‘9F26’ 8 Application Cryptogram ‘9F10’ up to 32 Issuer Application Data (coded according to the active co-application)



5.2.3 Data Field Returned in the Response Message The response message varies with the cryptogram computed and is specified in the sections dedicated to the cryptogram generation.

5.2.4 Destination State The destination states for the GENERATE AC command are listed in Table 5.9.

Table 5.9—Destination State for GENERATE AC Command

SW1 SW2 INITIATED ‘67’ ‘00’ SELECTED ‘69’ ‘85’ SELECTED ‘6A’ ‘86’ SELECTED ‘90’ ‘00’ SELECTED

Other SELECTED

C-APDU Processing Get Data



5.3 GET DATA

5.3.1 Command Message The GET DATA command message is coded as shown in Table 5.10.

Table 5.10—GET DATA Command Message

Code Value CLA ‘80’ INS ‘CA’ P1/P2 Tag Lc Not present Data Not present Le ‘00’

Single byte tags are preceded with a leading ‘00’ byte to fill P1/P2.

Table 5.11 shows the tag values that must be supported by the GET DATA command of the PayPass – M/Chip Flex application.

Table 5.11—Tag Values for GET DATA

P1/P2 Data Element Length ‘0082’ Application Interchange Profile 2 ‘0094’ Application File Locator var ‘00C3’ Card Issuer Action Code – Decline 3 ‘00C4’ Card Issuer Action Code – Default 3 ‘00C5’ Card Issuer Action Code – Online 3 ‘00C6’ Counters 10 ‘00C7’ CDOL 1 Related Data Length 1 ‘00C8’ CRM Country Code 2 ‘00C9’ CRM Currency Code 2 ‘00CA’ Lower Cumulative Offline Transaction Amount 6 ‘00CB’ Upper Cumulative Offline Transaction Amount 6 ‘00D1’ Currency Conversion Table 25 ‘00D3’ Additional Check Table 18 ‘00D5’ Application Control 3 ‘9F14’ Lower Consecutive Offline Limit 1 ‘9F23’ Upper Consecutive Offline Limit 1 ‘9F50’ Offline Balance 6 ‘9F7A’ Offline Consecutive Transactions Remaining 1 ‘9F7E’ Application Life Cycle Data 48 ‘DF02’ Security Limits Status 1

C-APDU ProcessingGet Data


5.3.2 Processing Figure 5.9 specifies the flow of the GET DATA command processing.

Figure 5.9—GET DATA Processing

OK

KO sw12:= '6A88'

1

P1-P2

resp:=TLV(data)sw12:= '9000'

no yes

2

Tag = '9F50'

no

3

allowed

no

sw12:= '6985'

yes

compute balance

4

no yes

5

Tag = '9F7A'

no

6

allowed

no

sw12:= '6985'

yes

compute remaining

7

C-APDU Processing Get Data



Symbol 1

P1/P2 is an accepted tag (i.e. tag in Table 5.11), otherwise the C-APDU is rejected (‘6A88’).

Symbol 2

If P1/P2 carry the tag of the Offline Balance (i.e. if P1/P2 = ‘9F50’), then the application will check the Application Control.

Symbol 3

If retrieval of the Offline Balance is allowed (i.e. if Application Control[2][2] = 1b), then the application will compute the offline balance. Otherwise the C-APDU is rejected (‘6985’).

Symbol 4

The Offline Balance is computed as follows:

Offline Balance = Upper Cumulative Offline Transaction Amount - Cumulative Offline Transaction Amount.

If an overflow occurs (i.e. if Upper Cumulative Offline Transaction Amount < Cumulative Offline Transaction Amount), then the value returned for the Offline Balance is ‘000000000000’.

Symbol 5

If P1/P2 carry the tag of the Offline Consecutive Transactions Remaining (i.e. if P1/P2 = ’9F7A’), then the application will check the Application Control.

Symbol 6

If retrieval of the Offline Balance is allowed (i.e. if Application Control[2][2] = 1b), then the application will compute the Offline Consecutive Transactions Remaining. Otherwise the C-APDU is rejected (‘6985’).

Symbol 7

The Offline Consecutive Transactions Remaining is computed as follows:

Offline Consecutive Transactions Remaining = Upper Consecutive Offline Limit – Consecutive Offline Transactions Number.

If an overflow occurs (i.e. if Upper Consecutive Offline Limit < Consecutive Offline Transaction Number), then the value returned for the Offline Consecutive Transactions Remaining is ‘00’.

C-APDU ProcessingGet Data


5.3.3 Data Field Returned in the Response Message The data field of the response message contains the data object, TLV encoded.

Table 5.12—GET DATA Response Message

Name Length Tag 1 or 2 Length 1 Value var.

5.3.4 Destination State The destination states for the GET DATA command are listed in Table 5.13.

Table 5.13—Destination State for GET DATA Command

SW1 SW2 SELECTED INITIATED ‘69’ ‘85’ SELECTED SELECTED ‘6A’ ‘88’ SELECTED SELECTED ‘90’ ‘00’ SELECTED INITIATED


C-APDU Processing Get Processing Options



5.4 GET PROCESSING OPTIONS

5.4.1 Command Message The GET PROCESSING OPTIONS command message is coded according to Table 5.14.

Table 5.14—GET PROCESSING OPTIONS Command Message

Code Value CLA ‘80’

INS ‘A8’

P1 ‘00’

P2 ‘00’

Lc ‘02’

Data PDOL Related Data

Le ‘00’

PDOL Related Data follows a command template equal to ‘83’ and is empty as shown in Table 5.15.

Table 5.15—PDOL Related Data

Data Element Tag Length Value PDOL Related Data ‘83’ ‘00’ empty

C-APDU ProcessingGet Processing Options


5.4.2 Processing Figure 5.10 specifies the flow of the GET PROCESSING OPTIONS command processing.

Figure 5.10—GET PROCESSING OPTIONS Processing

OK

OK

OK

KO sw12:='6A86'

1

P1-P2

2

Lc KO sw12:='6700'

KO sw12:='6985'

3

PDOL related data

resp:=AIP, AFLsw12:= '9000'

ATC++;save ATC

6

compute ICC DN

7


5

4ATC

< ATC Limit

no

sw12:='6985'

4''

application disabled?

yes

no

disable application

4'

yes

Symbol 1

P1=’00’ and P2=00’, otherwise the C-APDU is rejected (‘6A86’).

Symbol 2

Lc=’02’, otherwise the C-APDU is rejected (‘6700’).

Symbol 3

PDOL Related Data = ‘8300’, otherwise the C-APDU is rejected (‘6985’).

C-APDU Processing Get Processing Options



Symbol 4, 4'

If the Application Transaction Counter has reached the limit (i.e. if Application Transaction Counter >= Application Transaction Counter Limit), then the application is disabled:

SAVE Previous Transaction History [6] (1b)

Symbol 4''

If the application is disabled (i.e. if Previous Transaction History [6] = 1b), then GET PROCESSING OPTIONS is rejected (‘6985’).

Symbol 5











• RESET ICC Dynamic Number (’00…00’) (if CDA supported)







Note This step corresponds to the resetting of all the transient data elements that exist beyond the processing of a single C-APDU. It is possible to reset these data elements during the processing of other C-APDUs, without changing the external behavior of the PayPass – M/Chip Flex application. This is allowed since it is undetectable by Type Approval. Section 7.1 gives information about the usage of these transient data elements throughout the PayPass – M/Chip Flex application.

C-APDU ProcessingGet Processing Options


Symbol 6

The Application Transaction Counter is incremented and saved in non-volatile memory:

SAVE Application Transaction Counter (Application Transaction Counter +1)

Symbol 7

If CDA supported:

The ICC Dynamic Number (ICC DN) is computed using the ICC Dynamic Number Master Key (MKIDN) and the Application Transaction Counter (ATC):

ICC DN := DES3 (MKIDN) [(ATC ||‘00’||‘00’||‘00’||‘00’||‘00’||‘00’)]

5.4.3 Data Field Returned in the Response Message The data field of the response message is an EMV Format 2 constructed data object with tag equal to '77' containing the BER-TLV coded objects specified in Table 5.16.

Table 5.16— GET PROCESSING OPTIONS Response Message

Data Element Tag Response Message Template ‘77’ Application Interchange Profile ‘82’

Application File Locator ‘94’

5.4.4 Destination State Table 5.17 lists the destination states for the GET PROCESSING OPTIONS command.

Table 5.17—Destination State for GET PROCESSING OPTIONS Command

SW1 SW2 SELECTED ‘67’ ‘00’ SELECTED ‘69’ ‘85’ SELECTED ‘6A’ ‘86’ SELECTED ‘90’ ‘00’ INITIATED

Other SELECTED

C-APDU Processing Read Record



5.5 READ RECORD The PayPass – M/Chip Flex application supports only one form of the READ RECORD C-APDU: the EMV 4.1 READ RECORD.

5.5.1 Command Message The READ RECORD command message is coded according to Table 5.18.

Table 5.18—READ RECORD Command Message


INS ‘B2’

P1 Record Number

P2 Reference Control Parameter

Lc not present

Data not present

Le ‘00’

Table 5.19 specifies the coding of the Reference Control Parameter.

Table 5.19—Reference Control Parameter Coding for the READ RECORD

b8 b7 b6 b5 b4 b3 b2 b1 Meaning x x x x x SFI x x x 1 0 0 P1 is a record number

C-APDU ProcessingRead Record


5.5.2 Processing Figure 5.11 specifies the flow of the READ RECORD command processing.

Figure 5.11—READ RECORD Processing

EMV

OK

OK

sw12:='6A86'

1

P1-P2

2

file supported KO

sw12:='6A82'

KO

sw12:='6A83'

3

record found

OK

KO

sw12:='6985'

4

record in AFL

resp:=recordsw12:='9000'

OK

OK

5

file supportedKO

KO

6

record found

OK

resp:=recordsw12:='9000'

KO

1'

SFI

out of scopepayment system

1''other

C-APDU Processing Read Record



Symbol 1

The PayPass – M/Chip Flex application checks that:

• P1<>’00’

• and (P2 & ‘07’) = ’04’

otherwise the C-APDU is rejected (‘6A86’).

Symbol 1'

If the C-APDU is the READ RECORD as reserved by EMV 4.1, then the PayPass – M/Chip Flex application checks if the file to read is an EMV file, a payment system specific file, or another file:

• If the SFI in the Reference Control Parameter is in the range 1 to 10, then the file to read is an EMV file.

• If the SFI in the Reference Control Parameter is in the range 11 to 20, then the file to read is a payment system specific file.

• If the SFI in the Reference Control Parameter is not in the range 1 to 20, then the file to read is neither an EMV file nor a payment system specific file.

Symbol 1''

If the file to read is neither an EMV file nor a payment system specific file, it may be that the platform supports it anyway (for instance, issuer specific files). This would be in addition to the functionality needed for the PayPass – M/Chip Flex application and is allowed but is proprietary to the implementation.

Symbol 2

If the file to read is an EMV file, the PayPass – M/Chip Flex application verifies that the SFI in the Reference Control Parameter corresponds to a supported record file. If the record file is not supported, the C-APDU is rejected (‘6A82’). The way the PayPass – M/Chip Flex application checks that the record file is supported is proprietary and left to the implementation.

Symbol 3

The PayPass – M/Chip Flex application verifies that there is a record corresponding to the Record Number, otherwise the C-APDU is rejected (‘6A83’). The way the PayPass – M/Chip Flex application checks that the record is supported is proprietary and left to the implementation.

Symbol 4

The PayPass – M/Chip Flex application checks if the record is referenced in the Application File Locator.

If the record is not referenced in the Application File Locator, the C-APDU is rejected (‘6985’).

If the record is referenced in the Application File Locator, it is sent in the response.

C-APDU ProcessingRead Record


Symbol 5

If the file to read is a payment system specific file, the PayPass – M/Chip Flex application verifies that the SFI in the Reference Control Parameter corresponds to a supported record file.

If the file is not supported, the C-APDU is rejected (‘6A82’). The way the PayPass – M/Chip Flex application checks that the file is supported is proprietary and left to the implementation.

Symbol 6

The PayPass – M/Chip Flex application verifies that there is a non-empty record corresponding to the Record Number, otherwise the C-APDU is rejected (‘6A83’). The way the PayPass – M/Chip Flex application checks that the record is supported or empty is proprietary and left to the implementation.

5.5.3 Data Field Returned in the Response Message The records referenced in the Application File Locator are stored in files with SFI in the range 1-10. For these records, the response message follows the AEF Data Template ‘70’, as shown in Table 5.20.

Table 5.20—READ RECORD Response Message (SFI in the range 1-10)

Name Tag AEF Data Template ‘70’

Record

5.5.4 Destination State Table 5.21 lists the destination states for the READ RECORD command.

Table 5.21—Destination State for READ RECORD Command

SW1 SW2 SELECTED INITIATED ‘90’ ‘00’ SELECTED INITIATED ‘6A’ ‘86’ SELECTED SELECTED ‘6A’ ‘82’ SELECTED SELECTED ‘6A’ ‘83’ SELECTED SELECTED


C-APDU Processing Select



5.6 SELECT The PayPass – M/Chip Flex application does not use the SELECT command for application selection. The application selection mechanism is described in Section 4.5. A SELECT command transferred to the PayPass – M/Chip Flex application indicates that the file/application to be selected is not present on the ICC.

Note In order to comply with the EMV 4.1 application selection process, the PayPass – M/Chip Flex application must support the SELECT command (i.e. CLA/INS = ‘00A4’) if any special behavior (i.e. responding ‘6A82’ when the application to be selected is not present on the ICC) is not handled by a lower card layer (for example by the card manager, the multi-application manager, or the operating system). If an ICC platform is used that handles this behavior by a lower layer, then the SELECT command does not have to be supported by the PayPass – M/Chip Flex application.

5.6.1 Command Message The SELECT command message is coded according to Table 5.22.

Table 5.22—SELECT Command Message


INS ‘A4’

P1 ‘04’

P2 ‘00’ first occurrence ‘02’ next occurrence

Lc ‘05’-‘10’

Data file name

Le ‘00’

C-APDU ProcessingSelect


5.6.2 Processing Figure 5.12 specifies the flow of the SELECT command processing.

Figure 5.12—SELECT Processing

OK

KO sw12:='6A86'

1

P1-P2

sw12:='6A82'

Symbol 1

If P1= ‘04’ and (P2 = ‘00’ or ‘02’), then the C-APDU is rejected with SW1-SW2 = ‘6A82’, otherwise the C-APDU is rejected with SW1-SW2 = ‘6A86’.

5.6.3 Data Field Returned in the Response Message The response consists only of SW1-SW2.

5.6.4 Destination State Table 5.23 lists the destination states for the SELECT command.

Table 5.23—Destination State for SELECT Command

SW1 SW2 SELECTED INITIATED ‘6A’ ‘82’ SELECTED SELECTED ‘6A’ ‘86’ SELECTED SELECTED


C-APDU Processing Select



Cryptographic Algorithms and Key ManagementApplication Cryptogram Generation


6 Cryptographic Algorithms and Key Management

6.1 Application Cryptogram Generation The Application Cryptogram is generated using the MAC algorithm specified in Section 6.6 and a symmetric key as specified in Section 6.4.

Data objects to be included in the Application Cryptogram are:

• Terminal resident data objects (referenced in CDOL1 transmitted to the terminal in response to the READ RECORD command) and

• Card internal data objects depending on the co-application.

Table 6.1 shows the terminal resident data objects to be included in the Application Cryptogram.

Table 6.1—Data Input for AC Generation (Terminal Resident Data Objects)

Tag Description

‘9F02’ Amount, Authorized

‘9F03’ Amount, Other

‘9F1A’ Terminal Country Code

‘95’ Terminal Verification Results

‘5F2A’ Transaction Currency Code

‘9A’ Transaction Date

‘9C’ Transaction Type

‘9F37’ Unpredictable Number

If the co-application is CCD-compliant, then the card data elements listed in Table 6.2 are included in the Application Cryptogram. They are included in the Application Cryptogram in the order shown at the end of the terminal residing data.

Table 6.2— Card Data Input for AC Generation (CCD-compliant)

Tag Length Description ‘82’ 2 Application Interchange Profile ‘9F36’ 2 Application Transaction Counter ‘9F10’ 32 Issuer Application Data (CCD-compliant co-application)

Cryptographic Algorithms and Key Management Dynamic CVC3 Generation



If the co-application is M/Chip 2.05, or M/Chip Lite 2.1, or UKIS, then the card data elements listed in Table 6.3 are included in the Application Cryptogram. They are included in the Application Cryptogram in the order shown at the end of the terminal residing data.

Table 6.3—Card Data Input for AC Generation (M/Chip 2.05, M/Chip Lite 2.1, UKIS)

Tag Length Description ‘82’ 2 Application Interchange Profile ‘9F36’ 2 Application Transaction Counter ‘9F52’ var. CVR-M/Chip 2.05 or CVR-M/Chip Lite 2.1 or CVR-UKIS

6.2 Dynamic CVC3 Generation The CVC3TRACK1 is generated using DES3 encipherment as follows:

1. Concatenate the data listed in Table 6.4 in the order specified to obtain an 8 byte data block (D):

Table 6.4—Track 1 CVC3 Data Elements

Data Element Length IVCVC3TRACK1 2 bytes Unpredictable Number 4 bytes

Application Transaction Countera 2 bytes

a If Application Control[3][7] = 0b (do not include the ATC in dynamic CVC3 generation), then the 2 bytes are filled with hexadecimal zeroes (’00 00’).

2. Calculate O as follows:

O := DES3(KDCVC3)[D]

3. The two least significant bytes of O are the CVC3TRACK1.

The CVC3TRACK2 is generated in the same way by replacing IVCVC3TRACK1 with IVCVC3TRACK2.

Cryptographic Algorithms and Key ManagementIVCVC3 Generation


6.3 IVCVC3 Generation The IVCVC3TRACK1 and IVCVC3TRACK2 are issuer proprietary static data elements that are used as input for the generation of the CVC3TRACK1 and CVC3TRACK2 cryptograms.

IVCVC3TRACK1 is a MAC calculated over the static part of the Track 1 Data using the ICC Derived Key for CVC3 Generation. IVCVC3TRACK2 is a MAC calculated over the static part of the Track 2 Data also using the ICC Derived Key for CVC3 Generation.

The MAC is generated using DES encipherment as specified in Section 6.6 using KDCVC3 as the key. For the generation of IVCVC3TRACK1 the message M consists of the static part of the Track 1 Data. For the generation of IVCVC3TRACK2 the message M consists of the static part of the Track 2 Data. The two least significant bytes of the MAC are the IVCVC3TRACK1 or IVCVC3TRACK2.

6.4 Symmetric Keys for Application Cryptogram Generation Master keys for Application Cryptogram Generation are stored in the ICC during personalization. Refer to Section 8.6 for details. Derived session keys are stored in the AC Session Key data element.

6.4.1 M/Chip 2.05, M/Chip Lite 2.1 A unique 16-byte AC Master Key (MKAC) is stored in the ICC during personalization. For Application Cryptogram generation a session key valid only for the current Application Cryptogram is used. This 16-byte session key SKAC = (SKAC,L || SKAC,R) is derived from MKAC using:

• The 2-byte Application Transaction Counter (ATC) of the ICC

• A 4-byte terminal Unpredictable Number (UN)

The session key is derived as follows:

• SKAC,L: = DES3(MKAC)[(ATC || ‘F0’ || ‘00’ ||UN)], and

• SKAC,R: = DES3(MKAC)[(ATC || ‘0F’ || ‘00’ ||UN)]

Cryptographic Algorithms and Key Management Symmetric Keys for Application Cryptogram Generation



6.4.2 CCD A unique 16-byte AC Master Key (MKAC) is stored in the ICC during personalization. For Application Cryptogram generation the EMV Common Session Key Derivation Method (EMV CSK) is used in order to produce a session key, valid for the current transaction and derived from the MKAC.

This 16-byte session key SKAC = (SKAC,L || SKAC,R) is derived from MKAC using the 2-byte Application Transaction Counter (ATC) of the ICC.

The session key is derived as follows:

• SKAC,L: = DES3(MKAC)[(ATC || ‘F0’ || ‘00’ || ‘00’ || ‘00’ || ‘00’ || ‘00’)], and

• SKAC,R: = DES3(MKAC)[(ATC || ‘0F’ || ‘00’ || ‘00’ || ‘00’ || ‘00’ || ‘00’)].

The AC Session Key Counter is incremented and saved in non-volatile memory:

SAVE AC Session Key Counter (AC Session Key Counter +1)

If (AC Session Key Counter ≥ AC Session Key Counter Limit), then

• The 'Application Cryptogram Error Limit Exceeded' bit in the Security Limits Status is set: SET Security Limits Status [8] (1b)

• The application is disabled: SAVE Previous Transaction History [6] (1b)

6.4.3 UKIS A unique 16-byte AC Master Key (MKAC), consisting of two 8-byte keys Unique DEA Key A and Unique DEA Key B, is stored in the ICC during personalization, where

MKAC = Unique DEA Key A || Unique DEA Key B.

This key is used for Application Cryptogram generation according to Cryptogram Version 10.

Cryptogram Version 12: Not supported.

Cryptogram Version 14: Not supported.

Cryptographic Algorithms and Key ManagementICC Derived Key for CVC3 Generation (KDCVC3)


6.5 ICC Derived Key for CVC3 Generation (KDCVC3) This section specifies the key derivation method used to generate the ICC Derived Key for CVC3 Generation (KDCVC3).

KDCVC3 is a 16-byte DES3 key derived from the Issuer Master Key for CVC3 Generation (IMKCVC3) as follows: 1. Concatenate from left to right the PAN (without any hex ‘F’ padding) with the PAN

sequence number (if the PAN sequence number is not available, then it is replaced by a ‘00’ byte). If the result X is less than 16 digits long, pad it to the left with hexadecimal zeros in order to obtain an eight-byte number Y in numeric (n) format. If X is at least 16 digits long, then Y consists of the 16 rightmost digits of X in numeric (n) format.

2. Compute the two eight-byte numbers: ZL := DES3(IMKCVC3)[Y] ZR := DES3(IMKCVC3)[Y ⊕ (‘FF’||‘FF’||‘FF’||‘FF’||‘FF’||‘FF’||‘FF’||‘FF’)] and define: Z := (ZL || ZR).

KDCVC3 is defined to be Z, with the exception of the least significant bit of each byte of Z which is set to a value that ensures that each of the 16 bytes of KDCVC3 has an odd number of nonzero bits (this is to conform with the odd parity requirements for DES keys).

6.6 MAC Algorithm The following algorithm, commonly known as Retail MAC, is used for Application Cryptogram generation and for IVCVC3 generation:

ISO/IEC 9797-1 MAC algorithm 3 with block cipher DES, zero IV (8 bytes), and ISO9797-1 padding method 2. The MAC length must be 8 bytes.

Cryptographic Algorithms and Key Management MAC Algorithm



Data Elements LocationTransient Data Elements that Exist Beyond a Single C-APDU


7 Data Elements Location

7.1 Transient Data Elements that Exist Beyond a Single C-APDU Some transient data elements exist beyond a single C-APDU processing. All such transient data elements are created at application selection and are identified in Table 7.1.

Note Column 3 of Table 7.1 specifies when the data elements are used for the different modes (create/reset/kill/read/write). This information can be used to decide when to create and kill the variables in an implementation.

Table 7.1—Transient Data Elements Management

Data Element Mode C-APDU Usage

create SELECT

reset SELECT, GET PROCESSING OPTIONS

kill UNSELECT2

read first GENERATE AC

CDOL 1 Related Data

write first GENERATE AC

The CDOL 1 Related Data is used to compute the intermediate hash result if the response to the first GENERATE AC uses the Combined DDA/AC generation.

Furthermore CDOL 1 Related Data is used for the Additional Check Table.

create SELECT


kill UNSELECT


Card Verification Results


The Card Verification Results contains the results of checks performed for Card Risk Management.

The first part contains some information for the issuer. The second part is used by the PayPass – M/Chip Flex application to take a decision: the Card Verification Results is compared to the Card Issuer Action Codes during the Card Risk Management to decide which cryptogram is computed.

It is used as input to the MAC for first GENERATE AC.

2 UNSELECT does not designate a C-APDU supported by the PayPass – M/Chip Flex application, but is a generic term for any operation that de-activates the application. It is used here for convenience. Refer to section 3.1 for more details.

Data Elements Location Transient Data Elements that Exist Beyond a Single C-APDU




create SELECT


kill UNSELECT


Amount, Authorised


The Amount, Authorised is received from the terminal in the first GENERATE AC command.

It is used for Card Risk Management and as input to the MAC for the first GENERATE AC.

create SELECT


kill UNSELECT


Amount, Other


The Amount, Other is received from the terminal in the first GENERATE AC command.

It is used as input to the MAC for first GENERATE AC.

create SELECT


kill UNSELECT


Terminal Country Code


The Terminal Country Code is received from the terminal in the first GENERATE AC command.


create SELECT


kill UNSELECT


Transaction Currency Code


The Transaction Currency Code is received from the terminal in the first GENERATE AC command.


create SELECT


kill UNSELECT


Transaction Date


The Transaction Date is received from the terminal in the first GENERATE AC command.

It is used as input to the MAC for the first GENERATE AC.

create SELECT


kill UNSELECT


Transaction Type


The Transaction Type is received from the terminal in the first GENERATE AC command.

It is used as input to the MAC for the first GENERATE AC.

Data Elements LocationPersistent Data Elements



create SELECT


kill UNSELECT


Data Authentication Code


The Data Authentication Code is received from the terminal in the first GENERATE AC command.

It is used as part of the Issuer Application Data for the first GENERATE AC.

create SELECT


kill UNSELECT


ICC Dynamic Number

write GET PROCESSING OPTIONS

The ICC Dynamic Number is only present if CDA is supported.

The ICC Dynamic Number is computed by the PayPass – M/Chip Flex application in the GET PROCESSING OPTIONS.

It is used as input to the signed data in the first GENERATE AC with Combined DDA/AC generation.

7.2 Persistent Data Elements The persistent data elements that are supported by the PayPass – M/Chip Flex application are listed in this section.

Table 7.2 shows the persistent data elements for application selection and their access conditions.

Table 7.2—Persistent Data Elements for Application Selection

Data Element Length read record

internal update

get data

AID [5, 16] (wider range allowed) No No No

FCI [10, 64] (wider range allowed) No No No

Table 7.3 lists the persistent data elements referenced in the AFL and their access conditions.

Data Elements Location Persistent Data Elements



Table 7.3—Persistent Data Elements Referenced in the AFL

Tag Name read record

internal read

internal update

get data

‘56’ Track 1 Data Yes No No No ‘9F62’ PCVC3TRACK1 Yes No No No ‘9F63’ PUNATCTRACK1 Yes No No No ‘9F64’ NATCTRACK1 Yes No No No ‘9F65’ PCVC3TRACK2 Yes No No No ‘9F66’ PUNATCTRACK2 Yes No No No ‘9F67’ NATCTRACK2 Yes No No No ‘9F68’ Mag Stripe CVM List Yes No No No ‘9F6B’ Track 2 Data Yes No No No ‘9F6C’ Mag Stripe Application Version Number Yes No No No

‘9F42’ Application Currency Code Yes No No No

‘5F25’ Application Effective Date Yes No No No

‘5F24’ Application Expiration Date Yes No No No

‘9F07’ Application Usage Control Yes No No No

‘5A’ Application Primary Account Number Yes No No No

‘5F34’ Application PAN Sequence Number Yes No No No

‘9F0D’ Issuer Action Code – Default Yes No No No

‘9F0E’ Issuer Action Code – Denial Yes No No No

‘9F0F’ Issuer Action Code – Online Yes No No No

‘9F08’ Application Version Number Yes No No No

‘8C’ CDOL 1 Yes No No No

‘5F20’ Cardholder Name Yes No No No

‘5F28’ Issuer Country Code Yes No No No

‘9F4A’ SDA Tag List Yes No No No

‘57’ Track-2 Equivalent Data Yes No No No

‘8F’ Certification Authority Public Key Index Yes No No No

‘9F32’ Issuer Public Key Exponent Yes No No No

‘92’ Issuer Public Key Remainder Yes No No No

‘93’ Signed Application Data Yes No No No

‘90’ Issuer Public Key Certificate Yes No No No

‘9F47’ ICC Public Key Exponent Yes No No No

‘9F48’ ICC Public Key Remainder Yes No No No

‘9F46’ ICC Public Key Certificate Yes No No No

Data Elements LocationPersistent Data Elements


Table 7.4 lists the persistent data elements for Card Risk Management and their access conditions.

Table 7.4—Persistent Data Elements for Card Risk Management


internal read

internal update

get data

‘D5’ Application Control No Yes No Yes

‘9F14’ Lower Consecutive Offline Limit No Yes No Yes

‘9F23’ Upper Consecutive Offline Limit No Yes No Yes

‘CA’ Lower Cumulative Offline Transaction Amount

No Yes No Yes

‘CB’ Upper Cumulative Offline Transaction Amount

No Yes No Yes

‘C4’ Card Issuer Action Code – Default No Yes No Yes

‘C5’ Card Issuer Action Code – Online No Yes No Yes

‘C3’ Card Issuer Action Code – Decline No Yes No Yes

‘C9’ CRM Currency Code No Yes No Yes

‘D1’ Currency Conversion Table No Yes No Yes

‘D3’ Additional Check Table No Yes No Yes

‘C7’ CDOL 1 Related Data Length No Yes No Yes

‘C8’ CRM Country Code No Yes No Yes

Table 7.5 shows miscellaneous persistent data elements and their access conditions.

Table 7.5—Miscellaneous Persistent Data Elements


internal read

internal update

get data

– Co-application Indicator No Yes No No

– Key Derivation Index No Yes No No

‘DF01’ Security Limits No Yes No No

‘DF02’ Security Limits Status No Yes Yes Yes

‘9F7E’ Application Life Cycle Data No No No Yes

Data Elements Location Persistent Data Elements



Table 7.6 lists the persistent data elements for the GPO response and their access conditions.

Table 7.6—Persistent Data Elements for the GPO Response


internal read

internal update

get data

‘94’ Application File Locator No No No Yes

‘82’ Application Interchange Profile No No No Yes

Table 7.7 lists the persistent data elements for the COMPUTE CRYPTOGRAPHIC CHECKSUM command and their access conditions.

Table 7.7—Persistent Data Elements for COMPUTE CRYPTOGRAPHIC CHECKSUM


internal read

internal update

get data

-- Static CVC3TRACK1 No Yes No No

-- Static CVC3TRACK2 No Yes No No

-- IVCVC3TRACK1 No Yes No No

-- IVCVC3TRACK2 No Yes No No

Table 7.8 lists the persistent data elements for the Counters and Previous Transaction History and their access conditions.

Table 7.8—Persistent Data Elements for Counters and Previous Transaction History


internal read

internal update

get data

‘9F36’ Application Transaction Counter No Yes Yes As part of Counters

Application Transaction Counter Limit No Yes No No

Cumulative Offline Transaction Amount No Yes Yes No

Consecutive Offline Transactions Number No Yes Yes No

AC Session Key Counter No Yes Yes No

AC Session Key Counter Limit No Yes No No

Previous Transaction History No Yes Yes No

Data Elements LocationSecret Keys


7.3 Secret Keys The secret keys that are listed in this section are supported by the PayPass – M/Chip Flex application.

Table 7.9 shows the Triple DES key for CVC3 generation.

Table 7.9—Triple DES Key for CVC3 Generation

Data Element length get data internal updateICC Derived Key for CVC3 Generation (KDCVC3) 16 No No

Table 7.10 shows the Triple DES key for ICC Dynamic Number generation. This key is only present if CDA is supported.

Table 7.10—Triple DES Key for ICC Dynamic Number Generation

Data Element length get data internal updateICC Dynamic Number Master Key (MKIDN) 16 No No

Table 7.11 shows the Triple DES master key for Session Key Derivation and Application Cryptogram generation. Refer to Section 6.4 for details.

Table 7.11—Triple DES Master Key for Session Key Derivation

Data Element length get data internal update

AC Master Key (MKAC) 16 No No

Table 7.12 shows the ICC's RSA private key and a related data element. These data elements are only present if CDA is supported.

Table 7.12—ICC's RSA Private Key

Data Element length get data internal update

Length of ICC Public Key Modulus (NIC) 1 No No

ICC Private Key Implemen-tation specific

No No

Data Elements Location Secret Keys



PersonalizationApplication Selection Data Elements


8 Personalization This section specifies the data elements that are available to the issuer for personalization. The personalization commands are not in the scope of this specification. They are left to the implementation.

8.1 Application Selection Data Elements Table 8.1 specifies the data elements used during the application selection process.

Table 8.1—Data Elements for Application Selection

Name Length Value AID 5 to16 Any binary value FCI var See Section A.26

8.2 COMPUTE CRYPTOGRAPHIC CHECKSUM Data Objects Table 8.2 lists the persistent card data elements used during the generation of CVC3TRACK1 and CVC3TRACK2.

Table 8.2—Data Elements for CVC3 Generation

Tag Data Element Length (bytes)

Format Value

-- Static CVC3TRACK1 2 Binary Refer to Section A.41

-- Static CVC3TRACK2 2 Binary Refer to Section A.42 -- IVCVC3TRACK1 2 Binary Refer to Section A.31 -- IVCVC3TRACK2 2 Binary Refer to Section A.32

Personalization Persistent Data Referenced in the AFL



8.3 Persistent Data Referenced in the AFL The data elements listed in Table 8.3 are the PayPass – Mag Stripe specific data elements and are included in record 1 of the record file with SFI 1.

Table 8.3—SFI 1 – Record 1

Tag Name Length (bytes) Presence ‘9F6C’ Mag Stripe Application Version Number (Card) 2 Mandatory ‘9F62’ Track 1 Bit Map for CVC3 (PCVC3TRACK1) 6 Conditional(1)

‘9F63’ Track 1 Bit Map for UN and ATC (PUNATCTRACK1) 6 Conditional(1) ‘56’ Track 1 Data var. up to 76 Optional ‘9F64’ Track 1 Nr of ATC Digits (NATCTRACK1) 1 Conditional (1) ‘9F65’ Track 2 Bit Map for CVC3 (PCVC3TRACK2) 2 Mandatory

‘9F66’ Track 2 Bit Map for UN and ATC (PUNATCTRACK2) 2 Mandatory ‘9F6B’ Track 2 Data var. up to 19 Mandatory ‘9F67’ Track 2 Nr of ATC Digits (NATCTRACK2) 1 Mandatory ‘9F68’ Mag Stripe CVM List var. up to 32 Mandatory

(1) This data element must be present if Track 1 Data is present.

Table 8.4 lists the data elements to be included in record 1 of the file with SFI 2. The file with SFI 2 shall have only one record. Record 1 of SFI 2 is the only record to be used as input for the generation of the Signed Static Application Data.


Tag Description Length (bytes) ‘57’ Track 2 Equivalent Data var. up to 19 ‘5A’ Application Primary Account Number (PAN) var. up to 10 ‘5F20’ Cardholder Name var. up to 26 ‘5F24’ Application Expiry Date 3 ‘5F25’ Application Effective Date 3 ‘5F28’ Issuer Country Code 2 ‘5F34’ PAN Sequence Number 1 ‘8C’ CDOL1 var. (refer to Section A.10) ‘8D’ CDOL2 var. ‘8E’ CVM List var. ‘9F07’ Application Usage Control 2 ‘9F08’ Application Version Number 2 ‘9F0D’ Issuer Action Code – Default 5 ‘9F0E’ Issuer Action Code – Denial 5 ‘9F0F’ Issuer Action Code – Online 5 ‘9F42’ Application Currency Code 2 ‘9F4A’ SDA Tag List var. up to 1

PersonalizationPersistent Data Referenced in the AFL


Table 8.5 and Table 8.6 list the data elements included in the first and second record of the file with SFI 3. These records include the data objects required to retrieve the Issuer Public Key and to perform static data authentication.


Tag Description Length (bytes) ‘8F’ Certification Authority Public Key Index 1 ‘9F32’ Issuer Public Key Exponent var. up to 3 ‘92’ Issuer Public Key Remainder NI-NCA+36 ‘90’ Issuer Public Key Certificate NCA


Tag Description Length (bytes) ‘93’ Signed Static Application Data NI

Table 8.7 and Table 8.8 list the data objects required to retrieve the ICC Public Key and to perform combined DDA/AC generation.


Tag Description Length (bytes) ‘9F47’ ICC Public Key Exponent var. up to 3 ‘9F48’ ICC Public Key Remainder NIC-NI+42


Tag Description Length ‘9F46’ ICC Public Key Certificate NI

Personalization Persistent Data Elements for GPO Response



8.4 Persistent Data Elements for GPO Response Table 8.9 lists the persistent data elements for the GPO response.

Table 8.9—Persistent Data Elements for GPO Response

Tag Data Element Length Format/Value supported

‘94’ Application File Locator 12 or 16 Binary

‘82’ Application Interchange Profile 2 Binary

For a card that supports only static data authentication, the AFL shall be personalized with the value:

’08 01 01 00 10 01 01 01 18 01 02 00’

For a card that supports combined DDA/AC generation, the AFL shall be personalized with the value:

’08 01 01 00 10 01 01 01 18 01 02 00 20 01 02 00’

The AIP includes the ‘M/Chip profile is supported’ bit and must be personalized as specified in Table 8.10 and Table 8.11.

Table 8.10—Byte 1 of the Application Interchange Profile

b8 b7 b6 b5 b4 b3 b2 b1 Meaning 0 RFU 0/1 Offline static data authentication supported 0 Offline dynamic data authentication supported 1 Cardholder verification supported 1 Terminal risk management to be performed 0 Issuer authentication supported 0 RFU 0/1 Combined DDA – GENERATE AC supported

Table 8.11—Byte 2 of the Application Interchange Profile

b8 b7 b6 b5 b4 b3 b2 b1 Meaning 1 M/Chip profile is supported 0 0 0 0 0 0 0 RFU

PersonalizationPersistent Data Elements for CRM


8.5 Persistent Data Elements for CRM The data elements listed in Table 8.12 are the persistent data elements for Card Risk Management.

Table 8.12—Persistent Data Elements for Card Risk Management

Tag Name Length (bytes) ‘D5’ Application Control 2 ‘9F14’ Lower Consecutive Offline Limit 1 ‘9F23’ Upper Consecutive Offline Limit 1 ‘CA’ Lower Cumulative Offline Transaction Amount 6 ‘CB’ Upper Cumulative Offline Transaction Amount 6 ‘C9’ CRM Currency Code 2 ‘D1’ Currency Conversion Table 25 ‘C8’ CRM Country Code 2 ‘C3’ Card Issuer Action Code – Decline 3 ‘C4’ Card Issuer Action Code – Default 3 ‘C5’ Card Issuer Action Code – Online 3 ‘D3’ Additional Check Table 18 ‘C7’ CDOL 1 Related Data Length 1

8.6 Secret Keys Table 8.13 lists the Triple DES keys.

Table 8.13—Triple DES Keys

Data Element Length (bytes) ICC Dynamic Number Master Key (MKIDN) (if CDA supported) 16 AC Master Key (MKAC) 16 ICC Derived Key for CVC3 Generation (KDCVC3) 16

Table 8.14 shows the ICC's RSA private key and a related data element (only if CDA supported).

Table 8.14—ICC's RSA Private Key

Data Element Length (bytes)

Length of ICC Public Key Modulus (NIC) 1

ICC Private Key Implementation specific

Personalization Miscellaneous



Note If the PayPass – M/Chip Flex application supports CDA, then it must accept any RSA key with modulus in the range 80 to128. The storage format of the RSA key is implementation specific. The card application developer must provide storage format details for the RSA keys.

8.7 Miscellaneous

Table 8.15 shows miscellaneous persistent data elements.

Table 8.15—Miscellaneous Persistent Data Elements

Tag Name Length (bytes)

– Co-application Indicator 1

– Key Derivation Index 1

‘9F7E’ Application Life Cycle Data 48

8.8 Counters and Previous Transaction History Table 8.16 lists those persistent data elements that are linked to the counters and keep track of previous transaction history.

Table 8.16—Counters and Previous Transaction

Name Length (bytes)

Application Transaction Counter Limit 2

Previous Transaction History 1

AC Session Key Counter Limit 2

PersonalizationData Elements with a Fixed Initial Value


8.9 Data Elements with a Fixed Initial Value

Table 8.17 lists data elements with a fixed initial value. The decision about whether to include these data elements as data to be personalized is implementation specific. If these data elements cannot be personalized, their initial values must be as specified in Table 8.17.

Table 8.17—Data Elements with a Fixed Initial Value

Name Length Initial Value

Cumulative Offline Transaction Amount 6 ‘000000000000’

Consecutive Offline Transaction Number 1 ‘00’

Application Transaction Counter 2 ‘0000’

AC Session Key Counter 2 ‘0000’

Personalization Data Elements with a Fixed Initial Value



Data Elements DictionaryAC Session Key Counter


Annex A: Data Elements Dictionary This annex lists the definitions of data elements that are supported by the PayPass – M/Chip Flex application and that are not provided by [PAYPASS M/CHIP], or that are constrained by the PayPass – M/Chip Flex application.

A.1 AC Session Key Counter Tag: – Format: b, 2 bytes Description: The AC Session Key Counter is a two-byte counter, initialized to zero and

counting the number of times the AC Master Key (MKAC) has been used to derive a session key in the case of a CCD compliant co-application. When the AC Session Key Counter has reached the AC Session Key Counter Limit, the application is disabled. PayPass – M/Chip Flex does not provide a mechanism to reset the AC Session Key Counter.

A.2 AC Session Key Counter Limit Tag: – Format: b, 2 bytes Description: The AC Session Key Counter Limit limits the number the AC Master Key

can be used to derive a session key in the case of a CCD compliant co-application. The AC Session Key Counter Limit is determined by the issuer at personalization time.

A.3 Additional Check Table Tag: ‘D3’ Format: b, 18 bytes Description: The Additional Check Table contains values that are compared to values

given by the terminal in CDOL 1 Related Data. The result of the comparison is reflected in the decision-making part of the Card Verification Results. The check with the Additional Check Table is only performed if Application Control [2][3] is set to 1b.

Data Elements Dictionary Application Control



A.4 Application Control Tag: ‘D5’ Format: b, 3 bytes Description: The Application Control activates or de-activates functions in the

application. The PayPass – M/Chip Flex application extends the definition of the Application Control of the M/Chip 4 contact-only application with 1 additional byte, which is used to activate or to de-activate options for the generation of the dynamic CVC3.

Byte 1 of the Application Control is coded according to Table A.1.

Table A.1—Byte 1 of the Application Control


x magstripe grade issuer activated

0 not supported

x skip CIAC-default on CAT3

0 do not skip CIAC-default on CAT3

1 skip CIAC-default on CAT3

x offline-only

0 not offline-only

1 offline-only

x key for offline encrypted PIN verification

0 not supported

x offline encrypted PIN verification

0 not supported

x offline plaintext PIN verification

0 not supported

x session key derivation

0 not supported

x encrypt offline counters

0 not supported


Data Elements DictionaryApplication Control




x x x x reserved

0 0 0 0 other values RFU

x always add to consecutive transaction number

0 do not add always

1 add always

x activate additional check table

0 do not activate additional check table

1 activate additional check table

x allow retrieval of balance

0 do not allow retrieval of balance

1 allow retrieval of balance

x include counters in AC

0 not supported




x indicate if Static CVC3 must be used

0 do not use Static CVC3

1 use Static CVC3

x include ATC in CVC3 generation

0 do not include ATC

1 include ATC

0 0 0 0 0 0 other values RFU

Data Elements Dictionary Application Life Cycle Data



A.5 Application Life Cycle Data Tag: ‘9F7E’ Format: b, 48 bytes Description: The purpose of the Application Life Cycle Data is to uniquely identify the

application code and the application issuer. The Application Life Cycle Data is coded as shown in Table A.4. The 7 bytes reserved for the Type Approval ID will contain an identifier given by MasterCard when the application has passed the Type Approval process. 20 bytes are reserved to identify the application issuer, most likely the card issuer. The issuer should, using this value, be able to identify the personalizer and the personalization batch. The last 20 bytes are used to uniquely identify the application code. This identifier must allow discrimination between any different behaviors of the application. Typically, this field may contain the identifier of the application provider and the identifier of the application code. It is left to the application provider to ensure that two different behaviors will always be discriminated with this field. The easiest way to implement this feature is to modify the value of this field at each modification of the application (version identifier), the application code (release identifier), the platform on which the application is actually running (e.g. virtual machine version x or y), and the hardware on which the platform or the application is actually running. The organization of the storage of these fields in the application is left to the implementation. The last field may be coded in the application itself (i.e. in the code) while the others are set at personalization.

Table A.4—Coding of Application Life Cycle Data

Field Length Format

Version Number 1 binary

Type Approval ID 7 binary

Application Issuer ID 20 binary

Application Code ID 20 binary

Data Elements DictionaryApplication Transaction Counter


A.6 Application Transaction Counter Tag: ‘9F36’ Format: b, 2 bytes Description: The Application Transaction Counter counts the number of transactions

processed by the application. The PayPass – M/Chip Flex application increments the ATC by 1 when it receives the GET PROCESSING OPTIONS command.

A.7 Application Transaction Counter Limit Tag: – Format: b, 2 bytes Description: The Application Transaction Counter Limit limits the number of

transactions processed by the application. When the Application Transaction Counter reaches the Application Transaction Counter Limit, the application will not process transactions anymore.

A.8 Card Issuer Action Code – Decline, Default, Online Tag: Card Issuer Action Code – Decline: ‘C3’

Card Issuer Action Code – Default: ‘C4’ Card Issuer Action Code – Online: ‘C5’

Format: b, 3 bytes each Description: The Card Issuer Action Codes (CIACs) are compared to the decisional part

of the Card Verification Results to take decisions: Card Issuer Action Code – Decline is used by the issuer to set the situations when a transaction is always declined at the first GENERATE AC. Card Issuer Action Code – Online is used by the issuer to set the situations when a transaction goes online if the terminal is online capable. Card Issuer Action Code – Default is used by the issuer to set the situations when a transaction is declined if the terminal is not online capable. The three Card Issuer Action Codes have the format given below.

CIAC Byte 1 is coded according to Table A.5.

Data Elements Dictionary Card Issuer Action Code – Decline, Default, Online



Table A.5—Coding of CIAC (Byte 1)


x Reserved-no meaning

0 Other value RFU

x Unable to go online indicated

0 Not supported

x Offline PIN verification not performed

0 Not supported

x Offline PIN verification failed

0 Not supported

x PTL exceeded

0 Not supported

x International transaction

0 Do not take action if International transaction

1 Take action if International transaction

x Domestic transaction

0 Do not take action if Domestic transaction

1 Take action if Domestic transaction

x Terminal erroneously considers offline PIN OK

0 Not supported


Data Elements DictionaryCard Issuer Action Code – Decline, Default, Online




x Lower consecutive offline limit exceeded

0 Do not take action if lower consecutive offline limit exceeded

1 Take action if lower consecutive offline limit exceeded

x Upper consecutive offline limit exceeded

0 Do not take action if upper consecutive offline limit exceeded

1 Take action if upper consecutive offline limit exceeded

x Lower cumulative offline limit exceeded

0 Do not take action if lower cumulative offline limit exceeded

1 Take action if lower cumulative offline limit exceeded

x Upper cumulative offline limit exceeded

0 Do not take action if upper cumulative offline limit exceeded

1 Take action if upper cumulative offline limit exceeded

x Go online on next transaction was set

0 Not supported

x Issuer Authentication failed

0 Not supported

x Script received

0 Not supported

x Script failed

0 Not supported


Data Elements Dictionary Card Verification Results





x x x x x x Reserved

0 0 0 0 0 0 Other values RFU

x Match found in Additional Check Table

0 Do not take action if match found in Additional Check Table

1 Take action if match found in Additional Check Table

x No match found in Additional Check Table

0 Do not take action if no match found in Additional Check Table

1 Take action if no match found in Additional Check Table

A.9 Card Verification Results Tag: ‘9F52’ Format: b, 6 bytes Description: The Card Verification Results contains transaction related information as

well as decision making information resulting from the Card Risk Management with regard to accepting a transaction offline, going online to the issuer, or declining a transaction.

Byte 1 of the Card Verification Results is coded according to Table A.8.

Data Elements DictionaryCard Verification Results


Table A.8—Coding of the Card Verification Results (Byte 1)


x x AC returned in second GENERATE AC

0 0 AAC

0 1 TC

1 0 Not requested

1 1 RFU

x x AC returned in first GENERATE AC

0 0 AAC

0 1 TC

1 0 ARQC

1 1 RFU

x Reserved

0 Other value RFU

x Offline PIN verification performed

0 Not supported

x Offline Encrypted PIN verification performed

0 Not supported

x Offline PIN verification successful

0 Not supported







x DDA Returned

0 Not supported

x Combined DDA/AC Generation returned in first GENERATE AC

0 Combined DDA/AC Generation not returned in first GENERATE AC

1 Combined DDA/AC Generation returned in first GENERATE AC

x Combined DDA/AC Generation returned in second GENERATE AC

0 Not supported

x Issuer Authentication performed

0 Not supported

x CIAC-Default skipped On CAT3

0 Not supported

x x x Reserved

0 0 0 All other values RFU




x x x x Right nibble of Script Counter

0 0 0 0 Not supported

x x x x Right nibble of PIN Try Counter

0 0 0 0 Not supported


Data Elements DictionaryCard Verification Results




x Reserved

0 Other value RFU

x Unable to go online indicated

0 Not supported

x Offline PIN verification not performed

0 Not supported

x Offline PIN verification failed

0 Not supported

x PTL exceeded

0 Not supported

x International transaction

0 Domestic transaction

1 International transaction

x Domestic transaction

0 International transaction

1 Domestic transaction

x Terminal erroneously considers Offline PIN OK

0 Not supported







x Lower Consecutive Offline Limit exceeded

0 Lower Consecutive Offline Limit not exceeded

1 Lower Consecutive Offline Limit exceeded

x Upper Consecutive Offline Limit exceeded

0 Upper Consecutive Offline Limit not exceeded

1 Upper Consecutive Offline Limit exceeded

x Lower Cumulative Offline Limit exceeded

0 Lower Cumulative Offline Limit not Exceeded

1 Lower Cumulative Offline Limit exceeded

x Upper Cumulative Offline Limit exceeded

0 Upper Cumulative Offline Limit not exceeded

1 Upper Cumulative Offline Limit exceeded


0 Not supported


0 Not supported

x Script received

0 Not supported

x Script failed

0 Not supported




x x x x x x Reserved

0 0 0 0 0 0 Other value RFU

x Match Found in Additional Check Table

0 No match found in Additional Check Table

1 Match found in Additional Check Table

x No Match Found in Additional Check Table

0 Match found in Additional Check Table

1 No match found in Additional Check Table

Data Elements DictionaryCDOL 1


A.10 CDOL 1 Tag: ‘8C’ Format: b, var. Description: Informs the terminal of data needed by the ICC in the first GENERATE AC

command.

Table A.14 defines the content of the CDOL 1 for the PayPass – M/Chip Flex application.

Table A.14—Content of the CDOL 1

Data Element Tag Length

Amount Authorized (Numeric) ‘9F02’ 6

Amount Other (Numeric) ‘9F03’ 6

Terminal Country Code ‘9F1A’ 2

Terminal Verification Results ‘95’ 5

Transaction Currency code ‘5F2A’ 2

Transaction Date ‘9A’ 3

Transaction Type ‘9C’ 1

Unpredictable Number ‘9F37’ 4

Terminal Type ‘9F35’ 1

Data Authentication Code ‘9F45’ 2

A.11 CDOL 1 Related Data Length Tag: ‘C7’ Format: b, 1 byte Description: Contains the length of CDOL 1 Related Data. If no extension to CDOL 1

Related Data is used, the CDOL 1 Related Data Length value is '20'.

The PayPass – M/Chip Plus application allows the extension of this value by at least 10 bytes. The personalization value for CDOL 1 Related Data Length must be consistent with the personalization value for CDOL 1.

Data Elements Dictionary Co-application Indicator



A.12 Co-application Indicator Tag: – Format: b, 1 byte Description: The Co-application Indicator is a persistent data element personalized by

the issuer. It defines the active co-application. Table A.15 shows the Co-application Indicator coding.

Table A.15—Co-application Indicator Coding


0 0 0 0 0 0 Other values RFU

0 0 M/Chip Lite 2.1 co-application active

0 1 M/Chip 2.05 co-application active

1 0 UKIS co-application active

1 1 CCD-compliant co-application active

A.13 Consecutive Offline Transactions Number Tag: – Format: b, 1 byte Description: The Consecutive Offline Transactions Number represents the number of

transactions accepted offline and which have not been cumulated in the Cumulative Offline Transaction Amount. The offline counters are internally compared to the offline limits. If a counter has exceeded its lower or upper limit, the relevant Card Verification Results bit is set.

A.14 Counters Tag: ‘C6’ Format: b, 10 bytes Description: Counters is the concatenation of internal counters as specified in

Table A.16.

Table A.16—Content of Counters

Element Length

Application Transaction Counter 2

AC Session Key Counter 2

RFU 6

Data Elements DictionaryCRM Country Code


A.15 CRM Country Code Tag: ‘C8’ Format: n 3, 2 bytes Description: The CRM Country Code is used to differentiate between domestic

transactions (when the CRM Country Code matches the Terminal Country Code) and international transactions (when the CRM Country Code does not match the Terminal Country Code). This may have an influence on the Card Risk Management, depending on the Card Issuer Action Codes settings.

A.16 CRM Currency Code Tag: ‘C9’ Format: n 3, 2 bytes Description: The CRM Currency Code is the currency of the Cumulative Offline

Transaction Amount.

A.17 Cryptogram Information Data Tag: '9F27’' Format: b, 1 byte Description: The Cryptogram Information Data contains Application Cryptogram

related information. If Co-application Indicator [2-1] = 10b (co-application UKIS is active), or if Co-application Indicator [2-1] = 01b (co-application M/Chip 2.05 is active), or if Co-application Indicator [2-1] = 00b (co-application M/Chip Lite 2.1 is active), then the Cryptogram Information Data is coded according to [EMV BOOK 3], Section 6.5.5.4. If Co-application Indicator [2-1] = 11b (CCD-compliant co-application is active), then the Cryptogram Information Data is coded according to Table CCD 3 in the CCD section of [EMV BOOK 3].

A.18 Cryptogram Version Number Tag: – Format: b, 1 byte Description: The Cryptogram Version Number informs the issuer about algorithm and

data used for Application Cryptogram computation.

Data Elements Dictionary Cumulative Offline Transaction Amount



A.19 Cumulative Offline Transaction Amount Tag: – Format: n, 12 Description: The Cumulative Offline Transaction Amount represents the cumulative

value of transactions accepted offline. Transactions can be cumulated if they are in the counter currency or if they are in a currency that can be converted into the counter currency by the application. The offline counters are internally compared to the offline limits. If a counter has exceeded its lower or upper limit, the relevant Card Verification Results bit is set.

A.20 Currency Conversion Parameters Tag: – Format: b, 5 bytes Description: Used to convert transactions in recognized currencies into transactions in

the counter currency. See Table A.17 for details.

Table A.17— Currency Conversion Parameters

Position Data Length Value

Byte 1-2 Currency Code 2 Issuer specific

Byte 3-4 Conversion Rate 2 Decimal, BCD coding of multiplication factor

Byte 5 Conversion Exponent 1 Binary coding of 10-power (most significant bit is the sign)

A.21 Currency Conversion Table Tag: ‘D1’ Format: b, 25 bytes Description: The Currency Conversion Table is used to convert transactions in

recognized currencies into transactions in the counter currency. See Table A.18 for details.

Table A.18—Currency Conversion Table

Data Element Length

Currency Conversion Table 25

Currency Conversion Parameters 1 5





Data Elements DictionaryCVR – CCD


A.22 CVR – CCD Tag: ‘9F52’ Format: b, 5 bytes Description: The CVR - CCD contains the CVR for a CCD-compliant co-application.

Byte 1 of the CVR - CCD is coded according to Table A.19.

Table A.19—Coding of CVR - CCD (Byte 1)


x x Application Cryptogram Type returned in second GENERATE AC:

0 0 Not supported

0 1 Not supported

1 0 Second GENERATE AC not requested

1 1 RFU

x x Application Cryptogram Type returned in first GENERATE AC:

0 0 AAC

0 1 TC

1 0 ARQC

1 1 RFU

x CDA performed

1 'Combined DDA/AC Generation returned in first GENERATE AC' bit = 1 in Card Verification Results

0 'Combined DDA/AC Generation not returned in first GENERATE AC ' bit = 1 in Card Verification Results

x Offline DDA performed

0 DDA not supported

x Issuer Authentication not performed

0 Issuer Authentication not supported




Data Elements Dictionary CVR – CCD





x x x x Low order nibble of PIN Try Counter

0 0 0 0 VERIFY command not supported

x Offline PIN verification performed

0 VERIFY command not supported

x Offline PIN verification performed and PIN not successfully verified


x PIN Try Limit exceeded


x Last online transaction not completed

0 PayPass never completes online transactions




x Lower Offline Transaction Count Limit exceeded

1 Lower Consecutive Offline Limit Exceeded' bit = 1 in Card Verification Results

0 'Lower Consecutive Offline Limit Exceeded' bit = 0 in Card Verification Results

x Upper Offline Transaction Count Limit exceeded

1 Upper Consecutive Offline Limit Exceeded' bit = 1 in Card Verification Results

0 'Upper Consecutive Offline Limit Exceeded' bit = 0 in Card Verification Results

x Lower Cumulative Offline Amount Limit exceeded

1 'Lower Cumulative Offline Limit Exceeded' bit = 1 in Card Verification Results

0 'Lower Cumulative Offline Limit Exceeded' bit = 0 in Card Verification Results

x Upper Cumulative Offline Amount Limit exceeded

1 'Upper Cumulative Offline Limit Exceeded' bit = 1 in Card Verification Results

0 'Upper Cumulative Offline Limit Exceeded' bit = 0 in Card Verification Results

Data Elements DictionaryCVR – CCD



x Issuer-discretionary bit 1

0 Not used


0 Not used


0 Not used


0 Not used




x x x x Number of Issuer Script commands containing secure messaging processed

0 0 0 0 Issuer-to-card Script Processing not supported

x Issuer script processing failed

0 Issuer-to-card Script Processing not supported

x Offline data authentication failed on previous transaction

0 Information not available from terminal because card is removed after first GENERATE AC



x Unable to go online





0 0 0 0 0 0 0 0 RFU

Data Elements Dictionary CVR - M/Chip 2.05



A.23 CVR - M/Chip 2.05 Tag: ‘9F52’ Format: b, 4 bytes Description: The CVR - M/Chip 2.05 contains the CVR for a co-application

M/Chip 2.05.

Byte 1 of the CVR - M/Chip 2.05 indicates the CVR length and is set to '03'.

Byte 2 of the CVR - M/Chip 2.05 is coded according to Table A.24.

Table A.24—Coding of CVR - M/Chip 2.05 (Byte 2)


x x Type of Application Cryptogram returned in second GENERATE AC:

0 0 Not supported

0 1 Not supported

1 0 Second GENERATE AC not requested (true for first issuance of GENERATE AC, false for the second issuance)

1 1 RFU

x x Type of Application Cryptogram returned in first GENERATE AC:

0 0 AAC

0 1 TC

1 0 ARQC

1 1 RFU



x Offline PIN Verification performed

0 Offline PIN Verification not supported

x Offline PIN Verification failed





Data Elements DictionaryCVR - M/Chip 2.05






x Pin Try Limit exceeded


x Exceeded velocity checking

1 'Lower Consecutive Offline Limit Exceeded' bit = 1 or 'Upper Consecutive Offline Limit Exceeded' bit = 1 in Card Verification Results

0 'Lower Consecutive Offline Limit Exceeded' bit = 0 and 'Upper Consecutive Offline Limit Exceeded' bit = 0 in Card Verification Results

x New card

0 Not supported

x Issuer Authentication failure on last online transaction

0 No Issuer Authentication supported because card is removed after first GENERATE AC

x Issuer Authentication not performed after online authorization


0 Not set by the application

x Static Data Authentication failed on last transaction and transaction declined offline

0 Information not available from terminal because card is removed after first GENERATE AC (SDA performed after GENERATE AC)


Data Elements Dictionary CVR - M/Chip 2.05





x x x Number of Issuer Script Commands containing secure messaging processed on last transaction

0 0 0 Issuer-to-card Script Processing not supported

x DDA failed on last transaction and transaction declined offline

0 DDA not supported

x Issuer script processing failed on last transaction


x Lower Consecutive Offline Limit or Lower Cumulative Offline Transaction Amount exceeded

1 'Lower Consecutive Offline Limit Exceeded' bit = 1 or 'Lower Cumulative Offline Limit Exceeded' bit = 1 in Card Verification Results

0 'Lower Consecutive Offline Limit Exceeded' bit = 0 and 'Lower Cumulative Offline Limit Exceeded' bit = 0 in Card Verification Results

x Upper Consecutive Offline Limit or Upper Cumulative Offline Transaction Amount exceeded

1 'Upper Consecutive Offline Limit Exceeded' bit = 1 or 'Upper Cumulative Offline Limit Exceeded' bit = 1 in Card Verification Results

0 'Upper Consecutive Offline Limit Exceeded' bit = 0 and 'Upper Cumulative Offline Limit Exceeded' bit = 0 in Card Verification Results

x Maximum offline transaction amount exceeded

0 Not supported

Data Elements DictionaryCVR - M/Chip Lite 2.1


A.24 CVR - M/Chip Lite 2.1 Tag: ‘9F52’ Format: b, 4 bytes Description: The CVR - M/Chip Lite 2.1 contains the CVR for a co-application

M/Chip Lite 2.1.

Byte 1 of the CVR - M/Chip Lite 2.1 indicates the CVR length and is set to '03'.

Byte 2 of the CVR - M/Chip Lite 2.1 is coded according to Table A.27.

Table A.27—Coding of CVR - M/Chip Lite 2.1 (Byte 2)



0 0 Not supported

0 1 Not supported


1 1 RFU


0 0 AAC

0 1 TC

1 0 ARQC

1 1 RFU




0 Offline PIN not supported






Data Elements Dictionary CVR - M/Chip Lite 2.1









x Exceeded velocity checking

1 'Lower Consecutive Offline Limit Exceeded' bit = 1 or 'Upper Consecutive Offline Limit Exceeded' bit = 1 in Card Verification Results

0 'Lower Consecutive Offline Limit Exceeded' bit = 0 and 'Upper Consecutive Offline Limit Exceeded' bit = 0 in Card Verification Results

x New card

0 Not supported





x Application blocked by card because PIN Try Limit exceeded


x Offline Static Data Authentication failed on last transaction

0 Information not available from terminal because card is removed after first GENERATE AC (SDA performed after GENERATE AC)


Data Elements DictionaryCVR - M/Chip Lite 2.1




x x x Number of script commands processed successfully

0 0 0 Issuer-to-card Script Processing not supported

0 Not used

x Issuer script processing failed on last or current transaction


x Lower Consecutive Offline Limit or Lower Cumulative Offline Transaction Amount exceeded

1 'Lower Consecutive Offline Limit Exceeded' bit = 1 or 'Lower Cumulative Offline Limit Exceeded' bit = 1 in Card Verification Results

0 'Lower Consecutive Offline Limit Exceeded' bit = 0 and 'Lower Cumulative Offline Limit Exceeded' bit = 0 in Card Verification Results

x Upper Consecutive Offline Limit or Upper Cumulative Offline Transaction Amount exceeded

1 'Upper Consecutive Offline Limit Exceeded' bit = 1 or 'Upper Cumulative Offline Limit Exceeded' bit = 1 in Card Verification Results

0 'Upper Consecutive Offline Limit Exceeded' bit = 0 and 'Upper Cumulative Offline Limit Exceeded' bit = 0 in Card Verification Results

0 Not used

Data Elements Dictionary CVR - UKIS



A.25 CVR - UKIS Tag: ‘9F52’ Format: b, 4 bytes Description: The CVR - UKIS contains the CVR for a co-application UKIS.

Byte 1 of the CVR - UKIS indicates the CVR length and is set to '03'.

Byte 2 of the CVR - UKIS is coded according to Table A.30.

Table A.30—Coding of CVR – UKIS (Byte 2)



0 0 Not supported

0 1 Not supported


1 1 RFU


0 0 AAC

0 1 TC

1 0 ARQC

1 1 AAR (not supported)

x Issuer Authentication performed and failed









Data Elements DictionaryCVR - UKIS


Table A.31—Coding of CVR – UKIS (Byte 3)






x Exceeded velocity checking counters

1 'Lower Consecutive Offline Limit Exceeded' bit = 1 or 'Lower Cumulative Offline Limit Exceeded' bit = 1 or 'Upper Consecutive Offline Limit Exceeded' bit = 1 or 'Upper Cumulative Offline Limit Exceeded' bit = 1 in Card Verification Results

0 'Lower Consecutive Offline Limit Exceeded' bit = 0 and 'Lower Cumulative Offline Limit Exceeded' bit = 0 and 'Upper Consecutive Offline Limit Exceeded' bit = 0 and 'Upper Cumulative Offline Limit Exceeded' bit = 0 in Card Verification Results

x New card

0 Not supported





x Application blocked by card because PIN Try Limit exceeded


x Offline Static Data Authentication failed on last transaction and transaction declined offline



Data Elements Dictionary File Control Information



Table A.32—Coding of CVR - UKIS (Byte 4)


x x x x Number of Issuer Script Commands received after the second GENERATE AC command containing secure messaging processed on last transaction

0 0 0 0 Issuer-to-card Script Processing not supported

x Issuer script processing failed on last transaction


x Offline dynamic data authentication failed on last transaction and transaction declined offline

0 Dynamic Data Authentication not supported

x Offline dynamic data authentication performed

0 Dynamic Data Authentication not supported

0 RFU

A.26 File Control Information Tag: ‘6F’ (FCI template) Format: b, length is variable Description: The File Control Information (FCI) is not interpreted by the application. It

is simply returned in the response to the SELECT. The FCI must be personalized by the issuer to values compliant to [PAYPASS MCHIP]. Since the PayPass – M/Chip Flex application does not use the PDOL to receive data from the terminal in the GET PROCESSING OPTIONS, having a PDOL in the FCI is not allowed. Table A.33 shows the coding of the FCI.

Table A.33—FCI Coding

Tag Value Presence

‘6F’ FCI Template Mandatory

‘84’ DF Name Mandatory

‘A5’ FCI Proprietary Template Mandatory

‘50’ Application Label Optional

‘87’ Application Priority Indicator Optional

‘5F2D’ Language Preference Optional

‘9F11’ Issuer Code Table Index Optional

‘9F12’ Application Preferred Name Optional

‘BF0C’ FCI Issuer Discretionary Data Optional

Data Elements DictionaryIssuer Application Data (CCD)


A.27 Issuer Application Data (CCD) Tag: ‘9F10’ Format: b, 32 bytes Description: The Issuer Application Data (IAD) generated by the PayPass – M/Chip

Flex application contain transaction related information for the issuer. The IAD for a CCD-compliant co-application is coded as specified in the CCD Part of EMV Book 3, Annex C.7, for a CCD-compliant application with a Format Code of 'A' with Cryptogram Version of '4'. The coding is shown in Table A.34.

Table A.34—Coding of CCD-compliant Issuer Application Data

IAD Byte Description Comment

1 Length Indicator '0F'

2 Common Core Identifier (CCI) 'A4'

3 Derivation Key Index (DKI) Issuer-discretionary

4-8 CVR – CCD The Card Verification Results from Card Risk Management processing

9-16 Counters Cumulative Offline Transaction Amount || Consecutive Offline Transaction Number || 'FF'

17 Length Indicator '0F'

18-32 Issuer-Discretionary any

A.28 Issuer Application Data (M/Chip 2.05) Tag: ‘9F10’ Format: b, 8 bytes Description: The Issuer Application Data (IAD) generated by the PayPass – M/Chip

Flex application contains transaction related information for the issuer. The IAD for an M/Chip 2.05 co-application is coded according to Table A.35.

Table A.35—Coding of M/Chip 2.05 Issuer Application Data


1 Derivation Key Index Determined by issuer

2 Cryptogram Version Number Determined by issuer

3-6 CVR - M/Chip 2.05 The Card Verification Results from Card Risk Management processing

7-8 Data Validation Response Data Authentication Code if SDA is performed. Otherwise, set to zero.

Data Elements Dictionary Issuer Application Data (M/Chip Lite 2.1)



A.29 Issuer Application Data (M/Chip Lite 2.1) Tag: ‘9F10’ Format: b, 8 bytes Description: The Issuer Application Data (IAD) generated by the PayPass – M/Chip

Flex application contains transaction related information for the issuer. The IAD for an M/Chip Lite 2.1 co-application is coded according to Table A.36.

Table A.36—Coding of M/Chip Lite 2.1 Issuer Application Data


1 Key Derivation Index Determined by issuer

2 Cryptogram Version Number Determined by issuer

3-6 CVR - M/Chip Lite 2.1 The Card Verification Results from Card Risk Management processing

7-8 Data Authentication Code Determined by issuer

A.30 Issuer Application Data (UKIS) Tag: ‘9F10’ Format: b, 23 bytes Description: The Issuer Application Data (IAD) generated by the PayPass – M/Chip

Flex application contains transaction related information for the issuer. The IAD for an UKIS co-application is coded according to Table A.37.

Table A.37—Coding of UKIS Issuer Application Data


1 Length Indicator

2 Derivation Key Index (DKI) Assigned by the issuer (default '00')

3 Cryptogram Version Number Assigned by Visa, value supported: '0A'

4-7 CVR – UKIS The Card Verification Results from Card Risk Management processing

8-23 Issuer Discretionary Data Optional, first byte indicates length

Data Elements DictionaryIVCVC3TRACK1


A.31 IVCVC3TRACK1 Tag: ‘DC’ Format: b, 2 bytes Description: The IVCVC3TRACK1 is an issuer proprietary static data element that is used as

input for the generation of the CVC3TRACK1 cryptogram. Refer to Section 6.3 for a detailed description of the generation of IVCVC3TRACK1.

A.32 IVCVC3TRACK2 Tag: ‘DD’ Format: b, 2 bytes Description: The IVCVC3TRACK2 is an issuer proprietary static data element that is used as

input for the generation of the CVC3TRACK2 cryptogram. Refer to Section 6.3 for a detailed description of the generation of IVCVC3TRACK2.

A.33 Key Derivation Index Tag: – Format: b, 1 byte Description: The Key Derivation Index is an issuer specific data element.

A.34 Lower Consecutive Offline Limit Tag: ‘9F14’ Format: b, 1 byte Description: If the Consecutive Offline Transactions Number has exceeded this limit, the

relevant CVR bit is set.

A.35 Lower Cumulative Offline Transaction Amount Tag: ‘CA’ Format: n, 12 Description: If the Cumulative Offline Transaction Amount has exceeded this limit, the

relevant Card Verification Results bit is set.

Data Elements Dictionary Offline Balance



A.36 Offline Balance Tag: ‘9F50’ Format: n, 12 Description: The Offline Balance represents the amount of offline spending available and

can be retrieved by the GET DATA command, if allowed by the Application Control. The Offline Balance is computed as follows: Offline Balance = Upper Cumulative Offline Transaction Amount - Cumulative Offline Transaction Amount

A.37 Offline Consecutive Transactions Remaining Tag: ‘9F7A’ Format: b, 1 byte Description: The Offline Consecutive Transactions Remaining represents the remaining

number of offline consecutive transactions which have not been cumulated in the Cumulative Offline Transaction Amount.

The Offline Consecutive Transactions Remaining is retrievable by the GET DATA command, if allowed by the Application Control and is computed as follows: Offline Consecutive Transactions Remaining = Upper Consecutive Offline Limit – Consecutive Offline Transactions Number.

A.38 Previous Transaction History Tag: – Format: b, 1 byte Description: The Previous Transaction History is used to store information about

previous transactions in non-volatile memory. It is used in Card Risk Management. The Previous Transaction History is coded as shown in Table A.38.

Data Elements DictionarySecurity Limits


Table A.38—Previous Transaction History Coding


x x Reserved

0 0 Other value RFU

x Application disabled

0 Application is not disabled

1 Application is disabled

x Application blocked

0 Application is not blocked

1 Application is blocked

x Go online on next transaction

0 Not supported


0 Not supported

x Script received

0 Not supported

x Script failed

0 Not supported

A.39 Security Limits Tag: ‘DF01’ Format: b, 2 bytes Description: The Security Limits data element contains the concatenation of security

limits associated with internal security-related counters. The format of the Security Limits data element is shown in Table A.39.

Table A.39—Content of Security Limits

Element Length

AC Session Key Counter Limit 2

Data Elements Dictionary Security Limits Status



A.40 Security Limits Status Tag: ‘DF02’ Format: b, 1 byte Description: The Security Limits Status data element is introduced for forensic reasons to

make it possible to determine that a security counter has reached its limit. The format of the Security Limits Status data element is shown in Table A.40.

Table A.40—Content of Security Limits Status


1 Application Cryptogram Error Limit Exceeded

0 not used

0 0 0 0 0 0 RFU

A.41 Static CVC3TRACK1 Tag: ‘DA’ Format: b, 2 bytes Description: The Static CVC3TRACK1 is the static variant of the dynamic CVC3 of the

track 1 data converted into the binary format (e.g. a Static CVC3TRACK1 with value “812” in ans format is stored as ‘032C’). The PayPass – M/Chip Flex application returns the Static CVC3TRACK1 instead of the dynamically calculated CVC3TRACK1 if Application Control [3][8] = 1b.

A.42 Static CVC3TRACK2 Tag: ‘DB’ Format: b, 2 bytes Description: The Static CVC3TRACK2 is the static variant of the dynamic CVC3 of the

track 2 data converted into the binary format (e.g. a Static CVC3TRACK2 with value 812 in numeric (n) format is stored as ‘032C’). The PayPass – M/Chip Flex application returns the Static CVC3TRACK2 instead of the dynamically calculated CVC3TRACK2 if Application Control [3] [8] = 1b.

Data Elements DictionaryUpper Consecutive Offline Limit


A.43 Upper Consecutive Offline Limit Tag: ‘9F23’ Format: b, 1 byte Description: If the Consecutive Offline Transactions Number has exceeded this limit, the


A.44 Upper Cumulative Offline Transaction Amount Tag: ‘CB’ Format: n, 12 Description: If the Cumulative Offline Transaction Amount has exceeded this limit, the


Data Elements Dictionary Upper Cumulative Offline Transaction Amount



Currency ConversionCurrency Conversion Process


Annex B: Currency Conversion This appendix describes the mechanism of currency conversion used by the PayPass – M/Chip Flex application.

B.1 Currency Conversion Process The currency conversion mechanism allows the PayPass – M/Chip Flex application to accumulate - in the Cumulative Offline Transaction Amount - transaction amounts in five additional currencies.

The method used for recording offline transactions in the two offline counters is as follows:

• The application checks if the Transaction Currency Code is the CRM Currency Code.

• If the Transaction Currency Code is equal to the CRM Currency Code, then the Amount, Authorised is added to the Cumulative Offline Transaction Amount.

• If the Transaction Currency Code is not equal to the CRM Currency Code, then the application checks whether the Transaction Currency Code is equal to one of the five entries in the Currency Conversion Table, i.e. the Transaction Currency Code is equal to the currency code of one of the Currency Conversion Parameters.

• If the Transaction Currency Code is equal to one of the five entries in the Currency Conversion Table, then the Amount Authorized is converted into the counter currency, and the converted amount is added to the Cumulative Offline Transaction Amount.

If the Transaction Currency Code is not equal to one of the five currencies in the Currency Conversion Table, then the Consecutive Offline Transactions Number is incremented by 1.

Figure B.1 illustrates the currency conversion process.

Currency Conversion Currency Conversion Parameters



Figure B.1—Cumulated Transaction Amounts with Currency Conversion

transaction currencyis in the

conversion table?

yes

no

transaction currencyis the

application currency

add amount to cumulative amount

yes

convert amount to application currency

add converted amount to cumulative amount

add transaction to consecutive

number

no

?

B.2 Currency Conversion Parameters Currency conversion uses the following parameters:

• Amount, Authorised

• The Currency Conversion Parameters corresponding to the Transaction Currency Code, as described in Table B.1.

Table B.1—Currency Conversion Parameters

Position Data Length Value

Byte 1-2 Currency Code 2 Issuer specific

Byte 3-4 Conversion Rate 2 Decimal, BCD coding of multiplication factor

Byte 5 Conversion Exponent 1 Binary coding of 10-power (most significant bit is the sign)

Currency ConversionCurrency Conversion Algorithm


B.3 Currency Conversion Algorithm If (conversion exponent [8]=0b) then

{

Amount in Counter Currency = Amount, Authorised * conversion rate * 10 conversion exponent [7-1]

If (Amount in Counter Currency > 999999999999) then an overflow occurs.

}

If (conversion exponent [8]=1b) then

{

Amount in Counter Currency = Amount, Authorised * conversion rate / 10 conversion exponent [7-1]

the division is the integer division3

If (Amount in Counter Currency > 999999999999) then an overflow occurs.

}

3 the integer division is the truncated division, which can be implemented as a shift.

Currency Conversion Currency Conversion Algorithm



CVR Mapping TablesCurrency Conversion Algorithm


Annex C: CVR Mapping Tables This annex illustrates the CVR mapping mechanism of the PayPass – M/Chip Flex application. First, Card Risk Management defines the Card Verification Results. Secondly, the Card Verification Results are mapped on the CVR belonging to the co-application.

A hit in the table between a Card Verification Results bit and a co-application CVR bit is to be interpreted in the following way. If a Card Verification Results bit is set, then the relating co-application CVR bit must also be set.

It may be possible that several Card Verification Results bits are related to only one co-application CVR bit. In this case the co-application CVR bit is set if at least one of the related Card Verification Results bits is set. Refer to Figure C.1, Card Verification Results [5] [7, 8], as an example for this behavior.

Only CVR bits marked bold are used.

CVR Mapping Tables CVR Mapping Table for M/Chip 2.05



C.1 CVR Mapping Table for M/Chip 2.05 Figure C.1—CVR Mapping Table for M/Chip 2.05

Issu

er sc

ript p

roc.

faile

d on

last

tran

s.

"

UC

OL

or

UC

OT

A e

xcee

ded

LC

OL

or

LC

OT

A e

xcee

ded

DD

A fa

iled

on la

st tr

ans.

and

trans

. dec

l. of

fl.

AC

Typ

e re

turn

ed in

firs

t Gen

erat

e A

C

Off

line

PIN

Ver

ifica

tion

perf

orm

ed

AC

Typ

e re

turn

ed in

seco

nd G

ener

ate

AC

Issu

er A

uthe

ntic

atio

n fa

iled

"

"

Not

set b

y th

e ap

plic

atio

n

"

Issu

er A

uth.

failu

re o

n la

st o

nlin

e tra

nsac

tion

N. o

f Iss

. Scr

ipt C

om. c

on. s

m p

r. on

last

tran

s.SD

A fa

iled

on la

st tr

ans.

and

trans

. dec

l. of

fl.

Issu

er A

uth.

not

per

form

ed a

fter o

nlin

e au

thor

.

Last

onl

ine

trans

actio

n no

t com

plet

ed

New

car

d

Off

line

PIN

Ver

ifica

tion

faile

d

Exc

eede

d ve

loci

ty c

heck

ing

Pin

Try

Lim

it ex

ceed

ed

Una

ble

to g

o on

line

Offline PIN Verification Failed

Reserved

International Transaction

Unable To Go Online IndicatedOffline PIN Verification Not Performed

PTL Exceeded

Reserved

"

No Match Found in Additional Check Table

" "

Match Found in Additional Check Table

Upper Consecutive Offline Limit Exceeded

Domestic Transaction

Upper Cumulative Offline Limit Exceeded

Terminal Err. Considers Offline PIN OKLower Consecutive Offline Limit Exceeded

Lower Cumulative Offline Limit Exceeded

Script Failed

Go Online On Next Transaction Was Set

"

Issuer Authentication FailedScript Received

"

AC returned in first GENERATE AC

"

Offline PIN Verification Performed

AC returned in second Generate AC "

Reserved

"

"

Right nibble of PIN Try Counter

Right nibble of Script Counter "

"

Comb. DDA/AC Gen. Ret. In First GEN AC

Offline Encrypted PIN Verification Performed

Issuer Authentication Performed

Offline PIN Verification SuccessfulDDA returned

Comb. DDA/AC Gen. Ret. In Sec. GEN AC

Reserved

CIAC-Default Skipped On CAT3

"

ReservedReserved

"


83

45

67

21

83

45

67

21

83

45

67

21

83

45

67

21

83

45

67

21

83

45

67

21

Byt

e 4

Byt

e 5

Byt

e 6

Byt

e 1

Byt

e 2

Byt

e 3

CVR - M/Chip 2.05

Byte 2 Byte 38 34567 2 1 8 34567 2 1 8 34567 2

Max

imum

off

line

trans

actio

n am

ount

exc

eede

d

Byte 41

CVR Mapping TablesCVR Mapping Table for M/Chip Lite 2.1


C.2 CVR Mapping Table for M/Chip Lite 2.1 Figure C.2—CVR Mapping Table for M/Chip Lite 2.1

Issu

er sc

ript p

roc.

fail.

on

last

or c

urre

nt tr

ans.

"

UC

OL

or

UC

OT

A e

xcee

ded

LC

OL

or

LC

OT

A e

xcee

ded

Not

use

d

AC

Typ

e re

turn

ed in

firs

t Gen

erat

e A

C

Off

line

PIN

Ver

ifica

tion

perf

orm

ed

AC

Typ

e re

turn

ed in

seco

nd G

ener

ate

AC

Issu

er A

uthe

ntic

atio

n fa

iled

"

"

App

l. bl

ocke

d by

car

d be

caus

e PT

L ex

ceed

ed

"

Issu

er A

uth.

failu

re o

n la

st o

nlin

e tra

nsac

tion

N. o

f scr

ipt c

omm

ands

pro

cess

ed su

cces

sful

lyO

fflin

e SD

A fa

iled

on la

st tr

ansa

ctio

n

Issu

er A

uth.

not

per

form

ed a

fter o

nlin

e au

thor

.

Last

onl

ine

trans

actio

n no

t com

plet

ed

New

car

d

Off

line

PIN

Ver

ifica

tion

faile

d

Exc

eede

d ve

loci

ty c

heck

ing

Pin

Try

Lim

it ex

ceed

ed

Una

ble

to g

o on

line


Reserved



PTL Exceeded

Reserved

"


" "







Script Failed


"


"


"



Reserved

"

"



"






Reserved


"

ReservedReserved

"

83

45

67

21

83

45

67

21

83

45

67

21

83

45

67

21

83

45

67

21

83

45

67

21

Byt

e 4

Byt

e 5

Byt

e 6

Byt

e 1

Byt

e 2

Byt

e 3

CVR - M/Chip Lite 2.1

Byte 2 Byte 38 34567 2 1 8 34567 2 1 8 34567 2

Not

use

d

Byte 41


CVR Mapping Tables CVR Mapping Table for CCD



C.3 CVR Mapping Table for CCD Figure C.3—CVR Mapping Table for CCD

Issu

er-d

iscr

etio

nary

bit

1

Issu

er-d

iscr

etio

nary

bit

4

Low

er C

umul

. Off

l. A

mou

nt L

imit

exce

eded

Issu

er-d

iscr

etio

nary

bit

3Is

suer

-dis

cret

iona

ry b

it 2

Upp

er C

umu.

Off

l. A

mou

nt L

imit

exce

eded

AC

ret

urne

d in

firs

t GE

NE

RA

TE

AC

Off

line

DD

A p

erfo

rmed

AC

ret

urne

d in

seco

nd G

ener

ate

AC

CD

A p

erfo

rmed

"

"

PIN

Try

Lim

it ex

ceed

ed

Upp

er O

fflin

e T

rans

. Cou

nt L

imit

exce

eded

Off

line

PIN

Ver

ifica

tion

perf

orm

ed

Low

er O

fflin

e Tr

ans.

Cou

nt L

imit

exce

eded

Last

onl

ine

trans

actio

n no

t com

plet

ed

Off

. PIN

Ver

if. p

erf.

and

PIN

not

suc.

ver

.

Low

ord

er n

ibbl

e of

PIN

Try

Cou

nter

"

Issu

er A

uthe

ntic

atio

n no

t per

form

ed

"

"

Issu

er A

uthe

ntic

atio

n fa

iled


Reserved



PTL Exceeded

Reserved

"


" "







Script Failed


"


"


"



Reserved

"

"



"






Reserved


"

ReservedReserved

"

83

45

67

21

83

45

67

21

83

45

67

21

83

45

67

21

83

45

67

21

83

45

67

21

Byt

e 4

Byt

e 5

Byt

e 6

Byt

e 1

Byt

e 2

Byt

e 3

CVR - CCD

Issu

er sc

ript p

roce

ssin

g fa

iled

Una

ble

to g

o on

line

"

Go

onlin

e on

nex

t tra

nsac

tion

was

set

Off

line

data

aut

h. fa

iled

on p

revi

ous t

rans

.

"

"

Num

. of I

ssue

r Scr

. Com

. con

tain

ing

sm p

roc.

Byte 1 Byte 2 Byte 38 34567 2 1 8 34567 2 1 8 34567 2 1

Byte 48 34567 2 1


CVR Mapping TablesCVR Mapping Table for UKIS


C.4 CVR Mapping Table for UKIS Figure C.4—CVR Mapping Table for UKIS

Issu

er sc

ript p

roce

ssin

g fa

iled

on la

st tr

ans.

"

Off

line

dyna

mic

dat

a au

then

ticat

ion

perf

orm

edO

ffl.

dda

fail.

on

last

tran

s. an

d tra

ns. d

ecl.

offl.

"

AC

Typ

e re

turn

ed in

firs

t Gen

erat

e A

C

Off

line

PIN

Ver

ifica

tion

perf

orm

ed

AC

Typ

e re

turn

ed in

seco

nd G

ener

ate

AC

Issu

er A

uthe

ntic

atio

n pe

rfor

med

and

faile

d

"

"

App

l. bl

ocke

d by

car

d be

caus

e PT

L ex

ceed

ed

... c

. se

mes

sagi

ng p

roce

ssed

on

last

tran

sact

ion

Issu

er A

uth.

failu

re o

n la

st o

nlin

e tra

nsac

tion

N. o

f Iss

uer S

crip

t Com

. rec

. a. s

ec. G

EN A

C...

O

ffl.

SDA

fail.

o. l

ast t

rans

. a. t

rans

. dec

l. of

fl.

Issu

er A

uth.

not

per

f. af

ter o

nlin

e au

thor

izat

ion

Last

onl

ine

trans

actio

n no

t com

plet

ed

New

car

d

Off

line

PIN

Ver

ifica

tion

faile

d

Exc

eede

d ve

loci

ty c

heck

ing

coun

ters

Pin

Try

Lim

it ex

ceed

ed

Una

ble

to g

o on

line


Reserved



PTL Exceeded

Reserved

"


" "







Script Failed


"


"

AC returned in first G ENERATE AC

"



Reserved

"

"



"






Reserved


"

ReservedReserved

"

83

45

67

21

83

45

67

21

83

45

67

21

83

45

67

21

83

45

67

21

83

45

67

21

Byt

e 4

Byt

e 5

Byt

e 6

Byt

e 1

Byt

e 2

Byt

e 3

CVR - UKIS

Byte 2 Byte 38 34567 2 1 8 34567 2 1 8 34567 2

RFU

Byte 41


CVR Mapping Tables CVR Mapping Table for UKIS





Annex D: Additional Check Table This appendix provides a description of the check that may be added to the Card Risk Management via the Additional Check Table.

The Additional Check Table allows an issuer to add a check to the basic Card Risk Management. This additional check is only performed if the Application Control [2][3] is set to 1b.

The check consists of the following steps:

1. The application extracts a value from the CDOL 1 Related Data. This value can be any number of consecutive bytes.

2. The application masks the extracted value to a Bit Mask to force some of the bits to 0b.

3. The application compares the masked value with values stored in the Additional Check Table.

4. If the requested value matches a value in the table, the application sets the bit Card Verification Results [6][2] to 1b, otherwise the application sets the bit Card Verification Results [6][1] to 1b.

5. Depending on the settings of the Card Issuer Action Codes, the application can take an action when a match is found in the table, or when no match is found.

Figure D.1 illustrates the use of the Additional Check Table.




Figure D.1—Additional Check Table Usage

CDOL1 related data

extracted value

extraction

masking

masked value

+

value 1

value 2

value 3

table

=?

comparison

match found match found

no match found

CVR

1

0

no match found match found

no match found

CVR

0

1

bit mask

The part that is extracted from CDOL 1 Related Data is defined at personalization, with two parameters:

• Position in CDOL 1 Related Data

• Length in CDOL 1 Related Data

CDOL 1 Related Data is illustrated in Figure D.2.



Figure D.2—CDOL 1 Related Data

CDOL1 related data

extracted value

extraction

position

length

The Additional Check Table is the concatenation (without TLV coding) of the data elements identified in Table D.1.

Table D.1—Additional Check Table

Data Element Length Format

Position In CDOL 1 Related Data 1 binary

Length In CDOL 1 Related Data 1 binary

Number of Entries 1 binary

Entries 15 binary

Bit Mask Length In CDOL 1 Related Data binary

Value 1 Length In CDOL 1 Related Data binary

... ... ...

Value Number Of Entries - 1 Length In CDOL 1 Related Data binary

Padding 15 - Number Of Entries * Length In CDOL 1 Related Data

‘FF ... FF’

The following sections describe the contents of the data elements in Table D.1.

Position In CDOL 1 Related Data

This data element contains the position of the portion of CDOL 1 Related Data that is compared to the table entries. If the first byte in CDOL 1 Related Data is checked against the entries in the table, the value of Position in CDOL 1 Related Data is ‘01’.

Length In CDOL 1 Related Data

This data element contains the length of the portion of CDOL 1 Related Data that is compared to the table entries.




Number Of Entries

This data element contains the number of values (including the Bit Mask) in the Table Content that are used for the comparison.

Entries

This data element contains the concatenation of the values used for the comparison, optionally padded with ‘FF’ to make up 15 bytes. The first value is used as a Bit Mask.

Figure D.3 illustrates the Additional Check Table.

Figure D.3—Additional Check Table

offset length number bit mask val1 val2 ... padding

entries

Note It is possible to apply the check on any value that can be requested from the terminal.

Example

The Additional Check Table is used to take a decision when the value of the Terminal Country Code indicates that the transaction did not take place in the following countries:

• Belgium (‘0056’)

• France (‘0250’).

The position of the Terminal Country Code in CDOL 1 Related Data is the 13th byte, i.e. ‘0D’ in hexadecimal.

The length of the Terminal Country Code is 2 bytes.

The two values in the table used for the comparison are the Terminal Country Code for Belgium and France.

The comparison is performed on the complete value of the Terminal Country Code. The Bit Mask is therefore equal to ‘FFFF’.

The Additional Check Table value is therefore equal to:

‘0D0203FFFF00560250FFFFFFFFFFFFFFFFFF’.


**** End of Document ****

Documents

PayPass M/Chip Flex - cardzone.czdata.cardzone.cz/contactless/PayPass - MChip Flex... · PayPass – M/Chip Flex application on a card or acceptance device. This document is also