+ All Categories
Home > Documents > MasterCard ICC

MasterCard ICC

Date post: 28-Apr-2015
Category:
Upload: pinkbubbles2013
View: 410 times
Download: 5 times
Share this document with a friend
Description:
Martercard Integrated Circuit CardApplication Specification
233
Version 2.0 Integrated Circuit Card Application Specification For Debit and Credit on Chip
Transcript
Page 1: MasterCard ICC

Version 2.0

Integrated Circuit CardApplication Specification

For Debit and Credit on Chip

Page 2: MasterCard ICC

ICC Application SpecificationNovember 1998

Notice: The information contained in this manual is proprietary andconfidential to MasterCard International Incorporated and itsmembers.

This material may not be duplicated, published, or disclosed, inwhole or in part, without the prior written permission ofMasterCard International Incorporated.

Trademarks: All products, names, and services are trademarks or registeredtrademarks of their respective companies.

Version 2.0Published November 1998

Page 3: MasterCard ICC

Table of Contents

ICC Application SpecificationNovember 1998

i

USING THIS MANUAL

Purpose of this Manual.................................................................. 1Intended Audience ........................................................................ 2

Related Publications ................................................................ 2Organization of this Manual .......................................................... 3Using the Sections in this Manual.................................................. 6Abbreviations................................................................................ 7Notations .................................................................................... 11Revisions to this Manual ............................................................. 12Related Information .................................................................... 12MasterCard Contacts .................................................................. 13Comments and Suggestions......................................................... 13

SECTION 1 FUNCTIONAL SPECIFICATION OF EMV ‘96, VERSION3.1.1 SPECIFICATION FOR PAYMENT SYSTEMSTRANSACTIONS

1.1 Overview ............................................................................1-11.2 Transaction Flow ................................................................1-2

1.2.1 Card Transaction Flow Flags ......................................1-31.3 Standard Payment Functions ...............................................1-5

1.3.1 Application Selection..................................................1-51.3.2 Initiate Application Processing....................................1-91.3.3 Read Application Data..............................................1-121.3.4 Offline Card Authentication ......................................1-121.3.5 Cardholder Verification ............................................1-131.3.6 First GENERATE AC Processing.............................1-171.3.7 Issuer Authentication................................................1-371.3.8 Second GENERATE AC Command.........................1-39

1.4 Standard Post-Issuance Functions .....................................1-471.4.1 Script Processing Overview......................................1-471.4.2 Card Blocking ..........................................................1-521.4.3 Application Blocking ................................................1-541.4.4 Application Unblocking ............................................1-561.4.5 Updating Card Data..................................................1-581.4.6 PIN Change/Unblock................................................1-601.4.7 End Of Script ...........................................................1-62

Page 4: MasterCard ICC

Table of Contents

ICC Application Specification © 1998 MasterCard International IncorporatedNovember 1998ii

SECTION 2 SECURITY SPECIFICATION OF EMV ‘96, VERSION 3.1.1ICC SPECIFICATION FOR PAYMENT SYSTEMSTRANSACTIONS

2.0 Overview ............................................................................2-12.1 Static Data Authentication...................................................2-2

2.1.1 Keys and Certificates ..................................................2-22.1.2 Retrieval of the Certification Authority

Public Key.........................................................................2-72.1.3 Retrieval of the Issuer Public Key ...............................2-82.1.4 Verification of the Signed Static

Application Data .............................................................2-102.2 Dynamic Data Authentication............................................2-12

2.2.1 Keys and Certificates ................................................2-122.2.2 Retrieval of the Certification Authority

Public Key.......................................................................2-162.2.3 Retrieval of the Issuer Public Key .............................2-162.2.4 Retrieval of the ICC Public Key................................2-182.2.5 Dynamic Signature Generation .................................2-202.2.6 Dynamic Signature Verification ................................2-22

2.3 PIN Encipherment.............................................................2-242.3.1 Keys and Certificates ................................................2-242.3.2 PIN Encipherment and Verification...........................2-27

2.4 Application Cryptograms ..................................................2-292.4.1 Initial Selection of Data ............................................2-292.4.2 TC, AAC and ARQC Algorithm...............................2-31

2.5 Issuer Authentication ........................................................2-332.6 Secure Messaging .............................................................2-35

2.6.1 Secure Messaging for Integrity .................................2-352.6.2 Secure Messaging for Confidentiality........................2-382.6.3 Combined Integrity and Confidentiality.....................2-39

2.7 ICC Key Derivation ..........................................................2-402.7.1 ICC Master Key Derivation ......................................2-402.7.2 ICC Session Key Derivation .....................................2-42

2.8 Random Number for Session Key Derivation.....................2-432.9 Data Authentication Code Generation ...............................2-442.10 ICC Dynamic Number Generation...................................2-45

Page 5: MasterCard ICC

Table of Contents

ICC Application SpecificationNovember 1998

iii

SECTION 3 DATA SPECIFICATION OF EMV ‘96 ICC SPECIFICATIONFOR PAYMENT SYSTEMS TRANSACTIONS

3.1 Data Elements and Files ......................................................3-13.1.1 Management of data elements by ICC.........................3-1

3.1.2 EMV data elements ....................................................3-83.1.3 MasterCard proprietary data elements.......................3-30

3.2 Updating Card Risk Management Data..............................3-403.3 Card Risk Management Data Object List...........................3-41

3.3.1 Card Risk Management Data Object List 1 ...............3-413.3.2 Card Risk Management Data Object List 2 ...............3-42

3.2 Card Life Cycle Data.........................................................3-44

APPENDIX A NETWORK DATA ELEMENT REQUIREMENTS

Network Data Element Requirements........................................A-1

APPENDIX B DIGITAL SIGNATURE SCHEME GIVING MESSAGERECOVERY

B.1 Overview........................................................................... B-1B.2 Signature Generation ......................................................... B-1B.3 Signature Verification........................................................ B-3

APPENDIX C CRYPTOGRAPHIC ALGORITHMS

C.1 DES and Triple-DES......................................................... C-1C.2 RSA/Rabin ........................................................................ C-2

C.2.1 Odd Public Key Exponent ......................................... C-3C.2.2 Public Key Exponent 2.............................................. C-3

C.3 SHA-1............................................................................... C-5

Page 6: MasterCard ICC
Page 7: MasterCard ICC

Using this Manual

ICC Application SpecificationNovember 1998

i

USING THIS MANUAL

Purpose of this Manual.................................................................. 1Intended Audience ........................................................................ 2

Related Publications ................................................................ 2Organization of this Manual .......................................................... 3Using the Sections in this Manual.................................................. 6Abbreviations................................................................................ 7Notations .................................................................................... 11Revisions to this Manual ............................................................. 12Related Information .................................................................... 12MasterCard Contacts .................................................................. 13Comments and Suggestions......................................................... 13

Page 8: MasterCard ICC
Page 9: MasterCard ICC

Using this ManualPurpose of this Manual

ICC Application SpecificationNovember 1998

1

PURPOSE OF THIS MANUAL

The ICC Application Specification is provided to the payment system members and the cardmanufacturers to assist in the development of chip card applications to support EMV compliantdebit and credit products. The usage of this specification is not mandated to achieve TypeApproval of the developed products.

Members are encouraged to contact MasterCard to discuss any implementation issues that are notaddressed by this publication.

Any comments or questions regarding this publication should be addressed to:

[email protected]

Page 10: MasterCard ICC

Using this ManualIntended Audience

ICC Application Specification © 1998 MasterCard International IncorporatedNovember 19982

INTENDED AUDIENCE

This manual is intended for MasterCard members planning debit/credit/ATM productimplementation on chip, ICC application developers, and terminal vendors.

This publication assumes that the reader is familiar with the EMV ‘96, Version 3.1.1 specifications(see “Related Publications,” below).

Related Publications

The following MasterCard publications contain material directly related to the contents of thispublication.

• Minimum Card Requirements for Debit and Credit on Chip, Version 2.0

• EMV ’96 Integrated Circuit Card Application Specification for Payment Systems, Version3.1.1

• EMV ’96 Integrated Circuit Card Specification for Payment Systems, Version 3.1.1

Page 11: MasterCard ICC

Using this Manual Organization of this Manual

ICC Application SpecificationNovember 1998

3

ORGANIZATION OF THIS MANUAL

This manual is organized into sections presenting information in the following manner:

• Table of ContentsA list of the manual’s sections and subsections. Each entry references a section and pagenumber.

• Using this ManualA description of this manual and its contents.

• Functional SpecificationThis section describes how the necessary functionality described in EMV’96 (version 3.1.1)should be managed in the ICC to be compliant with the MasterCard business rules (set out inthe Minimum Card Requirements). This part is fully platform independent. Any MasterCarddebit or credit application can be constructed using the different building blocks described inthis part.

This section contains:

– The description of Payment and Post-Issuance commands

– The internal card processing

– The description of all ICC related specifications to perform all transaction types supportedby business rules for chip cards

• Security SpecificationThis section describes how the security should be managed in the ICC to be compliant withthe MasterCard security requirements. Because security is often an end-to-end requirement,issues related to the terminal and the issuer host system are also addressed, where appropriate.The different security aspects considered are:

– Static Data Authentication

– Dynamic Data Authentication

– Off-line PIN Encipherment

– Application Cryptogram generation

– Issuer Authentication

Page 12: MasterCard ICC

Using this ManualOrganization of this Manual

ICC Application Specification © 1998 MasterCard International IncorporatedNovember 19984

– Secure Messaging

Furthermore, this section contains the security mechanisms, cryptographic algorithms and keymanagement used to realize the six topics specified above:

– Issuer derivation of a unique triple-DES ICC Master Key for generation of the ApplicationCryptogram and for Secure Messaging

– Issuer derivation of the Data Authentication Codes

– ICC and Issuer derivation of the ICC Dynamic Numbers

• Data SpecificationThis section lists and describes the data elements, which are required to support financialtransactions. These data elements include:

– ICC related data objects defined in EMV’96 Integrated Circuit Card Specification forPayment Systems - Part 2 and EMV’96 Integrated Circuit Card Application Specificationfor Payment Systems

– ICC internal data objects which are MasterCard and Europay proprietary

– Authorization and clearing data elements

This document does not describe ICC internal data objects that are Issuer proprietary.

• Appendix A: Network Data Element RequirementsThis section summarizes by message the list of new data elements that the acquirer is to passto the issuer. Some of these data elements may not be provided/requested by the ICC or theissuer, however the acquirer should support them and pass them when present. Data Element55 has been established for the chip data in the Authorization Messages.

Page 13: MasterCard ICC

Using this Manual Organization of this Manual

ICC Application SpecificationNovember 1998

5

• Appendix B: Digital Signature Scheme Giving Message RecoveryThis section describes the digital signature scheme giving message recovery using a hashfunction according to ISO/IEC CD 9796-2. The main features of the scheme are thefollowing:

– Adding of redundancy in the signature by applying a hash function to the data to be signed

– Adding of a header and trailer byte to obtain a unique recovery procedure and to preventcertain attacks

• Appendix C: Cryptographic AlgorithmsThis section explains the following cryptographic algorithms:

– DES and Triple-DES

– RSA/Rabin

– SHA-1

• IndexAn alphabetical listing by topic, subject, or title where items can be located in this manual.

Page 14: MasterCard ICC

Using this ManualUsing the Sections in this Manual

ICC Application Specification © 1998 MasterCard International IncorporatedNovember 19986

USING THE SECTIONS IN THIS MANUAL

You do not have to read the contents of any section in any particular order. The followingelements used in the manual help you locate the information you need more quickly:

+ The hand points at important information that you need to know. The text is inboldface type. Be sure to read everything that is labeled this way.

ENTER Terms in UPPER CASE within a paragraph are acronyms, keyboard functionkeys, or computer commands.

Procedures Numbered steps describe the sequence of actions you must take to perform atask.

Notations Values surrounded by single quotes are hexadecimal values. For example, abinary field that is one byte in length and has a value of zero would berepresented as ‘00’.

Page 15: MasterCard ICC

Abbreviations and NotationsAbbreviations

ICC Application SpecificationNovember 1998

7

ABBREVIATIONS

The following abbreviations are used in this specification:

a AlphaAAC Application Authentication CryptogramABF Application Blocked FlagAC Application CryptogramADF Application Definition FileAEF Application Elementary FileAFL Application File LocatorAID Application IdentifierAIP Application Interchange Profilean Alphanumericans Alphanumeric SpecialAPDU Application Protocol Data UnitARC ARPC Response CodeARPC Authorization Response CryptogramARQC Authorization Request CryptogramASN Abstract Syntax NotationATC Application Transaction CounterATM Automated Teller Machineb BinaryBER Basic Encoding RulesBIN BASE Identification NumberCA Certification AuthorityCAM Card Authentication MethodCBC Cipher Block ChainingCCPS Chip Card Payment ServiceCDOL Card Risk Management Data Object ListCD Committee DraftCIAC Card Issuer Action CodeCID Cryptogram Information DataCLCD Card Life Cycle DataCLA Class Byte of the Command Messagecn Compressed Numeric

Page 16: MasterCard ICC

Abbreviations and NotationsAbbreviations

ICC Application Specification © 1998 MasterCard International IncorporatedNovember 19988

CRM Card Risk ManagementCSI Card Status InformationCTVR Card Terminal Verification ResultsCVM Cardholder Verification MethodCVC Card Verification CodeCVR Card Verification ResultsCVV Card Verification ValueCVM Cardholder Verification MethodDAC Data Authentication CodeDDF Directory Definition FileDDOL Dynamic Data Object ListDEA Data Encryption AlgorithmDES Data Encryption StandardDES3 Triple DESDF Dedicated FileDIS Draft International StandardDK Derivation (DEA) KeyEMV Europay/MasterCard/VisaECB Electronic Code BookEPI EUROPAY InternationalFCI File Control InformationHex. HexadecimalHHMMSS Hours, Minutes, SecondsIAD Issuer Application DataIARC Issuer Authentication Response CodeIC Integrated CircuitICC Integrated Circuit CardID IdentifierIDN ICC Dynamic NumberIEC International Electrotechnical CommissionIFD Interface DeviceIMK Issuer Master KeysIMKDAC Issuer Master Keys for Data Authentication CodeINS InstructionISO International Organization for Standardization

Page 17: MasterCard ICC

Abbreviations and NotationsAbbreviations

ICC Application SpecificationNovember 1998

9

Lc Length command dataLcm Least Common MultipleLDD Length of the ICC Dynamic DataLATC Last on-line Application Transaction CounterLCOLL Lower Consecutive Offline LimitLRC Longitudinal Redundancy CheckM MandatoryMAC Message Authentication CodeMCI MasterCard InternationalMF Master FileMK Master KeyMKAC ICC Master Key Application CryptogramMKIDN ICC Master Key for ICC Dynamic Number generationMKSMI ICC Master Key for Secure Messaging for IntegrityMKSMC ICC Master Key for Secure Messaging for Confidentialityn NumericNCA Length of the Certification Authority Public Key ModulusNI Length of the Issuer Public Key ModulusNIC Length of the ICC Public Key ModulusNPE ICC PIN Encipherment Public Key ModulusO OptionalOLCTA Offline Cumulative Transaction AmountP1 Parameter 1P2 Parameter 2PAN Primary Account NumberPCA Certification Authority Public KeyPI Issuer Public KeyPIC ICC Public KeyPDOL Processing Options Data Object ListPIN Personal Identification NumberPIX Proprietary Application Identifier ExtensionPOS Point of ServicePSE Payment System EnvironmentPTC PIN Try CounterPTL PIN Try Limit

Page 18: MasterCard ICC

Abbreviations and NotationsAbbreviations

ICC Application Specification © 1998 MasterCard International IncorporatedNovember 199810

PVV PIN Verification ValueRFU Reserved for Future Use (see next table)RID Registered Application Provider IdentifierRIP Reset Internal ParametersROM Read-Only MemoryRSA Rivest Shamir Adleman (a Public Key algorithm)SCA Certification Authority Private KeySHA Secure Hash AlgorithmSI Issuer Private KeySIC ICC Private KeySK Session KeySKAC Session Key Application CryptogramSFI Short File IdentifierSM Secure MessagingSW1 Status byte 1SW2 Status byte 2T-DES Triple DESTC Transaction CertificateTDOL Transaction Certificate Data Object ListTLV Tag Length ValueTSI Transaction Status InformationTVR Terminal Verification ResultsUCOLL Upper Consecutive Off-Line LimitUDK Unique DEA Keyvar. VariableYDDD Year, Day

“Y” = Rightmost digit of the year.“D” = Day of the year (1-366)

YYMMDD Year, Month, Day

Page 19: MasterCard ICC

Abbreviations and NotationsNotations

ICC Application SpecificationNovember 1998

11

NOTATIONS

The following notations are used in this specification:

Notation Meaning

‘0’ to ‘9’ and ‘A’ to ‘F’ 16 hexadecimal digits

# Number

[...] Optional part

xx Any value

n/a not applicable

Page 20: MasterCard ICC

Introduction Revisions to this Manual

ICC Application Specification © 1998 MasterCard International IncorporatedNovember 199812

REVISIONS TO THIS MANUAL

MasterCard periodically will issue revisions to this document as enhancements and changes areimplemented, or as corrections to the manual are required.

All changes to this document are distributed as either (1) a full replacement of the entire manual,or (2) a partial update with new pages and replacement pages to be inserted throughout thedocument. Each revision is issued with the revision date printed in the page footer (replacing therelease date), along with the page number, to ensure that all changes are accurately documented.

When issuing a partial update, in addition to the new document revision date, each revised page isannotated with “revision markers” (vertical lines in the right margin) to indicate where deletions,additions, or changes occurred.

At times, revisions or additions to this document initially will be published in an OperationsBulletin or other bulletin. A revision announced in a MasterCard bulletin or release document iseffective as of the date indicated in that publication.

RELATED INFORMATION

In addition to this ICC Application Specification, the following information is available for thisproduct:

Contact the ISO Web site at www.iso.ch for more information.

Page 21: MasterCard ICC

Using this Manual MasterCard Contacts

ICC Application SpecificationNovember 1998

13

MASTERCARD CONTACTS

For inquiries on programs and services, contact your regional Member Services representative oryour representative in St. Louis at the following addresses and numbers:

Attn: (your Member Services representative)MasterCard International Incorporated12115 Lackland RoadSt. Louis, MO 63146-4071USA

Phone: 314-275-6100Fax: 314-542-7192Telex: 434800 answerback: 434800 ITAC UIE-mail: [email protected]

For a list of member representatives, please see the Member Information Manual, Headquartersand Regional Offices section.

COMMENTS AND SUGGESTIONS

MasterCard is listening...

Please take a moment to provide us with your feedback on the material and usefulness of the ICCApplication Specification using the Comment Form found in the back of the manual.

Or send us your comments on this manual via e-mail:

+ [email protected]

We continually strive to improve our publications. Your input will help us accomplish our goal ofproviding you with the information you need.

Page 22: MasterCard ICC
Page 23: MasterCard ICC

Table of Contents

ICC Application SpecificationNovember 1998

1-i

SECTION 1 FUNCTIONAL SPECIFICATION OF EMV ‘96, VERSION3.1.1 SPECIFICATION FOR PAYMENT SYSTEMSTRANSACTIONS

1.1 Overview ............................................................................1-11.2 Transaction Flow ................................................................1-2

1.2.1 Card Transaction Flow Flags ......................................1-31.3 Standard Payment Functions ...............................................1-5

1.3.1 Application Selection..................................................1-51.3.1.1 Data Field Returned in the

Response message .......................................................1-51.3.1.2 Coding of Payment System

Application Identifiers .................................................1-61.3.1.3 Structure of the Payment

Systems Environment ..................................................1-71.3.1.4 Coding of a Payment System’s Directory ...........1-71.3.1.5 Application Selection with or

without cardholder confirmation ..................................1-81.3.2 Initiate Application Processing....................................1-9

1.3.2.1 Optional Data Objects Supplied WithThe GET PROCESSING OPTIONS command ...........1-9

1.3.2.2 AIP and AFL ...................................................1-101.3.2.3 Mandatory Data Objects Supplied With

The GET PROCESSING OPTIONS command .........1-101.3.2.4 Initiate Application Processing flow .................1-11

1.3.2.4.1 PDOL supported? ...................................1-111.3.2.4.2 ATC=’FFFF’ ?........................................1-121.3.2.4.3 AIP and AFL found?...............................1-12

1.3.3 Read Application Data..............................................1-121.3.4 Offline Card Authentication ......................................1-12

1.3.4.1 Static offline card authentication ......................1-121.3.4.2 Dynamic offline card authentication .................1-12

1.3.5 Cardholder Verification ............................................1-131.3.5.1 Reference PIN definition..................................1-131.3.5.2 Enciphered offline PIN definition .....................1-131.3.5.3 General processing...........................................1-141.3.5.4 Verify description ............................................1-16

1.3.5.4.1 Update Sequence Flag about PIN............1-161.3.5.4.2 PTC = 0 ? ...............................................1-161.3.5.4.3 Decrement PIN Try Counter (PTC).........1-161.3.5.4.4 PIN Enciphered? .....................................1-161.3.5.4.5 Decipher PIN..........................................1-161.3.5.4.6 Deciphered data correct?.........................1-16

Page 24: MasterCard ICC

Table of Contents

ICC Application Specification © 1998 MasterCard International IncorporatedNovember 19981-ii

1.3.5.4.7 PIN OK?.................................................1-161.3.5.4.8 Reset PIN Try Counter ...........................1-161.3.5.4.9 Reset “PIN Verification Failed”...............1-17

1.3.6 First GENERATE AC Processing.............................1-171.3.6.1 Card Risk Management Data (CDOL1) ...........1-211.3.6.2 Internal Process ...............................................1-22

1.3.6.2.1 Reset CVR (Card Verification Result).....1-231.3.6.3 CRM ...............................................................1-24

1.3.6.3.1 PIN verification status.............................1-251.3.6.3.2 Previous transaction status ......................1-251.3.6.3.3 New Card ...............................................1-261.3.6.3.4 Maximum Offline Transaction

Amount ...............................................................1-261.3.6.3.5 Velocity Checking of Offline Consecutive

Transactions ........................................................1-261.3.6.3.6 Offline Cumulative amount......................1-28

1.3.6.4 Card Action Analysis .......................................1-331.3.6.4.1 Terminal type? ........................................1-341.3.6.4.2 TVR asks for ARQC...............................1-341.3.6.4.3 Card Issuer Action Codes........................1-34

1.3.6.5 Update ICC Parameters ...................................1-361.3.6.5.1 Transaction completion/Online

processing...........................................................1-361.3.7 Issuer Authentication................................................1-37

1.3.7.1 Issuer Authentication Data definition ...............1-371.3.7.2 Issuer Authentication Response Code

definition ...................................................................1-371.3.7.3 ARQC generated?............................................1-371.3.7.4 Issuer Authentication .......................................1-371.3.7.5 Update Internal Indicator “Issuer Authentication

Successful”................................................................1-371.3.7.6 Update Internal Indicator “Issuer Authentication

Failed”.......................................................................1-381.3.8 Second GENERATE AC Command.........................1-39

1.3.8.1 Cryptogram Information data...........................1-391.3.8.2 Card Risk Management Data CDOL2 ..............1-401.3.8.3 Internal Process (Issuer Authentication Data

performed during External Authenticate) ...................1-411.3.8.3.1 TC or AAC asked?..................................1-421.3.8.3.2 Card returned ARQC?.............................1-421.3.8.3.3 Update CVR ...........................................1-421.3.8.3.4 Issuer Authentication ..............................1-421.3.8.3.5 Issuer Authentication verification ............1-42

Page 25: MasterCard ICC

Table of Contents

ICC Application SpecificationNovember 1998

1-iii

1.3.8.3.6 Issuer Authentication successful? ............1-431.3.8.3.7 Authorization Response Code

“Y3” or “Z3”? .....................................................1-431.3.8.3.8 Card Action Analysis...............................1-431.3.8.3.9 Set TC for 2nd Generate AC...................1-451.3.8.3.10 Set AAC for 2nd Generate AC..............1-451.3.8.3.11 Update ICC parameters.........................1-461.3.8.3.12 Transaction completion .........................1-46

1.4 Standard Post-Issuance Functions .....................................1-471.4.1 Script Processing Overview......................................1-47

1.4.1.1 Script Processing Counter................................1-481.4.1.2 Script Processing Status...................................1-481.4.1.3 Script Processing Overall Diagram...................1-50

1.4.1.3.1 ARQC generated? ...................................1-511.4.1.3.2 Previous script command failed?..............1-511.4.1.3.3 Set “script performed” ............................1-511.4.1.3.4 Update script processing status to “script

processing pending”.............................................1-511.4.1.3.5 Verify secure messaging..........................1-511.4.1.3.6 SM correct ? ...........................................1-511.4.1.3.7 Perform the script command....................1-511.4.1.3.8 Update script processing counter

(optionally update script processing status) ..........1-511.4.1.3.9 Command rejected ..................................1-51

1.4.2 Card Blocking ..........................................................1-521.4.3 Application Blocking ................................................1-541.4.4 Application Unblocking ............................................1-56

1.4.4.1.1 Verify Secure Messaging.........................1-561.4.4.1.2 Unblock the selected ADF.......................1-56

1.4.5 Updating Card Data..................................................1-581.4.5.1 Update the data ...............................................1-58

1.4.6 PIN Change/Unblock................................................1-601.4.6.1 Unblock or Change..........................................1-601.4.6.2 Decipher PIN...................................................1-601.4.6.3 Update PIN value ............................................1-601.4.6.4 Update PTC to PTL.........................................1-61

1.4.7 End Of Script ...........................................................1-62

Page 26: MasterCard ICC
Page 27: MasterCard ICC

Functional Specification of EMV’96 ICC Specification for Payment Systems Transactions1.1 Overview

ICC Application SpecificationNovember 1998

1-1

1.1 OVERVIEW

When a card that contains an Integrated Circuit Card (ICC) is presented to a terminal, theterminal determines which applications are mutually supported and the appropriate application isselected. If a MasterCard application is selected, the terminal reads the data from the ICC anddetermines whether to perform static or dynamic data authentication.

If supported, the appropriate cardholder verification method is performed.

Both the terminal and ICC perform offline risk management (for example, floor limit checking,transaction velocity checking) to determine whether the transaction should be approved,transmitted online for authorization, or declined. If both the ICC and the terminal indicate thatthe transaction satisfied the criteria for offline authorization, the transaction may be approvedoffline, and the ICC generates a Transaction Certificate (TC). The TC is stored by acquirers forpossible use in the resolution of any future cardholder disputes and/or issuer chargebacks.

If the criteria for offline authorization are not satisfied, the terminal transmits an online request tothe issuer indicating why the transaction was transmitted online (if the terminal has onlinecapability). During online processing, the issuer verifies that the ICC is genuine and the ICC mayverify that the issuer is genuine. The issuer may choose to transmit cardholder data updates to theICC in the response message. To successfully complete the transaction, the ICC generates aTransaction Certificate.

To decline a transaction, the ICC will generate, or be asked to generate by the terminal, anApplication Authentication Cryptogram (AAC).

Page 28: MasterCard ICC

Functional Specification of EMV’96 ICC Specification for Payment Systems Transactions1.2 Transaction Flow

ICC Application Specification © 1998 MasterCard International IncorporatedNovember 19981-2

1.2 TRANSACTION FLOW

Exception handling shall be performed as described in the EMV”96 ICC Specification forPayment Systems.

An example of the transaction flow (without exceptions) is as:

FIGURE 1.1: TRANSACTION FLOW

DataAuthentication

Terminal RiskManagement

Card ActionAnalysis

CardholderVerification

ProcessingRestrictions

Completion

ReadApplication

Data

Script Processing

Terminal ActionAnalysis

InitiateApplication

Online/OfflineDecision

OnlineProcessing &

IssuerAuthorization

Offline

Online

Page 29: MasterCard ICC

Functional Specification of EMV’96 ICC Specification for Payment Systems Transactions1.2 Transaction Flow

ICC Application SpecificationNovember 1998

1-3

1.2.1 Card Transaction Flow Flags

The following data elements are defined in ICC to manage the transaction flow. The “SequenceFlag” is a data object grouping flags or indicators managed in the ICC volatile memory to keeptrack of events in the current transaction. Table 1.1 lists the recommended number of indicatorsto be used.

TABLE 1.1: INTERNAL FLAGS— VOLATILE MEMORY (“SEQUENCE FLAG”)

Flag name Meaning

“PIN Verification Performed” A VERIFY command has been performed during the currenttransaction

“PIN Verification Failed” A PIN Verification has failed during the current transaction

“Issuer Authentication Performed” Issuer Authentication has been performed

“Issuer Authentication successful” Issuer Authentication has been performed successfully

“Script performed” A script command has been performed during the currenttransaction

“Script failed” A script command has failed during the script processing

The “Application Flag” is a data object grouping flags or indicators managed in the ICC non-volatile memory to keep track of events in previous transactions. Table 1.2 lists therecommended number of indicators to be used.

Page 30: MasterCard ICC

Functional Specification of EMV’96 ICC Specification for Payment Systems Transactions1.2 Transaction Flow

ICC Application Specification © 1998 MasterCard International IncorporatedNovember 19981-4

TABLE 1.2: INTERNAL FLAGS - NON-VOLATILE MEMORY (“APPLICATION FLAG”)

Flag name Meaning

Script Status Flag(SSF) The setting of this flag to 1 indicates that the script processing is“pending”, the setting of this flag to 0 indicates that no scriptprocessing is “ pending” (the previous script processing has beennormally terminated)

Application Blocked Flag (ABF) The setting of this flag to 1 indicates that the selected Application isblocked

Last online transaction not completed The ICC issued an ARQC on the 1st Generate AC but a 2nd GenerateAC was not received

Issuer Authentication failure on lastonline authorization

Issuer Authentication Data was present but failed on the last onlinetransaction.

Offline Static data authenticationfailed on last transaction

Offline Static CAM failed in a previous transaction

Offline Dynamic data authenticationfailed on last transaction

Offline Dynamic CAM failed in a previous transaction

Page 31: MasterCard ICC

Functional Specification of EMV’96 ICC Specification for Payment Systems Transactions1.3 Standard Payment Functions

ICC Application SpecificationNovember 1998

1-5

1.3 STANDARD PAYMENT FUNCTIONS

1.3.1 Application Selection

Application selection is performed as described in the EMV”96 ICC Specification for PaymentSystems:

The ICC has different options in supporting the application selection:

• It can support the Payment System Environment (PSE)• It can support selection by partial name• It must support direct selection by full name

Application selection is always the first application function performed. A successful execution ofthe function sets the path to the Application Definition File (ADF). Subsequent commands applyto Application Elementary Files (AEFs) associated to the selected ADF using Short FileIdentifiers (SFIs).

In response to the selection, the ICC returns the File Control Information (FCI) of the file.

1.3.1.1 Data Field Returned in the Response message

The data objects returned after the successful selection of the PSE, with file name“1PAY.SYS.DDF01,” are described in Table 1.3.

TABLE 1.3: SELECT RESPONSE MESSAGE DATA FIELD (FCI) OF THE PSE

Name Presence Tag Length Format

FCI Template M ‘6F’ var. up to 252 var.

DF Name ‘1PAY.SYS.DDF01’ M ‘84’ 14 b

FCI Proprietary Template M ‘A5’ var. var.

SFI of the directory elementary file M ‘88’ 1 b

Language Preference O ‘5F2D’ 2-8 an 2

Issuer Code Table Index O ‘9F11’ 1 n 2

FCI Issuer Discretionary Data O ‘BF0C’ var. up to 222 var.

Page 32: MasterCard ICC

Functional Specification of EMV’96 ICC Specification for Payment Systems Transactions1.3 Standard Payment Functions

ICC Application Specification © 1998 MasterCard International IncorporatedNovember 19981-6

The data objects returned after the successful selection of an ADF are described in Table 1.4

TABLE 1.4: SELECT RESPONSE MESSAGE DATA FIELDS OF AN ADF

Value Presence Tag Length Format

FCI Template M ‘6F’ var. up to252

var.

DF Name M ‘84’ 5-16 b

FCI Proprietary Template M ‘A5’ var. var..

Application Priority Indicator O ‘87’ 1 b

Application Label O ‘50’ 1-16 an 1-16

Language Preference O ‘5F2D’ 2-8 an 2

Issuer Code Table Index O ‘9F11’ 1 n 2

PDOL O ‘9F38’ var. b

Application Preferred Name O ‘9F12’ 1-16 an 1-16

FCI Issuer Discretionary Data O ‘BF0C’ var. var.

For an ADF the Dedicated File (DF) Name and Application Identifiers (AIDs) are identical.

If any of the optional data elements above have length 0 (meaning they are empty), they are notpresent in the FCI.

1.3.1.2 Coding of Payment System Application Identifiers

Application Identifiers (AIDs) which conform to ISO/IEC 7816-5 standard uniquely identifyapplications. An AID consists of two parts:

• A Registered Application Provider Identifier (RID) of 5 bytes, unique to an applicationprovider and assigned according to ISO/IEC 7816-5.

• An optional field assigned by the application provider of up to 11 bytes. This field is knownas a Proprietary Application Identifier Extension (PIX) and may contain any 0 - 11 byte valuespecified by the provider. The meaning of this field is defined only for the specific RID; itneeds not be unique across different RIDs.

Page 33: MasterCard ICC

Functional Specification of EMV’96 ICC Specification for Payment Systems Transactions1.3 Standard Payment Functions

ICC Application SpecificationNovember 1998

1-7

Additional ADFs defined under the control of other application providers may be present in theICC but must not duplicate the range of RIDs assigned to Payment Systems (which is anapplication provider according to ISO/IEC 7816-5). Compliance with ISO/IEC 7816-5 willassure this avoidance.

Refer to the Minimum Card Requirements for the MasterCard products (MasterCard, Cirrus).

1.3.1.3 Structure of the Payment Systems Environment

If present, the Structure of the PSE is compliant with EMV ‘96 ICC Specification for PaymentSystems— Part 3.

The PSE begins with a Directory Definition File (DDF) called ‘1PAY.SYS.DDF01’ whichcontains a Directory file referencing the Payment Applications which are stored within the ICC.The presence of the PSE ‘1PAY.SYS.DDF01’ is optional.

1.3.1.4 Coding of a Payment System’s Directory

A Payment System’s Directory is a linear file identified by a SFI in the range 1 to 10. The SFI forthe directory is contained in the FCI of the PSE.

Each entry in a Payment Systems Directory is an Application Template (tag ‘61’) and contains theinformation according to Table 1.5:

TABLE 1.5: ADF DIRECTORY ENTRY FORMAT

Tag Length Value Presence

‘4F’ 5-16 ADF Name (AID) M

‘50’ 1-16 Application Label M

‘9F12’ 1-16 Application Preferred Name O

‘73’ var. Directory Discretionary Template O

Page 34: MasterCard ICC

Functional Specification of EMV’96 ICC Specification for Payment Systems Transactions1.3 Standard Payment Functions

ICC Application Specification © 1998 MasterCard International IncorporatedNovember 19981-8

1.3.1.5 Application Selection with or without cardholder confirmation

The applications can be ranked by priority order according to Table 1.6:

The applications that are intended to be selected after the confirmation of the cardholder will haveb8 set.

TABLE 1.6: CODING OF APPLICATION PRIORITY WITH OR WITHOUT CARDHOLDER CONFIRMATION

b8 b7-b5 b4-b1 Definition

0/1 0 = Application may be selected without confirmation ofcardholder

1 = Application cannot be selected without confirmation ofcardholder

xxx RESERVED

0000 No priority assigned

xxxx

(except0000)

Order in which the application is to be listed or selected,ranging from 1 to 15, with 1 being highest priority.

Page 35: MasterCard ICC

Functional Specification of EMV’96 ICC Specification for Payment Systems Transactions1.3 Standard Payment Functions

ICC Application SpecificationNovember 1998

1-9

1.3.2 Initiate Application Processing

Initiate application processing is performed as described in the EMV ‘96’ ICC Specification forPayment Systems.

In the Get Processing Options command data, the ICC may receive the PDOL which contains theterminal data object values as required in the response to the Select command. According to thisPDOL data object values the ICC shall be able to return the appropriate Application File Locator(AFL) and Application Interchange Profile (AIP). The ICC can manage several sets of AIP/AFLand chooses the appropriate AIP and AFL depending on the PDOL data. An AFL defines the setof data records that the terminal must read.

In order to differentiate several behaviors regarding CVM list, CDOLs, IACs … depending on theterminal environment where the ICC is used, the ICC may contain several AFLs.

If a single couple (AIP, AFL) is defined for the application, an empty PDOL can be used (PDOLnot present in the response to the Select command).

A single couple (AIP, AFL) may be used with a non empty PDOL to test additional constraints ofthe selected application (e.g. to rejecting a transaction based on non supported terminalcapabilities).

The ATC shall be incremented during the Initiate application processing.

1.3.2.1 Optional Data Objects Supplied With The GET PROCESSING OPTIONScommand

If the Processing Option Data Object List (PDOL) is used in the GET PROCESSING OPTIONScommand, it is recommended that it includes one or more data objects defined Table 1.7:

TABLE 1.7: PDOL DATA

Value Presence Tag Length

Terminal Type O ‘9F35’ 1

Terminal Capabilities O ‘9F33’ 3

Merchant Category Code O ‘9F15’ 3

Transaction Type O ‘9C’ 1

Terminal Country Code O ‘9F1A’ 2

Transaction Category Code O ‘9F53’ 1

Page 36: MasterCard ICC

Functional Specification of EMV’96 ICC Specification for Payment Systems Transactions1.3 Standard Payment Functions

ICC Application Specification © 1998 MasterCard International IncorporatedNovember 19981-10

1.3.2.2 AIP and AFL

The AIP and AFL information are defined at card personalization stage.

The AFL value is a list of objects defined in Table 1.8:

TABLE 1.8: AFL DESCRIPTION

B8 b7 b6 b5 b4 b3 b2 b1 Meaning

Byte 1 x x x x x 0 0 0 coding of the SFI (five most significant bits)

Byte 2 x x x x x x x x first record number to be read for that SFI

Byte 3 x x x x x x x x last record number to be read for that SFI

Byte 4 x x x x x x x x number of records involved in offline dataauthentication

1.3.2.3 Mandatory Data Objects Supplied With The GET PROCESSING OPTIONScommand

TABLE 1.9: DATA RETRIEVABLE BY GET PROCESSING OPTIONS COMMAND

Value Presence Tag Length

Application Interchange Profile M ‘82’ 2

Application File Locator M ‘94’ 4-252

Page 37: MasterCard ICC

Functional Specification of EMV’96 ICC Specification for Payment Systems Transactions1.3 Standard Payment Functions

ICC Application SpecificationNovember 1998

1-11

1.3.2.4 Initiate Application Processing flow

Figure 1.2 describes all the functions performed by the ICC during the Get Processing Optionscommand.

FIGURE 1.2: INITIATE APPLICATION PROCESSING

Initiate Application Processing

PDOL supported?

Increment ATC

Normal End Transaction rejected

AIP and AFL found?

ATC ='FFFF'?

No

Yes

No

Yes

No

Yes

1.3.2.4.1 PDOL supported?

The ICC verifies that it supports the PDOL data objects values provided in the Get ProcessingOptions command. If one data object value is not supported, the transaction is rejected.

Page 38: MasterCard ICC

Functional Specification of EMV’96 ICC Specification for Payment Systems Transactions1.3 Standard Payment Functions

ICC Application Specification © 1998 MasterCard International IncorporatedNovember 19981-12

1.3.2.4.2 ATC=’FFFF’ ?

The ICC verifies that ATC equals ‘FFFF’. If ATC equals ‘FFFF’, the transaction is rejected, elsethe ATC is incremented by 1.

1.3.2.4.3 AIP and AFL found?

The ICC searches for an appropriate AIP and an AFL corresponding to the PDOL data. If thecouple (AIP, AFL) is not found the transaction is rejected; else the Initiate Application Processingis successful and the couple (AIP, AFL) is returned to the terminal.

1.3.3 Read Application Data

Read application data is performed as described in the EMV”96 ICC Specification for PaymentSystems. Data Objects are read through the command READ RECORD according to theEMV”96 ICC Specification for Payment Systems.

The complete list of the Data Objects will be described in Section III and Appendix A of thisspecification.

1.3.4 Offline Card Authentication

Data authentication is performed by the terminal as described in the EMV”96 ICC Specificationfor Payment Systems. Using digital signatures based on public key techniques the terminal canverify the legitimacy of the card and of critical ICC data; the ICC contains certificates the terminalcan verify.

1.3.4.1 Static offline card authentication

Data objects that are signed are “read only”. Issuers may choose other data objects to be signedbut such data must be static (i.e. never change) and for which the detection of fraudulent changeis beneficial. With static offline card authentication the ICC doesn’t play an active role.

1.3.4.2 Dynamic offline card authentication

For dynamic offline card authentication, the ICC plays an active role. As a response to theINTERNAL AUTHENTICATE command, it signs data the terminal can verify with the ICCpublic key.

Page 39: MasterCard ICC

Functional Specification of EMV’96 ICC Specification for Payment Systems Transactions1.3 Standard Payment Functions

ICC Application SpecificationNovember 1998

1-13

1.3.5 Cardholder Verification

Cardholder verification is performed as described in the EMV”96 ICC Specification for PaymentSystems.

The following Cardholder Verification Methods (CVMs) can be supported by the ICC applicationand may be included in the ICC applications CVM List:

• Paper signature• No CVM required• Online PIN• Offline PIN (plain text or enciphered)

If offline plain text PIN is used, the VERIFY command initiates in the ICC the comparison of theTransaction PIN Data (tag ‘99’) sent in the data field of the command with the Reference PINstored in the ICC.

If offline enciphered PIN is used, the ICC first deciphers the enciphered PIN, before comparing itwith the Reference PIN.

1.3.5.1 Reference PIN definition

The total length of the PIN may vary from 4 to 12 numeric digits. The initial length determinedby the Issuer at the personalization stage of the ICC could be updated during the further life cycleof the ICC.

The PIN Try Limit (PTL), may vary from Issuer to Issuer. The PIN Try Counter (PTC) is linkedto a single Reference PIN. The PTL value is determined by the Issuer during the personalizationstage of the ICC, and is not changed during the further life cycle of the ICC. The plain text andenciphered PIN are the only supported offline PIN formats.

It must be impossible to extract the Reference PIN from the ICC.

For a PIN, the Offline PIN Verification status “PIN Verification Performed,” “PIN VerificationFailed” should be valid until a further ADF selection is performed.

1.3.5.2 Enciphered offline PIN definition

The complete process of PIN Encipherment by the terminal is described in Section 2. An ICCwith dynamic RSA is required to perform the functionality:

The key involved to encipher the PIN by the terminal is the ICC PIN Encipherment Public key ifpresent or the ICC Application Public key in the other case.

Page 40: MasterCard ICC

Functional Specification of EMV’96 ICC Specification for Payment Systems Transactions1.3 Standard Payment Functions

ICC Application Specification © 1998 MasterCard International IncorporatedNovember 19981-14

Unpredictable data are provided by the terminal and by the ICC, to complete the PIN data to beenciphered. The unpredictable data provided by the ICC are obtained by means of the command“GET CHALLENGE”. The random number stays only valid for the next command, which shouldbe a “VERIFY” command. If an error occurs or if the command is a command different from the“VERIFY” command, the random number is lost.

1.3.5.3 General processing

When the terminal determines that an offline PIN is to be used, the terminal should send a GETDATA command to the ICC to obtain the PTC. If the GET DATA command is supported by theICC, the ICC replies with the PTC. If the PTC is “0”, indicating no more PIN tries, the ICC doesnot allow offline PIN check.

The application decrements the PTC and then compares the Transaction and Reference PINs. Ifthey match, the ICC indicates this in the response to the VERIFY command, and the ICC resetsthe PTC to the value of the PTL.

If the PTC was “0” before the beginning of the command, the ICC does not compare theTransaction and Reference PINs, it indicates in the response to the VERIFY command that thePTL is exceeded (the PIN is blocked).

If the PIN Verification has failed, the resulting value of the PTC is sent in the VERIFY responseindicating the number of remaining PIN tries.

Page 41: MasterCard ICC

Functional Specification of EMV’96 ICC Specification for Payment Systems Transactions1.3 Standard Payment Functions

ICC Application SpecificationNovember 1998

1-15

FIGURE 1.3: OFFLINE PIN VERIFICATION

Off-line PIN Verification

DecrementPIN Try Counter

PINEnciphered?

CommandRejected

DecipherPIN

Reset 'PIN Verification Failed'

Update Sequence Flagabout PIN

Reset PIN Try Counter

PTC=0 ?

PIN OK ?

Deciphered data correct?

Yes

No

No

Yes

No

Yes

No

Yes

Page 42: MasterCard ICC

Functional Specification of EMV’96 ICC Specification for Payment Systems Transactions1.3 Standard Payment Functions

ICC Application Specification © 1998 MasterCard International IncorporatedNovember 19981-16

1.3.5.4 Verify description

1.3.5.4.1 Update Sequence Flag about PIN

The ICC updates the PIN related flags in Sequence flag:

• The “PIN Verification Performed” bit is set• The “PIN Verification Failed” bit is set

1.3.5.4.2 PTC = 0 ?

The ICC checks if the PTC has reached the value 0. In this case, the ICC cannot perform the PINverification and returns an error code in the processing state SW1 SW2: ‘6983’ Authenticationmethod blocked.

1.3.5.4.3 Decrement PIN Try Counter (PTC)

Before comparing the Transaction PIN with the Reference PIN, the ICC decrements the PTC.

1.3.5.4.4 PIN Enciphered?

The ICC tests if the Transaction PIN data is sent in plain text or enciphered.

1.3.5.4.5 Decipher PIN

The ICC deciphers the Transaction PIN data with the ICC private key.

1.3.5.4.6 Deciphered data correct?

The ICC verifies the format of the deciphered data and its header (value ‘7F’), and checks withthe challenge provided by ICC. In case the comparison fails, the command is rejected.

1.3.5.4.7 PIN OK?

The ICC verifies the PIN header and compares the Transaction PIN data sent in the data field ofthe command with the Reference PIN. In case the comparison fails, the ICC returns a warning inthe processing state SW1 SW2: ‘63 Cx’ (Verification Failed) where “x” designates the number offurther retries allowed.

1.3.5.4.8 Reset PIN Try Counter

When the comparison of the Transaction PIN Data with the Reference PIN Data has beensuccessful, the ICC resets the PTC to the PTL value.

Page 43: MasterCard ICC

Functional Specification of EMV’96 ICC Specification for Payment Systems Transactions1.3 Standard Payment Functions

ICC Application SpecificationNovember 1998

1-17

1.3.5.4.9 Reset “PIN Verification Failed”

When the comparison of the Transaction PIN Data with the Reference PIN Data has beensuccessful, the ICC resets the “PIN Verification Failed” flag in Sequence flag.

1.3.6 First GENERATE AC Processing

The GENERATE AC command is used to transmit transaction-related data objects from theterminal to the ICC and to demand an Application Cryptogram. The terminal demands one ofthree different types of Application Cryptogram.

1. Request for the generation of a TC:

The ICC will respond with a Transaction Certificate (TC) when the terminal requests a TCand none of the results of the card risk management checks performed indicate that the ICCshould respond with an Authorization Request Cryptogram (ARQC) or ApplicationAuthentication Cryptogram (AAC).

Prior to responding with a TC, the ICC performs any necessary card risk managementfunctions:

• Set the bits in the Card Verification Results (CVR) to indicate that a TC was returned inthe first GENERATE AC response and a second GENERATE AC command was notrequested.

• Increment the Cumulative Offline Transaction Amount by the value of the transactionamount where application currency is the same as transaction currency.

+ When the ICC responds with a TC or an AAC in response to the firstGENERATE AC command, the terminal completes the transaction. Theterminal should display a message to indicate the action taken (approved,declined).

Page 44: MasterCard ICC

Functional Specification of EMV’96 ICC Specification for Payment Systems Transactions1.3 Standard Payment Functions

ICC Application Specification © 1998 MasterCard International IncorporatedNovember 19981-18

2. Request for the generation of an ARQC

If the terminal requests an ARQC and the results of the card risk management allow the ICCto respond with an ARQC, the ICC responds with an ARQC. Upon receipt of the response,the terminal proceeds to online processing. Prior to responding with an ARQC, the ICCperforms any necessary card risk management functions:

• Set the bits in the CVR to indicate that an ARQC was returned in the first GENERATEAC response and a second GENERATE AC command was not yet requested

• Set the “Last Online Transaction not completed” flag

If the terminal requests an ARQC but the results of the card risk management do not allow theICC to respond with an ARQC, the ICC responds with an AAC.

3. Request for the generation of an AAC

The ICC will respond with an AAC when:

• The terminal requests an AAC, or• The results of the card risk management checks indicate at least once that the ICC should

respond with an AAC

Prior to responding with an AAC, the ICC performs the following function:

• Set the bits in the CVR to indicate that an AAC was returned in the first GENERATE ACresponse and a second GENERATE AC command was not requested;

The GENERATE AC command is coded as described in Part II of the EMV ‘96 ICCSpecification for Payment Systems.

When a data object is referenced in CDOL1 or CDOL2, the length of the data objects is asspecified for this specification.

When the “Amount, Authorized” and “Amount, Other” are referenced in CDOL1 and CDOL2 forinput to the TC, AAC or ARQC, the tags and lengths for the numeric versions are used (tags“9F02” and “9F03”), not the tags and lengths for the binary versions.

Page 45: MasterCard ICC

Functional Specification of EMV’96 ICC Specification for Payment Systems Transactions1.3 Standard Payment Functions

ICC Application SpecificationNovember 1998

1-19

The data field of the GENERATE AC command is not TLV encoded, so it is imperative for theICC to know the format of this data when the command is received. This is achieved by havingspecified the format of the data to be included in the command, using the Card Risk ManagementData Object List CDOL1 (tag ‘8C’).

As a result of the GENERATE AC command, the ICC response consists of returning thefollowing data objects to the terminal:

TABLE 1.10: DATA ELEMENTS SENT TO THE TERMINAL

Name Tag Length Format

Cryptogram Information Data ‘9F27’ 1 b

ATC (Application Transaction Counter) ‘9F36’ 2 b

Application Cryptogram ‘9F26’ 8 b

Issuer Application Data ‘9F10’ 8-321 b

1 Due to network restrictions in the U.K, the Issuer is only guaranteed to receive the first seven bytes of the IssuerApplication Data in the authorization.

Page 46: MasterCard ICC

Functional Specification of EMV’96 ICC Specification for Payment Systems Transactions1.3 Standard Payment Functions

ICC Application Specification © 1998 MasterCard International IncorporatedNovember 19981-20

• Cryptogram Information Data: see Table 1.11.

TABLE 1.11: CRYPTOGRAM INFORMATION DATA

b8 b7 b6 b5 b4 b3 b2 b1 Meaning

0 0 AAC

0 1 TC

1 0 ARQC

1 1 Not used

x x RESERVED

0 No advice required

1 Advice required

x x x Reason/advice/referral code

0 0 0 No information given

0 1 0 PIN try limit exceeded

0 1 1 Issuer Authentication Failed

x x x Other values RESERVED

* An advice can be required (bit b4 = 1) in case the PIN is blocked (reason: PIN Try Limitexceeded) and the ICC does not demand an ARQC. During the First Generate AC the case“Issuer Authentication has failed” is not supported.

• ATC: This is the Application Transaction Counter stored in the ICC. It is incremented by oneeach time the GET PROCESSING OPTIONS command is executed. The ATC is used togenerate the application cryptogram.

• Application Cryptogram: Section 2 describes in detail how the cryptogram is generated(using the appropriate ICC Master Key...), and which transaction data need to be taken intoaccount. The result is a TC, an ARQC, or an AAC. The cryptogram returned by the ICCmay differ from that requested by the terminal in the command message according to theinternal ICC processing.

+ * Advice messages will not be supported across MasterCard networks, but maybe supported under other circumstances.

Page 47: MasterCard ICC

Functional Specification of EMV’96 ICC Specification for Payment Systems Transactions1.3 Standard Payment Functions

ICC Application SpecificationNovember 1998

1-21

• Issuer Application Data contains the following data objects ordered as follows:– Key Derivation Index– Cryptogram Version Number– CVR: information about the ICC decisions taken during the Card Risk Management

(CRM) processing– Data Authentication Code (DAC) or 2 leftmost bytes of ICC Dynamic Number: proving

that the terminal correctly performed Static or Dynamic Data Authentication– Other data

1.3.6.1 Card Risk Management Data (CDOL1)

The Card Risk Management Data Object List (CDOL1) is an EMV ICC data object, whichprovides the terminal with a list of data objects required for the CRM processing and thecertificate generation.

The CDOL1 is used with the first GENERATE AC command. The coding of CDOL1 is definedin Section 3.

The value of each data objects of the CDOL1 has to be passed from the terminal to the ICCwithin the data field of the first GENERATE AC command.

Page 48: MasterCard ICC

Functional Specification of EMV’96 ICC Specification for Payment Systems Transactions1.3 Standard Payment Functions

ICC Application Specification © 1998 MasterCard International IncorporatedNovember 19981-22

1.3.6.2 Internal Process

Figure 1.4 describes all the functions performed by the ICC during the first GENERATE ACcommand.

FIGURE 1.4: FIRST GENERATE AC OVERALL DIAGRAM

First Generate AC

Reset CVR

CRM

Set TC in CVR

Calculation of ACTransaction completion

Terminal Request?(optional test)

Set AAC in CVR

Update ICC parameters

Set ARQC in CVR

Application blocked?

Card Action Analysis

AAC

Yes

AAC ARQC

TC, ARQC, or AAC (in case optional test not done)

No

Page 49: MasterCard ICC

Functional Specification of EMV’96 ICC Specification for Payment Systems Transactions1.3 Standard Payment Functions

ICC Application SpecificationNovember 1998

1-23

A detailed analysis of the Card Risk Management (CRM) function is described in section.1.3.6.3CRM.

A detailed analysis of the Card Action Analysis function is described in section 1.3.6.4 CardAction Analysis.

A detailed analysis of the Update ICC Parameters function is described in section 1.3.6.5 UpdateICC Parameters.

A detailed analysis of the Transaction Completion function is described in section 1.3.6.6Transaction Completion/Online Processing.

1.3.6.2.1 Reset CVR (Card Verification Result)

The CVR are ICC internal registers storing information concerning the ICC functions performedduring a Payment Transaction. The major ICC functions reflected in these registers are the PINverification, the card risk management checks and the status of the previous transaction:

• Type of Application Cryptogram returned in 1st Generate AC (AAC, TC, ARQC)• Type of Application Cryptogram returned in 2nd Generate AC (AAC, TC, 2nd Generate AC

not requested)• Issuer Authentication Failed• Offline PIN Verification performed• Offline PIN Verification failed• Unable to go online• Last online transaction not completed• Pin try limit exceeded• Exceeded velocity checking• New card• Issuer Authentication failure on last online transaction• Issuer Authentication not performed after online authorization• Application blocked by card because PIN Try Limit exceeded• Offline Static data authentication failed on last transaction• Number of script commands processed successfully• Offline Dynamic data authentication failed on last transaction• Issuer script processing failed on last or current transaction• Lower consecutive Offline limit or Lower Cumulative Offline Transaction Amount Exceeded• Upper consecutive Offline limit or Upper Cumulative Offline Transaction Amount Exceeded• Maximum Offline Transaction Amount exceeded

The CVR is reset to ‘0’ at the beginning of the first Generate AC.

Page 50: MasterCard ICC

Functional Specification of EMV’96 ICC Specification for Payment Systems Transactions1.3 Standard Payment Functions

ICC Application Specification © 1998 MasterCard International IncorporatedNovember 19981-24

1.3.6.3 CRM

This section describes the MasterCard recommended card risk management functions that aresupported for international transactions and the setting of the bits in the CVR to record theoutcome of the execution of the card risk management functions. Issuers can implement furthernon-EMV card risk management functions on the cards that they issue. As a general guideline, ifthe issuer uses EMV data elements and the risk management functionality is entirely within theICC, such functionality should be supported for international transactions. If terminals arerequired to carry out any additional processing then that functionality may only be supporteddomestically. In all cases, implementers must seek MasterCard approval for issuer/country/regionspecific card risk management functionality before assuming anything other than local support.

The Issuer is free to pick among the different card risk management functions:

• PIN verification status• Previous transaction status• New card• Maximum offline transaction Amount• Velocity checking of Offline Consecutive transactions• Offline cumulative amount

“Offline cumulative amount” and “Velocity checking of Offline Consecutive transactions” arestrongly recommended as a minimum. Once the card risk management functions have beenselected, those functions are to be performed as indicated in this specification.

+ Velocity checking is mandatory. It can be either performed by the terminal orby the card internally. The velocity checking described in this documentconcerns the velocity checking done by the card internally.

To determine whether the ICC responds with a TC, ARQC, or AAC, the ICC may perform one ormore of card risk management functions. Even if one of the card risk management functionsdetermines that an AAC will be returned in the response to the GENERATE AC command, theICC must proceed through all functions in card risk management prior to responding with anAAC. Since the ICC must perform all functions, the order in which the functions are performedneed not conform to the order described in this section.

If a data object requested from the terminal is not available (the data object returned in theGENERATE AC command data field is zero filled), the ICC proceeds to the next function in cardrisk management.

Page 51: MasterCard ICC

Functional Specification of EMV’96 ICC Specification for Payment Systems Transactions1.3 Standard Payment Functions

ICC Application SpecificationNovember 1998

1-25

1.3.6.3.1 PIN verification status

The ICC updates the CVR Offline PIN Verification bits:

• The CVR bit “Offline PIN Verification was performed” is set if a VERIFY command wasreceived in the current transaction

• The CVR bit “Offline PIN Verification failed” is set if a VERIFY command has failed (PINfailed or blocked during the current transaction)

• The CVR bit “PIN Try Limit exceeded” is set if the PIN Try Counter became 0 before orduring the current transaction

1.3.6.3.2 Previous transaction status

The ICC updates the previous transaction CVR bits using Application Flag and Script Counter:

• Last online transaction not completed• Issuer Authentication failure on last online transaction• Offline Static Data Authentication failed on last transaction• Offline Dynamic Data Authentication failed on last transaction

This information is copied in the CVR for the current transaction.

The Application Flag data object also contains the status of the previous script processing. TheCVR bit “Issuer script processing failed on last or current transaction” is set if the scriptprocessing status has the value “script processing under-process”; else it is reset.

+ The three least significant bits (b3-b1) of the Script Counter are copied in CVR(byte 4, b8-b6).

Page 52: MasterCard ICC

Functional Specification of EMV’96 ICC Specification for Payment Systems Transactions1.3 Standard Payment Functions

ICC Application Specification © 1998 MasterCard International IncorporatedNovember 19981-26

1.3.6.3.3 New Card

If the Last Online Application Transaction Counter (LATC: tag ‘9F13’) is zero, the ICC performsthe following function:

• Set the “New card” bit in the CVR (the ICC has never performed a successful IssuerAuthentication followed by a TC computation);

1.3.6.3.4 Maximum Offline Transaction Amount

This function determines if the current transaction exceeds a pre-determined maximum offlinetransaction amount.

As a first step in applying this function the ICC verifies that the Terminal Country Code (tag‘9F1A’) is the same as the Issuer Country Code (tag ‘5F28’), and the Transaction Currency Code(Tag’5F2A’) supplied in the first GENERATE AC command, is the same as the ApplicationCurrency Code (Tag’9F42’) stored in the ICC application. If these values are different or if eithervalue is not available, the ICC proceeds to the next function in card risk management.

The ICC determines if the value of the Amount Authorized (tag ‘9F02’) exceeds the parameter“Maximum Domestic Offline Transaction Amount.” If the value is exceeded, the ICC sets the“Maximum Offline Transaction Amount exceeded” bit in the CVR.

1.3.6.3.5 Velocity Checking of Offline Consecutive Transactions

The “Velocity Checking of Offline Consecutive Transactions” function determines if the limit setfor the maximum number of consecutive offline transactions has been exceeded.

If the Terminal Country Code (tag ‘9F1A’) is NOT the same as the Issuer Country Code (tag‘5F28’), or the Transaction Currency Code (Tag ‘5F2A’) supplied in the first GENERATE ACcommand is NOT the same as the Application Currency Code (Tag ‘9F42’) stored in the ICCapplication, then the Upper and Lower Consecutive Offline Limits (tag ‘9F23’ and ‘9F14’) areadjusted in accordance with the Non-Domestic Control Factor (NDCF) in Table 1.12 and Figure1.5. The adjustment will either force all transactions online or increase the frequency of onlinetransactions.

Page 53: MasterCard ICC

Functional Specification of EMV’96 ICC Specification for Payment Systems Transactions1.3 Standard Payment Functions

ICC Application SpecificationNovember 1998

1-27

The ICC determines if the difference between the ATC (tag ‘9F36’) and the LATC (tag ‘9F13’) isgreater than the Lower Consecutive Offline Limit (tag ‘9F14’). If it is, the ICC sets the “LowerConsecutive Offline Limit exceeded” bit and the “Exceeded Velocity Checking” bit in the CVR.

The ICC determines if the difference between the ATC (tag ‘9F36’) and the LATC (tag ‘9F13’) isgreater than the Upper Consecutive Offline Limit (tag ‘9F23’). If it is, the ICC sets the “UpperConsecutive Offline Limit” bit and the “Exceeded Velocity Checking” bit in the CVR.

The “Offline Consecutive Transaction Number” function is illustrated in Figure 1.5.

FIGURE 1.5: OFFLINE CONSECUTIVE TRANSACTION FUNCTION PROCESSING

Offline Consecutive Transactions

Domestic Transaction?

Read in ICCNon Domestic Control Factor

InitialiseNon Domestic Control Factor = 1

ATC - LATC> LCOLL/NDCF

� CVR flag "Lower consecutiveoffline limt was exceeded" = 1

� CVR flag "Exceeded velocitychecking" = 1

ATC - LATC> UCOLL/NDCF

� CVR flag "Upper consecutiveoffline limt was exceeded" = 1

� CVR flag "Exceeded velocitychecking" = 1

Yes

Yes

No

No

Exit

YesNo

Page 54: MasterCard ICC

Functional Specification of EMV’96 ICC Specification for Payment Systems Transactions1.3 Standard Payment Functions

ICC Application Specification © 1998 MasterCard International IncorporatedNovember 19981-28

The Issuer can determine its maximum offline risk by using the Lower Consecutive Offline Limit(tag ‘9F14’) and the Upper Consecutive Offline Limit (tag ‘9F23’) that correspond to themaximum value (ATC - LATC). The Issuer can update these parameters through scriptprocessing.

+ The division LCOLL/NDCF and UCOLL/NDCF can be truncated to integervalue

TABLE 1.12: DATA OBJECTS INVOLVED IN MAXIMUM OFFLINE CONSECUTIVE TRANSACTION NUMBER CHECK

Name Source Tag Length Format

Application Transaction Counter (ATC) ICC ‘9F36’ 2 b

Last Online Application Transaction Counter (LATC)Register

ICC ‘9F13’ 2 b

Lower Consecutive Offline Limit ICC ‘9F14’ 1 b

Upper Consecutive Offline Limit ICC ‘9F23’ 1 b

Non Domestic Control Factor (NDCF) ICC 1 b

Application Currency Code ICC ‘9F42’ 2 n 3

Transaction Currency Code Terminal ‘5F2A’ 2 n 3

Issuer Country Code ICC ‘5F28’ 2 n 3

Terminal Country Code Terminal ‘9F1A’ 2 n 3

1.3.6.3.6 Offline Cumulative amount

This function determines if the current transaction, together with the cumulative value of thepreceding consecutive offline transactions, exceeds a pre-determined cumulative value set by theissuer.

As a first step in applying this function the ICC verifies that the Transaction Currency Code(Tag’5F2A’) supplied in the GENERATE AC command is the same as the Application CurrencyCode (Tag’9F42’) stored in the ICC application. If these values are different, the ICC can trycurrency conversion or it can proceed to the next function in card risk management.

Page 55: MasterCard ICC

Functional Specification of EMV’96 ICC Specification for Payment Systems Transactions1.3 Standard Payment Functions

ICC Application SpecificationNovember 1998

1-29

Lower and Upper bounds are used:

• The ICC determines if the value of Cumulative Offline Transactions plus the AmountAuthorized (AA: tag ‘9F02’) requested for the current transaction exceeds the LowerCumulative Offline Transaction Amount. If it is, the ICC sets the “Lower Cumulative OfflineTransaction Amount exceeded” bit in the CVR.

• The ICC determines if the value of Cumulative Offline Transactions plus the AmountAuthorized (AA: tag ‘9F02’) requested for the current transaction exceeds the UpperCumulative Offline Transaction Amount. If it is, the ICC sets the “Upper Cumulative OfflineTransaction Amount exceeded” bit in the CVR.

The “Offline Cumulative amount” function is illustrated in Figure 1.6.

FIGURE 1.6: CUMULATIVE AMOUNT CHECK PROCESSING

Cumulative Amount

Application Currency Code=

Transaction Currency Code?

Currency Conversion

successful conversion?

LCDOTA - COT< AA

UCDOTA - COT< AA

CVR flag "Lower cumulativeoffline amount was exceeded" = 1

CVR flag "Upper cumulativeoffline amount was exceeded" = 1

Exit

Yes No

Yes

Yes

Yes

No

No

No

Page 56: MasterCard ICC

Functional Specification of EMV’96 ICC Specification for Payment Systems Transactions1.3 Standard Payment Functions

ICC Application Specification © 1998 MasterCard International IncorporatedNovember 19981-30

The ICC data objects used in the “Maximum Offline Cumulative Amount” function are defined inTable 1.13.

TABLE 1.13: DATA OBJECTS INVOLVED IN CUMULATIVE AMOUNT FUNCTION FOR A PAYMENT TRANSACTION

Name Source Tag Length Format

Lower Cumulative Domestic Offline TransactionAmount (LCDOTA)

ICC 6 n12

Upper Cumulative Domestic Offline TransactionAmount (UCDOTA)

ICC 6 n12

Cumulative Offline Transaction (COT) ICC 6 n12

Application Currency Code ICC ‘9F42’ 2 n 3

Transaction Currency Code Terminal ‘5F2A’ 2 n 3

Reference Currency Conversion Table ICC Up to 20 b

1.3.6.3.6.1 Currency conversion

Currency conversion in the ICC is included at the issuers discretion. It is strongly recommendedthat issuers only use this function if they are confident that currency fluctuations will not exposethem to unmanageable risks.

The ICC initiates currency conversion by listing the “Amount in Reference Currency” (tag‘9F3A’) and “Transaction Reference Currency Code” (tag ‘9F3C’) in CDOL1.

+ The terminals that support currency conversion, convert the “AmountAuthorized” (AA: tag ‘9F02’) into the “Amount in Reference Currency” (tag‘9F3A’). It is done by using the conversion rate managed by the terminals (fromthe Transaction Currency Code (tag ‘5F2A’) to the Transaction ReferenceCurrency Code (tag ‘9F3C’).

Then the ICC converts the “Amount in Reference Currency” (tag ‘9F3A’) into the “Amount inApplication Currency” using a conversion rate found in the Reference Currency Conversion Tablefrom the Transaction Reference Currency Code (tag ‘9F3C’) to the “Application Currency Code”(tag ‘9F42’).

Conversion at ICC level

Page 57: MasterCard ICC

Functional Specification of EMV’96 ICC Specification for Payment Systems Transactions1.3 Standard Payment Functions

ICC Application SpecificationNovember 1998

1-31

The “Currency Conversion” function is illustrated in Figure 1.7.

FIGURE 1.7: CURRENCY CONVERSION AT ICC LEVEL

Currency Conversion

TransactionReference

Currency Codesupported by the ICC?

Amount inApplication Currency = Amount in Reference Currency * Reference Currency to Application Currency Conversion Rate / 2 POWER (Reference Currency to Application Currency Conversion Rate Exponent)

Conversion failed

Yes

No

If the terminal’s “Transaction Reference Currency Code” (tag ‘9F3C’) equals one of the referencecurrencies supported by the ICC, then the ICC converts the “Amount in Reference Currency” (tag‘9F3A’) provided by the terminal in binary format into the “Amount in Application Currencycode”, which then is used by the ICC. Otherwise currency conversion has failed.

Page 58: MasterCard ICC

Functional Specification of EMV’96 ICC Specification for Payment Systems Transactions1.3 Standard Payment Functions

ICC Application Specification © 1998 MasterCard International IncorporatedNovember 19981-32

The “Reference Currency Conversion Table” is an ICC internal data object. It can contain theconversion rates for up to four reference currencies supported by the ICC. For each referencecurrency supported by the ICC, this table contains an entry as described in Table 1.14.

TABLE 1.14: REFERENCE CURRENCY CONVERSION TABLE

Field Size in bytes Format Meaning

1 2 n3 Reference Currency Code (according ISO 4217)

2 2 b Reference Currency to Application Currency Conversion rate

3 1 b Reference Currency to Application Currency Conversion rateexponent

The ICC data objects involved in the currency conversion function are defined in Table 1.15.

TABLE 1.15: DATA OBJECTS INVOLVED IN CURRENCY CONVERSION AT ICC LEVEL

Name Source Tag Length Format

Reference Currency Conversion Table ICC -- var.

Amount in Reference Currency Terminal ‘9F3A’ 4 b

Transaction Reference Currency Code Terminal ‘9F3C’ 2 n3

The Issuer can consider updating the conversion rates from time to time by means of scriptprocessing.

Example:

• Terminal provides:Amount in Reference Currency = 125Transaction Reference Currency Code = Dollar

• The ICC table containsReference Currency = Dollar

Conversion Rate = 5045Conversion Rate Exponent = (/210)

The ICC computes the Amount in Application CurrencyAmount in Application Currency = 125* 5045 / 1024

Page 59: MasterCard ICC

Functional Specification of EMV’96 ICC Specification for Payment Systems Transactions1.3 Standard Payment Functions

ICC Application SpecificationNovember 1998

1-33

1.3.6.4 Card Action Analysis

This section describes the MasterCard/Europay recommended Card Action Analysis risk functionsthat are supported for international transactions. After having performed the different CRMfunctions, the ICC may decide to:

• Decline a transaction• To complete a transaction online• To complete a transaction offline

The ‘Card Action Analysis’ function is illustrated in Figure 1.8.

FIGURE 1.8: CARD ACTION ANALYSIS OF THE FIRST GENERATE AC

Card Action Analysis

Terminal Request?

Terminal type?

TVR requests ARQC?CVR and

CIAC Decline=0?

Terminal type?

CVR andCIAC Offline

=0? Terminal Request?

CVR andCIAC Online

=0?

ICC returns AAC ICC returns TC ICC returns ARQC

AAC ARQC

TC Offline

Online

No

No

Offline Online

No Yes

Yes No

TC

ARQC

In this diagram, AND means “the logical function AND.”

Page 60: MasterCard ICC

Functional Specification of EMV’96 ICC Specification for Payment Systems Transactions1.3 Standard Payment Functions

ICC Application Specification © 1998 MasterCard International IncorporatedNovember 19981-34

1.3.6.4.1 Terminal type?

The ICC checks the Terminal Type2 (tag ‘9F35’) using the EMV definition.

1.3.6.4.2 TVR asks for ARQC

As a result of the Terminal Risk Management (TRM) process performed before the firstGENERATE AC command, the terminal may decide to complete a transaction online. The ICCcontains a mandatory data element, the Card TVR Action Code to reflect the Issuer’s selectedaction to be taken on this command. The Card TVR Action Code bit specifies a confirmation tothe ICC for going online if the corresponding bit in the Terminal Verification Results (TVR) (tag‘95’) is set. The easiest way to implement the Card TVR Actions Code is to mirror the format ofthe TVR.

1.3.6.4.3 Card Issuer Action Codes

The easiest way to implement this flexible risk management is the CIACs having the same formatas the CVRs: each CIAC has a bit correspondence to the CVR (when relevant).

When the terminal asks for an ARQC, and if a bit in the Card TVR Action Code and itscorresponding bit in the TVR are both set, the ICC generates an ARQC without any more tests.If the bit in the Card TVR Action Code and its corresponding bit in the TVR are not set, the ICCcontinues the test with the CIAC data.

As a result of the CRM process performed during the first GENERATE AC command, the ICCmay decide whether to decline the transaction, complete the transaction online or offline. For thispurpose, the ICC contains three mandatory data elements, to reflect the Issuer’s selected action tobe taken, based upon the content of the CVR and the Terminal type. These three ICC internaldata elements, called Card Issuer Action Codes (CIACs) are:

Card Issuer Action Code— Decline: it specifies the conditions that cause the decline of atransaction without attempting to go online according to the Issuer.

2 Terminal Type :online only: 11, 21, 14, 24, 34offline with online capability: 12, 22, 15 ,25 ,35offline only: 13, 23, 16, 26, 36Both ‘online only’ and ‘offline with online capability’ are considered as online in this specification

Page 61: MasterCard ICC

Functional Specification of EMV’96 ICC Specification for Payment Systems Transactions1.3 Standard Payment Functions

ICC Application SpecificationNovember 1998

1-35

Card Issuer Action Code— Online: it specifies the conditions that cause a transaction to becompleted online according to the Issuer. This data element should only be used when thetransaction terminal has online capability.

Card Issuer Action Code— Offline: it specifies the bit-settings that cause a decline of atransaction in two situations:

• Transaction performed on an offline terminal• Online transaction without Issuer Authentication present

1.3.6.4.3.1 CVR AND CIAC = 0

If a bit is set in the CIAC but no corresponding bit is set in the CVR, the ICC can continue withits card risk management (for CIAC-Decline) or accept the transaction offline (for CIAC-Onlineand CIAC-Offline).

1.3.6.4.3.2 CVR AND CIAC ≠ 0

The CIAC-bit specifies the action to be taken if the corresponding bit in the CVR is set. This canbe a decline or an attempt to go online.

The easiest way to implement this flexible risk management is the CIACs having the same formatas the CVRs: each CIAC has a bit correspondence to the CVR (when relevant).

The first step is to check the CVR with the CIAC-Decline. If, after CRM, a bit in the CIAC-Decline and its corresponding bit in the CVR are both set, then the transaction is declined and theICC generates an AAC, If the bits do not match, the CVR will be verified against either theCIAC-Online, or the CIAC-Offline, depending on the terminal online/offline capability.

1.3.6.4.4.1 ICC used in an online capable terminal

The CVR is verified against the CIAC-Online. If, after CRM, a bit in the CIAC-Online and itscorresponding bit in the CVR are both set, the transaction is completed online and the ICCgenerates an ARQC. If the bits do not match, the transaction is approved and the ICC generatesa TC.

1.3.6.4.4.2 ICC used in an offline only terminal

The CVR is verified against the CIAC-Offline. If, after CRM, a bit in the CIAC-Offline and itscorresponding bit in the CVR are both set, the transaction is declined and the ICC generates anAAC. If the bits do not match, the transaction is approved and the ICC generates a TC.

Page 62: MasterCard ICC

Functional Specification of EMV’96 ICC Specification for Payment Systems Transactions1.3 Standard Payment Functions

ICC Application Specification © 1998 MasterCard International IncorporatedNovember 19981-36

1.3.6.5 Update ICC Parameters

If the ICC approves the transaction offline (TC) after the CRM, it updates the cumulative offlinetransaction counters:

• The Cumulative Offline Transaction (if the function has been performed)• The CVR bits

– On 1st Generate AC indicate “TC returned in first Generate AC”– On 2nd Generate AC indicate “Second Generate AC not requested”

If the ICC requires an online transaction ARQC, it updates in the Application Flags the status ofthe transaction:

• Last online transaction not completed.

The ICC also updates the CVR bits:• On 1st Generate AC indicate “ARQC returned in first Generate AC”• On 2nd Generate AC indicate “Second Generate AC not requested”

If the ICC declines the transaction (AAC), an analysis of the TVR (tag ‘95’) is performed to setseveral bits in the Application Flag:

• The “Offline Static data authentication failed on last transaction” is set if the TVR indicatethat Offline Static Data Authentication has failed.

• The “Offline Dynamic data authentication failed on last transaction” is set if the TVRindicate that Offline Dynamic Data Authentication has failed.

The ICC also updates the CVR bits:• On 1st Generate AC indicate “AAC returned in first Generate AC”• On 2nd Generate AC indicate “Second Generate AC not requested”

1.3.6.5.1 Transaction completion/Online processing

The Application Cryptogram (tag ‘9F26’) is computed, the CID (tag ‘9F27’) is filled according tothe cryptogram type and the CRM results and a response message is returned to the terminal.

Online processing is performed as described in the EMV”96 ICC Specification for PaymentSystems and in the EMV”96 ICC Terminal Specification for Payment Systems.

Page 63: MasterCard ICC

Functional Specification of EMV’96 ICC Specification for Payment Systems Transactions1.3 Standard Payment Functions

ICC Application SpecificationNovember 1998

1-37

1.3.7 Issuer Authentication

It is indicated in the ICC’s Application Interchange Profile (AIP: tag ‘82’) whether the terminalshould issue the External Authenticate command or not. If the corresponding bit is set in the AIP,the terminal transmits an EXTERNAL AUTHENTICATE command to the ICC. If the bit is notset in the AIP, the Issuer Authentication Data may be requested by the ICC in the CDOL2.

1.3.7.1 Issuer Authentication Data definition

The Issuer Authentication Data (tag ‘91’) consist of a cryptogram, generated by the Issuer or theIssuer agent, and the Issuer Authentication Response Code (IARC). The cryptogram can beverified by the ICC, as verification that the terminal went online.

1.3.7.2 Issuer Authentication Response Code definition

The Issuer Authentication Response Code is the response of the Issuer or Issuer agent, indicatingwhether the transaction is approved or declined. Since it is signed in the cryptogram, the ICC canbe sure that it is effectively the answer of the Issuer.

1.3.7.3 ARQC generated?

When receiving the Issuer Authentication, the ICC always checks if it returned an ARQC inresponse to the first GENERATE AC command. If not, the ICC will abort the transaction andwill respond with an error.

1.3.7.4 Issuer Authentication

The Issuer Authentication mechanism is described in Section 2. The ICC sets “IssuerAuthentication performed” in Sequence flag.

1.3.7.5 Update Internal Indicator “Issuer Authentication Successful”

The ICC sets “Issuer Authentication successful” in the Sequence Flag because the IssuerAuthentication is successful. The last two bytes of the Issuer Authentication Data indicate theIssuer Authentication Response Code. If these bytes are equal to ‘00’, ‘01’ or ‘08’, the Issuerapproves the transaction; else the transaction is declined.

Page 64: MasterCard ICC

Functional Specification of EMV’96 ICC Specification for Payment Systems Transactions1.3 Standard Payment Functions

ICC Application Specification © 1998 MasterCard International IncorporatedNovember 19981-38

1.3.7.6 Update Internal Indicator “Issuer Authentication Failed”

The ICC resets “Issuer Authentication successful” in Sequence Flag because the IssuerAuthentication has failed.

Issuer Authentication is illustrated in Figure 1.9.

FIGURE 1.9: ISSUER AUTHENTICATION OVERALL DIAGRAM

Issuer Authentication

ARQC Generated?

Verification of IssuerAuthentication

Issuer Authenticationsuccessful?

Update Internal IndicatorsIssuer Auth. successful

Update Internal IndicatorsIssuer Auth. failed

Command Rejected

No

No

Yes

Yes

Set Issuer AuthenticationPerformed Flag

Set Issuer AuthorizationPerformed Flag

Page 65: MasterCard ICC

Functional Specification of EMV’96 ICC Specification for Payment Systems Transactions1.3 Standard Payment Functions

ICC Application SpecificationNovember 1998

1-39

1.3.8 Second GENERATE AC Command

Second GENERATE AC is performed as described in the EMV’ 96 ICC Specification forPayment Systems.

When the ICC responds with an ARQC in response to the first GENERATE AC command, theterminal transmits the transaction online (if capable of doing so). After the terminal receives theresponse, it transmits a second GENERATE AC command to the ICC requesting a TC or anAAC

The second Generate AC command is similar to the first Generate AC command, except that thereturned Application Cryptogram (AC) is limited to a TC or an AAC.The data field of the secondGENERATE AC command is not TLV encoded and the format of the data to be included in thecommand data is specified in the CDOL2 (tag ‘8D’).

As a result of the second GENERATE AC command, the ICC response consists of the followingdata objects:

TABLE 1.16: DATA ELEMENTS SENT TO THE TERMINAL

Name Source Tag Length Format

CID (Cryptogram Information Data) ICC ‘9F27’ 1 b

ATC (Application TransactionCounter)

ICC ‘9F36’ 2 b

Application Cryptogram ICC ‘9F26’ 8 b

Issuer Application Data ICC ‘9F10’ 8-321 b

1.3.8.1 Cryptogram Information data

For the purpose of this document, online advice can be required (bit b4 = 1 in CID) in case thePIN is blocked (reason: PIN Try Limit exceeded) but not in case the Issuer Authentication hasfailed.3 The “Issuer Authentication Failed” bit of the CID is reset when the ICC performs asuccessful Issuer Authentication. If Issuer Authentication is not performed or failed, the “IssuerAuthentication Failed” bit of the CID is set. In case both errors occur (PIN Try Limit exceededand Issuer Authentication Failed), only PIN Try Limit exceeded is reported in CID.

3 Advice messages will not be supported across MasterCard networks but may be supported under other circumstances.

Page 66: MasterCard ICC

Functional Specification of EMV’96 ICC Specification for Payment Systems Transactions1.3 Standard Payment Functions

ICC Application Specification © 1998 MasterCard International IncorporatedNovember 19981-40

1.3.8.2 Card Risk Management Data CDOL2

The CDOL2 is the EMV data required for the second GENERATE AC command. CDOL2 isdefined in Section 3.

The Issuer Authentication Data object (tag ‘91’) is present if the Issuer Authentication isperformed during the second Generate AC; if not, this data object is absent in CDOL2.

The Authorization Response Code (tag ‘8A’) data object is always present in CDOL2. TheTerminal Verification Results data object (tag ‘95’) is always present in the CDOL2 because thecontents have been updated between first and second Generate AC. For the other data objects inCDOL2 as referenced in Section 3, the ICC could use the data elements previously received in theCDOL1; therefore, they might not be requested in the CDOL2.

+ It is recommended to list in the CDOL2 only those data elements (TVR,Authorization Response Code...) that have changed between the first and thesecond GENERATE AC. It prevents the terminal from changing data (Amount,Transaction Currency Code...) that should not have been modified between thefirst and second GENERATE AC.

Page 67: MasterCard ICC

Functional Specification of EMV’96 ICC Specification for Payment Systems Transactions1.3 Standard Payment Functions

ICC Application SpecificationNovember 1998

1-41

1.3.8.3 Internal Process (Issuer Authentication Data performed during ExternalAuthenticate)

Figure 1.10 describes the functions performed by the ICC as a result of the second GENERATEAC command.

FIGURE 1.10: SECOND GENERATE AC OVERALL DIAGRAM

Second Generate AC

TC or AAC asked?

Card returned ARQC?

Update CVR

Issuer Authentication?

Authorization Response codeY3 or Z3?

Update CVR bit:Unable to go online

Update CVR bit:Issuer Authentication

not performed

Update CVR bit:Issuer Auth.

failed

Card Action Analysis

Set AAC for 2ndGenerate AC in CVR

Set TC for 2ndGenerate AC in CVR

Update ICC Parameters

Calculation of AVTransaction completion

Transaction rejected

Issuer AuthenticationVerification

Issuer Authenticationsuccessful?

No

NoYes

Yes

Yes

No

No

Yes

No

Yes

TCAAC

Page 68: MasterCard ICC

Functional Specification of EMV’96 ICC Specification for Payment Systems Transactions1.3 Standard Payment Functions

ICC Application Specification © 1998 MasterCard International IncorporatedNovember 19981-42

1.3.8.3.1 TC or AAC asked?

The second GENERATE AC must be for an AAC or a TC; otherwise the command is rejected.

1.3.8.3.2 Card returned ARQC?

The ICC checks if it returned an ARQC in response to the first GENERATE AC command. Ifnot, the ICC will abort the transaction and respond with an error.

1.3.8.3.3 Update CVR

The CVR bits are updated accordingly:• If the internal flag “Script Failed” is set, update CVR bit “Issuer script processing failed on

last or current transaction.”• The CVR bit “PIN Try Limit exceeded” is updated according to the value of the PIN Try

Counter at the beginning of the 2nd Generate AC processing. If the PIN Try Counter equals 0,the CVR bit is set; if not the CVR bit is reset.

• The CVR bit “Offline PIN Verification was performed” is set if a VERIFY command isreceived during the transaction.

• The CVR bit “Offline PIN Verification failed” is updated according to the last VERIFYcommand result. It is set if the PIN verification failed; it is reset if the VERIFY command wassuccessful.

+ The last two bullets represent an exceptional case; normally a VERIFYcommand is not received between a 1st and 2nd Generate AC.

1.3.8.3.4 Issuer Authentication

The meaning of this test depends if Issuer authentication is performed during or before the secondGenerate AC. If the Issuer Authentication is performed before the second Generate AC (by anExternal Authentication), the test means: Issuer Authentication already performed? (an ExternalAuthentication has been performed). If the Issuer Authentication is performed during the secondGenerate AC, the test means: Issuer Authentication data present? (Issuer Authentication datanot totally filled with hexadecimal zeroes bytes).

1.3.8.3.5 Issuer Authentication verification

The meaning of this test depends if Issuer authentication is performed during or before the secondGenerate AC. If the Issuer Authentication is performed before the second Generate AC (by anExternal Authentication), this box is empty.

Page 69: MasterCard ICC

Functional Specification of EMV’96 ICC Specification for Payment Systems Transactions1.3 Standard Payment Functions

ICC Application SpecificationNovember 1998

1-43

When Issuer Authentication data (tag ‘91’) is present in the 2nd GENERATE AC command data(non- hexadecimal zeroes bytes), the Issuer Authentication is performed according to IssuerAuthentication mechanism described in section 2.

1.3.8.3.6 Issuer Authentication successful?

If the Issuer Authentication is unsuccessful (performed during the 2nd Generate AC or previouslyin an External Authentication) the ICC sets the CVR bit “Issuer Authentication Failed.”

1.3.8.3.7 Authorization Response Code “Y3” or “Z3”?

The Authorization Response Code (tag ‘8A’) can be filled by the Issuer (or the Issuer agent) orby the Terminal. If the terminal was incapable of going online, the following options exist:

TABLE 1.17: AUTHORIZATION RESPONSE CODE - UNABLE TO GO ONLINE

Code Meaning

‘Y3’ Unable to go online – Offline Approved

‘Z3’ Unable to go online – Offline Declined

If the Authorization Response Code is filled with the values ‘Y3’ or ‘Z3’, the ICC sets the CVRbit “Unable to go online” to indicate that the terminal failed going online.

If the Authorization Response Code is different from ‘Y3’ and ‘Z3’, the ICC sets the CVR bit“Issuer Authentication not performed after online authorization” to indicate that the terminal hascompleted the online authorization but Issuer Authentication Data was not provided.

1.3.8.3.8 Card Action Analysis

This section describes the MasterCard/Europay recommended Card Action Analysis risk functionsperformed during the second Generate AC. The ICC may decide to:

• Decline a transaction• To complete a transaction offline.

Page 70: MasterCard ICC

Functional Specification of EMV’96 ICC Specification for Payment Systems Transactions1.3 Standard Payment Functions

ICC Application Specification © 1998 MasterCard International IncorporatedNovember 19981-44

The ‘Card Action Analysis’ function is illustrated in Figure 1.11.

FIGURE 1.11: CARD ACTION ANALYSIS OF THE SECOND GENERATE AC

Card Action Analysis

Issuer Authperformed?

TC Requested?

CVR ANDCIAC Offline

=0?

CVR ANDCIAC Decline

=0?

ICC returns a TC ICC returns an AAC ICC returns a TC

Issuer and TerminalRequest TC?

Issuer authenticationsuccessful?

Reset bits in CVR

.

Yes

Yes

Yes

Yes

No

No

No

No

No

No

Yes

1.3.8.3.8.1 TC Requested?

The TC is requested by the Reference Control Parameter P1 with the code of ‘TC’.

If the terminal requests an AAC, the ICC returns an AAC.

1.3.8.4.8.2 CVR AND CIAC Decline =0?

If the terminal asks for a TC (without providing online Issuer Authentication Data), the ICC usesthe updated CVR and compares it with the CIAC Decline. If a bit in the CIAC Decline and itscorresponding bit in the CVR are both set, the transaction is declined and the ICC generates anAAC. If the bits do not match, the test with CIAC Offline will be performed.

Page 71: MasterCard ICC

Functional Specification of EMV’96 ICC Specification for Payment Systems Transactions1.3 Standard Payment Functions

ICC Application SpecificationNovember 1998

1-45

1.3.8.3.8.3 CVR AND CIAC Offline =0?

If the terminal asks for a TC (without providing online Issuer Authentication Data), the ICC usesthe updated CVR and compares it with CIAC Offline. If a bit in CIAC offline and itscorresponding bit in the CVR are both set, the transaction is declined and the ICC generates anAAC. If the bits do not match, the transaction is approved and the ICC generates a TC.

1.3.8.3.8.4 Issuer and Terminal Request a TC?

The last two bytes of the Issuer Authentication Data (tag ‘91’) indicate the response codereturned by the Issuer or its agent. If these bytes are equal to ‘00’, ’01’ or ‘08’, the transaction isapproved, otherwise the transaction is declined. The Terminal requests a TC or an AAC with thevalue of the Reference Control Parameter (P1 parameter) of the second GENERATE ACcommand. The ICC returns a TC if both the Issuer and the Terminal require a TC; otherwise, theICC returns an AAC. The ICC disregards the Authorization Response Code (tag ‘8A’).

1.3.8.3.8.5 Reset bits in CVR

• The CVR “Last online transaction not completed” bit is reset• The CVR “Issuer Authentication failure on last online transaction” bit is reset• The CVR “Offline Static data authentication failed on last transaction” bit is reset• The CVR “Offline Dynamic data authentication failed on last transaction” bit is reset• The CVR “New Card” is reset• The CVR “Issuer script processing failed on last or current transaction” bit is reset if no

critical script has been performed during the current transaction or all critical scripts have beenperformed successfully during the current transaction

• If no critical script has been performed during the current transactionthe Script Counter bits are reset

1.3.8.3.9 Set TC for 2nd Generate AC

Several CVR bits are updated:

• The CVR bits on the 2nd Generate AC indicate “TC is returned in second Generate AC”

1.3.8.3.10 Set AAC for 2nd Generate AC

Several CVR bits are updated:

• The CVR bits on the 2nd Generate AC indicate “AAC is returned in second Generate AC”

Page 72: MasterCard ICC

Functional Specification of EMV’96 ICC Specification for Payment Systems Transactions1.3 Standard Payment Functions

ICC Application Specification © 1998 MasterCard International IncorporatedNovember 19981-46

1.3.8.3.11 Update ICC parameters

The ICC updates internal indicators, Application Flag, Script Counter and LATC accordingly:

• Reset the Application Flag “Last online transaction not completed”• If the Issuer Authentication has failed, the Application Flag “Issuer Authentication failure on

last online transaction” is set• If the Issuer Authentication is successful, several flags are reset in Application Flag:

− “Issuer Authentication failure on last online transaction”− “Offline Static data authentication failed on last transaction”− “Offline Dynamic data authentication failed on last transaction”

• If the Issuer Authentication is successful and no critical script processing (no ‘71’ received)has been performed during the current transaction:− The Script Counter is reset− The Script Status Flag is reset

• If the Issuer Authentication is successful and a TC is returned, the following data objects areupdated:− The LATC is updated with the ATC value− The Offline Cumulative Amount is reset

• If the Issuer Authentication is not performed, a TC is returned for an Authorization ResponseCode different from ‘Y3’ and the resetting of parameters is allowed by the RIP, the followingdata objects are updated:• The LATC is updated with the ATC value• The Offline Cumulative Amount is reset

+ The Reset Internal Parameters (RIP) is an internal flag stored in the ICC, andfilled by the Issuer which allows or not the reset of the card Risk Managementparameters even if no Issuer Authentication is performed.

1.3.8.3.12 Transaction completion

The Application Cryptogram is computed according to Section 2. The CID (tag ‘9F27’) bits areset according to the cryptogram type and the CRM results and a response message is returned tothe terminal.

Page 73: MasterCard ICC

Functional Specification of EMV’96 ICC Specification for Payment Systems Transactions1.4 Standard Post-Issuance Functions

ICC Application SpecificationNovember 1998

1-47

1.4 STANDARD POST-ISSUANCE FUNCTIONS

Issuer Script processing is performed as described in the EMV’ 96 ICC Specification for PaymentSystems.

1.4.1 Script Processing Overview

Script Processing provides the Issuer with the capability to send Script Commands to the ICC,following an online connection and within a Payment Transaction. Either the critical ScriptProcessing (tag ‘71’) performed between the first and the second Generate AC or the non criticalScript Processing (tag ‘72’) performed after the second Generate AC can be supported.

The following functions may be performed using Issuer Script processing:

• Card Blocking• Application Blocking• Application Unblocking• Updating Card Data• PIN Change/Unblock

Issuer Script processing may be performed at any time after the first GENERATE AC command.Issuers may transmit one Issuer Script containing multiple script commands.

+ It is the terminal’s responsibility to parse out the script commands and deliverthem to the ICC individually.

For the script processing, two functions are managed in the ICC:

• A counter which counts the script processing commands successfully performed• A status of script processing

Secure messaging is used for all script commands sent. A complete description of the securemessaging mechanism is provided in Section 2.

Page 74: MasterCard ICC

Functional Specification of EMV’96 ICC Specification for Payment Systems Transactions1.4 Standard Post-Issuance Functions

ICC Application Specification © 1998 MasterCard International IncorporatedNovember 19981-48

If ICC processing of an Issuer Script command fails, the ICC performs:

• Terminate processing of the script processing; all following script commands in the currenttransaction will be rejected.

ICC Script processing fails if one of the following conditions occurred:

• Secure messaging failed• Secure messaging not present• Processing of a command failed

1.4.1.1 Script Processing Counter

The ICC manages a Script Counter; this Script Counter is incremented after each scriptprocessing command is successfully completed. It is reset during the second Generate AC after asuccessful Issuer Authentication if no critical script has been performed during the currenttransaction.

1.4.1.2 Script Processing Status

The ICC manages two kinds of Script Processing Status. A Script processing status stored inSequence flag to indicate the script status during the current transaction and a script status inApplication Flag to keep the script processing status for the next transaction.

In Sequence Flag, two flags manage the script status:

• “Script Performed”: a script command has been received during the current transaction• “Script Failed”: a script command has failed during the current transaction

In Application Flag the script status indicates one of two conditions:

• “Script processing pending”: a command of script processing has been received by the ICC;every script processing command updates script processing status to the value “scriptprocessing pending” at the beginning of the command.

• “Script processing not pending”: this status indicates that the script processing is not pending ;the behavior of script processing status depends on whether the END OF SCRIPT commandis supported or not.

Page 75: MasterCard ICC

Functional Specification of EMV’96 ICC Specification for Payment Systems Transactions1.4 Standard Post-Issuance Functions

ICC Application SpecificationNovember 1998

1-49

*The END OF SCRIPT command is supported

The script processing is concluded by a specific command (END OF SCRIPT), indicating thatall previous commands have been delivered; The ICC updates the Script Processing Statusto “Script processing not pending” at end of the command when the command issuccessfully performed.

*The END OF SCRIPT is not supported:

The ICC updates the Script Processing Status to “Script processing not pending” at end ofeach script processing command when the command is successfully performed.

The support of END OF SCRIPT command could be set at personalization step.

If a script processing command has failed (with an error code according to EMV specifications),all next script processing commands during the current transaction are rejected. The ScriptProcessing Status is reported to the Issuer during the current and next transactions (see first andSecond Generate AC section).

Page 76: MasterCard ICC

Functional Specification of EMV’96 ICC Specification for Payment Systems Transactions1.4 Standard Post-Issuance Functions

ICC Application Specification © 1998 MasterCard International IncorporatedNovember 19981-50

1.4.1.3 Script Processing Overall Diagram

For each script command received by the ICC, the internal ICC processing is as indicated inFigure 1.12.

FIGURE1.12: SCRIPT PROCESSING OVERALL DIAGRAM

Script Processing

ARQC Generated ?

Previous scriptcommand failed ?

Set "Script Performed"

Update Script Processing Status to:"Script Processing pending"

Verify Secure Messagingon the Script Command

SM Correct ?

Perform the ScriptCommand

Update Script Processing Counteroptionally Update Script Processing Status:

"Script processing n ot pending"

Normal End Command Rejected

No

Yes

Yes

No

No

Yes

Page 77: MasterCard ICC

Functional Specification of EMV’96 ICC Specification for Payment Systems Transactions1.4 Standard Post-Issuance Functions

ICC Application SpecificationNovember 1998

1-51

1.4.1.3.1 ARQC generated?

The ICC rejects the command if an ARQC was not generated.

1.4.1.3.2 Previous script command failed?

The ICC rejects the new command if the previous script processing command has failed duringthe current transaction (“Script failed” flag set in Sequence flag, see Table 1.4).

1.4.1.3.3 Set “script performed”

The ICC set “Script Performed” flag in Sequence flag.

1.4.1.3.4 Update script processing status to “script processing pending”

The ICC updates its internal script processing status to “pending” to indicate that scriptprocessing has started (in Application Flag see Table 1.5).

1.4.1.3.5 Verify secure messaging

The ICC verifies the Secure Messaging Cryptogram of that command using the Script session key(a complete description of the script session key generation and the verification of securemessaging is provided in Section 2).

1.4.1.3.6 SM correct ?

The ICC compares the result of its calculation with the Secure Messaging Cryptogram.

1.4.1.3.7 Perform the script command

The ICC performs the command.

1.4.1.3.8 Update script processing counter (optionally update script processing status)

The ICC increments its Script Processing Counter when the command is successfully performed.Optionally, if the END OF SCRIPT command is not supported in script processing ScriptProcessing Status is updated to “Script processing not pending”.

1.4.1.3.9 Command rejected

The ICC updates the “Script Failed” flag in Sequence Flag if the script command failed.

Page 78: MasterCard ICC

Functional Specification of EMV’96 ICC Specification for Payment Systems Transactions1.4 Standard Post-Issuance Functions

ICC Application Specification © 1998 MasterCard International IncorporatedNovember 19981-52

1.4.2 Card Blocking

Card blocking may be performed if the issuer determines that any future use of the ICC is to beprevented. Card blocking is usually performed only if the card has been reported as lost or stolen,since none of the applications in the ICC can be used after card blocking. The Issuer may blockthe card by using the EMV CARD BLOCK command in the Issuer script.

If during the processing of a transaction, the card is blocked, the ICC and terminal must continueto process the transaction through to completion. A blocked card can not be unblocked using anIssuer Script Command or any other command; therefore, the ICC is disabled. Therefore, theblocked ICC responds to a SELECT command or any other command, with status bytesindicating “Function not supported” (SW1 SW2 = ‘6A81’) and performs no further actions.

+ Some Issuer proprietary commands may still be supported to retrieve the CardLife Cycle Data.

Page 79: MasterCard ICC

Functional Specification of EMV’96 ICC Specification for Payment Systems Transactions1.4 Standard Post-Issuance Functions

ICC Application SpecificationNovember 1998

1-53

FIGURE 1.13: SCRIPT PROCESSING TO BLOCK THE CARD

Card Block

ARQC Generated ?

Previous scriptcommand failed ?

Set "Script Performed"

Update Script Processing Status to:"Script Processing pending"

SM Correct ?

Block the Card

Update Script Processing Counter Update Script Processing Status:"Script processing not pending"

Normal End Command Rejected

No

Yes

Yes

No

No

Yes

Page 80: MasterCard ICC

Functional Specification of EMV’96 ICC Specification for Payment Systems Transactions1.4 Standard Post-Issuance Functions

ICC Application Specification © 1998 MasterCard International IncorporatedNovember 19981-54

1.4.3 Application Blocking

Application blocking may be performed if the issuer determines that the application in use is to beinactivated. The blocked application may subsequently be re-activated by the issuer with anothercommand.

If during the processing of a transaction, the application is blocked, the ICC and the terminalcontinue to process the transaction through to completion. During any subsequent applicationselection, the ICC does not allow the inactivated application(s) to perform a financial transaction.

+ It is possible for a dedicated terminal to select an application that was previouslyinactivated to unblock the application. If this occurs, the ICC is required toreturn an AAC in response to a GENERATE AC command.

If Issuer Script processing is used to block an application, the APPLICATION BLOCK commandis used.

Page 81: MasterCard ICC

Functional Specification of EMV’96 ICC Specification for Payment Systems Transactions1.4 Standard Post-Issuance Functions

ICC Application SpecificationNovember 1998

1-55

FIGURE 1.14: SCRIPT PROCESSING TO BLOCK THE SELECTED APPLICATION

Application Block

ARQC Generated ?

Previous scriptcommand failed ?

Set "Script Performed"

Update Script Processing Status to:"Script Processing pending"

SM Correct ?

Block the application

Update Script Processing Counter Update Script Processing Status:"Script processing not pending"

Normal End Command Rejected

No

Yes

Yes

No

No

Yes

Page 82: MasterCard ICC

Functional Specification of EMV’96 ICC Specification for Payment Systems Transactions1.4 Standard Post-Issuance Functions

ICC Application Specification © 1998 MasterCard International IncorporatedNovember 19981-56

1.4.4 Application Unblocking

Application unblocking is performed only at dedicated terminals controlled by the issuer. IssuerScript processing may be used to perform this function.

If Issuer Script processing is used to unblock an application, the APPLICATION UNBLOCKcommand is used.

If the application is blocked a dedicated terminal for unblocking applications will use the AACobtained from the ICC as random number for the Secure Messaging (see Section). IssuerAuthentication by means of secure messaging is sufficient; (therefore the EXTERNALAUTHENTICATE command is not needed as an additional Issuer Authentication).

+ The Application Unblock may be processed before the second Generate AC, orthe second Generate AC may be omitted.

1.4.4.1.1 Verify Secure Messaging

Secure Messaging is used to send the command to the ICC, meaning that the command isprotected for Integrity. A Script Session Key (see Section 2) is derived based on the AAC(obtained in the response to the 1st Generate AC).

Using the Script Session Key, the ICC verifies the Secure Messaging Cryptogram of theAPPLICATION UNBLOCK command.

1.4.4.1.2 Unblock the selected ADF

The ICC re-activates the currently selected blocked application.

Page 83: MasterCard ICC

Functional Specification of EMV’96 ICC Specification for Payment Systems Transactions1.4 Standard Post-Issuance Functions

ICC Application SpecificationNovember 1998

1-57

FIGURE 1.15: SCRIPT PROCESSING TO UNBLOCK THE APPLICATION

Application Unblock

ARQC Generated ?

Previous scriptcommand failed ?

Set "Script Performed"

Update Script Processing Status to:"Script Processing pending"

SM Correct ?

Unblock the application

Update Script Processing Counter Update Script Processing Status:"Script processing not pending"

Normal End Command Rejected

No

Yes

Yes

No

No

Yes

Page 84: MasterCard ICC

Functional Specification of EMV’96 ICC Specification for Payment Systems Transactions1.4 Standard Post-Issuance Functions

ICC Application Specification © 1998 MasterCard International IncorporatedNovember 19981-58

1.4.5 Updating Card Data

The Update Card Data function provides the Issuer with the ability to update ICC data afterissuance of the ICC.

Updating ICC data is normally limited to updating the card risk parameters. This function isperformed using Secure Messaging for Integrity. Either the PUT DATA command or theUPDATE RECORD command is used.

The following data elements may be updated using Issuer Script processing:

• Upper Consecutive Offline Limit (tag ‘9F23’)• Lower Consecutive Offline Limit (tag ‘9F14’)• Maximum Domestic Offline Transaction Amount• Upper Cumulative Domestic Offline Transaction Amount• Lower Cumulative Domestic Offline Transaction Amount• Non-Domestic Control Factor• Card Issuer Action Codes• Card TVR Action Code• Reference Currency Conversion Table

1.4.5.1 Update the data

If the access conditions are satisfied, the ICC replaces the data, using the data provided in theupdate data command.

Page 85: MasterCard ICC

Functional Specification of EMV’96 ICC Specification for Payment Systems Transactions1.4 Standard Post-Issuance Functions

ICC Application SpecificationNovember 1998

1-59

FIGURE 1.16: SCRIPT PROCESSING TO UPDATE DATA

Update Data

ARQC Generated ?

Previous scriptcommand failed ?

Set "Script Performed"

Update Script Processing Status to:"Script Processing pending"

Verify Secure Messagingon the Script Command

SM Correct ?

Update Data

Update Script Processing CounterOptionally Update Script Processing Status:

"Script processing not pending"

Normal End Command Rejected

No

Yes

Yes

No

No

Yes

Page 86: MasterCard ICC

Functional Specification of EMV’96 ICC Specification for Payment Systems Transactions1.4 Standard Post-Issuance Functions

ICC Application Specification © 1998 MasterCard International IncorporatedNovember 19981-60

1.4.6 PIN Change/Unblock

Issuer Script Processing is used to perform this function. If issuer Script Processing is used tochange or unblock a PIN, the PIN CHANGE/UNBLOCK command is used.

+ A standard terminal can use the ARQC returned by the first GENERATE ACas random number for the Secure Messaging; a dedicated terminal can use boththe AAC or the ARQC by the first GENERATE AC as random number.

This function is performed using Secure Messaging for Confidentiality and Integrity when theChange option is used. Secure Messaging for Integrity is used when the Unblock option is used.If Secure Messaging is successful, the PIN CHANGE/UNBLOCK command is performed.

+ The PIN changing/unblocking may be processed before the second GENERATEAC, or the second GENERATE AC may be omitted (2nd Generate AC can beomitted if AAC was generated in 1st Generate AC).

The key management and cryptographic security architecture to be used is provided in Section 2.

+ Whenever the PIN change is evoked, then Issuers must ensure that no PVV isincluded on the magnetic stripe data and in the Track 2 equivalent data field inthe chip. Only the Application Reference PIN in the chip can be updated by thiscommand.

1.4.6.1 Unblock or Change

The same command can contain either a PIN change and unblock request or only a PIN unblockrequest without any PIN change. The ICC checks, which option is to be performed.

1.4.6.2 Decipher PIN

The new PIN value is sent in enciphered format conforming to Secure Messaging forConfidentiality. The ICC using the Script Session Key deciphers the new PIN value.

1.4.6.3 Update PIN value

The new PIN value is overwritten, replacing the old PIN value (PIN length may vary from 4 to 12numeric digits).

Page 87: MasterCard ICC

Functional Specification of EMV’96 ICC Specification for Payment Systems Transactions1.4 Standard Post-Issuance Functions

ICC Application SpecificationNovember 1998

1-61

1.4.6.4 Update PTC to PTL

The ICC copies the value of the PIN Try Limit into the PIN Try Counter.

FIGURE 1.17: SCRIPT PROCESSING TO PIN CHANGE/UNBLOCK DURING A PAYMENT TRANSACTION

PIN Change/Unblock

AAC orARQC Generated ?

Previous scriptcommand failed ?

Set "Script Performed"

Update Script Processing Status to:"Script Processing pending"

Verify Secure Messagingon the Script Command

SM Correct ?

PTC=PTL

Increment Script Processing CounterOptionally update Script Processing Status

Normal End Command Rejected

No

Yes

Yes

No

No

Yes

Unblock orChange

UnblockDecipher PIN

Update PIN value

Page 88: MasterCard ICC

Functional Specification of EMV’96 ICC Specification for Payment Systems Transactions1.4 Standard Post-Issuance Functions

ICC Application Specification © 1998 MasterCard International IncorporatedNovember 19981-62

1.4.7 End Of Script

The END OF SCRIPT command terminates a script. This function is performed using SecureMessaging for Integrity. It updates the Script Processing Status to “Script processing notpending.”

FIGURE 1.18: END OF SCRIPT PROCESSING

End Of Script

ARQC Generated ?

Previous scriptcommand failed ?

Set "Script Performed"

Update Script Processing Status to:"Script Processing pending"

Verify Secure Messagingon the Script Command

SM Correct ?

Update Script Processing CounterUpdate Script Processing Status"Script processing not pending"

Normal End Command Rejected

No

Yes

Yes

No

No

Yes

Page 89: MasterCard ICC

Table of Contents

ICC Application SpecificationNovember 1998

2-i

SECTION 2 SECURITY SPECIFICATION OF EMV ‘96, VERSION 3.1.1ICC SPECIFICATION FOR PAYMENT SYSTEMSTRANSACTIONS

2.0 Overview ............................................................................2-12.1 Static Data Authentication...................................................2-2

2.1.1 Keys and Certificates ..................................................2-22.1.2 Retrieval of the Certification Authority

Public Key.........................................................................2-72.1.3 Retrieval of the Issuer Public Key ...............................2-82.1.4 Verification of the Signed Static

Application Data .............................................................2-102.2 Dynamic Data Authentication............................................2-12

2.2.1 Keys and Certificates ................................................2-122.2.2 Retrieval of the Certification Authority

Public Key.......................................................................2-162.2.3 Retrieval of the Issuer Public Key .............................2-162.2.4 Retrieval of the ICC Public Key................................2-182.2.5 Dynamic Signature Generation .................................2-202.2.6 Dynamic Signature Verification ................................2-22

2.3 PIN Encipherment.............................................................2-242.3.1 Keys and Certificates ................................................2-242.3.2 PIN Encipherment and Verification...........................2-27

2.4 Application Cryptograms ..................................................2-292.4.1 Initial Selection of Data ............................................2-292.4.2 TC, AAC, and ARQC Algorithm..............................2-31

2.5 Issuer Authentication ........................................................2-332.6 Secure Messaging .............................................................2-35

2.6.1 Secure Messaging for Integrity .................................2-352.6.2 Secure Messaging for Confidentiality........................2-382.6.3 Combined Integrity and Confidentiality.....................2-39

2.7 ICC Key Derivation ..........................................................2-402.7.1 ICC Master Key Derivation ......................................2-402.7.2 ICC Session Key Derivation .....................................2-42

2.8 Random Number for Session Key Derivation.....................2-432.9 Data Authentication Code Generation ...............................2-442.10 ICC Dynamic Number Generation...................................2-45

Page 90: MasterCard ICC
Page 91: MasterCard ICC

Security Specification of EMV’96 ICC Specification for Payment SystemsTransactions

2.0 Overview

ICC Application SpecificationNovember 1998

2-1

2.0 OVERVIEW

This section contains a detailed specification of the ICC application security:

• Static Data Authentication• Dynamic Data Authentication• PIN Encipherment• Application Cryptogram generation• Issuer Authentication• Secure Messaging

Then the following concepts are described:

• Issuer derivation of the unique DES3ICC Master Keys for Application CryptogramGeneration and Secure Messaging

• Issuer derivation of the Data Authentication Codes• ICC and Issuer derivation of the ICC Dynamic Numbers

The specification for the security mechanisms and cryptographic algorithms used, are specified inAppendix B.

This document does not cover the security aspects of ICC production, initialization andpersonalization, and the overall key management.

Page 92: MasterCard ICC

Security Specification of EMV’96 ICC Specification for Payment SystemsTransactions

2.1 Static Data Authentication

ICC Application Specification © 1998 MasterCard International IncorporatedNovember 19982-2

2.1 STATIC DATA AUTHENTICATION

2.1.1 Keys and Certificates

To support Static Data Authentication, an ICC contains the Signed Static Application Data,which is signed with the Issuer Private Key. The Issuer Public Key is stored on the ICC as anIssuer Public Key Certificate.

FIGURE 2.1: TWO LAYER PUBLIC KEY CERTIFICATION SCHEME

Issuer Certification Authority Acquirer

Private Key(Issuer)

SI

Public Key(Issuer)

PI

Public Key(CA)PCA

Private Key(CA)SCA

PI certifiedwith SCA

IC Card

Distributed to Acquirer(resides in Terminal)

IC CardCommunication between IC Card and Terminal

Card provides to terminal:- PI certified by Certification Authority- Card data signed by the Issuer with SI

Terminal:- Uses PCA to verify that the Issuer's PI was certified by the CA and to retrieve PI- Uses PI to verify the digital signature of the card data

Page 93: MasterCard ICC

Security Specification of EMV’96 ICC Specification for Payment SystemsTransactions

2.1 Static Data Authentication

ICC Application SpecificationNovember 1998

2-3

A two layer public key certification scheme as depicted in Figure 2.1 is used. Each Issuer PublicKey is signed, with the Certification Authority (CA) Private Key, to obtain the Issuer Public KeyCertificate. To perform Static Data Authentication, the terminal first verifies the Issuer PublicKey Certificate with the CA Public Key to retrieve and authenticate the Issuer Public Key. Thenthe Issuer Public Key is used to verify the Signed Static Application Data stored in the ICC.

The signature scheme specified in Appendix B is applied to the data specified in Table 2.1 usingthe Certification Authority Private Key ‘SCA‘ to obtain the Issuer Public Key Certificate. Thepublic key pair of the CA has a public key modulus of NCA bytes.

The signature scheme specified in Appendix B is applied to the data specified in Table 2.2 usingthe Issuer Private Key ‘SI‘ to obtain the Signed Static Application Data. The public key pair ofthe Issuer has an Issuer Public Key Modulus of NI bytes. If NI > (NCA − 36), the Issuer PublicKey Modulus is split into two parts:

• One part consisting of the NCA − 36 most significant bytes of the modulus (the Leftmost Digitsof the Issuer Public Key).

• A second part consisting of the remaining NI − (NCA − 36) least significant bytes of themodulus (the Issuer Public Key Remainder).

All the information necessary for Static Data Authentication is specified in Table 2.5 and stored inthe ICC. With the exception of the RID, which is obtained from the AID, this data is retrievedwith the READ RECORD command. If any of this data is missing, Static Data Authenticationfails.

For length specifications of CA and Issuer Public Key Modules and the values of CA and IssuerPublic Key Exponents, see respectively Table C.1 and Table C.2 in appendix C.

Page 94: MasterCard ICC

Security Specification of EMV’96 ICC Specification for Payment SystemsTransactions

2.1 Static Data Authentication

ICC Application Specification © 1998 MasterCard International IncorporatedNovember 19982-4

TABLE 2.1: ISSUER PUBLIC KEY DATA TO BE SIGNED BY THE CERTIFICATION AUTHORITY

Field Name Length Description Format

Certificate Format 1 Hex. value ‘02’ b

Issuer IdentificationNumber

4 Leftmost 3-8 digits from the Primary Account Number (PAN)(padded to the right with hex. ‘F’s)

cn 8

Certificate ExpirationDate

2 MMYY after which this certificate is invalid n 4

Certificate SerialNumber

3 Binary number unique to this certificate assigned by thecertification authority

b

Hash AlgorithmIndicator

1 Identifies the hash algorithm used to produce the Hash Resultin the digital signature scheme

b

Issuer Public KeyAlgorithm Indicator

1 Identifies the digital signature algorithm to be used with theIssuer Public Key

b

Issuer Public KeyLength

1 Identifies the length of the Issuer Public Key Modulus in bytes b

Issuer Public KeyExponent Length

1 Identifies the length of the Issuer Public Key Exponent inbytes

b

Issuer Public Key orLeftmost Digits ofthe Issuer Public Key

NCA – 36 The NCA – 36 most significant bytes of the Issuer Public Key b

Issuer Public KeyRemainder

0 or NI –NCA + 36

This field is only present if NI > NCA - 36 and consists of theNI – NCA + 36 least significant bytes of the Issuer Public Key

b

Issuer Public KeyExponent

1 or 3 Issuer Public Key Exponent b

Page 95: MasterCard ICC

Security Specification of EMV’96 ICC Specification for Payment SystemsTransactions

2.1 Static Data Authentication

ICC Application SpecificationNovember 1998

2-5

TABLE 2.2: STATIC APPLICATION DATA TO BE SIGNED BY THE ISSUER

Field Name Length Description Format

Signed Data Format 1 Hex. value ‘03’ b

Hash Algorithm Indicator 1 Identifies the hash algorithm used to produce the HashResult in the digital signature scheme

b

Data Authentication Code(DAC)

2 Issuer-assigned code b

Pad Pattern NI − 26 Pad pattern consisting of NI − 26 bytes of value ‘BB’ b

Static Data to beAuthenticated

var. Static data to be authenticated as specified in Table 3 andTable 4

-

Page 96: MasterCard ICC

Security Specification of EMV’96 ICC Specification for Payment SystemsTransactions

2.1 Static Data Authentication

ICC Application Specification © 1998 MasterCard International IncorporatedNovember 19982-6

The Data Authentication Code (DAC) in Table 2.2 is an Issuer assigned value. A method forgenerating a DAC is described in Section 2.

According to EMV’96, the input to the Static Data Authentication process is a concatenation ofthe records defined by the Application File Locator (AFL), followed by a concatenation of thevalue fields of the elements specified in the SDA Tag List (which has tag ‘9F4A’).

The input to the Static Data Authentication process consists of the concatenation of the tags,lengths and values of the data objects specified in Table 2.3 and the value of the data objectspecified in Table 2.4.

TABLE 2.3: STATIC DATA TO BE AUTHENTICATED SPECIFIED BY THE AFL

Value Format Length Tag

Application Effective Date n 6 3 ‘5F25’

Application Expiration Date n 6 3 ‘5F24’

Application Usage Control b 2 ‘9F07’

Application Primary Account Number (PAN) Cnvar. up to 19

var. up to 10 ‘5A’

Application PAN Sequence number n 2 1 ‘5F34’

Issuer Action Code— Default b 5 ‘9F0D’

Issuer Action Code— Denial b 5 ‘9F0E’

Issuer Action Code— Online b 5 ‘9F0F’

+ Only Application Effective Date is optional in Table 2.3.

If AIP or AID is included in the Static Data to be authenticated, they are indicated in the SDATag List.

Page 97: MasterCard ICC

Security Specification of EMV’96 ICC Specification for Payment SystemsTransactions

2.1 Static Data Authentication

ICC Application SpecificationNovember 1998

2-7

TABLE 2.4: STATIC DATA, IF TO BE AUTHENTICATED, INDICATED IN THE SDA TAG LIST

Value Format Length Tag

Application Identifier b 5-16 ‘84’

Application Interchange Profile (AIP) b 2 ‘82’

Table 2.5 describes the data elements needed by the terminal for SDA.

TABLE 2.5: DATA OBJECTS REQUIRED FOR STATIC DATA AUTHENTICATION

Tag Length Value Format

— 5 Registered Application Provider Identifier (RID) (obtained from theAID)

b

‘8F’ 1 Certification Authority Public Key Index b

‘90’ NCA Issuer Public Key Certificate b

‘92’ NI – NCA + 36 Issuer Public Key Remainder, if present b

‘9F32 1 or 3 Issuer Public Key Exponent b

‘93’ NI Signed Static Application Data b

— var. Static data to be authenticated as specified by Table 2.3 and Table 2.4. —

2.1.2 Retrieval of the Certification Authority Public Key

The terminal reads the CA Public Key Index. Using the CA Public Key Index and the RID, theterminal identifies and retrieves the terminal-stored CA Public Key Modulus and Exponent andthe associated key-related information, and the corresponding algorithm to be used.

If the terminal does not have the key stored associated with this CA Public Key Index and RID,Static Data Authentication fails.

Page 98: MasterCard ICC

Security Specification of EMV’96 ICC Specification for Payment SystemsTransactions

2.1 Static Data Authentication

ICC Application Specification © 1998 MasterCard International IncorporatedNovember 19982-8

2.1.3 Retrieval of the Issuer Public Key

1. If the Issuer Public Key Certificate has a length different from the length of the CA Public KeyModulus obtained in the previous section, Static Data Authentication fails.

2. To obtain the recovered data specified in Table 2.6, apply the recovery function specified inAppendix B to the Issuer Public Key Certificate using the CA Public Key in conjunction withthe corresponding algorithm. If the Recovered Data Trailer is not equal to ‘BC’, Static DataAuthentication fails.

TABLE 2.6: FORMAT OF THE DATA RECOVERED FROM THE ISSUER PUBLIC KEY CERTIFICATE

Field Name Length Description Format

Recovered Data Header 1 Hex. Value ‘6A’ b

Certificate Format 1 Hex. Value ‘02’ b

Issuer Identification Number 4 Leftmost 3-8 digits from the PAN (padded to the rightwith hex. ‘F’s)

cn 8

Certificate Expiration Date 2 MMYY after which this certificate is invalid n 4

Certificate Serial Number 3 Binary number unique to this certificate assigned bythe certification authority

b

Hash Algorithm Indicator 1 Identifies the hash algorithm used to produce the HashResult in the digital signature scheme

b

Issuer Public Key AlgorithmIndicator

1 Identifies the digital signature algorithm to be usedwith the Issuer Public Key

b

Issuer Public Key Length 1 Identifies the length of the Issuer Public Key Modulusin bytes

b

Issuer Public Key ExponentLength

1 Identifies the length of the Issuer Public Key Exponentin bytes

b

Issuer Public Key or LeftmostDigits of the Issuer PublicKey

NCA − 36 The NCA – 36 most significant bytes of the IssuerPublic Key

b

Hash Result 20 Hash of the Issuer Public Key and its relatedinformation

b

Recovered Data Trailer 1 Hex. Value ‘BC’ b

3. Check the Recovered Data Header. If it is not ‘6A’, Static Data Authentication fails.

Page 99: MasterCard ICC

Security Specification of EMV’96 ICC Specification for Payment SystemsTransactions

2.1 Static Data Authentication

ICC Application SpecificationNovember 1998

2-9

4. Check the Certificate Format. If it is not ‘02’, Static Data Authentication fails.

5. Concatenate, from left to right, the second data element through the tenth data element inTable 2.6 (‘Certificate Format’ through ‘Issuer Public Key or Leftmost Digits of the IssuerPublic Key’), followed by the Issuer Public Key Remainder and finally the Issuer Public KeyExponent.

6. Apply the indicated hash algorithm (derived from the Hash Algorithm Indicator) to the resultof the concatenation of the previous step to produce the hash result.

7. Compare the calculated hash result from the previous step with the recovered hash result. Ifthey are not the same, Static Data Authentication fails.

8. Verify that the Issuer Identification Number matches the leftmost 3-8 PAN digits (allowing forthe possible padding of the Issuer Identification Number with hexadecimal ‘F’s). If not amatch, Static Data Authentication fails.

9. Verify that the last day of the month specified in the Certificate Expiration Date is equal to orlater than today's date. If the Certificate Expiration Date is earlier than today's date, thecertificate has expired, in which case Static Data Authentication fails.

10. If the Issuer Public Key Algorithm Indicator is not recognized, Static Data Authenticationfails.

11. If all the checks above are correct, concatenate the Leftmost Digits of the Issuer Public Keyand the Issuer Public Key Remainder to obtain the Issuer Public Key Modulus, and continuewith the next steps for the verification of the Signed Static Application Data.

Page 100: MasterCard ICC

Security Specification of EMV’96 ICC Specification for Payment SystemsTransactions

2.1 Static Data Authentication

ICC Application Specification © 1998 MasterCard International IncorporatedNovember 19982-10

2.1.4 Verification of the Signed Static Application Data

1. If the Signed Static Application Data has a length different from the length of the Issuer PublicKey Modulus, Static Data Authentication fails.

2. To obtain the Recovered Data specified in Table 2.7, apply the recovery function specified inAppendix B to the Signed Static Application Data using the Issuer Public Key in conjunctionwith the corresponding algorithm. If the Recovered Data Trailer is not equal to ‘BC’, StaticData Authentication fails.

TABLE 2.7: FORMAT OF THE DATA RECOVERED FROM THE SIGNED STATIC APPLICATION DATA

Field Name Length Description Format

Recovered Data Header 1 Hex. Value ‘6A’ b

Signed Data Format 1 Hex. Value ‘03’ b

Hash AlgorithmIndicator

1 Identifies the hash algorithm used to produce the HashResult in the digital signature scheme

b

Data AuthenticationCode

2 Issuer-assigned code b

Pad Pattern NI – 26 Pad pattern consisting of NI − 26 bytes of value ‘BB’ b

Hash Result 20 Hash of the Static Application Data to be authenticated b

Recovered Data Trailer 1 Hex. Value ‘BC’ b

3. Check the Recovered Data Header. If it is not ‘6A’, Static Data Authentication fails.

4. Check the Signed Data Format. If it is not ‘03’, Static Data Authentication fails.

5. Concatenate, from left to right, the second data element through the fifth data element inTable 2.7 (‘Signed Data Format’ through ‘Pad Pattern’), followed by the Static Data to beAuthenticated as specified in Table 2.7.

6. Apply the indicated hash algorithm (derived from the Hash Algorithm Indicator) to the resultof the concatenation of the previous step to produce the hash result.

7. Compare the calculated hash result from the previous step with the recovered hash result. Ifthey are not the same, Static Data Authentication fails.

8. If all of the above steps were executed successfully, Static Data Authentication passes.

Page 101: MasterCard ICC

Security Specification of EMV’96 ICC Specification for Payment SystemsTransactions

2.1 Static Data Authentication

ICC Application SpecificationNovember 1998

2-11

9. The terminal stores the retrieved Data Authentication Code for further processing asdescribed in the EMV’96 ICC Application Specification for Payment Systems.

Page 102: MasterCard ICC

Security Specification of EMV’96 ICC Specification for Payment SystemsTransactions

2.2 Dynamic Data Authentication

ICC Application Specification © 1998 MasterCard International IncorporatedNovember 19982-12

2.2 DYNAMIC DATA AUTHENTICATION

2.2.1 Keys and Certificates

To support Dynamic Data Authentication, an ICC possesses its own unique ICC Public Key pairconsisting of a private signature key and the corresponding public verification key. The ICCPublic Key is stored on the ICC in the form of an ICC Public Key Certificate.

FIGURE 2.2: THREE LAYER PUBLIC KEY CERTIFICATION SCHEME

Issuer Certification Authority Acquirer

Private Key(IC Cardr)

SIC

Public Key(IC Card)

PIC

Public Key(CA)PCA

Private Key(CA)SCA

PI certifiedwith SCA

IC Card

Distributed to Acquirer(resides in Terminal)

IC TerminalCommunication between IC Card and Terminal

Card provides to terminal:- PI certified by Issuer- PI certified by Certification Authority- Card and terminal dynamic data with digital signature

Terminal:- Uses PCA to verify that the Issuer's PI was certified by the CA- Uses PI to verify that the Card's P IC was certified by the Issuer- Uses PI to verify the digital signature of the card data

Issuer

Private Key(Issuer)

SI

Public Key(Issuer)

PI

PI certifiedwith SCA

A three layer public key certification scheme as depicted in Figure 2.2 is used. Each ICC PublicKey is certified by its Issuer, and the Certification Authority (CA) certifies the Issuer Public Key.This implies that, for the verification of an ICC signature, the terminal first needs to verify twocertificates to retrieve and authenticate the ICC Public Key, which is then used to verify the ICCdynamic signature.

Page 103: MasterCard ICC

Security Specification of EMV’96 ICC Specification for Payment SystemsTransactions

2.2 Dynamic Data Authentication

ICC Application SpecificationNovember 1998

2-13

The signature scheme specified in Appendix B is applied to the data in Table 2.8 and to the data inTable 2.9 using the CA Private Key SCA and the Issuer Private Key SI to obtain the Issuer PublicKey Certificate and ICC Public Key Certificate, respectively.

The CA public key pair has a CA Public Key Modulus of NCA bytes.

The Issuer public key pair has an Issuer Public Key Modulus of NI bytes. If NI > (NCA – 36), theIssuer Public Key Modulus is divided into two parts:

• One part consisting of the NCA – 36 most significant bytes of the modulus (the Leftmost Digitsof the Issuer Public Key)

• A second part consisting of the remaining NI − (NCA – 36) least significant bytes of themodulus (the Issuer Public Key Remainder)

The ICC public key pair has an ICC Public Key Modulus of NIC bytes. If NIC > (NI – 42), the ICCPublic Key Modulus is divided into two parts:

• One part consisting of the NI – 42 most significant bytes of the modulus (the Leftmost Digitsof the ICC Public Key)

• A second part consisting of the remaining NIC – (NI – 42) least significant bytes of themodulus (the ICC Public Key Remainder)

To execute Dynamic Data Authentication, the terminal first retrieves and authenticates the ICCPublic Key (this process is called ICC Public Key authentication). All the information necessaryfor ICC Public Key authentication is specified in Table 2.10 and stored in the ICC. With theexception of the RID, which can be obtained from the AID, this information is retrieved with theREAD RECORD command. If any of this data is missing, Dynamic Data Authentication fails.

For specification of the lengths of CA, Issuer and ICC Public Key Modules and the values of CA,Issuer and ICC Public Key Exponents, see respectively C.1 and C.2 in Appendix C.

Page 104: MasterCard ICC

Security Specification of EMV’96 ICC Specification for Payment SystemsTransactions

2.2 Dynamic Data Authentication

ICC Application Specification © 1998 MasterCard International IncorporatedNovember 19982-14

TABLE 2.8: ISSUER PUBLIC KEY DATA TO BE SIGNED BY THE CERTIFICATION AUTHORITY

Field Name Length Description Format

Certificate Format 1 Hex. value ‘02’ b

Issuer Identification Number 4 Leftmost 3-8 digits from the PAN (padded to the rightwith hex. ‘F’s)

cn 8

Certificate Expiration Date 2 MMYY after which this certificate is invalid n 4

Certificate Serial Number 3 Binary number unique to this certificate assigned bythe certification authority

b

Hash Algorithm Indicator 1 Identifies the hash algorithm used to produce the HashResult in the digital signature scheme

b

Issuer Public Key AlgorithmIndicator

1 Identifies the digital signature algorithm to be usedwith the Issuer Public Key

b

Issuer Public Key Length 1 Identifies the length of the Issuer Public Key Modulusin bytes

b

Issuer Public Key ExponentLength

1 Identifies the length of the Issuer Public Key Exponentin bytes

b

Issuer Public Key or LeftmostDigits of the Issuer Public Key

NCA – 36 The NCA – 36 most significant bytes of the IssuerPublic Key

b

Issuer Public Key Remainder 0 or NI –NCA + 36

This field is only present if NI > NCA - 36 and consistsof the NI – NCA + 36 least significant bytes of theIssuer Public Key

b

Issuer Public Key Exponent 1 or 3 Issuer Public Key Exponent b

Page 105: MasterCard ICC

Security Specification of EMV’96 ICC Specification for Payment SystemsTransactions

2.2 Dynamic Data Authentication

ICC Application SpecificationNovember 1998

2-15

TABLE 2.9: ICC PUBLIC KEY DATA TO BE SIGNED BY THE ISSUER

Field Name Length Description Format

Certificate Format 1 Hex. value ‘04’ b

Application PAN 10 PAN (padded to the right with hex. ‘F’s) cn 20

Certificate Expiration Date 2 MMYY after which this certificate is invalid n 4

Certificate Serial Number 3 Binary number unique to this certificate assigned by theIssuer

b

Hash Algorithm Indicator 1 Identifies the hash algorithm used to produce the HashResult in the digital signature scheme

b

ICC Public Key AlgorithmIndicator

1 Identifies the digital signature algorithm to be used withthe ICC Public Key

b

ICC Public Key Length 1 Identifies the length of the ICC Public Key Modulus inbytes

b

ICC Public Key ExponentLength

1 Identifies the length of the ICC Public Key Exponent inbytes

b

ICC Public Key or LeftmostDigits of the ICC Public Key

NI – 42 The NI – 42 most significant bytes of the ICC PublicKey

b

ICC Public Key Remainder 0 or NIC

– NI + 42The NI – NCA + 42 least significant bytes of the ICCPublic Key

b

ICC Public Key Exponent 1 or 3 ICC Public Key Exponent b

Static Data to beAuthenticated

var. Static data to be authenticated as specified in Table 2.3and Table 2.4

-

Page 106: MasterCard ICC

Security Specification of EMV’96 ICC Specification for Payment SystemsTransactions

2.2 Dynamic Data Authentication

ICC Application Specification © 1998 MasterCard International IncorporatedNovember 19982-16

TABLE 2.10: DATA OBJECTS REQUIRED FOR PUBLIC KEY AUTHENTICATION FOR DYNAMIC AUTHENTICATION

Tag Length Value Format

— 5 Registered Application Provider Identifier (RID) b

‘8F’ 1 Certification Authority Public Key Index b

‘90’ NCA Issuer Public Key Certificate b

‘92’ NI – NCA + 36 Issuer Public Key Remainder, if present b

‘9F32’ 1 or 3 Issuer Public Key Exponent b

‘9F46’ NI ICC Public Key Certificate b

‘9F48’ NIC – NI + 42 ICC Public Key Remainder, if present b

‘9F47’ 1 or 3 ICC Public Key Exponent b

— var. Static data to be authenticated as specified in Table 2.3 andTable 4.

-

2.2.2 Retrieval of the Certification Authority Public Key

The terminal reads the CA Public Key Index. Using this index and the RID, the terminal identifiesand retrieves the terminal-stored CA Public Key Modulus and Exponent and the associated key-related information, and the corresponding algorithm to be used. If the terminal does not have thekey stored associated with this index and RID, Dynamic Data Authentication fails.

2.2.3 Retrieval of the Issuer Public Key

1. If the Issuer Public Key Certificate has a length different from the length of the CA Public KeyModulus obtained in the previous section, Dynamic Data Authentication fails.

2. To obtain the recovered data specified in Table 2.11, apply the recovery function specified inAppendix B on the Issuer Public Key Certificate using the CA Public Key in conjunction withthe corresponding algorithm. If the Recovered Data Trailer is not equal to ‘BC’, DynamicData Authentication fails.

Page 107: MasterCard ICC

Security Specification of EMV’96 ICC Specification for Payment SystemsTransactions

2.2 Dynamic Data Authentication

ICC Application SpecificationNovember 1998

2-17

TABLE 2.11: FORMAT OF THE DATA RECOVERED FROM THE ISSUER PUBLIC KEY CERTIFICATE

Field Name Length Description Format

Recovered Data Header 1 Hex. value ‘6A’ b

Certificate Format 1 Hex. value ‘02’ b

Issuer Identification Number 4 Leftmost 3-8 digits from the PAN (padded to theright with hex. ‘F’s)

cn 8

Certificate Expiration Date 2 MMYY after which this certificate is invalid n 4

Certificate Serial Number 3 Binary number unique to this certificate assigned bythe certification authority

b

Hash Algorithm Indicator 1 Identifies the hash algorithm used to produce theHash Result in the digital signature scheme

b

Issuer Public Key AlgorithmIndicator

1 Identifies the digital signature algorithm to be usedwith the Issuer Public Key

b

Issuer Public Key Length 1 Identifies the length of the Issuer Public KeyModulus in bytes

b

Issuer Public Key ExponentLength

1 Identifies the length of the Issuer Public KeyExponent in bytes

b

Issuer Public Key or LeftmostDigits of the Issuer Public Key

NCA – 36 The NCA – 36 most significant bytes of the IssuerPublic Key

b

Hash Result 20 Hash of the Issuer Public Key and its relatedinformation

b

Recovered Data Trailer 1 Hex. value ‘BC’ b

3. Check the Recovered Data Header. If it is not ‘6A’, Dynamic Data Authentication fails.

4. Check the Certificate Format. If it is not ‘02’, Dynamic Data Authentication fails.

5. Concatenate, from left to right, the second through the tenth data elements in Table 2.11(‘Certificate Format’ through ‘Issuer Public Key or Leftmost Digits of the Issuer Public Key’),followed by the Issuer Public Key Remainder and finally the Issuer Public Key Exponent.

6. Apply the indicated hash algorithm (derived from the Hash Algorithm Indicator) to the resultof the concatenation of the previous step to produce the hash result.

7. Compare the calculated hash result from the previous step with the recovered hash result. Ifthey are not the same, Dynamic Data Authentication fails.

Page 108: MasterCard ICC

Security Specification of EMV’96 ICC Specification for Payment SystemsTransactions

2.2 Dynamic Data Authentication

ICC Application Specification © 1998 MasterCard International IncorporatedNovember 19982-18

8. Verify that the Issuer Identification Number matches the leftmost 3-8 PAN digits (allowing forthe possible padding of the Issuer Identification Number with hexadecimal ‘F’s). If not,Dynamic Data Authentication fails.

9. Verify that the last day of the month specified in the Certificate Expiration Date is equal to orlater than today's date. If the Certificate Expiration Date is earlier than today's date, thecertificate has expired, in which case Dynamic Data Authentication fails.

10. If the Issuer Public Key Algorithm Indicator is not recognized, Dynamic Data Authenticationfails.

11. If all the checks above are correct, concatenate the Leftmost Digits of the Issuer Public Keyand the Issuer Public Key Remainder to obtain the Issuer Public Key Modulus, and continuewith the next steps for the retrieval of the ICC Public Key.

2.2.4 Retrieval of the ICC Public Key

1. If the ICC Public Key Certificate has a length different from the length of the Issuer PublicKey Modulus obtained in the previous section, Dynamic Data Authentication fails.

2. To obtain the recovered data specified in Table 2.12, apply the recovery function specified inAppendix B on the ICC Public Key Certificate using the Issuer Public Key in conjunction withthe corresponding algorithm. If the Recovered Data Trailer is not equal to ‘BC’, DynamicData Authentication fails.

Page 109: MasterCard ICC

Security Specification of EMV’96 ICC Specification for Payment SystemsTransactions

2.2 Dynamic Data Authentication

ICC Application SpecificationNovember 1998

2-19

TABLE 2.12: FORMAT OF THE DATA RECOVERED FROM THE ICC PUBLIC KEY CERTIFICATE

Field Name Length Description Format

Recovered Data Header 1 Hex. value ‘6A’ b

Certificate Format 1 Hex. value ‘04’ b

Application PAN 10 PAN (padded to the right with hex. ‘F’s) cn 20

Certificate Expiration Date 2 MMYY after which this certificate is invalid n 4

Certificate Serial Number 3 Binary number unique to this certificate assigned bythe issuer

b

Hash Algorithm Indicator 1 Identifies the hash algorithm used to produce theHash Result in the digital signature scheme

b

ICC Public Key AlgorithmIndicator

1 Identifies the digital signature algorithm to be usedwith the ICC Public Key

b

ICC Public Key Length 1 Identifies the length of the ICC Public Key Modulusin bytes

b

ICC Public Key ExponentLength

1 Identifies the length of the ICC Public Key Exponentin bytes

b

ICC Public Key or LeftmostDigits of the ICC Public Key

NI – 42 The NI − 42 most significant bytes of the ICC PublicKey

b

Hash Result 20 Hash of the ICC Public Key and its relatedinformation

b

Recovered Data Trailer 1 Hex. value ‘BC’ b

3. Check the Recovered Data Header. If it is not ‘6A’, Dynamic Data Authentication fails.

4. Check the Certificate Format. If it is not ‘04’, Dynamic Data Authentication fails.

5. Concatenate from left to right the second data element through the tenth data element in Table2.12 (‘Certificate Format’ through ‘ICC Public Key or Leftmost Digits of the ICC PublicKey’), followed by the ICC Public Key Remainder, the ICC Public Key Exponent and finallythe static data to be authenticated specified in Table 2.3 and Table 2.4.

6. Apply the indicated hash algorithm (derived from the Hash Algorithm Indicator) to the resultof the concatenation of the previous step to produce the hash result.

7. Compare the calculated hash result from the previous step with the recovered hash result. Ifthey are not the same, Dynamic Data Authentication fails.

Page 110: MasterCard ICC

Security Specification of EMV’96 ICC Specification for Payment SystemsTransactions

2.2 Dynamic Data Authentication

ICC Application Specification © 1998 MasterCard International IncorporatedNovember 19982-20

8. Check if the recovered PAN is equal to the Application PAN, read from the ICC. If not,Dynamic Data Authentication fails.

9. Verify that the last day of the month specified in the Certificate Expiration Date is equal to orlater than today's date. If not, Dynamic Data Authentication fails.

10. If the ICC Public Key Algorithm Indicator is not recognized, Dynamic Data Authenticationfails.

11. If all the checks above are correct, concatenate the Leftmost Digits of the ICC Public Key andthe ICC Public Key Remainder to obtain the ICC Public Key Modulus, and continue with theactual Dynamic Data Authentication described in the two sections below.

2.2.5 Dynamic Signature Generation

1. After successfully retrieving the ICC Public Key as described above, the terminal issues anINTERNAL AUTHENTICATE command including the concatenation of the data elementsspecified by the Dynamic Data Object List (DDOL) according to the rules specified in Part IIof the EMV’96: IC Card Specification for Payment Systems.

The ICC may contain the DDOL, but there is a default DDOL in the terminal, specified by thePayment System, in case the DDOL is not present in the ICC.

The DDOL always contains a 4 byte Unpredictable Number (UN) generated by the terminal.

If any of the following cases occur, Dynamic Data Authentication fails:

• Both the ICC and the terminal do not contain a DDOL• The DDOL in the ICC does not include the Unpredictable Number• The ICC does not contain a DDOL and the default DDOL in the terminal does not include the

Unpredictable Number. Table 2.13 specifies the length and format of the data elements whichare in the DDOL.

Page 111: MasterCard ICC

Security Specification of EMV’96 ICC Specification for Payment SystemsTransactions

2.2 Dynamic Data Authentication

ICC Application SpecificationNovember 1998

2-21

TABLE 2.13: DYNAMIC DATA OBJECT LIST

Value Tag Presence Length Format

Unpredictable number ‘9F37’ M b

Terminal Identification ‘9F1C’ O 8 an 8

Terminal CountryCode(CRF075)

‘9F1A’ O 2 n 3

Transaction Date ‘9A’ O 3 n 6

2. The ICC generates a digital signature as described in Appendix B on the data specified inTable 2.14 using the ICC Private Key ‘SIC‘ in conjunction with the corresponding algorithm.The result is called the Signed Dynamic Application Data.

TABLE 2.14: DYNAMIC APPLICATION DATA TO BE SIGNED

Field Name Length Description Format

Signed Data Format 1 Hex. value ‘05’ b

Hash Algorithm Indicator 1 Identifies the hash algorithm used to produce the HashResult

b

ICC Dynamic DataLength

1 Identifies the length LDD of the ICC dynamic data inbytes

b

ICC Dynamic Data LDD Dynamic data generated by and/or stored in the ICC —

Pad Pattern NIC – LDD -25

(NIC – LDD - 25) padding bytes of value ‘BB’ b

Terminal Dynamic Data var. Concatenation of the data elements specified by theDDOL

The ICC Dynamic Data field consists of the concatenation of the length of the ICC DynamicNumber and an 8 byte Dynamic Number as specified in Table 2.15 (LDD = 9). Section 2 describeshow the ICC Dynamic Number is computed during Dynamic Data Authentication.

Page 112: MasterCard ICC

Security Specification of EMV’96 ICC Specification for Payment SystemsTransactions

2.2 Dynamic Data Authentication

ICC Application Specification © 1998 MasterCard International IncorporatedNovember 19982-22

TABLE 2.15: ICC DYNAMIC NUMBER

Field Name Length Description Format

ICC Dynamic Number 8 Time-variant number generated by the ICC to be capturedby the terminal

b

TABLE 2.16: ICC DYNAMIC DATA

Name Length Description Format

ICC Dynamic Data 9 (=LDD) 08 ICC Dynamic Number b

In addition to those data objects specified in Table 2.10, the data objects required for DynamicData Authentication are specified in Table 2.17.

TABLE 2.17: ADDITIONAL DATA OBJECTS REQUIRED FOR DYNAMIC SIGNATURE GENERATION AND VERIFICATION

Tag Length Value Format

‘9F4B’ NIC Signed Dynamic Application Data b

‘9F49’ var. DDOL —

2.2.6 Dynamic Signature Verification

1. If the Signed Dynamic Application Data has a length different from the length of the ICCPublic Key Modulus, Dynamic Data Authentication fails.

2. To obtain the recovered data specified in Table 2.18, apply the recovery function specified inAppendix B to the Signed Dynamic Application Data using the ICC Public Key in conjunctionwith the corresponding algorithm. If the Recovered Data Trailer is not equal to ‘BC’,Dynamic Data Authentication fails.

Page 113: MasterCard ICC

Security Specification of EMV’96 ICC Specification for Payment SystemsTransactions

2.2 Dynamic Data Authentication

ICC Application SpecificationNovember 1998

2-23

TABLE 2.18: FORMAT OF THE DATA RECOVERED FROM THE SIGNED DYNAMIC APPLICATION DATA

Field Name Length Description Format

Recovered Data Header 1 Hex. value ‘6A’ b

Signed Data Format 1 Hex. value ‘05’ b

Hash AlgorithmIndicator

1 Identifies the hash algorithm used to produce theHash Result in the digital signature scheme

b

ICC Dynamic DataLength

1 Identifies the length of the ICC dynamic data in bytes b

ICC Dynamic Data LDD Dynamic data generated by and/or stored in the ICC —

Pad Pattern NIC – LDD –25

(NIC – LDD – 25) padding bytes of value ‘BB’ b

Hash Result 20 Hash of the Dynamic Application Data and its relatedinformation

b

Recovered Data Trailer 1 Hex. value ‘BC’ b

3. Check the Recovered Data Header. If it is not ‘6A’, Dynamic Data Authentication fails.

4. Check the Signed Data Format. If it is not ‘05’, Dynamic Data Authentication fails.

5. Concatenate, from left to right, the second data element through the sixth data element inTable 2.18 (‘Signed Data Format’ through ‘Pad Pattern’), followed by the data elementsspecified by the DDOL.

6. Apply the indicated hash algorithm (derived from the Hash Algorithm Indicator) to the resultof the concatenation of the previous step to produce the hash result.

7. Compare the calculated hash result from the previous step with the recovered hash result. Ifthey are not the same, Dynamic Data Authentication fails.

8. If all the above steps were executed successfully, Dynamic Data Authentication passes. Theterminal stores the retrieved ICC Dynamic Number for further processing as described in theEMV’96 ICC Specification for Payment Systems.

Page 114: MasterCard ICC

Security Specification of EMV’96 ICC Specification for Payment SystemsTransactions

2.3 Pin Encipherment

ICC Application Specification © 1998 MasterCard International IncorporatedNovember 19982-24

2.3 PIN ENCIPHERMENT

If supported, Personal Identification Number (PIN) encipherment for offline PIN verification isperformed by the terminal using an asymmetric based encipherment mechanism to ensure thesecure transfer of a PIN from a secure tamper-evident PIN pad to the ICC. The ICC owns apublic key pair associated with PIN encipherment. The public key is used by the PIN pad toencipher the PIN, and the private key is used by the ICC to verify the enciphered PIN.

2.3.1 Keys and Certificates

There are two options for key usage:

1. The ICC owns a specific ICC PIN Encipherment Private and Public Key. The ICC PINEncipherment Public Key is stored on the ICC in a public key certificate in exactly the sameway as the ICC Public Key for dynamic data authentication as specified in Section 2.2.

The ICC PIN Encipherment public key pair has an ICC PIN Encipherment Public KeyModulus of NPE bytes, where NPE < NI, NI is the length of the Issuer Public Key Modulus (seeSection 2.1). If NPE > (NI − 42), the ICC PIN Encipherment Public Key Modulus is dividedinto two parts:

• One part consisting of the NI − 42 most significant bytes of the modulus (the LeftmostDigits of the ICC PIN Encipherment Public Key)

• Second part consisting of the remaining NPE − (NI − 42) least significant bytes of themodulus (the ICC PIN Encipherment Public Key Remainder)

The ICC PIN Encipherment Public Key Exponent is equal to 3 or 216+1. The ICC PINEncipherment Public Key Certificate is obtained by applying the digital signature schemespecified in Appendix B to the data in Table 2.19 using the Issuer Private Key (see Section2.1).

Page 115: MasterCard ICC

Security Specification of EMV’96 ICC Specification for Payment SystemsTransactions

2.3 Pin Encipherment

ICC Application SpecificationNovember 1998

2-25

TABLE 2.19: ICC PIN ENCIPHERMENT PUBLIC KEY DATA TO BE SIGNED BY THE ISSUER

Field Name Length Description Format

Certificate Format 1 Hex. Value ‘04’ b

Application PAN 10 PAN (padded to the right with hex. ‘F’s) cn 20

Certificate Expiration Date 2 MMYY after which this certificate is invalid n 4

Certificate Serial Number 3 Binary number unique to this certificateassigned by the issuer

b

Hash Algorithm Indicator 1 Identifies the hash algorithm used to producethe Hash Result in the digital signaturescheme

b

ICC PIN EnciphermentPublic Key AlgorithmIndicator

1 Identifies the digital signature algorithm to beused with the ICC PIN Encipherment PublicKey

b

ICC PIN EnciphermentPublic Key Length

1 Identifies the length of the ICC PINEncipherment Public Key Modulus in bytes

b

ICC PIN EnciphermentPublic Key or LeftmostDigits of the ICC PINEncipherment Public Key

NI – 42 If NPE ≤ NI –42, this field consists of the fullICC PIN Encipherment Public Key padded tothe right with NI – 42 – NPE bytes of value‘BB’If NPE > NI – 42, this field consists of the NI –42 most significant bytes of the ICC PINEncipherment Public Key 4

b

ICC PIN EnciphermentPublic Key Remainder

0 or NIC –NI + 42

This field is only present if NPE > NI – 42 andconsists of the NI – NPE + 42 least significantbytes of the ICC PIN Encipherment Public Key

b

ICC PIN EnciphermentPublic Key Exponent

1 or 3 ICC PIN Encipherment Public Key Exponentequal to 3 or 216+1

b

4 As can be seen in Appendix B, NI − 22 bytes of the data signed are retrieved from the signature. Since the first throughthe eighth data elements in Table 2.9 total 20 bytes, there are NI − 22 − 20 = NI − 42 bytes left for the data to be stored inthe signature.

Page 116: MasterCard ICC

Security Specification of EMV’96 ICC Specification for Payment SystemsTransactions

2.3 Pin Encipherment

ICC Application Specification © 1998 MasterCard International IncorporatedNovember 19982-26

2. The ICC does not own a specific ICC PIN Encipherment public key pair, but owns an ICCpublic key pair for Dynamic Data Authentication as specified in Section 2.2. This key pair isused for PIN encipherment, if and only if the ICC Public Key Exponent is equal to 3 or 216+1.The ICC Public Key is stored on the ICC in a public key certificate as specified in Section 2.2.

The first step of PIN Encipherment is the retrieval of the public key to be used by the terminal forthe encipherment of the PIN. This process takes place as:

1. If the terminal has obtained all the data objects specified in Table 2.20 from the ICC, then theterminal retrieves the ICC PIN Encipherment Public Key in exactly the same way as itretrieves the ICC Public Key for Dynamic Data Authentication (see Section 2.4).

2. If the terminal has not obtained all the data objects specified in Table 2.20, but has obtained allthe data objects specified in Table 2.10, and the ICC Public Key Exponent is equal to 3 or216+1, then the terminal retrieves the ICC Public Key as described in Section 2.4.

3. If the conditions under points 1 and 2 above are not satisfied, then PIN Encipherment fails.

TABLE 2.20: DATA OBJECTS REQUIRED FOR THE RETRIEVAL OF THE ICC PIN ENCIPHERMENT PUBLIC KEY

Tag Length Value Format

- 5 Registered Application Provider Identifier (RID) b

‘8F’ 1 Certification Authority Public Key Index b

‘90’ NCA Issuer Public Key Certificate b

‘92’ NI – NCA + 36 Issuer Public Key Remainder, if present b

‘9F32’ 1 or 3 Issuer Public Key Exponent b

‘9F2D’ NI ICC PIN Encipherment Public Key Certificate b

‘9F2E’ NPE – NI + 42 ICC PIN Encipherment Public Key Remainder, if present b

‘9F2F’ 1 or 3 ICC PIN Encipherment Public Key Exponent b

Page 117: MasterCard ICC

Security Specification of EMV’96 ICC Specification for Payment SystemsTransactions

2.3 Pin Encipherment

ICC Application SpecificationNovember 1998

2-27

2.3.2 PIN Encipherment and Verification

The exchange and verification of an enciphered PIN between terminal and ICC takes place as:

1. The PIN is entered in plain text format on the PIN pad and a PIN block is constructed asdefined in the EMV’96 ICC Specification for Payment Systems.

2. The terminal issues a GET CHALLENGE command to the ICC to obtain an 8-byteunpredictable number from the ICC.

3. The terminal generates a Random Pad Pattern consisting of N − 17 bytes, where N is thelength in bytes of the public key to be used for PIN encipherment retrieved as specified inSection 2.3 (hence N = NPE or N = NIC).

4. Using the PIN Encipherment Public Key or the ICC Public Key retrieved as specified inSection 2.3, the terminal applies the RSA Recovery Function specified in Appendix B to thedata specified in Table 2.21 to obtain the Enciphered PIN Data.

TABLE 2.21: DATA TO BE ENCIPHERED FOR PIN ENCIPHERMENT

Field Name Length Description Format

Data Header 1 Hex. value ‘7F’ b

PIN Block 8 PIN in PIN Block b

ICC Unpredictable Number 8 Unpredictable number obtained from the ICCwith the GET CHALLENGE command

b

Random Pad Pattern N – 17 Random Pad Pattern generated by the terminal b

5. The terminal issues a VERIFY command including the Enciphered PIN Data obtained in theprevious step.

6. With the ICC Private Key, the ICC applies the RSA Signing Function algorithm specified inAppendix B to the Enciphered PIN Data to recover the plain text data specified in Table 2.21.

7. The ICC verifies if the Data Header recovered is equal to ‘7F’. If the Data Header recoveredis not equal to ‘7F’, PIN verification fails.

Page 118: MasterCard ICC

Security Specification of EMV’96 ICC Specification for Payment SystemsTransactions

2.3 Pin Encipherment

ICC Application Specification © 1998 MasterCard International IncorporatedNovember 19982-28

8. The ICC verifies whether the ICC Unpredictable Number recovered is equal to the ICCUnpredictable Number generated by the ICC with the GET CHALLENGE command. If theICC Unpredictable Number recovered is not equal to the ICC Unpredictable Numbergenerated by the ICC (with the GET CHALLENGE command), PIN verification fails.

9. The ICC verifies whether the PIN included in the recovered PIN Block corresponds with thePIN stored in the ICC. If the PIN included in the recovered PIN Block does not correspondwith the PIN stored in the ICC, PIN verification fails.

10. If all the above steps were executed successfully, enciphered PIN verification passes.

+ For this mechanism to be secure, the steps 1 through 4 are executed in the secureenvironment of the tamper-evident PIN pad.

Page 119: MasterCard ICC

Security Specification of EMV’96 ICC Specification for Payment SystemsTransactions

2.4 Application Cryptograms

ICC Application SpecificationNovember 1998

2-29

2.4 APPLICATION CRYPTOGRAMS

This section describes how to generate a TC, AAC or ARQC.

2.4.1 Initial Selection of Data

A data object to be input to the TC, AAC or ARQC algorithm is either:

• Referenced in the ICC’s CDOLs and transmitted in plain text from the terminal to the ICC inthe GENERATE AC command

or

• Accessed internally by the ICC.

+ Only certain data elements (for example, data elements and data objectsretrievable by the GET PROCESSING OPTIONS command) can be accessedinternally by the ICC.

This specification supports a limited set of methods to generate an application cryptogram. Eachmethod is identified by a Cryptogram Version Number. The Cryptogram Version Numberindicates the data objects used to generate the application cryptogram and the method of datainput for each data object. (See Appendix D for other data elements which could be included inthe CDOL.) Table 2.22 lists the 11 objects recommended by MasterCard for input to applicationcryptograms and the source of the each data object.

+ The algorithm described is the recommended implementation. It is referencedas cryptogram version number x. Issuers that wish to use different algorithms(for example those issuers that do not require session keys in the cryptogram)can be accommodated by establishing a different cryptogram version numberfor their algorithm. It is strongly recommended that issuers contact MasterCardbefore committing to an unspecified cryptogram version number.

Page 120: MasterCard ICC

Security Specification of EMV’96 ICC Specification for Payment SystemsTransactions

2.4 Application Cryptograms

ICC Application Specification © 1998 MasterCard International IncorporatedNovember 19982-30

TABLE 2.22: TC, AAC, AND ARQC DATA ELEMENTS

Data Element Supplied byTerminal

Input by ICC

Amount, Authorized X

Amount, Other X

Terminal Country Code X

Terminal Verification Results X

Transaction Currency Code X

Transaction Date X

Transaction Type X

Unpredictable Number X

Application Interchange Profile x

ATC x

Card Verification Results x

If a data object is included as input to the algorithm, the data object is used in the order specifiedin Table 2.22.

It the Issuer wants to include other data elements than the ones recommended by MCI/EPI, theyshould be taken from the data elements listed in Appendix D, all of which have an EMV Tag.

Page 121: MasterCard ICC

Security Specification of EMV’96 ICC Specification for Payment SystemsTransactions

2.4 Application Cryptograms

ICC Application SpecificationNovember 1998

2-31

2.4.2 TC, AAC, and ARQC Algorithm

1. In the first step, the terminal issues the first/second GENERATE AC , using the data specifiedin CDOL1/CDOL2.

2. The second step of the AC generation consists of deriving a 16-byte Session Key SKAC fromthe ICC Master Key Cryptogram Key MKAC using (see Table 2.23).

• The 2-byte Application Transaction Counter (ATC) of the ICC• A 4-byte terminal Unpredictable Number (UN)

and the Session Key Derivation (SKD) function described in 2.7.

+ This UN is not necessarily the same UN that was possibly used previously forDynamic Data Authentication (see Section 2) or the enciphered PIN (see Section2).

+ SKAC: = SKD(MKAC)[(ATC || ‘00’ || ‘00’ ||UN)].

TABLE 2.23: DATA ELEMENTS INVOLVED IN THE APPLICATION CRYPTOGRAM SESSION KEY DERIVATION

Value Source Tag Length Format

Application Transaction Counter (ATC) ICC ‘9F36’ 2 b

Unpredictable Number (UN) Terminal ‘9F37’ 4 b

3. Based upon card risk management, the ICC determines whether to return a TC, an AAC or anARQC in the response message. The data to be used as input for the cryptogram algorithm ishard coded in the ICC. The ICC concatenates the data specified in Table 2.22 in the orderspecified to create a block of data.

4. The ICC formats this block of data into 8-byte data blocks, labelled D1, D2, D3, D4, D5. TheICC pads this block according to method 2 of ISO/IEC 9797, hence add a mandatory bytewith hexadecimal ‘80’ to the right and then add the smallest number of hexadecimal ‘00’ bytesto the right such that the length of the resulting message M := (M || ‘80’ || ‘00’ || ‘00’ || . . . ||‘00’) is a multiple of 8 bytes.

Page 122: MasterCard ICC

Security Specification of EMV’96 ICC Specification for Payment SystemsTransactions

2.4 Application Cryptograms

ICC Application Specification © 1998 MasterCard International IncorporatedNovember 19982-32

5. The ICC performs the algorithm shown in Figure 3 to generate the TC, AAC or ARQC usingthe Session keys SKAC. The TC, AAC or ARQC is the 8 byte final result.

FIGURE 2.3: AC ALGORITHM FOR A DOUBLE-LENGTH SESSION KEY

I 1 = D 1 I 2 I 5

DES(e)SKL DES(e)SKL DES(e)

0 1 0 2 0 5

+

D 2

+

D 3

SKL

TC/AAC/ARQCLegend:

I = InputDES(e) =Data Encryption Algorithm

(encipherment mode)

DES(d) =Data Encryption Algorithm(decipherment mode)

O = Output

D = Data block

SKAC = Unique Session key derived from MKAC

SKL = Left part of SKAC ; SKR = Right part of SKAC

+ = Exclusive-OR

I 3 I 4

DES(e) DES(e)SKL

0 3 0 4

+

D 4

+

D 5

SKL DES(d)SKR

0 6

DES(e)SKL

0 7

+ In the above figure, the number of cycles can be expanded beyond five

Page 123: MasterCard ICC

Security Specification of EMV’96 ICC Specification for Payment SystemsTransactions

2.5 Issuer Authentication

ICC Application SpecificationNovember 1998

2-33

2.5 ISSUER AUTHENTICATION

The validation process for the ARPC is described:

1. The ICC shall perform an exclusive-OR operation:ARQC ⊕ ARPC Response Code

The ARPC Response Code (ARC) used in this operation is transmitted to the ICC in theIssuer Authentication Data. Prior to performing the exclusive-OR operation, the ICC left-justifies the ARPC Response Code in an 8-byte field and zero fills (hexadecimal zero) theremaining 6 bytes.

2. The results of the exclusive-OR operation is used as input to the 8-byte data block D1.

3. The ICC performs the authentication algorithm as shown in Figure 2.4 to generate the ARPCusing the ICC Master Key Cryptogram Key MKAC. The ICC shall generate the ARPC byapplying the DES3 algorithm to the result of the exclusive-OR operation in step 1. TheARPC is the 8 byte final result.

Page 124: MasterCard ICC

Security Specification of EMV’96 ICC Specification for Payment SystemsTransactions

2.5 Issuer Authentication

ICC Application Specification © 1998 MasterCard International IncorporatedNovember 19982-34

FIGURE 2.4: ARPC ALGORITHM FOR A DOUBLE-LENGTH DES KEY

I 1 = D 1

DES(e)

0 1

DES(d)

0 3

0 2

DES(e)

ARPC

MKL

MKR

MKL

Legend:

I = Input D = Data block DES(e) = Data Encryption Algorithm MKL = Left part of MKAC (encipherment mode) MKR = Right part of MKAC DES(d) = Data Encryption Algorithm (decipherment mode) O = Output

+ There is no need to recalculate the ARQC to verify the ARPC. The ARQCtransmitted in the request message is used as input to the exclusive-ORoperation.

Page 125: MasterCard ICC

Security Specification of EMV’96 ICC Specification for Payment SystemsTransactions

2.6 Secure Messaging

ICC Application SpecificationNovember 1998

2-35

2.6 SECURE MESSAGING

Although Secure Messaging as described here may be used with a command other than the IssuerScript Commands described in Section 1, this section describes the use of Secure Messaging forIssuer Script Commands.

The principle objectives of secure messaging are to ensure:

• Message Integrity• Data Confidentiality• Issuer authentication

Data confidentiality is achieved using encipherment of the plain text command data. Messageintegrity and issuer authentication are achieved using a MAC.

2.6.1 Secure Messaging for Integrity

The Secure Messaging format defined in this specification is based upon ISO 7816-4. SecureMessaging is indicated for any EMV’96 command that may require it when the second nibble ofthe CLA byte is equal to hexadecimal ‘4’.

Data encipherment is done in accordance with the EMV’96 specification with the provision thatthe length field in front of the enciphered data is omitted.

The MAC is the last data element in the command data field and has a length of 8 bytes.

The length of the MAC is known by the originator of the command and by the currently selectedapplication in the ICC.

The MAC Session Key used during Secure Message processing is generated using the session keygeneration process described in Section 2.

The MAC is generated using DES3 encipherment:

1. An initial vector is set equal to 8 bytes of hexadecimal zeroes.

Page 126: MasterCard ICC

Security Specification of EMV’96 ICC Specification for Payment SystemsTransactions

2.6 Secure Messaging

ICC Application Specification © 1998 MasterCard International IncorporatedNovember 19982-36

2. The following data is concatenated in the order specified to create a block of data:• CLA, INS, P1, P2, Lc• Last ATC (for Issuer Script processing, this is the ATC transmitted in the request

message)• The RAND used for session key derivation

+ For Issuer Script processing, this is usually the ARQC transmitted in the requestmessage; when the application has been blocked prior to transmission of therequest, the Application Cryptogram is an AAC.

• Plain text data contained in the command data field (if present)

3. This block of data is formatted into 8-byte data blocks, labelled D1, D2, D3, D4, etc. The lastdata block may be 1-8 bytes in length.

4. If the last data block is 8 bytes in length, an additional 8-byte data block is concatenated to theright of the last data block: hexadecimal ‘80 00 00 00 00 00 00 00’. Proceed to step 5.

If the last data block is less than 8 bytes in length, it is padded to the right with a 1-bytehexadecimal ‘80’. If the last data block is now 8 bytes in length, proceed to step 5. If the lastdata block is still less than 8 bytes in length, it is right filled with 1-byte hexadecimal zeroesuntil it is 8 bytes in length.

5. The MAC is generated using the MAC Session Keys SKSMI as shown in Figure 2.5.

+ Depending on the length of the concatenated block of data created in step 2,there may be less than four 8-byte data blocks to input to the algorithm

6. The resultant value is the 8-byte MAC.

Page 127: MasterCard ICC

Security Specification of EMV’96 ICC Specification for Payment SystemsTransactions

2.6 Secure Messaging

ICC Application SpecificationNovember 1998

2-37

FIGURE 2.5: MAC ALGORITHM FOR A DOUBLE-LENGTH SESSION KEY

I 2 I 3 I 5

DES(e)SKL DES(e)SKL DES(e)

0 1 0 2 0 4

+

D 2

+

D 3

I 4

DES(e) SKL

0 3

+

D 4

SKL

InitialVector

+

I 1 = D 1

MAC

DES(d)SKR

0 5

DES(e)SKL

0 6

Legend:

I = Input D = Data block

DES(e) = Data Encryption Algorithm SKSMI = MAC Session Key (Integrity) (encipherment mode) SKL = Left part of SKSMI DES(d) = Data Encryption Algorithm SKR = Right part of SKSMI (decipherment mode) + = Exclusive - OR O = Output

Page 128: MasterCard ICC

Security Specification of EMV’96 ICC Specification for Payment SystemsTransactions

2.6 Secure Messaging

ICC Application Specification © 1998 MasterCard International IncorporatedNovember 19982-38

2.6.2 Secure Messaging for Confidentiality

The encryption mechanism used for Secure Messaging for Confidentiality is the DES3 algorithmin CBC mode.

Encryption of a message M of arbitrary length with a double-length Session Key SKSMC = (SKL ||SKR) takes place in the following steps (see Section 2).

1. If the length of the message M is not a multiple of 8 bytes, pad the message M according toISO 7816-4, hence add a mandatory byte with hexadecimal ‘80’ to the right of M, and thenadd the smallest number of hexadecimal ‘00’ bytes to the right such that the length of resultingmessage M := (M || ‘80’ || ‘00’ || ‘00’ || . . . || ‘00’) is a multiple of 8 bytes.

2. Divide M into 8-byte blocks X1, X2, . . . , Xk and encrypt the blocks into the 8-byte blocks Y1,Y2, . . . , Yk with the T-DES algorithm in CBC mode. Compute for i = 1, 2, . . . , k-1:

Yi := DES3 (SKSMC)[Xi ⊕ Yi-1],

where Y0 := 0.

+ Y := (Y1 || Y2 || . . . || Yk) = ENC(SKSMC)[M]

Decryption of Y with a double-length Session Key SKSMC = (SKL || SKR) takes place in thefollowing steps:

1. Compute for i = 1, 2, . . . , k:

Xi := DES3 (SKSMC)[Yi ] ⊕ Yi-1,

where Y0 := 0.

2. To obtain the original message M, concatenate the blocks X1, X2, . . . , Xk and, if paddingtook place, remove the trailing (‘80’ || ‘00’ || ‘00’ || . . . || ‘00’) byte-string from the last blockXk.

Page 129: MasterCard ICC

Security Specification of EMV’96 ICC Specification for Payment SystemsTransactions

2.6 Secure Messaging

ICC Application SpecificationNovember 1998

2-39

2.6.3 Combined Integrity and Confidentiality

The MAC is generated using all elements of the script command, including the command header.The integrity of the command, including the data component contained in the command data field(if present), is ensured by Secure Messaging.

When a specific command requires both Secure Messaging for Integrity and Confidentiality (forexample for the PIN CHANGE/UNBLOCK command), the following applies:

1. The plain text command data is enciphered as specified in Section 2 to obtain the encipheredcommand data.

2. The MAC is then computed over the enciphered command data.

3. The command data field consists of the enciphered command data, concatenated to the rightwith the MAC.

This mechanism enables the usage of the same ICC Master Key for both Secure Messaging forIntegrity and Confidentiality.

Page 130: MasterCard ICC

Security Specification of EMV’96 ICC Specification for Payment SystemsTransactions

2.7 ICC Key Derivation

ICC Application Specification © 1998 MasterCard International IncorporatedNovember 19982-40

2.7 ICC KEY DERIVATION

2.7.1 ICC Master Key Derivation

The Debit/Credit application on the ICC uses the following unique 16-byte DES3 keys

• MKAC — ICC Master Key for Application Cryptogram Generation (see Section 2).• MKSMI — ICC Master Key for Secure Messaging for Integrity (see Section 2).• MKSMC — ICC Master Key for Secure Messaging for Confidentiality (see Section 2)• MKIDN — ICC Master Key for ICC Dynamic Number generation (see Section 2).

This section illustrates the method of key derivation used to generate the keys stored in the ICCduring personalization.

The ICC Master Keys (MK) are derived from the corresponding Issuer Master Keys (IMK) (seeTable 2.24).

TABLE 2.24: ISSUER MASTER KEYS USED TO DERIVE ICC MASTER KEYS

Unique ICC Master Key Derived from Issuer Master Key

MKAC IMKAC

MKSMI IMKSMI

MKSMC IMKSMC

MKIDN IMKIDN

Figure 2.6 shows the method for the derivation of ICC unique Master keys.

Page 131: MasterCard ICC

Security Specification of EMV’96 ICC Specification for Payment SystemsTransactions

2.7 ICC Key Derivation

ICC Application SpecificationNovember 1998

2-41

FIGURE 2.6: KEY DERIVATION METHODOLOGY

IMK

IMK

IssuerSecurity Module

IMK

PAN, PAN Sequence No.

T-DES(encipher,decipher,encipher)

MKL

Issuer generates its double-lengthMaster Key (IMK).

For each application in ICC, issuerpersonalises ICC with an ICC MasterMK.

The left part of Master Key MK is derived by usingApplication PAN and Application PANSequence Number as input andperforming T-DES encipherment.

the inverted Application PAN andApplication PAN Sequence Number asinput and performing T-DESencipherment.

Inverted PAN, PAN Sequence No.

T-DES(encipher,decipher,encipher)

MKR

The right part of Master Key MK is derived by using

Page 132: MasterCard ICC

Security Specification of EMV’96 ICC Specification for Payment SystemsTransactions

2.7 ICC Key Derivation

ICC Application Specification © 1998 MasterCard International IncorporatedNovember 19982-42

To derive the left part of ICC Master Key MK, the Application PAN and Application PANSequence Number are concatenated together in a 16-hexadecimal field. If the combined length ofthe concatenation of the Application PAN and the Application PAN Sequence Number is notequal to 16 digits, the following formatting rules apply:

• If the combined length of ‘Application PAN’ plus the ‘Application PAN Sequence Number’ isless than 16 digits, right-justify the data in a 16-hexadecimal field and pad on the left with ‘0’s;

• If the combined length of ‘Application PAN’ followed by the ‘Application PAN SequenceNumber’ exceeds 16 digits, use only the rightmost 16 digits.

To derive the right part of the ICC Master Key, the Application PAN and Application PANSequence Number are first concatenated together into a 16-hexadecimal field using the formattingrules described above and then inverted. Inversion is performed at the bit level, each bit withvalue ‘1’ is set to ‘0’ and each bit with value ‘0’ is set to ‘1’.

2.7.2 ICC Session Key Derivation

The session key derivation function uses a 16-byte Master Key MK and an 8-byte random numberR = (R0 || R1 || R2 || R3 || R4 || R5 || R6 || R7), and produces a 16-byte Session Key SK = (SKL ||SKR):

SKL := DES3 (MK)[(R0 || R1 || ‘F0’ || R3 || R4 || R5 || R6 || R7)]

SKR := DES3 (MK)[(R0 || R1 || ‘0F’ || R3 || R4 || R5 || R6 || R7)].

The left part of the double-length Session Key is obtained by applying the DES3 algorithm withthe double-length ICC Master Key to the 8-byte data-block obtained by replacing the third mostsignificant byte R2 of R by the byte ‘F0’.

The right part of the double-length Session Key is obtained by applying the DES3 algorithm withthe double-length ICCMaster Key to the 8-byte data-block obtained by replacing the third mostsignificant byte R2 of R by the byte ‘0F’.

+ SK: = SKD(MK)[R]

Page 133: MasterCard ICC

Security Specification of EMV’96 ICC Specification for Payment SystemsTransactions

2.8 Random Number for Session Key Derivation

ICC Application SpecificationNovember 1998

2-43

2.8 RANDOM NUMBER FOR SESSION KEY DERIVATION

In Secure Messaging for Integrity and Confidentiality, the Session Key used is derived from anICC Master Key using a random number RAND generated by the ICC. For script processing, theRAND can either be an ARQC or an AAC generated by the ICC in response to a GENERATEAC command.

If more than one subsequent command is sent using Secure Messaging, a separate Session Key isderived for the Secure Messaging of each subsequent command:

• The RAND used for the Session Key derivation for the first command is equal to the ARQCor the AAC

• The RAND for the Session Key derivation of a subsequent command is obtained byincrementing the RAND used for the previous command by 1 (see Figure 2.7).

FIGURE 2.7: DIAGRAM OF A SECURE MESSAGING COMMAND

Verify Secure Messagingon the Command

Secure Messaging Command

Script SessionKey derived?

Session keyderivation

using Rand

Session keyderivation

using Rand = Rand + 1

SM correct ?

Perform theCommand

Yes

Yes

No

No

Page 134: MasterCard ICC

Security Specification of EMV’96 ICC Specification for Payment SystemsTransactions

2.9 Data Authentication Code Generation

ICC Application Specification © 1998 MasterCard International IncorporatedNovember 19982-44

2.9 DATA AUTHENTICATION CODE GENERATION

The Data Authentication Code (DAC) is retrieved by the terminal during Static DataAuthentication. The Data Authentication Code is sent to the Issuer as proof that the terminalexecuted SDA successfully.

This section describes how the Issuer computes the Data Authentication Code (DAC) based onICC specific data for personalization and verification.

A 16-byte DES3 Issuer Master Key IMKDAC is used by the Issuer for the purpose of generating aDAC.

The 2-byte DAC is equal to the 2 leftmost bytes of Z, which is given by

Z: = DES3 (IMKDAC)[Y]

where the 8-byte data block Y is obtained:

• If the combined length of ‘Application PAN’ plus the ‘Application PAN Sequence Number’ isless than 16 digits, right-justify the data in a 16-hexadecimal field and pad on the left withhexadecimal ‘0’s

• If the combined length of ‘Application PAN’ followed by the ‘Application PAN SequenceNumber’ exceeds 16 digits, use only the rightmost 16 digits.

+ For security reasons IMKDAC must be distinct from the Issuer Master Keysspecified in Table 2.24.

Page 135: MasterCard ICC

Security Specification of EMV’96 ICC Specification for Payment SystemsTransactions

2.10 ICC Dynamic Number Generation

ICC Application SpecificationNovember 1998

2-45

2.10 ICC DYNAMIC NUMBER GENERATION

The ICC Dynamic Number (IDN) is computed by the ICC and retrieved by the terminal duringDynamic Data Authentication. The 2 leftmost bytes of the ICC Dynamic Number are sent to theIssuer as proof that the terminal executed DDA successfully.

This section describes how the ICC generates and the Issuer verifies the ICC Dynamic Number.

A 16-byte DES3 ICC Master Key MKIDN is stored in the ICC for the purpose of generating theICC Dynamic Number.

+ This ICC Master Key is unique for each ICC. The key management at Issuerlevel of these keys is described in Section 2.

The ICC Dynamic Number is computed using the ICC Application Transaction Counter (ATC)and the Unpredictable Number (UN) requested in the DDOL:

IDN := DES3(MKIDN)[(ATC || ‘00’ || ‘00’ || ‘00’ || ‘00’ || ‘00’ || ‘00’ ||)].

Page 136: MasterCard ICC
Page 137: MasterCard ICC

Table of Contents

ICC Application SpecificationNovember 1998

3-i

SECTION 3 DATA SPECIFICATION OF EMV ’96 ICC SPECIFICATIONFOR PAYMENT SYSTEMS TRANSACTIONS

3.1 Data Elements and Files ......................................................3-13.1.1 Management of data elements by ICC.........................3-1

3.1.2 EMV data elements ....................................................3-83.1.3 MasterCard proprietary data elements.......................3-30

3.2 Updating Card Risk Management Data..............................3-403.3 Card Risk Management Data Object List...........................3-41

3.3.1 Card Risk Management Data Object List 1 ...............3-413.3.2 Card Risk Management Data Object List 2 ...............3-42

3.2 Card Life Cycle Data.........................................................3-44

Page 138: MasterCard ICC
Page 139: MasterCard ICC

Data Specification of EMV ’96 ICC Specification for Payment Systems Transactions3.1 Data Elements and Files

ICC Application SpecificationNovember 1998

3-1

3.1 DATA ELEMENTS AND FILES

3.1.1 Management of data elements by ICC

Table 3.1 gives an overview of the management of the ICC data elements, whether they arealways present or not, whether they can be updated or not and how the terminal accesses them.

TABLE 3.1: MANAGEMENT OF ICC DATA ELEMENTS

Name Tag Presence Updated by Access Condition

ApplicationCurrency Code

‘9F42’ C — READ RECORD

If the value for either Amount “X”or Amount “Y” contained in theCVM List is nonzero, theApplication Currency Code ismandatory

Present if the card supports“Maximum Domestic OfflineTransaction Amount”, “OfflineCumulative Amount” or “Currencyconversion”

ApplicationDiscretionaryData

‘9F05’ O — —

ApplicationEffective Date

‘5F25’ O — READ RECORD

ApplicationExpiration Date

‘5F24’ M — READ RECORD

Application FileLocator

‘94’ M — GETPROCESSING

OPTIONS

Application Control ‘9F60’ O Script —

Application Flag ‘9F5E’ M Internally —

ApplicationIdentifier (AID)

‘4F’ C — READ RECORD If the PSE is present, the AID ismandatory in the ADF entryformat

ApplicationInterchangeProfile

‘82’ M — GETPROCESSING

OPTIONS

Page 140: MasterCard ICC

Data Specification of EMV ‘96 ICC Specification for Payment Systems Transactions3.1 Data Elements and Files

ICC Application Specification © 1998 MasterCard International IncorporatedNovember 19983-2

Name Tag Presence Updated by Access Condition

Application Label ‘50’ C — READ RECORD The Application Label ismandatory in the ADF entry ofthe PSE. It is optional in theADF.

ApplicationPreferred Name

‘9F12’ O — READ RECORD

ApplicationPrimary AccountNumber (PAN)

‘5A’ M — READ RECORD

ApplicationPrimary AccountNumber (PAN)SequenceNumber

‘5F34’ M — READ RECORD

ApplicationPriority Indicator

‘87’ O — READ RECORD

SELECT

ApplicationTemplate

‘61’ C — The Application Template ismandatory if the PSE is present

ApplicationTransactionCounter (ATC)

‘9F36’ M Internally GENERATE AC

GET DATA

The ATC is always returned inthe response to the GENERATEAC

The ATC can be retrieved by theGET DATA command if the cardwants the terminal to do thevelocity checking

ApplicationUsage Control

‘9F07’ M — READ RECORD

ApplicationVersion Number

‘9F08’ M — READ RECORD

Card Issuer ActionCode— Decline

— M Script —

Card IssuerAction Code—Offline

— M Script —

Card IssuerAction Code—Online

— M Script —

Page 141: MasterCard ICC

Data Specification of EMV ’96 ICC Specification for Payment Systems Transactions3.1 Data Elements and Files

ICC Application SpecificationNovember 1998

3-3

Name Tag Presence Updated by Access Condition

Card RiskManagementData Object List1 (CDOL1)

‘8C’ M — READ RECORD

Card RiskManagementData Object List2 (CDOL2)

‘8D’ M — READ RECORD

Cardholder Name ‘5F20’ M — READ RECORD The Cardholder Name is mandatoryif present on the magnetic stripetrack 1 and in that case both shallbe identical.

Cardholder NameExtended

‘9F0B’ O — READ RECORD

CardholderVerificationMethod (CVM)List

‘8E’ M — READ RECORD

Card TVR ActionCode

— M Script —

CertificationAuthority PublicKey Index

‘8F’ C — READ RECORD Mandatory for cards that supportoffline CAM

CryptogramVersion Number

— M — GENERATE AC

DataAuthenticationCode

‘9F45’ C — READ RECORD Mandatory for cards that supportoffline CAM (included in theSigned Static Application Data)

DDF Name ‘9D’ C — READ RECORD If the PSE is present, the DDFName is mandatory if an DDFentry is present

Dedicated File(DF) Name

‘84’ M — SELECT

Dynamic DataAuthenticationData Object(DDOL)

‘9F49’ O — READ RECORD

Page 142: MasterCard ICC

Data Specification of EMV ‘96 ICC Specification for Payment Systems Transactions3.1 Data Elements and Files

ICC Application Specification © 1998 MasterCard International IncorporatedNovember 19983-4

Name Tag Presence Updated by Access Condition

File ControlInformation (FCI)IssuerDiscretionary Data

‘BF0C’ O — SELECT

File ControlInformation (FCI)ProprietaryTemplate

‘A5’ M — SELECT

File ControlInformation (FCI)Template

‘6F’ M — SELECT

Integrated CircuitCard (ICC) PINEnciphermentPublic KeyCertificate

‘9F2D’ C — READ RECORD Mandatory if a separate key pair isused for offline PIN encryption.Absent when the same key pair isused as for DDA

Integrated CircuitCard (ICC) PINEnciphermentPublic KeyExponent

‘9F2F’ C — READ RECORD Mandatory if a separate key pair isused for offline PIN encryption.Absent if the same key pair isused as for DDA

Integrated CircuitCard (ICC) PINEnciphermentPrivate Key

C — — Present if offline enciphered PINverification is supported and adedicated key pair is used for thatpurpose (ICC private key for DDAis not used for that purpose)

Integrated CircuitCard (ICC) PINEnciphermentPublic KeyRemainder

‘9F2E’ C — READ RECORD Present if a separate key pair isused for offline PIN encryptionand NPE − (NI − 42)>0. Absent ifthe same key pair is used as forDDA or if NPE − (NI − 42)=0

Integrated CircuitCard (ICC) PublicKey Certificate

‘9F46’ C — READ RECORD Mandatory if offline dynamicCAM is supported by the card

Integrated CircuitCard (ICC) PublicKey Exponent

‘9F47’ C — READ RECORD Mandatory if offline dynamicCAM is to be supported by thecard

Integrated CircuitCard (ICC) PrivateKey

C — — Mandatory if offline dynamicCAM is to be supported by thecard

Page 143: MasterCard ICC

Data Specification of EMV ’96 ICC Specification for Payment Systems Transactions3.1 Data Elements and Files

ICC Application SpecificationNovember 1998

3-5

Name Tag Presence Updated by Access Condition

Integrated CircuitCard (ICC) PublicKey Remainder

‘9F48’ C — READ RECORD Present if offline dynamic CAM isto be supported by the card andNIC – (NI - 42) > 0. Absentotherwise

Issuer ActionCode— Default

‘9F0D’ M — READ RECORD

Issuer ActionCode— Denial

‘9F0E’ M — READ RECORD

Issuer ActionCode— Online

‘9F0F’ M — READ RECORD

Issuer Code TableIndex

‘9F11’ O — READ RECORD

Issuer CountryCode

‘5F28’ M — READ RECORD

Issuer Public KeyCertificate

‘90’ C — READ RECORD Mandatory if the card is tosupport offline CAM

Issuer Public KeyExponent

‘9F32’ C — READ RECORD Mandatory if the card is tosupport offline CAM

Issuer Public KeyRemainder

‘92’ C — READ RECORD Mandatory if the card is tosupport offline CAM and NI −(NCA – 36) > 0; Absent otherwise

Issuer ScriptCommandCounter

— M Internally GENERATE AC Only the least three significantbits are indicated in the CVR

Key DerivationIndex

— M — GENERATE AC

LanguagePreference

‘5F2D’ O — READ RECORD

Last OnlineApplicationTransactionCounter (LATC)

‘9F13’ C Internally GET DATA Mandatory if the card wants theterminal to do the velocitychecking.

Mandatory if the card does thevelocity checking internally

LowerConsecutiveOffline Limit

‘9F14’ C Script GET DATA

Mandatory if the card wants theterminal to do the velocitychecking.

Mandatory if the card does thevelocity checking internally

Page 144: MasterCard ICC

Data Specification of EMV ‘96 ICC Specification for Payment Systems Transactions3.1 Data Elements and Files

ICC Application Specification © 1998 MasterCard International IncorporatedNovember 19983-6

Name Tag Presence Updated by Access Condition

Lower CumulativeDomestic OfflineTransactionAmount

— C Script — Mandatory if the card includes the“Maximum Domestic OfflineTransaction Amount” function in itscard risk management

MaximumDomestic OfflineTransactionAmount

— O Script — Present if the card includes the“Maximum Domestic OfflineTransaction Amount” function in itscard risk management

MKAC M — —

MKSMI C — — Mandatory if the card supportsscript commands

MKSMC C — — Mandatory if the card supports ascript command that uses SecureMessaging for Confidentiality

This key can be the same asMKSMI

MKIDN C — — Mandatory if offline dynamicCAM is to be supported by thecard

Non DomesticControl Factor

— C Script — Mandatory if the card does thevelocity checking internally andwants a different behavior fordomestic and non-domestictransactions

Cumulative OfflineTransaction

— C Internally — Present if the card includes the“Offline Cumulative Amount”function in its card riskmanagement

PIN Try Counter ‘9F17’ C Internally GET DATA

VERIFY

Mandatory if the cards supportsoffline PIN verification and theGET DATA command.

Present if the card supports offlinePIN verification

PIN Try Limit — C — — Mandatory if the card supportsoffline PIN verification.

Processing OptionsData Object List(PDOL)

‘9F38’ O — SELECT

Page 145: MasterCard ICC

Data Specification of EMV ’96 ICC Specification for Payment Systems Transactions3.1 Data Elements and Files

ICC Application SpecificationNovember 1998

3-7

Name Tag Presence Updated by Access Condition

Reference CurrencyConversion Table

— C Script — Present if the card supportscurrency conversion

Reference PersonalIdentificationNumber (PIN)

— C Script — Mandatory if the card supportsoffline PIN verification.

Service Code ‘5F30’ O Script READ RECORD

Short FileIdentifier (SFI)

‘88’ C — SELECT Mandatory if PSE is present onthe card

Signed DynamicApplication Data

‘9F4B’ C — READ RECORD Mandatory if offline dynamicCAM is supported by the card

Signed StaticApplication Data

‘93’ C — READ RECORD Mandatory if offline static CAM issupported by the card

Static DataAuthentication TagList

‘9F4A’ C — READ RECORD Present if AIP or AID are includein the Static Data to beAuthenticated.

Track 1DiscretionaryData

‘9F1F’ C — READ RECORD The Track 1 Discretionary datamust be present in the ICC ifpresent on the magnetic stripe andthey must be identical.

Track 2Equivalent Data

‘57’ C Script READ RECORD The data included in the Track 2Equivalent Data must be identicalto the data on the Track 2 of themagnetic stripe except for theIssuer proprietary DiscretionaryData.(CRF003.6)

TransactionCertificate DataObject List (TDOL)

‘97’ O — READ RECORD

Upper ConsecutiveOffline Limit

‘9F23’ C Script GET DATA Mandatory if the card wants theterminal to do the velocitychecking.

Mandatory if the card does thevelocity checking internally

Upper CumulativeDomestic OfflineTransactionAmount

— C Script — Mandatory if the card includes the“Maximum Domestic OfflineTransaction Amount” function in itscard risk management

Page 146: MasterCard ICC

Data Specification of EMV ‘96 ICC Specification for Payment Systems Transactions3.1 Data Elements and Files

ICC Application Specification © 1998 MasterCard International IncorporatedNovember 19983-8

3.1.2 EMV data elements

Table 3.2 gives a dictionary of EMV data elements to support financial transactions. Thisdictionary contains all relevant data elements from Section 2 of the EMV ‘96, Version 3.1.1, ICCSpecification for Payment Systems and in the EMV’96 ICC Terminal Specification for PaymentSystems.

TABLE 3.2 EMV DATA ELEMENTS

Name Description Source Format Tag Length Values

Amount,Authorized(Numeric)

Authorized amount ofthe transaction.

Terminal

n 12 ‘9F02’ 6

Amount,Authorized(Binary)

Authorized amount ofthe transaction(excluding adjustments)

Terminal

b ‘81’ 4 Should not be used forCDOL1 or CDOL2

Amount, Other(Numeric)

Secondary amountassociated with thetransaction representinga cashback amount.

Terminal

n 12 ‘9F03’ 6

Amount, Other(Binary)

A secondary amountassociated with thetransaction representinga cashback amount

Terminal

b ‘9F04’ 4 Should not be used forCDOL1 or CDOL2

Amount, ReferenceCurrency

Authorized amountexpressed in thereference currency

Terminal

b ‘9F3A’ 4

ApplicationAuthenticationCryptogram(AAC)

Application cryptogramcomputed by the card fora declined transaction.

ICC b ‘9F26’ 8 see 2.4

ApplicationCurrency Code

Indicates the currency inwhich the account ismanaged according toISO 4217

ICC n 3 ‘9F42 2

ApplicationDiscretionaryData

Issuer-specified datarelating to the cardapplication.

ICC b ‘9F05’ 1-32 The use of this dataobject is reserved forfuture use byMCI/EPI and issuersare not allowed to useit for private ordomestic use

Page 147: MasterCard ICC

Data Specification of EMV ’96 ICC Specification for Payment Systems Transactions3.1 Data Elements and Files

ICC Application SpecificationNovember 1998

3-9

Name Description Source Format Tag Length Values

ApplicationEffective Date

Date from which the cardapplication may be used.

ICC n 6

YYMMDD

‘5F25’ 3

ApplicationElementary File(AEF) DataTemplate

Indicates the recordtemplate of a recordcontaining data objects.

ICC var. ‘70’ var.

ApplicationExpiration Date

Date after which the cardapplication expires.

ICC n 6

YYMMDD

‘5F24’ 3

Application FileLocator

Indicates the location(SFI, range of records) ofthe AEFs related to agiven application.

ICC var. ‘94’ var.up to252

Byte 1:bits 8-4 = SFIbits 3-1 = 000

Byte 2:First record number tobe read for that SFI(never equal to zero)

Byte 3:Last record number tobe read for that SFI(shall be greater thanor equal to byte 2)

Byte 4:Number ofconsecutive recordssigned in SignedApplication Data,starting with recordnumber in byte 2(may be equal to zero)

Byte 1-4Can be repeated forother files orsubsequences ofrecords within a file

ApplicationInterchangeProfile

Indicates the capabilitiesof the card to supportspecific functions in theapplication.

ICC b 16 ‘82’ 2 Byte 1bit 8: 1 = Initiatebit 7: 1 = Offline staticData Authentication issupported (this bit isonly zero for ATM-onlycards)

Page 148: MasterCard ICC

Data Specification of EMV ‘96 ICC Specification for Payment Systems Transactions3.1 Data Elements and Files

ICC Application Specification © 1998 MasterCard International IncorporatedNovember 19983-10

Name Description Source Format Tag Length Valuesbit 6: 1 = Off lineDynamic DataAuthentication issupportedbit 5: 1 = CardholderVerification is supportedbit 4: 1 = Terminal RiskManagement is to beperformedbit 3: 1 = Issuerauthentication issupported usingEXTERNALAUTHENTICATE0 = Issuer authenticationis supported usingsecond GENERATE ACbit 2: 1 = RESERVEDbit 1: 1 = RESERVED

Byte 2 = RESERVED

ApplicationLabel

Mnemonic associatedwith AID according toISO/IEC 7816-5. Usedin application selection.

ICC an 1-16 ‘50’ 1-16 See Minimum CardRequirements for listof all ApplicationLabels.

ApplicationPreferred Name

Preferred mnemonicassociated with the AID

ICC an 1-16 ‘9F12’ 1-16 See Minimum CardRequirements for listof all ApplicationPreferred Names.

ApplicationPrimary AccountNumber (PAN)

Valid cardholder accountnumber.

ICC var. up tocn 19

‘5A’ var.up to10

ApplicationPrimary AccountNumber (PAN)Sequence Number

Identifies anddifferentiates cardapplications with thesame PAN.

ICC n 2 ‘5F34’ 1

ApplicationPriority Indicator

Indicates the priority of agiven application orgroup of applications in adirectory.

ICC b 8 ‘87’ 1 bit 8: 1=Application shall notbe selected withoutconfirmation ofcardholder

0 =

Page 149: MasterCard ICC

Data Specification of EMV ’96 ICC Specification for Payment Systems Transactions3.1 Data Elements and Files

ICC Application SpecificationNovember 1998

3-11

Name Description Source Format Tag Length ValuesApplication may beselected withoutconfirmation ofcardholder

bits 7-5: RESERVEDbits 4-1:0000 =No priority assignedxxxx = Order inwhich the applicationis to be listed orselected, ranging from1 to 15, with 1 beingthe highest priority

ApplicationTemplate

Template containing oneor more data objectsrelevant to an applicationdirectory entry accordingto ISO/IEC 7816-5.

ICC b ‘61’ var.up to252

Only present if thecard has a PSE

ApplicationTransactionCounter (ATC)

Counter maintained bythe application in thecard.

ICC b ‘9F36’ 2 Initial value is zero. Itis incremented by 1 eachtime the GETPROCESSINGOPTIONS command isexecuted.

ApplicationUsage Control

Indicates issuer-specifiedrestrictions on thegeographic usage andservices allowed for thecard application.

ICC b ‘9F07’ 2 Byte 1:bit 8: 1 =

Valid fordomestic cashtransactionsbit 7: 1 =

Valid forinternational cashtransactionsbit 6: 1 =

Valid fordomestic goodsbit 5: 1 =

Valid forinternational goodsbit 4: 1 =

Valid fordomestic servicesbit 3: 1 =

Page 150: MasterCard ICC

Data Specification of EMV ‘96 ICC Specification for Payment Systems Transactions3.1 Data Elements and Files

ICC Application Specification © 1998 MasterCard International IncorporatedNovember 19983-12

Name Description Source Format Tag Length ValuesValid for

international servicesbit 2: 1 =

Valid at ATMsbit 1: 1 =

Valid atterminals other thanATMs

Byte 2:bit 8: 1 =Domestic cashbackallowedbit 7: 1 =Internationalcashback allowedbits 6-1 =

RESERVED

See Minimum CardRequirements for thedifferent settings ofeach product.

ApplicationVersion Number

Version number assignedby the payment systemfor the application.

ICC b ‘9F08’ 2 For this version of thespecifications, theversion numbershould be ‘0002’

AuthorizationRequestCryptogram(ARQC)

Value computed by thecard application foronline cardauthentication.

ICC b ‘9F28’ 8 see 2.4

AuthorizationResponse Code

Indicates the dispositionof the transaction.

Issuer orterminal

an 2 ‘8A’ 2 Codes generated bythe issuer are asindicated in ISO8583:1987.

The following codesare generated by theterminal for thefollowing exceptionconditions:

Y1= OfflineapprovedZ1 = Offline declinedY3 = Unable to go

Page 151: MasterCard ICC

Data Specification of EMV ’96 ICC Specification for Payment Systems Transactions3.1 Data Elements and Files

ICC Application SpecificationNovember 1998

3-13

online (offlineapproved)Z3 =Unable to goonline (offlinedeclined)

If the terminal did notreceive an answerfrom the Issuer, thedata element will be(hex) zero filled.

Other values areconsidered as Issuerresponse, possiblymodified byintermediatenetworks.

Card RiskManagementData Object List1 (CDOL1)

List of data objects (tagand length) to be passedto the card applicationwith the firstGENERATE ACcommand.

ICC an ‘8C’ var.

Card RiskManagementData Object List2 (CDOL2)

List of data elements (tagand length) to be passedto the card applicationwith the secondGENERATE ACcommand.

ICC an ‘8D’ var.

Cardholder Name Indicates cardholdername according to ISO7813.

ICC ans 2-26 ‘5F20’ 2-26

Cardholder NameExtended

Indicates the wholecardholder name whengreater than 26characters using the samecoding convention as inISO 7813

ICC ans 27-45 ‘9F0B’ 27-45

CardholderVerificationMethod (CVM)List

Identifies a prioritizedlist of methods ofverification of thecardholder supported bythe card application.

ICC b ‘8E’ var.up to252

Bytes 1-4Amount (‘X’)

Bytes 5-8:Amount (‘Y’)

Page 152: MasterCard ICC

Data Specification of EMV ‘96 ICC Specification for Payment Systems Transactions3.1 Data Elements and Files

ICC Application Specification © 1998 MasterCard International IncorporatedNovember 19983-14

Name Description Source Format Tag Length Values

Byte 9 (CVM MethodCodes):bit 8: 0 = Onlyvaluebit 7: 0 = Failcardholderverification if thisCVM is unsuccessful

1 = Applysucceeding CVM fieldif this CVM isunsuccessfulbits 6-1:000000 = Fail CVMprocessing000001 =Plaintext PINverification performedby the ICC000010 = EncipheredPIN verified online000011 = Plaintext PINverification performedby ICC and signature(paper)000100 = EncipheredPIN verificationperformed by ICC000101 = EncipheredPIN verificationperformed by ICC andsignature(paper)000110-011101= RESERVED011110 = Signature011111 = No CVMrequired100000-101111 =RESERVED by theindividual PaymentSystems110000-111110 =RESERVED by theIssuer111111 = RESERVED

Page 153: MasterCard ICC

Data Specification of EMV ’96 ICC Specification for Payment Systems Transactions3.1 Data Elements and Files

ICC Application SpecificationNovember 1998

3-15

Name Description Source Format Tag Length Values

Byte 10 (CVMConditions):00 = Always01 = If cash orcashback (includesquasi-cash)02 = If not cash orcashback (includesquasi-cash)

03 = If terminalsupports the CVM04 = If terminal doesnot support the CVM05 = If terminalsupport not operative06 = If transaction isin ApplicationCurrency Code and isunder X value07 = If transaction isin ApplicationCurrency Code and isover X value08 = If transaction isin ApplicationCurrency Code and isunder Y value09 = If transaction isin ApplicationCurrency Code and isover Y value

An additional 2 bytesis added followingbyte 10 for eachadditional CVM andcorresponding CVMCondition.

For the CVM lists ofthe different products,refer to MinimumCard Requirements

Page 154: MasterCard ICC

Data Specification of EMV ‘96 ICC Specification for Payment Systems Transactions3.1 Data Elements and Files

ICC Application Specification © 1998 MasterCard International IncorporatedNovember 19983-16

Name Description Source Format Tag Length Values

CertificationAuthority PublicKey Index

Identifies the certificationauthority’s public key inconjunction with the RIDfor use in static dataauthentication.

ICC b 8 ‘8F’ 1 Values assigned byCard Schemes.

CommandTemplate

Identifies the data field ofa command message.

Terminal

b ‘83’ var. Used in GetProcessing Optionsresponse

CryptogramInformation Data

Indicates the type ofcryptogram and theactions to be performedby the terminal

ICC b ‘9F27’ 1 bit 8-7: 00 = AAC01 = TC10 = ARQC11 = Not

usedbit 6-5: RESERVEDbit 4: 1 = Advicerequired

0 = Noadvice requiredbit 3-1:(Reason/advice/referral code)

000 = Noinformation given

001 =Service not allowed

010 = PINTry Limit exceeded

011 = Issuerauthentication failed

xxx = Allother values areRESERVED

DataAuthenticationCode

Issuer-assigned valuecontained in SignedApplication Data used to‘prove’ that static dataauthentication wasperformed.

ICC b ‘9F45’ 2 see 2.9

Dedicated File(DF) Name

Identifies the name of theDF as described inISO/IEC 7816-4.

ICC b ‘84’ 5-16

Page 155: MasterCard ICC

Data Specification of EMV ’96 ICC Specification for Payment Systems Transactions3.1 Data Elements and Files

ICC Application SpecificationNovember 1998

3-17

Name Description Source Format Tag Length Values

DirectoryDefinition File(DDF) Name

Identifies the name of aDF associated with adirectory

ICC b ‘9D’ 5-16

Dynamic DataAuthenticationData Object(DDOL)

List of data objects (tagand length) to be passedto the ICC in theINTERNALAUTHENTICATEcommand

ICC b ‘9F49’ up to252

File ControlInformation(FCI) IssuerDiscretionaryData

Issuer discretionary partof the FCI

ICC var. ‘BF0C’ var.up to222

File ControlInformation(FCI) ProprietaryTemplate

Identifies the data objectproprietary to thisspecification in the FCItemplate according toISO/IEC 7816-4

ICC var. ‘A5’ var.

File ControlInformation(FCI) Template

Identifies the FCItemplate according toISO/IEC 7816-4

ICC var. ‘6F’ var.up to252

Integrated CircuitCard (ICC)Dynamic Number

Time variant numbergenerated by the card tobe retrieved by theterminal during dynamicdata authentication

ICC b ‘9F4C’ 8

Integrated CircuitCard (ICC) PINEnciphermentPublic KeyCertificate

ICC PIN EnciphermentPublic Key certified bythe issuer

ICC b ‘9F2D’ NI

Integrated CircuitCard (ICC) PINEnciphermentPublic KeyExponent

ICC PIN EnciphermentPublic Key Exponentused for PINEncipherment

ICC b ‘9F2F’ 1 or 3

Integrated CircuitCard (ICC) PINEnciphermentPublic KeyRemainder

Remaining digits of theICC PIN EnciphermentPublic Key Modulus

ICC b ‘9F2E’ NPE −NI +42

Page 156: MasterCard ICC

Data Specification of EMV ‘96 ICC Specification for Payment Systems Transactions3.1 Data Elements and Files

ICC Application Specification © 1998 MasterCard International IncorporatedNovember 19983-18

Name Description Source Format Tag Length Values

Integrated CircuitCard (ICC)Public KeyCertificate

ICC Public Key certifiedby the issuer

ICC b ‘9F46’ NI

Integrated CircuitCard (ICC)Public KeyExponent

ICC Public KeyExponent used for theverification of the SignedDynamic ApplicationData

ICC b ‘9F47’ 1 or 3

Integrated CircuitCard (ICC)Public KeyRemainder

Remaining digits of theICC Public Key Modulus

ICC b ‘9F48’ NIC −NI +42

Issuer ActionCode— Default

Specifies the issuer’sconditions that cause atransaction to be declinedif it might have beenapproved online, but theterminal is unable toprocess the transactiononline.

ICC b ‘9F0D’ 5 Bit assignments areidentical to those forTerminal VerificationResults.

The settings for thedifferent products aredescribed in MinimumCard Requirements

Issuer ActionCode— Denial

Specifies the issuer’sconditions that cause thedecline of a transactionwithout attempting to goonline.

ICC b ‘9F0E’ 5 Bit assignments areidentical to those forTerminal VerificationResults.

The settings for thedifferent products aredescribed in MinimumCard Requirements

Issuer ActionCode— Online

Specifies the issuer’sconditions that cause atransaction to betransmitted online.

ICC b ‘9F0F’ 5 Bit assignments areidentical to those forTerminal VerificationResults.

The settings for thedifferent products aredescribed in MinimumCard Requirements

Page 157: MasterCard ICC

Data Specification of EMV ’96 ICC Specification for Payment Systems Transactions3.1 Data Elements and Files

ICC Application SpecificationNovember 1998

3-19

Name Description Source Format Tag Length Values

IssuerApplication Data

Contains proprietaryapplication data fortransmission to the issuer inan online transaction

ICC b ‘9F10’ var. upto 32

For this version of thespecifications, theIssuer ApplicationData is 8 bytes:

• Key DerivationIndex (1 byte)

• CryptogramVersion Number(1 byte)

• CVR:information aboutthe ICC decisionstaken during theCRM processing.(4 bytes)

• DAC or 2leftmost bytes ofICC DynamicNumber: provingthat the terminalcorrectlyperformed Staticor Dynamic DataAuthentication

IssuerAuthenticationData

Issuer data transmitted tocard for online issuerauthentication.

Issuer b ‘91’ 8-16 For this version of thespecifications, the IssuerAuthentication Data is10 bytes:

• ARPCCryptogram(first8 bytes)

• IssuerAuthenticationResponse Code(IARC)' Code(last 2 bytes)

Page 158: MasterCard ICC

Data Specification of EMV ‘96 ICC Specification for Payment Systems Transactions3.1 Data Elements and Files

ICC Application Specification © 1998 MasterCard International IncorporatedNovember 19983-20

Name Description Source Format Tag Length Values

Issuer Code TableIndex

Indicates the code tableaccording to ISO 8859for displaying theApplication PreferredName

ICC n 2 ‘9F11’ 1 Values are: 01 = Part 1 of ISO885902 = Part 2 of ISO885903 = Part 3 of ISO885904 = Part 4 of ISO885905 = Part 5 of ISO885906 = Part 6 of ISO885907 = Part 7 of ISO885908 = Part 8 of ISO885909 = Part 9 of ISO885910 = Part 10 of ISO8859

Issuer CountryCode

Indicates the country ofthe issuer, representedaccording to ISO 3166.

ICC n 3 ‘5F28’ 2

Issuer Public KeyCertificate

Issuer public key certifiedby a certification authority

ICC b ‘90’ NCA

Issuer Public KeyExponent

Issuer public key exponentused for the verification ofthe Signed StaticApplication Data and theICC Public Key Certificate

ICC b ‘9F32’ 1 or 3

Issuer Public KeyRemainder

Remaining digits of theIssuer Public KeyModulus

ICC b ‘92’ NI −NCA +

36

Issuer ScriptCommand

Contains a command fortransmission to the card.

Issuer b ‘86’ var.up to261

Issuer ScriptIdentifier

Identification of theIssuer Script

Issuer b ‘9F18’ 4

Page 159: MasterCard ICC

Data Specification of EMV ’96 ICC Specification for Payment Systems Transactions3.1 Data Elements and Files

ICC Application SpecificationNovember 1998

3-21

Name Description Source Format Tag Length Values

Issuer ScriptTemplate 1

Contains proprietaryissuer data fortransmission to the ICCbefore the secondGENERATE ACcommand

Issuer b ‘71’ var.

Issuer ScriptTemplate 2

Contains proprietaryissuer data fortransmission to the ICCafter the secondGENERATE ACcommand

Issuer b ‘72’ var.

LanguagePreference

1-4 languages stored inorder of preference, eachrepresented by 2alphabetical charactersaccording to ISO 639

ICC an 2 ‘5F2D’ 2-8

Last OnlineApplicationTransactionCounter (LATC)

ATC value of the lasttransaction that wentonline successfully.

ICC b ‘9F13’ 2 Initial value is zero.Updated to containthe current value ofthe ATC when atransaction has beentransmitted onlineand issuerauthentication issuccessful.

LowerConsecutiveOffline Limit

Issuer-specified dataelement indicating apreference for maximumnumber of consecutiveoffline transactionsallowed for theapplication in a terminalwith online capability.

ICC b ‘9F14’ 1

MerchantCategory Code

Terminal

n 4 ‘9F15’ 2

Offline EncipheredTransactionPersonalIdentificationNumber

Data entered by thecardholder for hisauthentication, andenciphered by terminal

Terminal b ‘9F4D’ NIC orNPE

PIN Try Counter Number of triesremaining

ICC b ‘9F17’ 1 Initial value is PINTry Limit

Page 160: MasterCard ICC

Data Specification of EMV ‘96 ICC Specification for Payment Systems Transactions3.1 Data Elements and Files

ICC Application Specification © 1998 MasterCard International IncorporatedNovember 19983-22

Name Description Source Format Tag Length Values

Point of Service(POS) EntryMode

Indicates source ofcardholder account dataat the terminal accordingto ISO 8583:1987

Terminal

n 2 ‘9F39’ 1

ProcessingOptions DataObject List(PDOL)

Contains a list ofterminal resident dataobjects (tags and lengths)needed by the ICC inprocessing the GETPROCESSINGOPTIONS command

ICC b ‘9F38’ var. For this version ofspecifications, thePDOL is not used.

ResponseMessageTemplate Format1

Contains the data objects(without tags andlengths) returned by theICC in response to acommand.

ICC var. 80 -

ResponseMessageTemplate Format2

Contains the data objects(with tags and lengths)returned by the ICC inresponse to a command

ICC var. 77 -

Service Code Service code as definedon magnetic stripe tracks1 and 2 according toISO/IEC 7813.

ICC n 3 ‘5F30’ 2

Short FileIdentifier (SFI)

Identifies the SFI to beused in the commandsrelated to a given AEF

ICC b ‘88’ 1 Values are:1-10: Governed byjoint payment systems11-20: Paymentsystem specific21-30: Issuer specific

Signed DynamicApplication Data

Digital Signature on criticalapplication parameters fordynamic data authentication

ICC b ‘9F4B’ NIC see 2.2.1

Signed StaticApplication Data

Digital Signature oncritical applicationparameters for static dataauthentication

ICC b ‘93’ NI see 2.1.1

Page 161: MasterCard ICC

Data Specification of EMV ’96 ICC Specification for Payment Systems Transactions3.1 Data Elements and Files

ICC Application SpecificationNovember 1998

3-23

Name Description Source Format Tag Length Values

Static DataAuthenticationTag List

List of tags of primitivedata objects defined inthis specification whosevalue fields are to beincluded in the SignedStatic or DynamicApplication Data

ICC b ‘9F4A’ var. For this specification,the SDA Tag list islimited to the AIP andthe AID.

TerminalCapabilities

Indicates the card datainput, CVM, and securitycapabilities of theterminal

Terminal

b ‘9F33’ 3 Byte 1 (Card DataInput Capability)bit 8: 1 = Manual KeyEntry

bit 7: 1 = MagneticStripebit 6: 1 = IC withContactsbit 5: 1 =RESERVED

Byte 2 (CVMCapability)bit 8: 1 = PlaintextPIN for ICCverificationbit 7: 1 = EncipheredPIN for onlineverificationbit 6: 1 = Signature(Paper)bit 5: 1 = EncipheredPIN for offlineverificationbit 4: 1 =RESERVED

Byte 3 (SecurityCapability)bit 8: 1 = Static DataAuthenticationbit 7: 1 = DynamicData Authenticationbit 6: 1 = CardCapturebit 5: 1 =RESERVED

Page 162: MasterCard ICC

Data Specification of EMV ‘96 ICC Specification for Payment Systems Transactions3.1 Data Elements and Files

ICC Application Specification © 1998 MasterCard International IncorporatedNovember 19983-24

Name Description Source Format Tag Length Values

Terminal CountryCode

Indicates the country ofthe terminal representedaccording to ISO 3166.

Terminal

n 3 '9F1A' 2

Terminal Type Indicates theenvironment of theterminal, itscommunicationcapability, and itsoperational control

Terminal

n 2 ‘9F35’ 1 Values are:Financial Institution11 = Attended Onlineonly12 = Attended Offlinewith online capability13 = Attended Offlineonly14 = UnattendedOnline only15 = UnattendedOffline with onlinecapability16 = UnattendedOffline only

Merchant21 = Attended Onlineonly22 = Attended Offlinewith online capability23 = Attended Offlineonly24 = UnattendedOnline only25 = UnattendedOffline with onlinecapability26 = UnattendedOffline only

Cardholder34 = UnattendedOnline only35 = UnattendedOffline with onlinecapability36 = UnattendedOffline only

TerminalVerificationResults

Status of the differentfunctions as seen from theterminal

Terminal b ‘95’ 5 Byte 1bit 8: 1 = Offline Dataauthentication was notperformed

Page 163: MasterCard ICC

Data Specification of EMV ’96 ICC Specification for Payment Systems Transactions3.1 Data Elements and Files

ICC Application SpecificationNovember 1998

3-25

Name Description Source Format Tag Length Valuesbit 7: 1 = Offline Staticdata authenticationfailed

bit 6: 1 = ICC datamissingbit 5: 1 = Card appearson terminal exceptionlistbit 4: 1 = OfflineDynamic dataauthentication failedbit 3-1 = RESERVED

Byte 2bit 8: 1 = ICC andterminal have differentapplication versionsbit 7: 1 = Expiredapplicationbit 6: 1 = Applicationnot yet activebit 5: 1 = Requestedservice not allowed forcard productbit 4: 1 = New cardbit 3-1 = RESERVED

Byte 3bit 8: 1 = Cardholderverification was notsuccessfulbit 7: 1 = UnrecognizedCVMbit 6: 1 = PIN try limitexceededbit 5: 1 = PIN entryrequired, PIN pad notpresent or not workingbit 4: 1 = PIN entryrequired, PIN padpresent, PIN not enteredbit 3: 1 = Online PINenteredbit 2-1 = RESERVED

Page 164: MasterCard ICC

Data Specification of EMV ‘96 ICC Specification for Payment Systems Transactions3.1 Data Elements and Files

ICC Application Specification © 1998 MasterCard International IncorporatedNovember 19983-26

Name Description Source Format Tag Length Values

Byte 4bit 8: 1 = Transactionexceeds floor limitbit 7: 1 = LowerConsecutive Offlinelimit exceededbit 6: 1 = UpperConsecutive Offlinelimit exceededbit 5: 1 = Transactionselected randomly foronline processingbit 4: 1 = Merchantforced the transactiononlinebit 3-1 = RESERVED

Byte 5bit 8: 1 = Default TDOLusedbit 7: 1 = Issuerauthentication wasunsuccessfulbit 6: 1 = Scriptprocessing failed beforefinal GENERATE ACbit 5: 1 = Scriptprocessing failed afterfinal GENERATE ACbit 4-1 = RESERVED

Track 1DiscretionaryData

Discretionary Data fromtrack 1 of the magneticstripe according toISO/IEC 7813

ICC ans ‘9F1F’ var.

Page 165: MasterCard ICC

Data Specification of EMV ’96 ICC Specification for Payment Systems Transactions3.1 Data Elements and Files

ICC Application SpecificationNovember 1998

3-27

Name Description Source Format Tag Length Values

Track 2Equivalent Data

The Track 2 EquivalentData contains the track 2data elements as definedin ISO/IEC 7813 asfollows:

• PAN, FieldSeparator(hex ‘D’),Expiration Date(YYMM),Service Code, CardVerification Code(CVC), and PINVerification Value(PVV) (if present)

• Issuer proprietarydiscretionary data(defined by individualpayment systems) isoptional;

• Start sentinel, endsentinel, and longitudinalredundancy check (LRC)shall be excluded.

The data included in theTrack 2 Equivalent Datamust be identical to thedata on the Track 2 ofthe magnetic stripeexcept for the Issuerproprietary DiscretionaryData. (CRF003.6

ICC var. up tocn 37

‘57’ var.up to19

Pad with hex ‘F’ ifneeded to ensure wholebytes

TransactionCertificate (TC)

Application cryptogramcomputed by the card foran approved financialtransaction.

ICC b ‘9F29’ 8

TransactionCertificate (TC)Hash Value

Results of a hashfunction

Terminal

b ‘98’ 8-20

TransactionCertificate DataObject List(TDOL)

List of data objects (tagand length) to be used bythe terminal ingenerating the TC Hash

ICC b ‘97’ var.up to252

Not used in thisspecification

Page 166: MasterCard ICC

Data Specification of EMV ‘96 ICC Specification for Payment Systems Transactions3.1 Data Elements and Files

ICC Application Specification © 1998 MasterCard International IncorporatedNovember 19983-28

Name Description Source Format Tag Length ValuesValue

TransactionCurrency Code

Indicates the currencycode of the transactionaccording to ISO 4217.The implied exponent isindicated by the minorunit of currencyassociated with theTransaction CurrencyCode in ISO 4217.

Terminal

n 3 ‘5F2A’ 2

Transaction Date Local date that thetransaction wasauthorized.

Terminal

n 6YYMMDD

‘9A’ 3

TransactionPersonalIdentificationNumber (PIN) Data

Data entered by thecardholder for the purposeof PIN verification

Terminal cn ‘99’ 8

TransactionReference CurrencyCode

Code defining the commoncurrency used by theterminal in case theTransaction Currency codeis different from theApplication Currency Code.

Terminal n 3 ‘9F3C’ 2

Transaction StatusInformation

Indicates the functionsperformed in a transaction

Terminal b ‘9B’ 2 Byte 1bit 8: 1 = Offline Dataauthentication wasperformedbit 7: 1 = Cardholderverification wasperformedbit 6: 1 = Card riskmanagement wasperformedbit 5: 1 = Issuerauthentication wasperformedbit 4: 1 = Terminal riskmanagement wasperformedbit 3: 1 = Scriptprocessing wasperformedbit 2-1 = RESERVED

Byte 2

Page 167: MasterCard ICC

Data Specification of EMV ’96 ICC Specification for Payment Systems Transactions3.1 Data Elements and Files

ICC Application SpecificationNovember 1998

3-29

Name Description Source Format Tag Length Valuesbit 8-1 = RESERVED

Transaction Time Local time that thetransaction was authorized

Terminal n 6HHMMSS

‘9F21’ 3

Transaction Type Indicates the type offinancial transaction,represented by the firsttwo digits of ISO8583:1987 ProcessingCode

Terminal

n 2 ‘9C’ 1

UnpredictableNumber

Value to providevariability anduniqueness to thegeneration of theapplication cryptogram.

Terminal

b ‘9F37’ 4

Upper ConsecutiveOffline Limit

Issuer-specified preferencefor the maximum number ofconsecutive offlinetransactions for this ICCapplication allowed in aterminal without onlinecapability

ICC b ‘9F23’ 1

When the length defined for the data object is greater than the length of the actual data, thefollowing rules apply:

• A data element in format n is right-justified and padded with leading hexadecimal zeroes• A data element in format cn is left justified and padded with trailing ‘F’• A data element in format an is left-justified and padded with trailing hexadecimal zeroes• A data element in format ans is left-justified and padded with trailing hexadecimal zeroes

Page 168: MasterCard ICC

Data Specification of EMV ‘96 ICC Specification for Payment Systems Transactions3.1 Data Elements and Files

ICC Application Specification © 1998 MasterCard International IncorporatedNovember 19983-30

3.1.3 MasterCard proprietary data elements

Table 3.3 gives the MasterCard proprietary data elements to support a MasterCardimplementation.

TABLE 3.3: MASTERCARD PROPRIETARY DATA ELEMENTS

Name Description Source Format Length Values

ApplicationControl

Stores control ofapplication(resetting ofparameters, scriptcontrol)

ICC b 1 Could be used for indicating whether

• the End Of Script is supported

• resetting of internal parameters isallowed when Issuer AuthenticationData is not present (RIP)

• domestic requirements

ApplicationFlag

Stores status ofapplication in non-volatile memory

ICC b Complete with list of Volume I

AuthorizationResponseCryptogram(ARPC)

Value computedby the issuer hostfor online hostauthentication;first 8 bytes of theIssuerAuthenticationData

Issuer b 8 See 2.5

Card IssuerActionCode—Decline

EPI/MCIproprietary dataelement indicatingthe Issuer’sconditions thatcause the ICC todecline atransactionwithout attemptingto go online.

ICC b 3 Byte 1:bits 8-7: 00bits 6-5: 00bit 4: 0bit 3: 0bit 2: 1 = Offline PIN verification failedbit 1: 0

Byte 2:bit 8: 1 = Last online transaction notcompletedbit 7: 1 = PIN Try Limit exceededbit 6: 1 = Exceeded velocity checkingbit 5: 0bit 4: 1 = Issuer authentication failure onlast online transaction

Page 169: MasterCard ICC

Data Specification of EMV ’96 ICC Specification for Payment Systems Transactions3.1 Data Elements and Files

ICC Application SpecificationNovember 1998

3-31

Name Description Source Format Length Valuesbit 3: 1 = Issuer authentication notperformed after online authorizationbit 2: 1 = Application blocked by cardbecause PIN Try Limit exceededbit 1: 1 = Static data authentication failedon last transaction and transaction declinedoffline

Byte 3:bits 8-6: 000bit 5: 1 = DDA failed on last offlinetransaction and transaction declinedoffline.bit 4: 1= Issuer Script processing failed onlast transactionbit 3: 1 = Lower Consecutive Offline Limitor Lower Cumulative Offline TransactionAmount Exceededbit 2: 1 = Upper Consecutive Offline Limitor Upper Cumulative Offline TransactionAmount Exceededbit 1: 1 = Maximum Offline transactionamount exceeded

Card IssuerActionCode—Offline

EPI/MCIproprietary dataelement indicatingthe Issuer’sconditions thatcause the ICC todecline atransaction in anoffline transactionterminal.

ICC b 3 Byte 1:bits 8-7: 00bits 6-5: 00bit 4: 0bit 3: 0bit 2: 1 = Offline PIN verification failedbit 1: 1 = Unable to go online

Byte 2:bit 8: 1 = Last online transaction notcompletedbit 7: 1 = PIN Try Limit exceededbit 6: 1 = Exceeded velocity checkingbit 5: 1 = New Cardbit 4: 1 = Issuer authentication failure onlast online transactionbit 3: 1 = Issuer authentication notperformed after online authorizationbit 2: 1 = Application blocked by cardbecause PIN Try Limit exceededbit 1: 1 = Static data authentication failedon last transaction and transaction declinedoffline

Page 170: MasterCard ICC

Data Specification of EMV ‘96 ICC Specification for Payment Systems Transactions3.1 Data Elements and Files

ICC Application Specification © 1998 MasterCard International IncorporatedNovember 19983-32

Name Description Source Format Length Values

Byte 3:bits 8-6: 000bit 5: 1 = DDA failed on last offlinetransaction and transaction declinedoffline.bit 4: 1 = Issuer Script processing failed onlast transactionbit 3: 1 = Lower Consecutive Offline Limitor Lower Cumulative Offline TransactionAmount Exceededbit 2: 1 = Upper Consecutive Offline Limitor Upper Cumulative Offline TransactionAmount Exceededbit 1: 1 = Maximum Offline transactionamount exceeded

Byte 3:bit 3: 1 = Lower Consecutive Offline Limitor Lower Cumulative Offline TransactionAmount Exceededbit 1: 1 = Maximum Offline transactionamount exceeded

Card IssuerActionCode—Online

EPI/MCIproprietary dataelement indicatingthe conditions thatcause a transactionto be completedonline accordingto the issuer and inan online capabletransactionterminal.

ICC b 3 Byte 1:bits 8-7: 00bits 6-5: 00bit 4: 0bit 3: 0bit 2:1 = Offline PIN verification failedbit 1: 0

Byte 2:bit 8: 1 = Last online transaction notcompletedbit 7: 1 = PIN Try Limit exceededbit 6: 1 = Exceeded velocity checkingbit 5: 1 = New Cardbit 4: 1 = Issuer authentication failure onlast online transactionbit 3: 0bit 2: 1 = Application blocked by cardbecause PIN Try Limit exceededbit 1: 1 = Static data authentication failedon last transaction and transaction declinedoffline

Byte 3:

Page 171: MasterCard ICC

Data Specification of EMV ’96 ICC Specification for Payment Systems Transactions3.1 Data Elements and Files

ICC Application SpecificationNovember 1998

3-33

Name Description Source Format Length Valuesbits 8-6: 000bit 5: 1 = DDA failed on last offlinetransaction and transaction declinedoffline.bit 4: 1 = Issuer cript processing failed onlast transactionbit 3: 1 = Lower Consecutive Offline Limitor Lower Cumulative Offline TransactionAmount Exceededbit 2: 1 = Upper Consecutive Offline Limitor Upper Cumulative Offline TransactionAmount Exceededbit 1: 1 = Maximum Offline transactionamount exceeded

Card TVRAction Code

MCI/EPIproprietary dataelement indicatingthe Issuer’sselected actionsbased upon thecontent of theTerminalVerificationResults bits

ICC b 5 Byte 1:bit 8: 1 = Data authentication was notperformedbit 7: 1 = Static data authentication failedbit 6: 1 = ICC data missingbit 5: 1 = Card appears on terminalexception listbit 4: 1 = Dynamic data authenticationfailedbit 3-1 = RESERVED

Byte 2:bit 8: 1 = ICC and terminal have differentapplication versionsbit 7: 1 = Expired applicationbit 6: 1 = Application not yet activebit 5: 1 = Requested service not allowed forcard productbit 4: 1 = New cardbit 3-1 = RESERVED

Byte 3:bit 8: 1 = Cardholder verification was notsuccessfulbit 7: 1 = Unrecognized CVMbit 6: 1 = PIN try limit exceededbit 5: 1 = PIN entry required, PIN pad notpresent or not workingbit 4: 1 = PIN entry required, PIN padpresent, PIN not enteredbit 3: 1 = Online PIN enteredbit 2-1 = RESERVED

Page 172: MasterCard ICC

Data Specification of EMV ‘96 ICC Specification for Payment Systems Transactions3.1 Data Elements and Files

ICC Application Specification © 1998 MasterCard International IncorporatedNovember 19983-34

Name Description Source Format Length Values

Byte 4:bit 8: 1 = Transaction exceeds floor limitbit 7: 1 = Lower Consecutive Offline limitexceededbit 6: 1 = Upper Consecutive Offline limitexceededbit 5: 1 = Transaction selected randomlyfor online processingbit 4: 1 = Merchant forced the transactiononlinebit 3-1 = RESERVED

Byte 5:bit 8: 1 = Default TDOL usedbit 7: 1 = Issuer authentication wasunsuccessfulbit 6: 1 = Script processing failed beforefinal GENERATE ACbit 5: 1 = Script processing failed afterfinal GENERATE ACbit 4-1 = RESERVED

CardVerificationResults

Data elementindicating theexceptionconditions thatoccurred duringcard riskmanagement.

Transmitted to theterminal in IssuerApplication Data.

ICC b 4 Byte 1: Length indicator (‘03’)

Byte 2:bits 8-7: 00 = AAC returned in secondGENERATE AC

01 = TC returned in second GENERATE AC10 = Second GENERATE AC not requested11 = RESERVED

bits 6-5: 00 = AAC returned in first GENERATE AC01 = TC returned in first GENERATE AC10 = ARQC returned in first GENERATE11 = RESERVED

bit 4: 1 =Issuer authentication failedbit 3: 1 =Offline PIN verificationperformedbit 2: 1 =Offline PIN verification failedbit 1: 1 =Unable to go online

Page 173: MasterCard ICC

Data Specification of EMV ’96 ICC Specification for Payment Systems Transactions3.1 Data Elements and Files

ICC Application SpecificationNovember 1998

3-35

Name Description Source Format Length Values

Byte 3:bit 8: 1 =Last online transaction notcompletedbit 7: 1 =PIN Try Limit exceededbit 6: 1 =Exceeded velocity checkingbit 5: 1 =New Cardbit 4: 1 =Issuer authentication failureon last online transactionbit 3: 1 =Issuer authentication notperformed after online authorizationbit 2: 1 =Application blocked by cardbecause PIN Try Limit exceededbit 1: 1 =Static data authenticationfailed on last transaction and transactiondeclined offline

Byte 4:bits 8-6: Number of Issuer ScriptCommands containing secure messagingprocessed on last transactionbit 5: 1 =DDA failed on last onlinetransaction and transaction declinedoffline.bit 4: Issuer Script processing failed onlast transactionbit 3: 1 =Lower Consecutive Offline

Limit or Lower Cumulative Offline Transaction Amount Exceeded

bit 2: 1 =Upper Consecutive Offline Limit or Upper Cumulative Offline Transaction Amount Exceeded

bit 1: 1 =Maximum Offline transactionamount exceeded

Note: If only one GENERATE ACcommand is issued for a transaction, byte2, bits 6-5 shall indicate that a TC or AACis returned in the first GENERATE ACcommand and bits 8-7 shall be indicatethat a second GENERATE AC commandwas not requested.

Page 174: MasterCard ICC

Data Specification of EMV ‘96 ICC Specification for Payment Systems Transactions3.1 Data Elements and Files

ICC Application Specification © 1998 MasterCard International IncorporatedNovember 19983-36

Name Description Source Format Length Values

CertificationAuthorityPublic KeyModulus

Part of the RSACertificationAuthority PublicKey

CryptogramVersionNumber

Data elementindicating theversion of the TC,AAC or ARQCalgorithm used bythe application.

ICC b 1 Transmitted in the Issuer ApplicationData.

CumulativeOfflineTransaction

MCI/EPIproprietary dataelement indicatingthe ICC internalcounteraccumulating theconsecutive offlineapproved paymenttransactionamounts.

ICC n 6

HashAlgorithmIndicator

Algorithm used tocompress dataprior to signing.

ICC 1 Value is ‘01’ for SHA-1

ICC PINEnciphermentPrivate Key

ICC private key toverify theenciphered offlinePIN

80 = NPE

< NI

ICC PINEnciphermentPublic KeyModulus

Part of the RSAICC Public Keyused for offlinePIN encipherment

80 = NPE

< NI

ICC PrivateKey

ICC private key usedfor creating theSigned DynamicApplication Data (orverifying theenciphered offlinePIN)

80 = NIC

< NI

The memory occupied is implementationdependent. For an implementation basedon the Chinese Remainder theorem, thememory required is 5Nic/2. For animplementation based on standardexponentiation the memory required is2Nic.

ICC PublicKey Modulus

Part of the RSApublic key used forDDA

80 = NIC

< NI

Can also be used for enciphered offlinePIN verification is no dedicated key pair ispresent for that purpose.

Page 175: MasterCard ICC

Data Specification of EMV ’96 ICC Specification for Payment Systems Transactions3.1 Data Elements and Files

ICC Application SpecificationNovember 1998

3-37

Name Description Source Format Length Values

IntegratedCircuit Card(ICC)DynamicData

Part of the digitalsignaturegenerated by theICC with the ICCprivate key oncritical applicationparameters

ICC var. LDD <

Nic-25For this specification the ICC DynamicData is limited to the concatenation of hex‘08’ and an ICC Dynamic Number

IssuerAuthenticationResponse Code

Response Code inIssuerAuthenticationData used tovalidate ARPC

Issuer an 2 2 Values ‘00’, ‘01’ and ‘08’ are consideredas approval.

Issuer PublicKey Modulus

Part of the RSAIssuer Public Key

80 = NI

< NCA

Issuer ScriptCommandCounter

This ScriptCounter isincremented aftereach scriptprocessingcommandperformedsuccessfully.

ICC b 1 It is reset during the second Generate ACafter a successful Issuer Authentication ifno critical script (‘71’) has been performedduring the current transaction.

KeyDerivationIndex

Index of the keyused inApplicationCryptogram

ICC b 1 Value assigned by the Issuer/paymentsystem

LowerCumulativeDomesticOfflineTransactionAmount

MCI/EPIproprietary dataelement indicatingthe lowermaximum valuewhich the ‘OfflineCumulativeTransactionAmount’ canreach. Once thisvalue is exceeded,the paymenttransaction willseek onlineauthorization.

ICC n 6

Page 176: MasterCard ICC

Data Specification of EMV ‘96 ICC Specification for Payment Systems Transactions3.1 Data Elements and Files

ICC Application Specification © 1998 MasterCard International IncorporatedNovember 19983-38

Name Description Source Format Length Values

MaximumDomesticOfflineTransactionAmount

MCI/EPIproprietary dataelement indicatingthe maximumtransactionamount. Once thisvalue is exceeded,the paymenttransaction willseek onlineauthorization.

ICC n 6

MKAC ICC Master keyfor Cryptogramcalculation andIssuerAuthentication

ICC b 16 The Issuer Master-keys IMK from whichthe ICC Master keys MK are derived, arenot stored in the card. (CRF004.9)

MKIDN ICC Master keyfor the Generationof the ICCDynamic Number

ICC b 16

MKSMC ICC Master keyfor Securemessaging forConfidentiality

ICC b 16

MKSMI ICC Master keyfor Securemessaging forIntegrity

ICC b 16

NonDomesticControlFactor

MCI/EPIproprietary dataelement. A npower of 2 used todivide themaximumconsecutive nondomestictransactions

ICC b 1 The Non Domestic Control Factor can beimplemented easily as NDCF = 2^n

PIN TryLimit

MCI/EPI proprietarydata elementindicating themaximum number ofconsecutive wrongPIN entries.

ICC b 1

Page 177: MasterCard ICC

Data Specification of EMV ’96 ICC Specification for Payment Systems Transactions3.1 Data Elements and Files

ICC Application SpecificationNovember 1998

3-39

Name Description Source Format Length Values

ReferenceCurrencyConversionTable

MCI/EPIproprietary dataelement whichcontains referencecurrency codes,conversion ratesand the exponentsfor currencyconversion

ICC b up to 20 Byte 1-2: Reference Currency Code

Byte 3-4: Reference Currency to Application Currency Conversionrate

Byte 5: Reference Currency to Application Currency Conversion rate exponent

ReferencePersonalIdentificationNumber(PIN)

MCI/EPIproprietary dataelement indicatingthe PIN which isstored in the ICC,and against whichthe transactionPIN is verified.

ICC n var. The PIN is 4 to12 digits long.

UpperCumulativeDomesticOfflineTransactionAmount

MCI/EPIproprietary dataelement indicatingthe uppermaximum valuewhich the ‘OfflineCumulativeTransactionAmount’ canreach. Once thisvalue is exceeded,the paymenttransaction willseek onlineauthorization or bedeclined.

ICC n 6

Page 178: MasterCard ICC

Data Specification of EMV ‘96 ICC Specification for Payment Systems Transactions3.2 Updating Card Risk Management Data

ICC Application Specification © 1998 MasterCard International IncorporatedNovember 19983-40

3.2 UPDATING CARD RISK MANAGEMENT DATA

Issuers may define any card risk management function within their ICC that they choose andimplement it in cooperation with their chosen card vendor(s).

The data elements which set the risk management boundaries are provided in Table 3.4. The dataelements other than the ATC, and last online ATC, may be updated at the option of the issuerduring the life of the ICC by using a script processing command.

The ATC and last online ATC can only be updated by the ICC internally.

TABLE 3.4: CARD RISK MANAGEMENT DATA (PSMXXX)

Value Tag

ATC ‘9F36’

Last Online ATC ‘9F13’

CIAC – Decline —

CIAC – Offline —

CIAC – Online —

Card TVR Action Code —

Lower Consecutive Offline Limit ‘9F14’

Upper Consecutive Offline Limit ‘9F23’

Maximum Domestic Offline Transaction Amount —

Lower Cumulative Domestic Offline Amount —

Upper Cumulative Domestic Offline Amount —

Non Domestic Control Factor —

Reference Currency Conversion Table —

Page 179: MasterCard ICC

Data Specification of EMV’96 ICC Specification for Payment Systems Transactions3.3 Card Risk Management Data Object List

ICC Application SpecificationNovember 1998

3-41

3.3 CARD RISK MANAGEMENT DATA OBJECT LIST

The ICC's CDOL1 and CDOL2 contain the tags and lengths for the concatenated data objects tobe transmitted from the terminal to the ICC in the GENERATE AC command. Part of the cardrisk management is based on these data elements and a part of these data will be included in theApplication Cryptogram (see Section 2.4).

Issuers can easily check that a terminal has performed the Card Authentication process byrequesting from the terminal, in CDOL1 or CDOL2, data retrieved from the terminal whenperforming card authentication, and inserting this data in the Issuer Application Data. For StaticData Authentication this data is the Data Authentication Code (DAC). For Dynamic DataAuthentication this data is the (first two bytes of the) ICC Dynamic Number.

3.3.1 Card Risk Management Data Object List 1

A recommended list of data elements that may be used in the CDOL1 is as shown in Table 3.5.

TABLE 3.5: RECOMMENDED CDOL1 DATA OBJECT

Value Tag

Amount, Authorized ’9F02’

Amount, Other ’9F03’

Terminal Country Code ’9F1A’

Terminal Verification Results ’95’

Transaction Currency Code ’5F2A’

Transaction Date ’9A’

Transaction Type ’9C’

Unpredictable Number ’9F37’

Terminal Type ’9F35’

Amount in Reference Currency ’9F3A’

Transaction Reference Currency Code ’9F3C’

ICC Dynamic Number ’9F4C’

Data Authentication Code ’9F45’

Page 180: MasterCard ICC

Data Specification of EMV’96 ICC Specification for Payment Systems Transactions3.3 Card Risk Management Data Object List

ICC Application Specification © 1998 MasterCard International IncorporatedNovember 19983-42

3.3.2 Card Risk Management Data Object List 2

A recommended list of data elements in CDOL2 is indicated in Table 3.6:

TABLE 3.6: RECOMMENDED CDOL2 DATA OBJECTS

Value Tag

Issuer Authentication Data ’91’

Authorization Response Code ’8A’

Terminal Verification Results ’95’

• As indicated before, only Authorization Response Code and TVR are mandatory since otherdata elements could be retained from CDOL1.

• The Issuer Authentication Data (tag “91”) is only indicated in CDOL2 if Issuer Authenticationis done in the 2nd GENERATE AC and not by means of an EXTERNAL AUTHENTICATEcommand.

• The Authorization Response Code is not used in cryptogram generation but is used by theICC in completion processing. In this process the ICC verifies the Authorization Code toascertain whether the transaction succeeded in going online or not.

If the other data elements are not retained from the CDOL1, they can be added to CDOL2.

Page 181: MasterCard ICC

Data Specification of EMV’96 ICC Specification for Payment Systems Transactions3.3 Card Risk Management Data Object List

ICC Application SpecificationNovember 1998

3-43

A list of data elements that can be added to the CDOL2 is as shown in Table 3.5.

TABLE 3.5: ADDITIONAL CDOL2 DATA OBJECTS

Value Tag

Amount, Authorized ’9F02’

Amount, Other ’9F03’

Terminal Country Code ’9F1A’

Transaction Currency Code ’5F2A’

Transaction Date ’9A’

Transaction Type ’9C’

Unpredictable Number ’9F37’

ICC Dynamic Number ’9F35’

Data Authentication Code ’9F3A’

Page 182: MasterCard ICC

Data Specification of EMV’96 ICC Specification for Payment Systems Transactions3.4 Card Life Cycle Data

ICC Application Specification © 1998 MasterCard International IncorporatedNovember 19983-44

3.4 CARD LIFE CYCLE DATA

Card Life Cycle Data (CLCD) can be used by the Issuer for management of the ICC when thespecification is implemented. The format and content of the Card Life Cycle Data is under thecontrol of the Application Provider, and the Card Manufacturer. If the Application Providerwants to delegate part of the ICC management to the Payment System, the Payment System willbe involved also.

Page 183: MasterCard ICC

Appendix A— Network Data Element Requirements

ICC Application SpecificationNovember 1998

A-i

APPENDIX A NETWORK DATA ELEMENT REQUIREMENTS

Network Data Element Requirements........................................A-1

Page 184: MasterCard ICC
Page 185: MasterCard ICC

Appendix A— Network Data Element Requirements

ICC Application SpecificationNovember 1998

A-1

NETWORK DATA ELEMENT REQUIREMENTS

EMV ’96 Integrated Circuit Card Terminal Specification for Payment Systems, Version 3.1.1describes message content requirements associated with ICC transactions and chip data elements.

This annex summarizes by message the list of new data elements that the Acquirer is to pass tothe Issuer. Some of these data elements may not be provided/requested by the ICC or the Issuer,however the acquirer should support them and pass them when present. Data element 55 hasbeen established for these chip data in the Authorization Messages.

Table A.1 lists the data elements that should be supported by acquirer for authorization request.

Table A.2 lists the data elements that should be supported by acquirer for authorization response.

Table A.3 lists the data elements that should be supported by acquirer in clearing message.

Page 186: MasterCard ICC

Appendix A— Network Data Element Requirements

ICC Application Specification © 1998 MasterCard International IncorporatedNovember 1998A-2

TABLE A.1: CHIP DATA ELEMENTS IN AUTHORIZATION REQUEST MESSAGE

Field # Name Tag Format Length Usage

1 ApplicationCryptogram (ARQC)

‘9F26’ b 8 Allows Card Authentication processing

2 CryptogramInformation Data

‘9F27’ b 1 Indicates the type of cryptogram returned(approved, online or denied) by the card andthe actions to be performed by the terminal(Advice or not, reason for advice)

3 Issuer ApplicationData (IAD)

‘9F10’ b Var. up32

Provides data elements the Issuer has electedto have in the authorization message, forexample derivation key and algorithmversion numbers.

Present if provided by ICC in GENERATEAC command response.

4 UnpredictableNumber

‘9F37’ b 4 Provides variability and uniqueness of theARQC in order to reduce fraud risk.

Present if input to application cryptogramcalculation.

5 Applicationtransaction counter(ATC)

‘9F36’ b 2 Indicates sequential order of transactionperformed by the application. Providesvariability and uniqueness of ARQC in orderto reduce fraud risk

6 TerminalVerification Result

‘95’ b 5 Informs Issuer of the reason(s) thetransaction went online

7 Transaction Date ‘9A’ n 3 Indicates the date the transaction wasconducted and the authorization requested

8 Transaction Type ‘9C’ n 1 Indicates the transaction type used forapplication usage control

9 Amount Authorized ‘9F02’ n 6 Indicates the amount sent to the Issuer forauthorization

10 Transaction CurrencyCode

‘5F2A’ n 2 Indicates the currency code of themerchant/terminal associated with thetransaction

11 ApplicationInterchange Profile

‘82’ b 2 Indicates the specified chip applicationcapabilities

Page 187: MasterCard ICC

Appendix A— Network Data Element Requirements

ICC Application SpecificationNovember 1998

A-3

Field # Name Tag Format Length Usage

12 Terminal CountryCode

‘9F1A’ n 2 Indicates the country code of themerchant/terminal associated with thetransaction

13 Amount Other ‘9F03’ n 6 Indicates the cashback amount sent to theIssuer for authorization.

Present if cashback used for currenttransaction.

It is assumed that Track2 Equivalent Data (PAN, PAN Sequence Number and expiration date) arealready present in Authorization Message.

Table A.2: Chip Data Elements in Authorization Request Response Message

Field # Name Tag Format Length Usage

1 Issuer AuthenticationData

‘91’ b Var 8 to16

Provide data to be transmitted to the cardfor Issuer authentication

2 • Issuer ScriptTemplate 1

• Issuer ScriptTemplate 2

‘71’

‘72’

b Var up128

Allows the Issuer to provide a commandfor transmission to the card.

Present if commands to ICC are sent byissuer.

Acquirer network shall support aminimum of 24 Bytes

Page 188: MasterCard ICC

Appendix A— Network Data Element Requirements

ICC Application Specification © 1998 MasterCard International IncorporatedNovember 1998A-4

TABLE A.3: CHIP DATA ELEMENTS IN CLEARING MESSAGE

Field#

Name Tag Format Length Usage

1 ApplicationCryptogram(TC/ARQC orAAC)

‘9F26’ b 8 Allows authentication of transaction data insupport of chargeback processing, for singlemessage terminal ARQC may be used as TCsubstitute

2 CryptogramInformation Data

‘9F27’ b 1 Indicates the type of cryptogram returned(approved, online or denied) by the card and theactions to be performed by the terminal (Adviceor not, reason for advice)

3 Issuer ApplicationData (IAD)

‘9F10’ b Var. up32

Provides data elements the Issuer has elected tohave in the authorization message such asderivation key and algorithm version numbers.

Present if provided by ICC in GENERATE ACcommand response.

4 UnpredictableNumber

‘9F37’ b 4 Provides variability and uniqueness of theapplication cryptogram in order to reduce fraudrisk.

Present if input to application cryptogramcalculation.

5 Applicationtransaction counter(ATC)

‘9F36’ b 2 Indicates sequential order of transactionperformed by the application. Providesvariability and uniqueness of the applicationcryptogram in order to reduce fraud risk

6 TerminalVerification Result

‘95’ b 5 Informs Issuer of the results of transactionprocessing performed by the terminal and may beused for dispute management

7 Transaction Date ‘9A’ n 3 Indicates the date the transaction was conducted

8 Transaction Type ‘9C’ n 1 Indicates the type of transaction conducted by thecardholder

9 AmountAuthorized

‘9F02’ n 6 Indicates the amount authorized for thetransaction and used to generate the applicationcryptogram). This amount may be different fromthe transaction amount

10 TransactionCurrency Code

‘5F2A’ n 2 Indicates the currency code associated with thetransaction

11 ApplicationInterchange Profile

‘82’ b 2 Indicates the specified chip applicationcapabilities

Page 189: MasterCard ICC

Appendix A— Network Data Element Requirements

ICC Application SpecificationNovember 1998

A-5

Field#

Name Tag Format Length Usage

12 Terminal CountryCode

‘9F1A’ n 2 Indicates the country code of themerchant/terminal associated with thetransaction. Provides liability protection

13 Amount Other ‘9F03’ n 6 Indicates the cashback amount sent to the Issuerfor authorization.

Present if cashback used for current transaction

It is assumed that Track2 Equivalent Data (PAN, PAN Sequence Number and expiration date) arealready present in Clearing Message.

Page 190: MasterCard ICC
Page 191: MasterCard ICC

Appendix B— Digital Signature Scheme Giving Message Recovery

ICC Application SpecificationNovember 1998

B-i

APPENDIX B DIGITAL SIGNATURE SCHEME GIVING MESSAGERECOVERY

B.1 Overview........................................................................... B-1B.2 Signature Generation ......................................................... B-1B.3 Signature Verification........................................................ B-3

Page 192: MasterCard ICC
Page 193: MasterCard ICC

B.1 Digital Signature Scheme Giving Message RecoveryB.1 Overview

ICC Application SpecificationNovember 1998

B-1

B.1 OVERVIEW

This section describes the digital signature scheme giving message recovery using a hash functionaccording to ISO/IEC CD 9796-2. The main features of the scheme are the following.

• Adding of redundancy in the signature by applying a hash function to the data to be signed

• Adding of a header and trailer byte to obtain a unique recovery procedure and to preventcertain attacks

The scheme uses the following two algorithms:

• The reversible asymmetric algorithm RSA/Rabin as specified in Appendix C, consisting of asigning function Sign(SK)[ ] depending on a Private Key SK and a recovery functionRecover(PK)[ ] depending on a Public Key PK. Both functions map N-byte numbers onto N-byte numbers and have the property that

Recover(PK)[Sign(SK)[X]] = X,

for any N-byte number X.

• The secure hash function SHA-1 as specified in Appendix C, that maps a message M ofarbitrary length onto an 20-byte hash code H:

H: = SHA(M)In the following two sections the signature generation and verification process is described.

B.2 SIGNATURE GENERATION

The computation of a signature S on a message M, consisting of an arbitrary number L of bytes,takes place in the following way:

CASE 1: The length L of the message to be signed is at most N − 22 bytes

1. Compute the 20-byte hash value H: = SHA[M] of the message M

Page 194: MasterCard ICC

B.1 Digital Signature Scheme Giving Message RecoveryB.2 Signature Generation

ICC Application Specification © 1998 MasterCard International IncorporatedNovember 1998B-2

2. Define the (N – 21 – L)-byte block B as follows:

B: = ‘4A’ if L = N – 22,

B: = (‘4B’ || ‘BB’ || ‘BB’ || . . . || ‘BB’ || ‘BA’) if L < N – 22

3. Define the byte E: = ‘BC’.

4. Define the N-byte block X as the concatenation of the blocks B, M, H and E, hence

X: = (B || M || H || E)

5. The digital signature is then defined as the N-byte number

S: = Sign(SK)[X]

CASE 2: The length L of the message to be signed is larger than N − 22 bytes

1. Compute the 20-byte hash value H: = SHA[M] of the message M.

2. Split M into two parts M = (M1 || M2), where M1 consists of the N – 22 leftmost (mostsignificant bytes) of M and M2 of the remaining (least significant) L – N + 22 bytes of M.

3. Define the byte B: = ‘6A’.

4. Define the byte E: = ‘BC’.

5. Define the N-byte block X as the concatenation of the blocks B, M1, H and E, hence

X: = (B || M1 || H || E)

6. The digital signature S is then defined as the N-byte number

S: = Sign(SK)[X]

Page 195: MasterCard ICC

B.1 Digital Signature Scheme Giving Message RecoveryB.3 Signature Verification

ICC Application SpecificationNovember 1998

B-3

B.3 SIGNATURE VERIFICATION

Signature verification takes place in the following way:

CASE 1: The length L of the message signed is at most N – 22 bytes

1. Check whether the digital signature S consists of N bytes.

2. Retrieve the N-byte number X from the digital signature S:

X = Recover(PK)[S].

3. Partition X as X = (B || M || H || E), where– B = ‘4A’ or B is a leading byte-string of the form (‘4B’ || ‘BB’ || ‘BB’ || . . . || ‘BB’ ||

‘BA’). If none of these cases occur, the signature is rejected– H is 20 bytes long– E is one byte long– M consists of the remaining bytes

4. Check whether the byte E is equal to ‘BC’

5. Check whether H = SHA[M]

If and only if these checks are correct is the message accepted as genuine.

CASE 2: The length L of the message signed is larger than N – 22 bytes

1. Check whether the digital signature S consists of N bytes.

2. Retrieve the N-byte number X from the digital signature S:

X = Recover(PK)[S].

3. Partition X as X= (B || M1 || H || E), where– B is one byte long– H is 20 bytes long– E is one byte long– M1 consists of the remaining N – 22 bytes

4. Check whether the byte B is equal to ‘6A’

Page 196: MasterCard ICC

B.1 Digital Signature Scheme Giving Message RecoveryB.3 Signature Verification

ICC Application Specification © 1998 MasterCard International IncorporatedNovember 1998B-4

5. Check whether the byte E is equal to ‘BC’

6. Compute M = (M1 || M2) and check whether H = SHA[M].

If and only if these checks are correct is the message accepted as genuine.

Page 197: MasterCard ICC

Appendix C— Cryptographic Algorithms

ICC Application SpecificationNovember 1998

C-i

APPENDIX C CRYPTOGRAPHIC ALGORITHMS

C.1 DES and Triple-DES......................................................... C-1C.2 RSA/Rabin ........................................................................ C-2

C.2.1 Odd Public Key Exponent ......................................... C-3C.2.1.1 Keys................................................................. C-3C.2.1.2 Signing Function .............................................. C-3C.2.1.3 Recovery Function ........................................... C-3

C.2.2 Public Key Exponent 2.............................................. C-3C.2.2.1 Keys................................................................. C-3C.2.2.2 Signing Function .............................................. C-4C.2.2.3 Recovery Function ........................................... C-4

C.3 SHA-1............................................................................... C-5

Page 198: MasterCard ICC
Page 199: MasterCard ICC

Appendix C— Cryptographic AlgorithmsC.1 DES and Triple DES

ICC Application SpecificationNovember 1998

C-1

C.1 DES AND TRIPLE-DES

The Data Encryption Standard (DES) standardized in ISO 8731-1 and ISO 8372 is the blockcipher used for Application Cryptogram generation, Issuer Authentication and Secure Messaging.

More precisely, both single-DES and its triple-DES (DES3) version described below are used inthe session key derivation, MAC and encryption mechanisms described in Section 2.

The DES algorithm takes as input an 8-byte plain text block X and an 8-byte secret key K andproduces an 8-byte ciphertext block Y:

Y:= DES(K)[X]

Decryption is denoted as

X: = DES-1(K)[Y]

Triple DES encryption involves encrypting an 8-byte plain text block X in an 8-byte ciphertextblock Y with a double-length (16-byte) secret key K = (KL || KR) as follows:

Y: = DES3(K)[X] := DES(KL)[DES-1(KR)[DES(KL)[X]]]

Decryption takes place as follows:

X: = DES3-1(K)[Y]: = DES-1(KL)[DES(KR)[DES-1(KL)[Y]]]

Page 200: MasterCard ICC

Appendix C— Cryptographic AlgorithmsC.2 RSA/Rabin

ICC Application Specification © 1998 MasterCard International IncorporatedNovember 1998C-2

C.2 RSA/RABIN

The RSA algorithm and its Rabin variant with exponent 2 is the asymmetric reversiblecryptographic algorithm used in the digital signature scheme described in Annex B for Static andDynamic Data Authentication.

The RSA/Rabin algorithm produces a digital signature whose length equals the size of themodulus used. The lengths in bytes of the moduli and the values of the public exponents involvedin Static Data Authentication, Dynamic Data Authentication and PIN Encipherment are specifiedin Table C.1 and Table C.2. The bit length of all moduli shall be a multiple of 8, the leftmost bitof its leftmost byte being 1.

TABLE C.1: LENGTHS IN BYTES OF PUBLIC KEY MODULI

Description Length

Certification Authority Public Key Modulus 96 ≤ NCA ≤ 128

Issuer Public Key Modulus 80 ≤ NI < NCA

ICC Public Key Modulus 80 ≤ NIC < NI

ICC PIN Encipherment Public Key Modulus 80 ≤ NPE < NI

TABLE C.2: VALUES OF PUBLIC KEY EXPONENTS

Description Value

Certification Authority Public Key Exponent 2 or 3

Issuer Public Key Exponent 2 or 3 or 216 +1

ICC Public Key Exponent 2 or 3 or 216 +1

ICC PIN Encipherment Public Key Exponent 3 or 216 +1

The Public Key Algorithm Indicator for the RSA/Rabin algorithm shall be coded as hexadecimal‘01’.

The keys and signing and recovery functions for the RSA/Rabin algorithm are specified below.The cases for odd public key exponent and public key exponent equal to 2 are consideredseparately.

Page 201: MasterCard ICC

Appendix C— Cryptographic AlgorithmsC.2 RSA/Rabin

ICC Application SpecificationNovember 1998

C-3

C.2.1 Odd Public Key Exponent

C.2.1.1 Keys

The private key SK of the RSA digital signature scheme with an odd public key exponent econsists of two prime numbers p and q such that p – 1 and q – 1 are co-prime to e and a privateexponent d such that

ed ≡ 1 mod (p – 1)(q – 1).

The corresponding public key PK consists of the public key modulus n = pq and the public keyexponent e.

C.2.1.2 Signing Function

The signing function for RSA with an odd public key exponent is defined as

S = Sign(SK)[X]: = Xd mod n, 0 < X < n,

where X is the data to be signed and S the corresponding digital signature.

C.2.1.3 Recovery Function

The recovery function for RSA with an odd public key exponent is equal to

X = Recover(PK)[S]: = Se mod n.

C.2.2 Public Key Exponent 2

C.2.2.1 Keys

The private key SK of the Rabin variant of the RSA digital signature scheme with public keyexponent 2 consists of two prime numbers p and q such that p ≡ 3 mod 8 and q ≡ 7 mod 8 and aprivate exponent d equal to

d = (pq – p – q + 5)/8.

The corresponding public key PK consists of the public key modulus n = pq and the public keyexponent 2.

Page 202: MasterCard ICC

Appendix C— Cryptographic AlgorithmsC.2 RSA/Rabin

ICC Application Specification © 1998 MasterCard International IncorporatedNovember 1998C-4

C.2.2.2 Signing Function

The signing function for Rabin is defined as

S = Sign(SK)[X]: = Xd mod n, if the Jacobi symbol (X | n) = 1,

S = Sign(SK)[X]: = (X/2)d mod n, if the Jacobi symbol (X | n) = -1,

where X is the data to be signed and S the corresponding digital signature.

The data block X is a nonnegative integer less than n with the additional property that its leastsignificant byte is equal to ‘BC’. This is to ensure that the recovery process is unique. Note thatthis is always the case when RSA is used in the digital signature scheme described in Annex B.

C.2.2.3 Recovery Function

The recovery function for Rabin is as follows.

1. Compute Y: = Se mod n

2. The recovered data is obtained by one of the following casesa. If the least significant byte of Y is equal to ‘BC’, X: = Yb. If the least significant byte of 2Y is equal ‘BC’, X: = 2Yc. If the least significant byte of n – Y is equal to ‘BC’, X: = n – Yd. If the least significant byte of 2(n – Y) is equal to ‘BC’, X: = 2(n – Y)

+ If none of these cases occur, the signature shall be rejected

Page 203: MasterCard ICC

AppendixC.3 SHA-1

ICC Application SpecificationNovember 1998

C-5

C.3 SHA-1

The Secure Hash Algorithm (SHA-1) standardized in ISO/IEC 10118-3 and FIPS 180-1 is usedfor the generation of the TC Hash Value and in the digital signature scheme described in Annex Bfor Static and Dynamic Data Authentication. SHA-1 takes as input messages M of arbitrarylength and produces a 20-byte hash value H:

H: = SHA(M).

The Hash Algorithm Indicator for this hashing algorithm shall be coded as hexadecimal ‘01’.

Page 204: MasterCard ICC
Page 205: MasterCard ICC

Index

ICC Application SpecificationNovember 1998

Index-1

INDEX

The page references in this index reflect the pages where significantdescriptions or procedures begin. The page numbers separated by adash (-) refer to a section or appendix (before the dash) and a pagenumber within the section or appendix (after the dash). Forexample: 3-2 refers to section 3, page 2; A-4 refers to page 4 ofappendix A Page numbers in bold type refer to figures orillustrated text.

The following conventions are used:

• Entries are listed alphabetically, in word order

• Entries that are abbreviations have the full name following initalics

• See references are supplied from non-preferred to preferredterms

• See also references are supplied between related terms

NUMERICS

0 (empty) 1-60, PTC value of 1-16“1PAY.SYS.DDF01” 1-51st GENERATE AC. See first GENERATE AC processing2nd GENERATE AC. See second GENERATE AC processing

A

AA Amount Authorizedand cumulative offline amounts 1-29and currency conversion 1-30data element descriptions 3-8, A-2, A-4See also CRM processing

Page 206: MasterCard ICC

Index

ICC Application Specification © 1998 MasterCard International IncorporatedNovember 1998Index-2

AAC Application Authentication Cryptogramabout 1-17algorithm 2-31, 2-32checking during PIN change/unblock 1-60, 1-61data objects recommended for input 2-30EMV data element 3-8requesting 1-18setting 1-22, 1-41to decline transaction 1-1

abbreviations, list of 7ABF Application Blocked Flag 1-4AC. See Application Cryptogramsaction codes

card issuer 1-34, 1-35, 3-2card TVR 3-3, 3-33issuer 3-5, 3-18, 3-30

ADF Application Definition Fileapplication selection sets path to 1-5directory entry format 1-7response message data fields of 1-6

addresses, MasterCarde-mail 1, 13Member Services representative 13web site, ISO 12

AEFs Application Elementary Filesand application selection 1-5data element description 3-9

AFL Application File Locatordata element descriptions 1-10, 3-1, 3-9initiate application processing and 1-9, 1-12static data to be authenticated specified by 2-6

AIDs Application Identifierscoding of 1-6data element description 3-1in SDA Tag List 2-6

AIP Application Interchange Profiledata element descriptions 1-10, 3-1, 3-9, A-2, A-4in SDA Tag List 2-6initiate application processing and 1-9, 1-12Issuer Authentication and 1-37

algorithms. See cryptographic algorithms

Page 207: MasterCard ICC

Index

ICC Application SpecificationNovember 1998

Index-3

amountsAA (Amount Authorized) 1-29, 3-8, A-2, A-4EMV data elements 3-8maximum offline transaction 1-26offline cumulative 1-28other A-3, A-5See also CRM processing

an, data element format 3-29ans, data element format 3-29Application Authentication Cryptogram. See AACAPPLICATION BLOCK command 1-54, 1-55Application Blocked Flag (ABF) 1-4application blocking 1-54, 1-55

See also Script ProcessingApplication Control 3-1, 3-30Application Cryptograms

chip data elements in clearing message A-4data elements that may be included D-1defined 1-20first GENERATE AC processing used for demanding 1-17generating 2-29selection of data 2-29types of 1-17See also AAC; ARQC; cryptographic algorithms; TC

Application Currency Codecumulative amount check processing 1-28, 1-29currency conversion 1-30, 1-31data element descriptions 3-1, 3-8

Application Definition File. See ADFApplication Discretionary Data 3-1, 3-8Application Effective Date 3-1, 3-9Application Elementary Files. See AEFsApplication Expiration Date 3-1, 3-9Application File Locator. See AFLApplication Flag

data element descriptions 3-1, 3-30indicators used in 1-4keeps track of previous transactions 1-3script status in 1-4, 1-48

Application Identifiers. See AIDsApplication Interchange Profile. See AIPApplication Label 3-2, 3-10

Page 208: MasterCard ICC

Index

ICC Application Specification © 1998 MasterCard International IncorporatedNovember 1998Index-4

Application PAN Sequence NumberData Authentication Code generation 2-44data element descriptions 3-2, 3-10key derivation 2-42

Application Preferred Name 1-6, 3-10Application Primary Account Number (PAN)

Data Authentication Code generation 2-44data element descriptions 3-2, 3-10key derivation 2-42

Application Priority Indicator 1-6, 3-2, 3-10application selection

about 1-5coding of AIDs 1-6coding of Payment System’s Directory 1-7response messages 1-5, 1-6with/without cardholder confirmation 1-8See also payment functions, standard

Application Template 1-7, 3-2, 3-11Application Transaction Counter. See ATCAPPLICATION UNBLOCK command 1-56, 1-57

See also Script ProcessingApplication Usage Control 3-2, 3-11Application Version Number 3-2, 3-12ARPC Authorization Response Cryptogram

algorithm for double-length DES key 2-34data element description 3-30validation process for 2-33See also Issuer Authentication

ARQC Authorization Request Cryptogramabout 1-17algorithm 2-31, 2-32checking during

PIN change/unblock 1-60, 1-61second GENERATE AC processing 1-41Script Processing 1-50, 1-51

data element descriptions 3-12, A-2data elements recommended for input 2-30requesting 1-18setting 1-22TVR asks for 1-34when receiving Issuer Authentication 1-37

Page 209: MasterCard ICC

Index

ICC Application SpecificationNovember 1998

Index-5

ATC Application Transaction CounterApplication Cryptogram key derivation 2-31data element descriptions 3-2, 3-11, A-2, A-4defined 1-20difference between LATC 1-27See also CRM processing

audience of this manual 2authentication, issuer. See Issuer Authenticationauthentication, offline card 1-12

dynamic 1-4, 1-13static 1-4, 1-12

authentication, Public Key 2-16authorization

issuer 1-2offline 1-1, 1-2online 1-1, 1-2

Authorization Request Cryptogram. See ARQCauthorization request message, chip data elements in A-2authorization request response message, chip data elements in A-3Authorization Response Code

data element description 3-12in second GENERATE AC command 1-40, 1-41, 1-43

Authorization Response Cryptogram. See ARPC

B

blockingapplication 1-54, 1-55card 1-52, 1-53See also Script Processing

C

CA (Certification Authority) Private/Public keysDynamic Data Authentication 2-12, 2-13retrieval of 2-7, 2-16Static Data Authentication 2-2, 2-3See also certification

Page 210: MasterCard ICC

Index

ICC Application Specification © 1998 MasterCard International IncorporatedNovember 1998Index-6

Card Action Analysisdetailed descriptions 1-33, 1-43, 1-44during first GENERATE AC command 1-22during second GENERATE AC command 1-41transaction flow 1-2See also first GENERATE AC processing; payment

functions, standardcard authentication, offline 1-12

dynamic 1-4, 1-13static 1-4, 1-12

card blocking 1-52, 1-53See also Script Processing

Card Issuer Action Codes. See CIACsCard Life Cycle Data (CLCD) 3-44Card Risk Management data, updating 3-40

See also CRM processingCard Risk Management Data Object List. See CDOL1; CDOL2Card TVR Action Code 3-3, 3-33Card Verification Result. See CVRcardholder confirmation, application selection priority with/without

1-8Cardholder Name data elements 3-3, 3-13cardholder verification

about 1-1, 1-2Method List data element 3-13methods supported 1-13PIN verification 1-13See also payment functions, standard; verification

Cardholder Verification Methods. See CVMsCDOL1 Card Risk Management Data Object List 1

and Application Cryptograms 1-18, 1-19, 2-29data element descriptions 3-3, 3-13data elements recommended for 3-41data elements that can be put in AC D-1used with first GENERATE AC command 1-21

CDOL2 Card Risk Management Data Object List 2and Application Cryptograms 1-18, 2-29data element descriptions 3-3, 3-13data elements recommended for 3-42data elements that can be put in AC D-1used with second GENERATE AC command 1-40

Page 211: MasterCard ICC

Index

ICC Application SpecificationNovember 1998

Index-7

certificationOffline Card Authentication 1-12PIN encipherment 2-24, 3-4three-layer scheme (Dynamic Data Authentication) 2-12,

2-13two-layer scheme (Static Data Authentication) 2-2, 2-3See also keys and certificates

Certification Authority (CA) 2-3, 2-12See also CA Private/Public Keys

Certification Authority Public Key Exponent 2-13, C-2Certification Authority Public Key Index

data element descriptions 3-3, 3-15for retrieving CA Public Key 2-7, 2-16

Certification Authority Public Key Modulusdata element descriptions 3-36Dynamic Data Authentication 2-13RSA/Rabin algorithm lengths/values C-2

changing/unblocking PIN 1-60, 1-61See also Script Processing

chip card. See ICCchip data elements

in authorization request message A-2in authorization response message A-3in clearing message A-4See also data elements and files

CIACs Card Issuer Action Codesabout 1-34, 1-44data element descriptions 3-2, 3-30See also Card Action Analysis

CID Cryptogram Information Datafirst GENERATE AC command 1-20second GENERATE AC command 1-39

CLCD Card Life Cycle Data 3-44clearing message, chip data elements in A-4cn, data element format 3-29coding

application priority 1-8CDOL1 3-41CDOL2 3-42Payment System Application Identifiers (AIDs) 1-6Payment System’s Directory 1-7

Command Template 3-15

Page 212: MasterCard ICC

Index

ICC Application Specification © 1998 MasterCard International IncorporatedNovember 1998Index-8

commandsAPPLICATION BLOCK 1-54, 1-55APPLICATION UNBLOCK 1-56, 1-57EMV CARD BLOCK 1-52, 1-53END OF SCRIPT 1-49, 1-62EXTERNAL AUTHENTICATE 1-37, 1-41GENERATE AC 1-17, 1-39GET CHALLENGE 1-16, 2-28GET DATA 1-13, 1-14GET PROCESSING OPTIONS 1-9, 1-10INTERNAL AUTHENTICATE 1-13PIN CHANGE/UNBLOCK 1-60, 1-61PUT DATA 1-58READ RECORD 1-12, 2-3, 2-13rejected 1-15, 1-38, 1-50, 1-51, 1-53, 1-57, 1-59, 1-61,

1-62UPDATE RECORD 1-58, 1-59VERIFY 1-14

comments and suggestions 13completion. See Transaction Completionconfidentiality, Secure Messaging for 2-38confirmation, application selection priority with/without 1-8consecutive transactions, velocity checking 1-26, 1-27

See also CRM processingcounters

Application Transaction Counter (ATC) 1-20Last Online Application Transaction (LATC) 1-26, 1-27PIN Try Counter (PTC) 1-13Script Processing 1-48, 1-51See also ATC, LATC, PTC

CRM Card Risk Management processingcurrency conversion 1-30, 1-31detailed description 1-24during first GENERATE AC command 1-22maximum offline transaction amount 1-26new card 1-26offline cumulative amount 1-28, 1-29PIN verification status 1-25previous transaction status 1-25updating Card Risk Management data 3-40velocity checking, offline consecutive transactions 1-26See also CDOL1; CDOL2

Cryptogram Information Data

Page 213: MasterCard ICC

Index

ICC Application SpecificationNovember 1998

Index-9

data element descriptions 3-15, A-2, A-4first GENERATE AC command 1-20second GENERATE AC command 1-39

Cryptogram Version Number 3-3, 3-36cryptograms. See Application Cryptogramscryptographic algorithms C-1

AC, for double-length Session Key 2-32ARPC, for double-length DES Key 2-34DES/triple-DES C-1MAC, for double-length Session Key 2-37RSA/RABIN C-2SHA-1 C-5

cumulative amount, offlineabout 1-28, 1-29data element description 3-6See also CRM processing

Cumulative Offline Transaction 3-36currency conversion

detailed description 1-30, 1-31in cumulative amount check processing 1-29See also CRM processing

CVMs Cardholder Verification MethodsCVM List 3-13supported by ICC 1-13See also cardholder verification

CVR Card Verification Resultdata element description 3-34“new card” bit in 1-26resetting 1-22, 1-23, 1-45setting Application Cryptograms in 1-17, 1-18, 1-22, 1-41updating 1-36, 1-41verified against CIAC-Offline 1-45verified against CIAC-Online 1-35See also Card Action Analysis; CRM processing

Page 214: MasterCard ICC

Index

ICC Application Specification © 1998 MasterCard International IncorporatedNovember 1998Index-10

D

DAC Data Authentication Codedata element descriptions 3-3, 3-16defined 2-5generating 2-44

data authenticationData Authentication Codes, generation of 2-44Dynamic Data Authentication 2-12Static Data Authentication 2-2transaction flow 1-2See also individual index entries of above

Data Authentication Code. See DACdata elements and files 3-1

Card Risk Management data 3-40chip data elements A-2EMV data elements 3-8for AC (Application Cryptograms) D-1from GENERATE AC commands 1-19, 1-39management of 3-1MasterCard proprietary data elements 3-30network requirements A-1transaction flow 1-3See also chip data elements; data objects

data objectsAAC, ARQC, and TC 2-30dynamic data object list 2-21in cumulative amount function for payment transaction

1-30in currency conversion 1-32in Issuer Application Data 1-21in maximum offline consecutive transaction number check

1-28recommended CDOL1 3-41recommended CDOL2 3-42required for Dynamic Data Authentication 2-16required for retrieval of PIN encipherment Public Key

2-26required for Static Data Authentication 2-7signed (read only) 1-12with GET PROCESSING OPTIONS 1-9, 1-10See also data elements and files

Page 215: MasterCard ICC

Index

ICC Application SpecificationNovember 1998

Index-11

data specification of EMV ’96 3-1Card Life Cycle Data 3-44Card Risk Management Data Object List 3-41data elements and files 3-1updating Card Risk Management data 3-40See also CDOL1; CDOL2

DDF Directory Definition Filename, data element 3-3, 3-16PSE begins with 1-7

DDOL (Dynamic Data Authentication Data Object) 3-3, 3-16deciphering PIN 1-16, 1-60, 1-61declined transactions

about 1-1Card Issuer Action Code 1-34, 1-44indicated in Sequence Flag 1-37See also AAC; Card Action Analysis; rejected

commands/transactionsdecryption, DES 2-38, C-1

See also DES keyDedicated File. See DFDES key

double-length, ARPC algorithm for 2-34encryption mechanism used for Secure Messaging for

confidentiality 2-38single, cryptographic algorithm for C-1triple, cryptographic algorithm for C-1

DF Dedicated Filename, data element descriptions 3-3, 3-16name, data field returned in response message 1-5, 1-6

digital signature schemebased on Public Key techniques 1-12detailed description B-1

Directory Definition File. See DDFDirectory, Payment Systems 1-7double-length DES Key ARPC algorithm 2-34double-length Session Keys

AC algorithm 2-32MAC algorithm 2-37

Page 216: MasterCard ICC

Index

ICC Application Specification © 1998 MasterCard International IncorporatedNovember 1998Index-12

Dynamic Data Authentication 2-12data objects required for Public Key authentication 2-16DDOL (Dynamic Data Authentication Data Object)

3-3, 3-16ICC Public Key data to be signed by issuer 2-15Issuer Public Key data to be signed by Certification

Authority 2-14keys and certificates 2-12, 2-13offline card authentication 1-4, 1-13retrieval of CA Public Key 2-16retrieval of ICC Public Key 2-18retrieval of Issuer Public Key 2-16signature generation 2-20signature verification 2-22

Dynamic Data, ICC 3-37Dynamic Numbers

data element description 3-17generation of 2-45

E

e-mail address 1, 13empty (defined) 1-6EMV CARD BLOCK command 1-52, 1-53EMV data elements 3-8encipherment, PIN. See PIN enciphermentencryption, DES 2-38, C-1

See also DES keyEND OF SCRIPT command 1-49, 1-62

See also Script ProcessingEXTERNAL AUTHENTICATE command 1-37, 1-41

F

failure flags (internal)non volatile memory 1-4resetting 1-17updating 1-37, 1-38, 1-51, 1-52volatile memory 1-3

fax/phone/telex numbers, Member Services 13

Page 217: MasterCard ICC

Index

ICC Application SpecificationNovember 1998

Index-13

FCI File Control Informationdata fields returned in response messages 1-5, 1-6data element descriptions 3-4, 3-17

File Control Information. See FCIfiles. See data elements and files; data objectsfirst GENERATE AC processing

about 1-17Application Cryptograms 2-31Card Action Analysis 1-33Card Risk Management Data (CDOL1) 1-21, 3-41CRM processing 1-24cryptogram information data 1-17internal process 1-22update ICC parameters 1-36See also CDOL1; CRM processing; payment functions,

standardfunctional specifications 1-1

payment functions, standard 1-5transaction flow 1-2Script Processing (standard post-issuance) 1-47See also individual index entries of above

G

GENERATE AC commandfirst 1-17second 1-39See also first GENERATE AC processing; payment

functions, standard; second GENERATE AC processingGET CHALLENGE command 1-14, 2-28GET DATA command 1-14GET PROCESSING OPTIONS command

Application Transaction Counter (ATC) activated with each1-20

optional data objects 1-9required data objects 1-10See also initiate application processing

Page 218: MasterCard ICC

Index

ICC Application Specification © 1998 MasterCard International IncorporatedNovember 1998Index-14

H

Hash Algorithm Indicatordata element descriptions 2-8, 2-10, 3-36for dynamic signature verification 2-23

hash functionfor digital signature B-1SHA-1 (Secure Hash Algorithm) C-5

I

IAD Issuer Application Datadata element descriptions 3-19, A-2, A-4data objects contained in 1-21

ICC Integrated Circuit Cardabout 1-1communication with terminal 2-2data element descriptions 3-4, 3-17, 3-36Dynamic Number generation 2-45key derivation 2-40updating parameters 1-22, 1-36

ICC Master Keysdata element descriptions 3-6, 3-38derivation 2-40, 2-41unique for each ICC 2-45See also key derivation

ICC PIN Enciphermentdata element descriptions 3-4, 3-17, 3-36Public Key Exponent 2-24, 3-4, C-2RSA/Rabin algorithm lengths/values C-2See also PIN encipherment

ICC Private Keydata element descriptions 3-4, 3-36PIN encipherment 2-24See also Private Keys

ICC Public Keydata element descriptions 3-4, 3-17, 3-36RSA/Rabin algorithm lengths/values C-2three-layer certification scheme (Dynamic Data

Authentication) 2-12, 2-13See also Public Keys

ICC Public Key Modulus 2-13, C-2

Page 219: MasterCard ICC

Index

ICC Application SpecificationNovember 1998

Index-15

ICC Session Key derivation 2-40See also Session Key derivation

IDN ICC Dynamic Number 2-45IMK Issuer Master Key 2-40

See also Master Keys, ICCinitiate application processing

about 1-2, 1-9, 1-11GET PROCESSING OPTIONS command 1-9

Integrated Circuit Card. See ICCINTERNAL AUTHENTICATE command 1-13

See also Authentication, offline cardinternal flags

non-volatile memory (Application Flag) 1-4updating Issuer Authentication 1-37, 1-38updating Script Processing 1-51volatile memory (Sequence Flag) 1-3

internal processesfirst GENERATE AC 1-22second GENERATE AC 1-41

ISO web site 12Issuer Action Codes 3-5, 3-18Issuer Application Data (IAD)

data element descriptions 3-19, A-2, A-4data objects contained in 1-21

Issuer Authenticationabout 1-37detailed description 2-33internal flags 1-3, 1-41See also payment functions, standard

Issuer Authentication Data 3-19, A-3Issuer Authentication Response Code 1-37, 3-37Issuer Code Table Index

data element descriptions 3-5, 3-20data fields returned in response messages 1-5, 1-6

Issuer Country Code 3-5, 3-20Issuer Discretionary Data 1-6Issuer Master Key (IMK) 2-40

See also Master Keys, ICCIssuer Private Key 2-2, 2-3

Page 220: MasterCard ICC

Index

ICC Application Specification © 1998 MasterCard International IncorporatedNovember 1998Index-16

Issuer Public Keyabout 2-2data element descriptions 3-5, 3-20, 3-37retrieval of 2-8, 2-16RSA/Rabin algorithm lengths/values C-2three-layer certification scheme (Dynamic Data

Authentication) 2-12, 2-13two-layer certification scheme (Static Data Authentication)

2-2, 2-3Issuer Public Key Modulus 2-13, C-2Issuer Script data elements 3-5, 3-20, 3-37, A-3Issuer Script Processing. See Script Processing

K

key derivationKey Derivation Index 3-5, 3-37Master Key 2-40, 2-41Session Key 2-42, 2-43

keys and certificatesdata element descriptions 3-4, 3-17, 3-36DES key, ARPC algorithm for 2-34for Dynamic Data Authentication 2-12, 2-13for PIN encipherment 2-24for Static Data Authentication 2-2, 2-3MAC Session 2-35, 2-37retrieval of Public Keys 2-7, 2-8, 2-16, 2-18Session Keys 2-32, 2-42See also Private Keys; Public Keys; Session Key derivation

L

Language Preferencedata element descriptions 3-5, 3-21data field returned in response messages 1-5, 1-6

Last Application Transaction Counter. See LATCLATC Last Online Application Transaction Counter

data element descriptions 3-5, 3-21new card processing 1-26velocity checking 1-27See also CRM processing

Page 221: MasterCard ICC

Index

ICC Application SpecificationNovember 1998

Index-17

length of data objectsempty 1-6rules 3-29

life cycle data, card 3-44Lower Consecutive Offline Limit 1-28, 3-5, 3-21Lower Cumulative Domestic Offline Transaction Amount 3-37Lower Cumulative Offline Limit 1-29, 3-6

M

MAC Session Keyalgorithm for double-length session 2-37message integrity using 2-35

Master Keys, ICCdata element descriptions 3-6, 3-38derived from Issuer Master Keys 2-40, 2-41unique for each ICC 2-45

MasterCard proprietary data elements 3-30maximum amount, offline transactions

about 1-26data element descriptions 3-6, 3-38data objects involved in 1-28See also CRM processing

Member Services representative address/phone 13Merchant Category Code 1-9, 3-21MK. See Master Keys, ICC

N

n, data element format 3-29name

data element descriptions 3-3, 3-10response message data fields of ADF 1-6selection by full/partial 1-5

“new card” bit in CVR 1-26See also CRM processing

Non Domestic Control Factor 3-6, 3-38non-volatile memory 1-4notations

about 6list of 11

Page 222: MasterCard ICC

Index

ICC Application Specification © 1998 MasterCard International IncorporatedNovember 1998Index-18

O

odd public key exponent, RSA digital signature scheme C-3offline authorization 1-1, 1-2offline card authentication 1-12

See also payment functions, standardoffline Card Issuer Action Code 1-35, 3-2

See also Card Action Analysisoffline dynamic data authentication

card authentication 1-13failure flag 1-4See also Dynamic Data Authentication

Offline Enciphered Transaction PIN 3-21offline PIN verification 1-14, 1-15

See also PIN verificationoffline risk management 1-1

See also CRM processingoffline static data authentication

card authentication 1-12failure flag 1-4See also Static Data Authentication

offline transactionsconsecutive, velocity checking of 1-26, 1-27cumulative amount 1-28, 1-29maximum amount 1-26, 3-6, 3-38See also CRM processing

online Card Issuer Action Code 1-35, 3-2See also Card Action Analysis

online processingauthorization 1-1, 1-2transaction completion 1-36

online transaction failure flag 1-4

P

Pad Pattern 2-21payment functions, standard 1-5

application selection 1-5cardholder verification 1-2, 1-13first GENERATE AC processing 1-17initiate application processing 1-2, 1-9Issuer Authentication 1-2, 1-37

Page 223: MasterCard ICC

Index

ICC Application SpecificationNovember 1998

Index-19

payment functions, standard (continued)offline card authentication 1-12read application data 1-2, 1-12second GENERATE AC processing 1-39

Payment System Environment. See PSEPDOL Processing Option Data Object List

data element descriptions 3-6, 3-22returned after application selection 1-6to initiate application processing 1-9, 1-11

phone/telex numbers, Member Services 13PIN change/unblock 1-60, 1-61

See also Script ProcessingPIN encipherment

and cardholder verification 1-14, 1-16data element descriptions 3-4, 3-17, 3-36data objects required for retrieval of Public Key 2-26data to be enciphered 2-27detailed description 2-24keys and certificates 2-24, 3-4Public Key data to be signed by issuer 2-25

PIN Try Counter. See PTCPIN Try Limit. See PTLPIN verification

cardholder verification 1-13CRM processing 1-25internal flags 1-3offline 1-15See also CRM processing

PIX Proprietary Application Identifier Extension 1-6Point of Service (POI) Entry Mode 3-22post-issuance functions, standard (Script Processing) 1-47

See also Script Processingprevious transaction status 1-25

See also CRM processingpriority

Application Priority Indicator 1-6, 3-2, 3-10application selection (coding) 1-8

Page 224: MasterCard ICC

Index

ICC Application Specification © 1998 MasterCard International IncorporatedNovember 1998Index-20

Private Keysdata element descriptions 3-4, 3-36Dynamic Data Authentication 2-12, 2-13PIN encipherment 2-24Static Data Authentication 2-2, 2-3See also keys and certificates

Processing Option Data Object List. See PDOLprocessing restrictions 1-2Proprietary Application Identifier Extension (PIX) 1-6proprietary data elements, MasterCard 3-30Proprietary Template, FCI 1-5, 1-6PSE Payment System Environment

response message data field of 1-5structure of 1-7supports application selection 1-5See also AIDs

PTC PIN Try Counterabout 1-13data element descriptions 3-6, 3-21general processing 1-14offline PIN verification 1-15resetting 1-15, 1-17updating to PTL 1-61

PTL PIN Try Limitabout 1-13data element descriptions 3-6, 3-38general processing 1-14updating 1-61

Public KeysCA Public Key Modulus 2-13, C-2data element descriptions 3-4, 3-17, 3-36exponents of RSA digital signature scheme C-3ICC Public Key Modulus 2-13, C-2Issuer Public Key Modulus 2-3, C-2lengths/values for RSA/Rabin algorithm C-2PIN Encipherment 2-24retrieval of 2-7, 2-8, 2-16, 2-18three-layer certification scheme (Dynamic Data

Authentication) 2-12, 2-13two-layer certification scheme (Static Data Authentication)

2-2, 2-3See also keys and certificates

publications, related MasterCard 2

Page 225: MasterCard ICC

Index

ICC Application SpecificationNovember 1998

Index-21

PUT DATA command 1-58

R

Rabin, RSA algorithmfor message recovery B-1lengths/values C-2odd public key exponents C-3

random number (RAND) 2-43read application data 1-2, 1-12

See also payment functions, standard“read only” 1-12READ RECORD command

data objects read through 1-12Dynamic Data Authentication information retrieved with

2-13Static Data Authentication information retrieved with 2-3

recoverymessage B-1signature, Rabin cryptographic algorithm C-4signature, RSA cryptographic algorithm C-3

Reference Currency Conversion Table 1-32, 3-7, 3-39Reference PIN 1-13, 3-7, 3-39Registered Application Provider Identifier. See RIDrejected commands/transactions

application blocking 1-55application unblocking 1-57card blocking 1-53END OF SCRIPT 1-62initiate application processing 1-11Issuer Authentication 1-38offline PIN verification 1-15PIN change-unblock 1-61Script Processing 1-50, 1-51updating card data 1-59See also declined transactions

request messages, chip data elements in A-2

Page 226: MasterCard ICC

Index

ICC Application Specification © 1998 MasterCard International IncorporatedNovember 1998Index-22

resettingCard Verification Result (CVR) 1-22, 1-23, 1-45PIN Try Counter (PTC) 1-15, 1-17“PIN verification failed” 1-17

response codesAuthorization 1-40, 1-41, 1-43, 3-12Issuer Authentication 1-37, 3-37

Response Message Templates 3-22response messages

chip data elements in A-3data fields returned in 1-5

retrievalCA Public Key 2-7, 2-16ICC Public Key 2-18Issuer Public Key 2-8, 2-16PIN Encipherment Public Key 2-26

revisions to this manual 12RID Registered Application Provider Identifier

in AID 1-6Public Key stored using 2-7

risk managementabout 1-1, 1-2before responding with a TC 1-17data elements used 3-40See also CDOL1; CDOL2; CRM processing

RSA/Rabin algorithmfor message recovery B-1lengths/values C-2odd public key exponents C-3

S

Script Counter 1-48See also Script Processing

“Script failed”defined 1-3in application block 1-55in application unblocking 1-57in card block 1-51, 1-53in card data update 1-59in END OF SCRIPT processing 1-62

Page 227: MasterCard ICC

Index

ICC Application SpecificationNovember 1998

Index-23

“Script failed” (continued)in PIN change/unblock 1-61in Script Processing 1-48, 1-50

“Script performed”defined 1-3in application block 1-55in application unblocking 1-57in card block 1-51, 1-53in card data update 1-59in END OF SCRIPT processing 1-62in PIN change/unblock 1-61in Script Processing 1-48, 1-50

Script Processing (post-issuance)application blocking 1-54, 1-55application unblocking 1-56, 1-57card blocking 1-52, 1-53detailed description 1-47END OF SCRIPT command 1-49, 1-62PIN change/unblock 1-60, 1-61transaction flow 1-2updating card data 1-58

Script Status Flag (SSF) 1-4, 1-48SDA tag list 2-6

See also Static Data Authenticationsecond GENERATE AC processing

about 1-39Application Cryptograms 2-31Card Action Analysis 1-43Card Risk Management Data (CDOL2) 1-40, 3-42CRM processing 1-24cryptogram information data 1-39data elements sent to terminal 1-39internal process 1-41Issuer Authentication 1-42update ICC parameters 1-46See also CDOL1; CRM processing; payment functions,

standard

Page 228: MasterCard ICC

Index

ICC Application Specification © 1998 MasterCard International IncorporatedNovember 1998Index-24

Secure Messaging (SM)command 2-43confidentiality 2-38, 2-39detailed description 2-35in application block 1-54, 1-55in application unblock 1-56, 1-57in card block 1-51, 1-53in card data update 1-59in END OF SCRIPT processing 1-62in Script Processing 1-50integrity 2-39verifying in PIN change/unblock 1-60, 1-61

security specifications 2-1Application Cryptograms 2-29cryptographic algorithms B-1Data Authentication Code generation 2-44Dynamic Data Authentication 2-12Dynamic Number generation 2-45Issuer Authentication 2-33key derivation 2-40PIN encipherment 2-24random number for Session Key derivation 2-43Secure Messaging (SM) 2-35signature schemes B-1Static Data Authentication 2-2See also individual index entries of above

SELECT response message data fieldsof Application Definition File (ADF) 1-6of Payment System Environment (PSE) 1-5

Sequence Flagindicators used in 1-3script status in 1-48updating 1-16, 1-37, 1-51

Service Code 3-7, 3-22Session Key derivation

AAC, ARQC, and TC algorithm 2-31AC algorithm for double-length 2-32ICC derivation 2-42in Secure Messaging command 2-43

SFIs Short File Identifiersdata element descriptions 3-7, 3-22data field returned in response message 1-5

SHA-1 Secure Hash Algorithm

Page 229: MasterCard ICC

Index

ICC Application SpecificationNovember 1998

Index-25

cryptographic algorithm C-5digital signature scheme for message recovery B-1

Short File Identifiers. See SFIssignature generation

dynamic 2-20for message recovery B-1

signature schemes, digitalbased on Public Key techniques 1-12detailed description B-1Issuer Public Key data for 2-4Static Application Data for 2-5

signature verificationdynamic 2-22for message recovery B-3

signed data objects 1-12Signed Dynamic Application Data

data element descriptions 3-7, 3-22in ICC 2-15verification of 2-22

Signed Static Application Datadata element descriptions 3-7, 3-22in ICC 2-2, 2-3verification of 2-10

signing functionsRabin C-4RSA C-3

SK. See Session Key derivationSM. See Secure MessagingSSF Script Status Flag 1-4, 1-48Static Data Authentication 2-2

data objects required for 2-7indicated in SDA tag list 2-7keys and certificates 1-12, 2-2offline card authentication 1-4, 1-12retrieval of CA Public Key 2-7retrieval of Issuer Public Key 2-8Static Application Data to be signed by issuer 2-5tag list 3-7, 3-22verification of Signed Static Application Data 2-10

suggestions and comments 13

Page 230: MasterCard ICC

Index

ICC Application Specification © 1998 MasterCard International IncorporatedNovember 1998Index-26

T

TC Transaction Certificateabout 1-1algorithm 2-31, 2-32data element descriptions 3-7, 3-27data elements recommended for input 2-30requesting a 1-17, 1-44setting for first GENERATE AC 1-22setting for second GENERATE AC 1-41, 1-45See also Application Cryptograms

TDOL Transaction Certificate Data Object List 3-27telephone/telex numbers, Member Services 13templates

Application 1-7, 3-2, 3-11Application Elementary File 3-9Command 3-15FCI 1-5, 1-6, 3-4, 3-17Issuer Script 3-21, A-3Response Message 3-22

terminal action analysis 1-2Terminal Capabilities 1-9, 3-23Terminal Country Code 1-9, 3-23, A-3, A-5Terminal Risk Management (TRM) 1-34Terminal Type

checking for 1-34data element description 3-24optional data object 1-9See also Card Action Analysis

Terminal Verification Results. See TVRthree-layer certification scheme 2-12, 2-13

See also certification; Public KeysTrack 1 Discretionary Data 3-7, 3-26Track 2 Equivalent Data

data element descriptions 3-7, 3-27in authorization messages A-3, A-5

transaction amount. See amountsTransaction Certificate. See TCTransaction Certificate Data Object List (TDOL) 3-27

Page 231: MasterCard ICC

Index

ICC Application SpecificationNovember 1998

Index-27

Transaction Completiondetailed analysis 1-36during first GENERATE AC command 1-22during second GENERATE AC command 1-41transaction flow 1-2

Transaction Currency Codecumulative amount check 1-28, 1-29data element descriptions 3-28, A-2, A-4

Transaction Date 3-28, A-2, A-4transaction flow

data elements to manage 1-3diagram 1-2

Transaction PIN Data 1-14, 3-28Transaction Reference Currency Code

currency conversion 1-30, 1-31data element description 3-28

transaction rejection 1-11See also declined transactions; rejected

commands/transactionsTransaction Status Information 3-28Transaction Time 3-29Transaction Type 3-29, A-2, A-4tries, PIN 1-13, 1-14

See also PTLtriple-DES encryption C-1TRM Terminal Risk Management 1-34TVR Terminal Verification Results

asks for ARQC 1-34data element descriptions 3-24, A-2, A-4See also Card Action Analysis

two-layer certification scheme 2-2, 2-3See also certification; Public Keys

U

UN Unpredictable NumberApplication Cryptogram key derivation 2-31data element descriptions 3-29, A-2, A-4ICC Dynamic Number generation 2-45

Page 232: MasterCard ICC

Index

ICC Application Specification © 1998 MasterCard International IncorporatedNovember 1998Index-28

unblockingapplication 1-56, 1-57PIN 1-60, 1-61See also Script Processing

Unpredictable Number. See UNUPDATE RECORD command 1-58, 1-59updating

card data 1-58, 1-59Card Risk Management data 3-40ICC parameters

detailed description 1-36during first GENERATE AC command 1-22during second GENERATE AC command 1-41

internal indicatorsIssuer Authentication 1-37, 1-38Script Processing status 1-51

PIN value 1-60, 1-61See also payment functions, standard; Script Processing

Upper Consecutive Offline Limit 1-28, 3-7, 3-29Upper Cumulative Domestic Offline Transaction Amount 3-7,

3-39Upper Cumulative Offline Limit 1-29, 3-7

V

velocity checking, offline consecutive transactions 1-26, 1-27See also CRM processing

verificationcardholder 1-1, 1-2, 1-13Issuer Authentication 1-42PIN 1-3, 1-13, 1-15, 1-25PIN encipherment 2-24, 2-27Secure Messaging (SM) 1-56, 1-61, 2-43signature 2-22, B-3Signed Dynamic Application Data 2-22Signed Static Application Data 2-10

VERIFY command 1-13, 1-14volatile memory 1-3

Page 233: MasterCard ICC

Index

ICC Application SpecificationNovember 1998

Index-29

W

web site, ISO 12

Y

Y3, Authorization Response Code 1-41, 1-43

Z

Z3, Authorization Response Code 1-41, 1-43


Recommended