PCI Watch

Tracking changes across the Payment Card Industry

EMV® ’96 Integrated Circuit Card Specification for Payment Systems

v3.1.1 Specifications
Contact Card

EMV ‘96 Integrated Circuit Card Specification for Payment Systems Version 3.1.1 May 31, 1998 © 1998 Europay International S.A., MasterCard International Incorporated, and Visa International Service Association. All rights reserved. Permission to copy and implement the material contained herein is granted subject to the conditions that (i) any copy or re-publication must bear this legend in full, (ii) any derivative work must bear a notice that it is not the Integrated Circuit Card Specification for Payment Systems jointly published by the copyright holders, and (iii) that none of the copyright holders shall have any responsibility or liability whatsoever to any other party arising from the use or publication of the material contained herein. The authors of this documentation make no representation or warranty regarding whether any particular physical implementation of any part of this Specification does or does not violate, infringe, or otherwise use the patents, copyrights, trademarks, trade secrets, know-how, and/or other intellectual property of third parties, and thus any person who implements any part of this Specification should consult an intellectual property attorney before any such implementation. The following Specification includes public key encryption technology, which is the subject matter of patents in several countries. Any party seeking to implement this Specification is solely responsible for determining whether their activities require a license to any technology including, but not limited to, patents on public key encryption technology. Europay International S. A., MasterCard International Incorporated, and Visa International Service Association shall not be liable for any party’s infringement of any intellectual property right.

May 31, 1998 Contents Table of Contents 1. Scope 1.1 EMV Specification Version Numbering 2. Normative References 3. Definitions 4. Abbreviations and Notations Part I

  • Electromechanical Characteristics, Logical Interface, and Transmission Protocols 1. Electromechanical Interface 1.1 Mechanical Characteristics of the ICC 1.1.1 Physical Characteristics 1.1.2 Dimensions and Location of Contacts 1.1.3 Contact Assignment 1.2 Electrical Characteristics of the ICC 1.2.1 Measurement Conventions 1.2.2 Input/Output (I/O) 1.2.3 Programming Voltage (VPP) 1.2.4 Clock (CLK) 1.2.5 Reset (RST) 1.2.6 Supply Voltage (VCC) 1.2.7 Contact Resistance 1.3 Mechanical Characteristics of the Terminal 1.3.1 Interface Device 1.3.2 Contact Forces 1.3.3 Contact Assignment 1.4 Electrical Characteristics of the Terminal 1.4.1 Measurement Conventions 1.4.2 Input/Output (I/O) 1.4.3 Programming Voltage (VPP) 1.4.4 Clock (CLK) 1.4.5 Reset (RST) 1.4.6 Supply Voltage (VCC) 1.4.7 Contact Resistance 1.4.8 Short Circuit Resilience 1.4.9 Powering and Depowering of Terminal with ICC in Place 2. Card Session 2.1 Normal Card Session 2.1.1 Stages of a Card Session 2.1.2 ICC Insertion and Contact Activation Sequence 2.1.3 ICC Reset 2.1.4 Execution of a Transaction 2.1.5 Contact Deactivation Sequence 2.2 Abnormal Termination of Transaction Process 3. Physical Transportation of Characters 3.1 Bit Duration 3.2 Character Frame i ix x xi xiv xviii I-1 I-1 I-1 I-1 I-2 I-3 I-3 I-3 I-4 I-4 I-5 I-5 I-5 I-6 I-6 I-7 I-7 I-7 I-7 I-7 I-9 I-9 I-9 I-10 I-10 I-10 I-10 I-11 I-11 I-11 I-11 I-12 I-14 I-14 I-15 I-16 I-16 I-16 ii Contents May 31, 1998 4. Answer to Reset 4.1 Physical Transportation of Characters Returned at Answer to Reset 4.2 Characters Returned by ICC at Answer to Reset 4.3 Character Definitions 4.3.1 TS
  • Initial Character 4.3.2 T0
  • Format Character 4.3.3 TA1 to TC3
  • Interface Characters 4.3.4 TCK
  • Check Character 4.4 Terminal Behaviour during Answer to Reset 4.5 Answer to Reset
  • Flow at the Terminal 5. Transmission Protocols 5.1 Physical Layer 5.2 Data Link Layer 5.2.1 Character Frame 5.2.2 Character Protocol T=0 5.2.3 Error Detection and Correction for T=0 5.2.4 Block Protocol T=1 5.2.5 Error Detection and Correction for T=1 5.3 Terminal Transport Layer (TTL) 5.3.1 Transport of APDUs by T=0 5.3.2 Transportation of APDUs by T=1 5.4 Application Layer 5.4.1 C-APDU 5.4.2 R-APDU Part II
  • Data Elements and Commands 1. Data Elements and Files 1.1 Data Elements Associated with Financial Transaction Interchange 1.2 Data Objects 1.2.1 Classes of Data Objects 1.3 Files 1.3.1 File Structure 1.3.2 File Referencing 1.4 Rules for Using a Data Object List (DOL) 2. Commands for Financial Transaction 2.1 Message Structure 2.1.1 Command APDU Format 2.1.2 Response APDU Format 2.1.3 Command-Response APDU Conventions 2.2 Coding Conventions 2.2.1 Coding of the Class Byte 2.2.2 Coding of the Instruction Byte 2.2.3 Coding of Parameter Bytes 2.2.4 Coding of Data Field Bytes 2.2.5 Coding of the Status Bytes 2.2.6 Coding of RFU Data 2.3 Logical Channels 2.4 Commands 2.4.1 APPLICATION BLOCK Command-Response APDUs I-18 I-18 I-18 I-20 I-21 I-22 I-22 I-28 I-29 I-30 I-31 I-31 I-32 I-32 I-32 I-34 I-35 I-42 I-44 I-44 I-51 I-51 I-52 I-53 II-1 II-1 II-1 II-2 II-2 II-2 II-4 II-4 II-6 II-6 II-6 II-7 II-8 II-8 II-8 II-8 II-9 II-9 II-9 II-12 II-13 II-13 II-13 May 31, 1998 Contents iii 2.4.2 APPLICATION UNBLOCK Command-Response APDUs 2.4.3 CARD BLOCK Command-Response APDUs 2.4.4 EXTERNAL AUTHENTICATE Command-Response APDUs 2.4.5 GENERATE APPLICATION CRYPTOGRAM Command-Response APDUs 2.4.6 GET DATA Command-Response APDUs 2.4.7 GET PROCESSING OPTIONS Command-Response APDUs 2.4.8 INTERNAL AUTHENTICATE Command-Response APDUs 2.4.9 PIN CHANGE/UNBLOCK Command-Response APDUs 2.4.10 READ RECORD Command-Response APDUs 2.4.11 SELECT Command-Response APDUs 2.4.12 VERIFY Command-Response APDUs II-14 II-15 II-16 II-17 II-20 II-21 II-22 II-23 II-25 II-26 II-28 Part III
  • Application Selection 1. Overview of Application Selection 2. Data in the ICC Used for Application Selection 2.1 Coding of Payment System Application Identifier 2.2 Structure of the Payment Systems Environment 2.3 Coding of a Payment System’s Directory 2.4 Coding of Other Directories 3. Building the Candidate List 3.1 Matching Terminal Applications to ICC Applications 3.2 Using the Payment Systems Directories 3.3 Using a List of AIDs 3.4 Final Selection III-1 III-2 III-2 III-2 III-3 III-5 III-5 III-5 III-6 III-9 III-11 Part IV
  • Security Aspects 1. Static Data Authentication 1.1 Keys and Certificates 1.2 Retrieval of the Certification Authority Public Key 1.3 Retrieval of the Issuer Public Key 1.4 Verification of the Signed Static Application Data 2. Dynamic Data Authentication 2.1 Keys and Certificates 2.2 Retrieval of the Certification Authority Public Key 2.3 Retrieval of the Issuer Public Key 2.4 Retrieval of the ICC Public Key 2.5 Dynamic Signature Generation 2.6 Dynamic Signature Verification 3. Secure Messaging 3.1 Secure Messaging Format 3.2 Secure Messaging for Integrity and Authentication 3.2.1 Command Data Field 3.2.2 MAC Session Key Derivation 3.2.3 MAC Computation 3.3 Secure Messaging for Confidentiality 3.3.1 Command Data Field 3.3.2 Encipherment Session Key Derivation 3.3.3 Encipherment/Decipherment IV-1 IV-2 IV-5 IV-6 IV-7 IV-9 IV-11 IV-14 IV-14 IV-16 IV-18 IV-19 IV-21 IV-21 IV-21 IV-21 IV-22 IV-22 IV-23 IV-23 IV-23 IV-23 iv Contents 4. Personal Identification Number Encipherment 4.1 Keys and Certificates 4.2 PIN Encipherment and Verification Annexes Annex A
  • Examples of Exchanges Using T=0 A1. Case 1 Command A2. Case 2 Command A3. Case 3 Command A4. Case 4 Command A5. Case 2 Commands Using the ‘61’ and ‘6C’ Procedure A6. Case 4 Command Using the ‘61’ Procedure Byte A7. Case 4 Command with Warning Condition Annex B
  • Data Elements Table Annex C
  • Data Objects C1. Coding of BER-TLV Data Objects Annex D
  • Examples of Directory Structures D1. Examples of Directory Structures Annex E
  • Security Mechanisms E1. Symmetric Mechanisms E2. Asymmetric Mechanisms Annex F
  • Approved Cryptographic Algorithms F1. Symmetric Algorithms F2. Asymmetric Algorithms F3. Hashing Algorithms Annex G
  • Informative

References

Bytes May 31, 1998 IV-24 IV-24 IV-26 A-1 A-1 A-1 A-2 A-2 A-2 A-3 A-3 B-1 C-1 C-1 D-1 D-1 E-1 E-1 E-4 F-1 F-1 F-1 F-4 G-1

May 31, 1998 Contents Tables Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table I-1

  • ICC Contact Assignment I-2
  • Electrical Characteristics of I/O for ICC Reception I-3
  • Electrical Characteristics of I/O for ICC Transmission I-4
  • Electrical Characteristics of CLK to ICC I-5
  • Electrical Characteristics of RST to ICC I-6
  • IFD Contact Assignment I-7
  • Electrical Characteristics of I/O for Terminal Transmission I-8
  • Electrical Characteristics of I/O for Terminal Reception I-9
  • Electrical Characteristics of CLK from Terminal I-10
  • Electrical Characteristics of RST from Terminal I-11
  • Basic ATR for T=0 Only I-12
  • Basic ATR for T=1 Only I-13
  • Basic Response Coding of Character T0 I-14
  • Basic Response Coding of Character TB1 I-15
  • Basic Response Coding of Character TC1 I-16
  • Basic Response Coding of Character TD1 I-17
  • Basic Response Coding of Character TD2 I-18
  • Basic Response Coding of Character TA3 I-19
  • Basic Response Coding of Character TB3 I-20
  • Terminal Response to Procedure Byte I-21
  • Structure of a Block I-22
  • Coding of the PCB of an I-block I-23
  • Coding of the PCB of an R-block I-24
  • Coding of the PCB of a S-block I-25
  • Structure of Command Message I-26
  • GET RESPONSE Error Conditions I-27
  • Definition of Cases for Data in APDUs I-28
  • Cases of C-APDUs II-1
  • Structure of SFI II-2
  • Command APDU Content II-3
  • Response APDU Content II-4
  • Data Within an APDU Command-Response Pair II-5
  • Most Significant Nibble of the Class Byte II-6
  • Coding of the Instruction Byte II-7
  • Coding of Status Bytes SW1 SW2 II-8
  • Allocation of Status Bytes II-9
  • APPLICATION BLOCK Command Message II-10
  • APPLICATION UNBLOCK Command Message II-11
  • CARD BLOCK Command Message II-12
  • EXTERNAL AUTHENTICATE Command Message II-13
  • GENERATE AC Cryptogram Types II-14
  • GENERATE AC Command Message II-15
  • GENERATE AC Reference Control Parameter II-16
  • Format 1 GENERATE AC Response Message Data Field II-17
  • Coding of Cryptogram Information Data II-18
  • GET DATA Command Message v I-3 I-4 I-4 I-4 I-5 I-7 I-8 I-8 I-9 I-9 I-19 I-20 I-22 I-24 I-25 I-25 I-27 I-27 I-28 I-33 I-35 I-36 I-37 I-37 I-50 I-51 I-52 I-53 II-4 II-7 II-7 II-8 II-8 II-9 II-10 II-11 II-14 II-15 II-16 II-17 II-18 II-18 II-18 II-19 II-19 II-20 vi Contents May 31, 1998 Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table II-19
  • GET PROCESSING OPTIONS Command Message II-20
  • Format 1 GET PROCESSING OPTIONS Response Message Data Field II-21
  • INTERNAL AUTHENTICATE Command Message II-22
  • PIN CHANGE/UNBLOCK Command Message II-23
  • READ RECORD Command Message II-24
  • READ RECORD Command Reference Control Parameter II-25
  • READ RECORD Response Message Data Field II-26
  • SELECT Command Message II-27
  • SELECT Command Reference Control Parameter II-28
  • SELECT Command Options Parameter II-29
  • SELECT Response Message Data Field (FCI) of the PSE II-30
  • SELECT Response Message Data Field (FCI) of a DDF II-31
  • SELECT Response Message Data Field (FCI) of an ADF II-32
  • VERIFY Command Message II-33
  • VERIFY Command Qualifier of Reference Data (P2) III-1
  • PSE Directory Record Format III-2
  • DDF Directory Entry Format III-3
  • ADF Directory Entry Format III-4
  • Format of Application Priority Indicator IV-1
  • Issuer Public Key Data to be Signed by the Certification Authority IV-2
  • Static Application Data to be Signed by the Issuer IV-3
  • Data Objects Required for Static Data Authentication IV-4
  • Format of the Data Recovered from the Issuer Public Key Certificate IV-5
  • Format of the Data Recovered from the Signed Static Application Data IV-6
  • Issuer Public Key Data to be Signed by the Certification Authority IV-7
  • ICC Public Key Data to be Signed by the Issuer IV-8
  • Data Objects Required for Public Key Authentication for Dynamic Authentication IV-9
  • Format of the Data Recovered from the Issuer Public Key Certificate IV-10
  • Format of the Data Recovered from the ICC Public Key Certificate IV-11
  • Dynamic Application Data to be Signed IV-12
  • Additional Data Objects Required for Dynamic Signature Generation and Verification IV-13
  • Format of the Data Recovered from the Signed Dynamic Application Data IV-14
  • ICC PIN Encipherment Public Key Data to be Signed by the Issuer IV-15
  • Data Objects Required for the Retrieval of the ICC PIN Encipherment Public Key IV-16
  • Data to be Enciphered for PIN Encipherment B-1
  • Data Elements Dictionary B-2
  • Data Elements Tags II-21 II-22 II-22 II-24 II-25 II-25 II-25 II-26 II-26 II-27 II-27 II-27 II-28 II-29 II-29 III-4 III-4 III-4 IV-4 IV-4 IV-5 IV-5 IV-6 IV-8 IV-12 IV-13 IV-14 IV-15 IV-17 IV-19 IV-19 IV-20 IV-25 IV-26 IV-27 B-11 B-15 May 31, 1998 Contents vii Table C-1
  • Tag Field Structure (First Byte) BER-TLV C-1 Table C-2
  • Tag Field Structure (Subsequent Bytes) BER-TLV C-2 Table C-3
  • Primitive BER-TLV Data Object (Data Element) C-3 Table C-4
  • Constructed BER-TLV Data Object C-3 Table F-1
  • Mandatory Upper Bound for the Size in Bytes of the Moduli F-1 viii Contents May 31, 1998 Figures Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure I-2
  • Layout of Contacts I-3
  • Terminal Contact Location and Dimensions I-4
  • Contact Activation Sequence I-5
  • Cold Reset Sequence I-6
  • Warm Reset Sequence I-7
  • Contact Deactivation Sequence I-8
  • Character Frame I-9
  • ATR
  • Example Flow at the Terminal II-1
  • Command APDU Structure II-2
  • Response APDU Structure II-3
  • Structural Scheme of Status Bytes III-1- Terminal Logic Using Directories III-2
  • Using the List of Applications in the Terminal IV-1
  • Diagram of Static Data Authentication IV-2
  • Diagram of Dynamic Data Authentication IV-3
  • Format 1 Command Data Field for Secure Messaging for Integrity and Authentication IV-4
  • Format 2 Command Data Field for Secure Messaging for Integrity and Authentication IV-5
  • Format 1 Enciphered Data Object in a Command Data Field IV-6
  • Format 2 Command Data Field for Secure Messaging for Confidentiality D-1
  • Simplest Card Structure Single Application D-2
  • Single Level Directory D-3
  • Third Level Directory I-2 I-6 I-12 I-13 I-14 I-15 I-17 I-30 II-6 II-7 II-10 III-8 III-10 IV-1 IV-9 IV-22 IV-22 IV-23 IV-23 D-1 D-2 D-2 May 31, 1998 ICC Card Specification for Payment Systems ix 1.

Scope

The Integrated Circuit Card (ICC) Specification for Payment Systemsdescribes the minimum functionality required of integrated circuit cards (ICCs) and terminals to ensure correct operation and interoperability. Additional proprietary functionality and features may be provided, but these are beyond the scope of this specification and interoperability cannot be guaranteed. This specification consists of four parts: Part I - Electromechanical Characteristics, Logical Interface, and Transmission Protocols Part II - Data Elements and Commands Part III - Application Selection Part IV - Security Aspects Part 1 defines electromechanical characteristics, logical interface, and transmission protocols as they apply to the exchange of information between an ICC and a terminal. In particular it covers:

  • Mechanical characteristics, voltage levels, and signal parameters as they apply to both ICCs and terminals.
  • An overview of the card session.
  • Establishment of communication between the ICC and the terminal by means of the answer to reset.
  • Character- and block-oriented asynchronous transmission protocols. Part II defines data elements and commands as they apply to the exchange of information between an ICC and a terminal. In particular it covers:
  • Data elements for financial interchange and their mapping onto data objects.
  • Structure and referencing of files.
  • Structure and coding of messages between the ICC and the terminal to achieve application level functions. Part III defines the application selection process from the standpoint of both the card and the terminal. The logical structure of data and files within the card that is required for the process is specified, as is the terminal logic using the card structure. Part IV defines the security aspects of the processes specified in this specification. In particular it covers:
  • Offline static data authentication. x ICC Card Specification for Payment Systems May 31, 1998
  • Offline dynamic data authentication.
  • Offline PIN encipherment
  • Secure messaging. This specification does not cover the details of Transaction Certificate generation by the ICC, the internal implementation in the ICC, its security architecture, and its personalisation. This specification is based on the ISO/IEC 7816 series of standards and should be read in conjunction with those standards. However, if any of the provisions or definitions in this specification differ from those standards, the provisions herein shall take precedence. This specification is intended for a target audience that includes manufacturers of ICCs and terminals, system designers in payment systems, and financial institution staff responsible for implementing financial applications in ICCs.

1.1 EMV Specification Version Numbering To facilitate future reference of the EMV specifications and to differentiate between technical updates and editorial clarifications, with the publication of this version of the EMV specifications, EMV has introduced the following version numbering scheme: version X.Y.Z, where: X indicates the phase number of the specifications Y indicates technical change(s) from the previous version Z indicates editorial change(s) from the previous version Therefore, this version of the EMV specifications is version 3.1.1, since the basis for this specification is version 3.0 and both technical and editorial changes have been made.

May 31, 1998 ICC Card Specification for Payment Systems xi 2. Normative References The following standards contain provisions that are referenced in this specification. Europay, MasterCard, and Visa (EMV): March 31, 1998 Integrated Circuit Card Application Specification for Payment Systems Europay, MasterCard, and Visa (EMV): March 31, 1998 Integrated Circuit Card Terminal Specification for Payment Systems FIPS Pub 180-1:1995 Secure Hash Standard IEC 512-2:1979 Specifications for electromechanical components for electromechanical equipment

  • Part 2: Contact resistance tests, insulation tests, and voltage stress tests ISO 639:1988 Codes for the representation of names and languages ISO 3166:1997 Codes for the representation of names of countries ISO 4217:1995 Codes for the representation of currencies and funds ISO/IEC 7811-1:1995 Identification cards
  • Recording technique
  • Part 1: Embossing ISO/IEC 7811-3:1995 Identification cards
  • Recording technique
  • Part 3: Location of embossed characters on ID-1 cards ISO/IEC 7813:1995 Identification cards
  • Financial transaction cards ISO/IEC DIS 78161:1998 Identification cards
  • Integrated circuit(s) cards with contacts
  • Part 1: Physical characteristics ISO/IEC DIS 78162:1998 Identification cards
  • Integrated circuit(s) cards with contacts
  • Part 2: Dimensions and location of contacts ISO/IEC 7816-3:1989 Identification cards
  • Integrated circuit(s) cards with contacts
  • Part 3: Electronic signals and transmission protocols ISO/IEC 7816-3:1992 Identification cards
  • Integrated circuit(s) cards with contacts
  • Part 3, Amendment 1: Protocol type T=1, asynchronous half duplex block transmission protocol xii ICC Card Specification for Payment Systems May 31, 1998 ISO/IEC 7816-3:1994 Identification cards
  • Integrated circuit(s) cards with contacts
  • Part 3, Amendment 2: Protocol type selection (Draft International Standard) ISO/IEC 7816-4:1995 Identification cards
  • Integrated circuit(s) cards with contacts
  • Part 4, Inter-industry commands for interchange ISO/IEC 7816-5:1994 Identification cards
  • Integrated circuit(s) cards with contacts
  • Part 5: Numbering system and registration procedure for application identifiers ISO/IEC 7816-6:1996 Identification cards
  • Integrated circuit(s) cards with contacts
  • Part 6: Inter-industry data elements (Draft International Standard) ISO 8731-1:1987 Banking
  • Approved algorithms for message authentication Part 1: DEA ISO 8372:1987 Information processing
  • Modes of operation for a 64-bit block cipher algorithm ISO/IEC 8825:1990 Information technology
  • Open systems interconnection Specification of basic encoding rules for abstract syntax notation one (ASN.1) ISO 8583:1987 Bank card originated messages
  • Interchange message specifications
  • Content for financial transactions ISO 8583:1993 Financial transaction card originated messages
  • Interchange message specifications ISO 8859:1987 Information processing - 8-bit single-byte coded graphic character sets ISO/IEC 9796-2: 1997 Information technology
  • Security techniques
  • Digital signature scheme giving message recovery
  • Part 2: Mechanism using a hash function ISO/IEC 9797:1994 Information technology
  • Security techniques
  • Data integrity mechanism using a cryptographic check function employing a block cipher algorithm ISO/IEC 10116: 199 7 Information technology
  • Modes of operation of an n-bit block cipher algorithm ISO/IEC 10118-3: 1998 Information technology
  • Security techniques
  • Hash functions
  • Part 3: Dedicated hash functions May 31, 1998 ICC Card Specification for Payment Systems xiii ISO/IEC 10373:1993 Identification cards
  • Test methods xiv ICC Card Specification for Payment Systems May 31, 1998 3.

Definitions

The following terms are used in this specification. Application - The application protocol between the card and the terminal and its related set of data. Asymmetric Cryptographic Technique - A cryptographic technique that uses two related transformations, a public transformation (defined by the public key) and a private transformation (defined by the private key). The two transformation have the property that, given the public transformation, it is computationally infeasible to derive the private transformation. Block - A succession of characters comprising two or three fields defined as prologue field, information field, and epilogue field. Byte - 8 bits. Card - A payment card as defined by a payment system. Certification Authority - Trusted third party that establishes a proof that links a public key and other relevant information to its owner. Ciphertext - Enciphered information. Cold Reset - The reset of the ICC that occurs when the supply voltage (VCC) and other signals to the ICC are raised from the inactive state and the reset (RST) signal is applied. Command - A message sent by the terminal to the ICC that initiates an action and solicits a response from the ICC. Concatenation - Two elements are concatenated by appending the bytes from the second element to the end of the first. Bytes from each element are represented in the resulting string in the same sequence in which they were presented to the terminal by the ICC, that is, most significant byte first. Within each byte bits are ordered from most significant bit to least significant. A list of elements or objects may be concatenated by concatenating the first pair to form a new element, using that as the first element to concatenate with the next in the list, and so on. Contact - A conducting element ensuring galvanic continuity between integrated circuit(s) and external interfacing equipment. Cryptogram - Result of a cryptographic operation. Cryptographic Algorithm - An algorithm that transforms data in order to hide or reveal its information content.

May 31, 1998 ICC Card Specification for Payment Systems xv Data Integrity - The property that data has not been altered or destroyed in an unauthorised manner Decipherment - The reversal of a corresponding encipherment Digital Signature - An asymmetric cryptographic transformation of data that allows the recipient of the data to prove the origin and integrity of the data, and protect the sender and the recipient of the data against forgery by third parties, and the sender against forgery by the recipient. Embossing - Characters raised in relief from the front surface of a card. Encipherment - The reversible transformation of data by a cryptographic algorithm to produce ciphertext. Epilogue Field - The final field of a block. It contains the error detection code (EDC) byte(s). Financial Transaction - The act between a cardholder and a merchant or acquirer that results in the exchange of goods or services against payment. Function - A process accomplished by one or more commands and resultant actions that are used to perform all or part of a transaction. Guardtime - The minimum time between the trailing edge of the parity bit of a character and the leading edge of the start bit of the following character sent in the same direction. Hash Function - A function that maps strings of bits to fixed-length strings of bits, satisfying the following two properties:

  • It is computationally infeasible to find for a given output an input which maps to this output.
  • It is computationally infeasible to find for a given input a second input that maps to the same output. Additionally, if the hash function is required to be collision-resistant, it must also satisfy the following property:
  • It is computationally infeasible to find any two distinct inputs that map to the same output. Hash Result - The string of bits that is the output of a hash function. Inactive - The supply voltage (VCC) and other signals to the ICC are in the inactive state when they are at a potential of 0.4 V or less with respect to ground (GND). xvi ICC Card Specification for Payment Systems May 31, 1998 Integrated Circuit(s) - Electronic component(s) designed to perform processing and/or memory functions. Integrated Circuit(s) Card - A card into which one or more integrated circuits are inserted to perform processing and memory functions. Integrated Circuit Module - The sub-assembly embedded into the ICC comprising the IC, the IC carrier, bonding wires, and contacts. Interface Device - That part of a terminal into which the ICC is inserted, including such mechanical and electrical devices that may be considered part of it. Key - A sequence of symbols that controls the operation of a cryptographic transformation. Magnetic Stripe - The stripe containing magnetically encoded information. Message - A string of bytes sent by the terminal to the card or vice versa, excluding transmission-control characters. Message Authentication Code - A symmetric cryptographic transformation of data that protects the sender and the recipient of the data against forgery by third parties. Nibble - The four most significant or least significant bits of a byte. Padding - Appending extra bits to either side of a data string. Path - Concatenation of file identifiers without delimitation. Payment System - For the purposes of this specification, Europay International S.A., MasterCard International Incorporated, or Visa International Service Association. Payment Systems Environment - The set of logical conditions established within the ICC when a payment system application conforming to this specification has been selected, or when a directory definition file (DDF) used for payment system application purposes has been selected. Plaintext - Unenciphered information. Private Key - That key of an entity’s asymmetric key pair that should only be used by that entity. In the case of a digital signature scheme, the private key defines the signature function. Prologue Field - The first field of a block. It contains subfields for node address (AD), protocol control byte (PCB), and length (LEN). May 31, 1998 ICC Card Specification for Payment Systems xvii Public Key - That key of an entity’s asymmetric key pair that can be made public. In the case of a digital signature scheme, the public key defines the verification function. Public Key Certificate - The public key information of an entity signed by the certification authority and thereby rendered unforgeable. Redundancy - Any information that is known and can be checked. Response - A message returned by the ICC to the terminal after the processing of a command message received by the ICC. Secret Key - A key used with symmetric cryptographic techniques and usable only by a set of specified entities. Script - A command or a string of commands transmitted by the issuer to the terminal for the purpose of being sent serially to the ICC as commands. Signal Amplitude - The difference between the high and low voltages of a signal. Signal Perturbations - Any abnormal conditions occurring on a signal such as undershoot/overshoot, electrical noise, ripple, spikes, crosstalk, etc. State H - Voltage high on a signal line. May indicate a logic one or logic zero depending on the logic convention used with the ICC. State L - Voltage low on a signal line. May indicate a logic one or logic zero depending on the logic convention used with the ICC. Symmetric Cryptographic Technique - A cryptographic technique that uses the same secret key for both the originator’s and recipient’s transformation. Without knowledge of the secret key, it is computationally infeasible to compute either the originator’s or the recipient’s transformation. T=0 - Character-oriented asynchronous half duplex transmission protocol. T=1 - Block-oriented asynchronous half duplex transmission protocol. Template - Value field of a constructed data object, defined to give a logical grouping of data objects. Terminal - The device used in conjunction with the ICC at the point of transaction to perform a financial transaction. It incorporates the interface device and may also include other components and interfaces such as host communications. Warm Reset - The reset that occurs when the reset (RST) signal is applied to the ICC while the clock (CLK) and supply voltage (VCC) lines are maintained in their active state. xviii ICC Card Specification for Payment Systems May 31, 1998 4. Abbreviations and Notations The following abbreviations and notations are used in this specification. AAC Application Authentication Cryptogram AAR Application Authorisation Referral AC Application Cryptogram ACK Acknowledgment ADF Application Definition File AEF Application Elementary File AFL Application File Locator AID Application Identifier an Alphanumeric ans Alphanumeric Special APDU Application Protocol Data Unit ARPC Authorisation Response Cryptogram ARQC Authorisation Request Cryptogram ASN Abstract Syntax Notation ATC Application Transaction Counter ATR Answer to Reset b Binary BER Basic Encoding Rules BGT Block Guardtime BWI Block Waiting Time Integer BWT Block Waiting Time C Celsius or Centigrade C-APDU Command APDU May 31, 1998 ICC Card Specification for Payment Systems xix CBC CDOL CIN CLA CLK cn C-TPDU CVM CWI CWT DAD DC DDF DDOL DES DF DIR DIS ECB EDC EF etu FCI f FIPS Cipher Block Chaining Card Risk Management Data Object List Input Capacitance Class Byte of the Command Message Clock Compressed Numeric Command TPDU Cardholder Verification Method Character Waiting Time Integer Character Waiting Time Destination Node Address Direct Current Directory Definition File Dynamic Data Authentication Data Object List Data Encryption Standard Dedicated File Directory Draft International Standard Electronic Code Book Error Detection Code Elementary File Elementary Time Unit File Control Information Frequency Federal Information Processing Standard xx ICC Card Specification for Payment Systems May 31, 1998 GND hex. HHMM HHMMSS I-block IC ICC IEC IFD IFS IFSC IFSD IFSI IIH IIL INF INS I/O IOH IOL ISO KM KS kΩ Lc Ground Hexadecimal Hours, Minutes Hours, Minutes, Seconds Information Block Integrated Circuit Integrated Circuit Card International Electrotechnical Commission Interface Device Information Field Size Information Field Size for the ICC Information Field Size for the Terminal Information Field Size Integer High Level Input Current Low Level Input Current Information Field Instruction Byte of Command Message Input/Output High Level Output Current Low Level Output Current International Organisation for Standardisation Master Key Session Key Kilohm Exact Length of Data Sent by the TAL in a Case 3 or 4 Command May 31, 1998 ICC Card Specification for Payment Systems xxi lcm LDD Le Licc LEN Lr LRC M µm mA MAC max. MF MHz min. mm mΩ m/s µA µs N n NAD Least Common Multiple Length of the ICC Dynamic Data Maximum Length of Data Expected by the TAL in Response to a Case 2 or 4 Command Exact Length of Data Available (or Remaining) in the ICC to be Returned in Response to the Case 2 or 4 Command Received by the ICC Length Length of Response Data Field Longitudinal Redundancy Check Mandatory Micrometre Milliampere Message Authentication Code Maximum Master File Megahertz Minimum Millimetre Milliohm Meters per Second Microampere Microsecond Newton Numeric Node Address xxii NAK nAs NCA NI NIC NPE ns O P1 P2 P3 PAN PCA PCB PDOL pF PI PIC PIN PSA PSE PTS R-APDU R-block RFU ICC Card Specification for Payment Systems May 31, 1998 Negative Acknowledgment Nanoampere-second Length of the Certification Authority Public Key Modulus Length of the Issuer Public Key Modulus Length of the ICC Public Key Modulus Length of the ICC PIN Encipherment Public Key Modulus Nanosecond Optional Parameter 1 Parameter 2 Parameter 3 Primary Account Number Certification Authority Public Key Protocol Control Byte Processing Options Data Object List Picofarad Issuer Public Key ICC Public Key Personal Identification Number Payment System Application Payment System Environment Protocol Type Selection Response APDU Receive Ready Block Reserved for Future Use May 31, 1998 ICC Card Specification for Payment Systems xxiii RID RSA RST R-TPDU SAD S-block SCA SI SIC SFI SHA SW1 SW2 TAL TC TCK TDOL tF TLV TPDU tR TTL TVR V var. Registered Application Provider Identifier Rivest, Shamir, Adleman Algorithm Reset Response TPDU Source Node Address Supervisory Block Certification Authority Private Key Issuer Private Key ICC Private Key Short File Identifier Secure Hash Algorithm Status Word One Status Word Two Terminal Application Layer Transaction Certificate Check Character Transaction Certificate Data Object List Fall Time Between 90% and 10% of Signal Amplitude Tag Length Value Transport Protocol Data Unit Rise Time Between 10% and 90% of Signal Amplitude Terminal Transport Layer Terminal Verification Results Volt Variable xxiv ICC Card Specification for Payment Systems May 31, 1998 VCC VCC VIH VIL VOH VOL VPP WI WTX YYMMDD Voltage Measured on VCC Contact Supply Voltage High Level Input Voltage Low Level Input Voltage High Level Output Voltage Low Level Output Voltage Programming Voltage Waiting Time Integer Waiting Time Extension Year, Month, Day The following notations apply: ‘0’ to ‘9’ and ‘A’ to ‘F’ 16 hexadecimal digits # Number [...] Optional part A:= B A is assigned the value of B A = B Value of A is equal to the value of B A ≡ B mod n Integers A and B are congruent modulo the integer n, that is, there exists an integer d such that (A - B) = dn A mod n The reduction of the integer A modulo the integer n, that is, the unique integer 0 ≤ r < n for which there exists an integer d such that A = dn + r abs(n) Absolute value of an integer n defined as n if n ≥ 0, and as −n if n < 0 May 31, 1998 ICC Card Specification for Payment Systems xxv Y:= ALG(K)[X] X = ALG-1(K)[Y] Y:= Sign (SK)[X] X = Recover(PK)[Y] C:= (A || B) H:= Hash[MSG] lcm(a, b) |n| (X | n) xx Encipherment of a 64-bit data block X with a 64-bit block cipher as specified in Annex E1 using a secret key K Decipherment of a 64-bit data block Y with a 64-bit block cipher as specified in Annex E1 using a secret key K The signing of a data block X with an asymmetric reversible algorithm as specified in Annex E2, using the private key SK The recovery of the data block X with an asymmetric reversible algorithm as specified in Annex E2, using the public key PK The concatenation of an n-bit number A and an m-bit number B, which is defined as C = 2m A + B. Hashing of a message MSG of arbitrary length using an 80-bit hash function Least common multiple of two integers a and b Length of an integer n in bits The Jacobi symbol of an integer X with respect to an integer n = pq consisting of the product of two primes p and q, and which is defined as follows. Define J:= (X(p-1)/2 mod p)(X(q-1)/2 mod q) If J = 1 or J = (pq – p – q + 1), then (X  n):= 1. Otherwise, (X  n):= -1. Note that the Jacobi symbol can efficiently be computed without the prime factors of n (for example, see Informative Reference [5] in Annex G). Any value xxvi ICC Card Specification for Payment Systems May 31, 1998 THIS PAGE LEFT INTENTIONALLY BLANK Part I Electromechanical Characteristics, Logical Interface, and Transmission Protocols May 31, 1998 Part I - Electromechanical Characteristics and Protocols I-1 1. Electromechanical Interface This section covers the electrical and mechanical characteristics of the ICC and the terminal. ICC and terminal specifications differ to allow a safety margin to prevent damage to the ICC. The ICC characteristics defined herein are based on the ISO/IEC 7816 series of standards with some small variations.

1.1 Mechanical Characteristics of the ICC This section describes the physical characteristics, contact assignment, and mechanical strength of the ICC.

1.1.1 Physical Characteristics Except as otherwise specified herein, the ICC shall comply with the physical characteristics for ICCs as defined in ISO/IEC DIS 7816-1. The ICC shall also comply with the additional characteristics defined in ISO/IEC DIS 7816-1 as related to ultra-violet light, X-rays, surface profile of the contacts, mechanical strength, electromagnetic characteristics, and static electricity and shall continue to function correctly electrically under the conditions defined therein.

1.1.1.1 Module Height The highest point on the IC module surface shall not be greater than 0.05mm above the plane of the card surface. The lowest point on the IC module surface shall not be greater than 0.10mm below the plane of the card surface.

1.1.2 Dimensions and Location of Contacts The dimensions and location of the contacts shall be as shown in Figure I-1:

I-2 Part I

  • Electromechanical Characteristics and Protocols May 31, 1998 19.23 20.93 21.77 23.47 24.31 26.01 26.85 28.55 Figure I-1
  • ICC Contact Location and Dimensions It is recommended that the metallised contact areas be larger than the minimum specified wherever possible. The layout of the contacts relative to embossing and/or magnetic stripe shall be as shown in Figure I-2: Magnetic Stripe (Back of Card) Mandatory Contacts Optional Contacts Embossing Area Front of Card Figure I-2
  • Layout of Contacts 1.1.3 Contact Assignment The assignment of the ICC contacts shall be as defined in ISO/IEC DIS 7816-2 and is shown in Table I-1: May 31, 1998 Part I
  • Electromechanical Characteristics and Protocols I-3 C1 Supply voltage (VCC) C2 Reset (RST) C3 Clock (CLK) C5 Ground (GND) C6 Not used1 C7 Input/output (I/O) Table I-1
  • ICC Contact Assignment C4 and C8 are not used and need not be physically present. C6 is not used and need not be physically present; if present, it shall be electrically isolated2 from the integrated circuit (IC) itself and other contacts on the ICC.

1.2 Electrical Characteristics of the ICC This section describes the electrical characteristics of the signals as measured at the ICC contacts.

1.2.1 Measurement Conventions All measurements are made at the point of contact between the ICC and the interface device (IFD) contacts and are defined with respect to the GND contact over an ambient temperature range 0° C to 50° C. All currents flowing into the ICC are considered positive. Note: The temperature range limits are dictated primarily by the thermal characteristics of polyvinyl chloride (that is used for the majority of cards that are embossed) rather than by constraints imposed by the characteristics of the IC.

1.2.2 Input/Output (I/O) This contact is used as an input (reception mode) to receive data from the terminal or as an output (transmission mode) to transmit data to the terminal. During operation, the ICC and the terminal shall not both be in transmit mode. In the event that this condition occurs, the state (voltage level) of the I/O contact is indeterminate and no damage shall occur to the ICC.

1.2.2.1 Reception Mode When in reception mode, and with the supply voltage (VCC) in the range specified in section I-1.2.6, the ICC shall correctly interpret signals from the terminal having the characteristics shown in Table I-2: 1 Defined in ISO/IEC 7816 as programming voltage (VPP). 2 Electrically isolated means that the resistance measured between C6 and any other contact shall be ≥10MΩ with an applied voltage of 5V DC.

I-4 Part I

  • Electromechanical Characteristics and Protocols May 31, 1998 Symbol VIH VIL tR and tF Minimum 0.7 x VCC 0
  • Maximum VCC 0.8 1.0 Unit V V µs Table I-2
  • Electrical Characteristics of I/O for ICC Reception Note: The ICC shall not be damaged by signal perturbations on the I/O line in the range –0.3 V to VCC + 0.3 V.

1.2.2.2 Transmission Mode When in transmission mode, the ICC shall send data to the terminal with the characteristics shown in Table I-3: Symbol VOH VOL tR and tF Conditions –20 µA < IOH < 0, VCC = min. 0 < IOL < 1 mA, VCC = min. CIN (terminal) = 30 pF max. Minimum 0.7 x VCC 0

  • Maximum VCC 0.4 1.0 Unit V V µs Table I-3
  • Electrical Characteristics of I/O for ICC Transmission Unless transmitting, the ICC shall set its I/O line driver to reception mode. There is no requirement for the ICC to have any current source capability from I/O.

1.2.3 Programming Voltage (VPP) The ICC shall not require VPP (see note in section I-1.3.3).

1.2.4 Clock (CLK) With VCC in the range specified in section I-1.2.6, the ICC shall operate correctly with a CLK signal having the characteristics shown in Table I-4: Symbol VIH VIL tR and tF Conditions VCC = min. to max. Minimum Maximum Unit VCC – 0.7 VCC V 0 0.5 V - 9% of clock period Table I-4

  • Electrical Characteristics of CLK to ICC Note: The ICC shall not be damaged by signal perturbations on the CLK line in the range –0.3 V to VCC + 0.3 V. May 31, 1998 Part I
  • Electromechanical Characteristics and Protocols I-5 The ICC shall operate correctly with a CLK duty cycle of between 44% and 56% of the period during stable operation. The ICC shall operate correctly with a CLK frequency in the range 1 MHz to 5 MHz. Note: Frequency shall be maintained by the terminal to within ± 1% of that used during the answer to reset throughout the card session.

1.2.5 Reset (RST) With VCC in the range specified in section I-1.2.6, the ICC shall correctly interpret a RST signal having the characteristics shown in Table I-5: Symbol VIH VIL tR and tF Conditions VCC = min. to max. Minimum VCC – 0.7 0

  • Maximum VCC 0.6 1.0 Unit V V µs Table I-5
  • Electrical Characteristics of RST to ICC Note: The ICC shall not be damaged by signal perturbations on the RST line in the range –0.3 V to VCC + 0.3 V. The ICC shall answer to reset asynchronously using active low reset.

1.2.6 Supply Voltage (VCC) The ICC shall operate correctly with a supply voltage VCC of 5 V ± 0.5 V DC and have a maximum current requirement of 50 mA when operating at any frequency within the range specified in section I-1.2.4. Note: It is strongly recommended that the current consumption of ICCs is maintained at as low a value as possible, since the maximum current consumption allowable for the ICC may be reduced in future versions of this specification. Issuers of ICCs bearing multisector applications should ensure that the IC used has a current requirement compatible with all terminals (from all sectors) in which the ICC might be used.

1.2.7 Contact Resistance The contact resistance as measured across a pair of clean ICC and clean nominal IFD contacts shall be less than 500 mΩ throughout the design life of an ICC (see ISO/IEC 10373 for test method). Note: A nominal IFD contact may be taken as a minimum of 1.25 µm of gold over 5.00 µm of nickel.

I-6 Part I - Electromechanical Characteristics and Protocols May 31, 1998 1.3 Mechanical Characteristics of the Terminal This section describes the mechanical characteristics of the terminal interface device.

1.3.1 Interface Device The IFD into which the ICC is inserted shall be capable of accepting ICCs having the following characteristics:

  • Physical characteristics compliant with ISO/IEC DIS 7816-1
  • Contacts on the front, in the position compliant with Figure 2 of ISO/IEC DIS 7816-2
  • Embossing compliant with ISO/IEC 7811-1 and 3 The IFD contacts shall be located such that if an ICC having contacts with the dimensions and locations specified in Figure I-3 is inserted into the IFD, correct connection of all contacts shall be made. Figure I-3 - Terminal Contact Location and Dimensions Location guides and clamps (if used) shall cause no damage to ICCs, particularly in the areas of the magnetic stripe, signature panel, embossing, and hologram. May 31, 1998 Part I - Electromechanical Characteristics and Protocols I-7 Note: As a general principle, an ICC should be accessible to the cardholder at all times. Where the ICC is drawn into the IFD, a mechanism should exist to return the ICC to the cardholder in the event of a failure (for example, loss of power).

1.3.2 Contact Forces The force exerted by any one IFD contact on the corresponding ICC contact shall be in the range 0.2 N to 0.6 N.

1.3.3 Contact Assignment The assignment of the IFD contacts shall be as shown in Table I-6: C1 VCC C2 RST C3 CLK C5 GND C6 Not used3 C7 I/O Table I-6 - IFD Contact Assignment C4 and C8 are not used and need not be physically present. C6 shall be electrically isolated4. Note: If connected in existing terminals, C6 shall be maintained at a potential between GND and 1.05 x VCC throughout the card session. Keeping C6 isolated in new terminals facilitates its use for other purposes if so defined in future versions of this specification.

1.4 Electrical Characteristics of the Terminal This section describes the electrical characteristics of the signals as measured at the IFD contacts.

1.4.1 Measurement Conventions All measurements are made at the point of contact between the ICC and the IFD contacts and are defined with respect to GND contact over an ambient temperature range 0° C to 50° C. All currents flowing out of the terminal are considered positive.

1.4.2 Input/Output (I/O) This contact is used as an output (transmission mode) to transmit data to the ICC or as an input (reception mode) to receive data from the ICC. During operation, the terminal and the ICC shall not both be in transmit mode. In the event that this 3 Defined in ISO/IEC 7816 as programming voltage (VPP). 4 Electrically isolated means that the resistance measured between C6 and any other contact shall be ≥10MΩ with an applied voltage of 5V DC.

I-8 Part I - Electromechanical Characteristics and Protocols May 31, 1998 condition occurs, the state (voltage level) of the contact is indeterminate and no damage shall occur to the terminal. When both the terminal and the ICC are in reception mode, the contact shall be in the high state. To achieve this, the terminal shall incorporate a pull-up resistor to VCC, or other device. The terminal shall not pull I/O high unless VCC is powered and stable within the tolerances specified in section I-1.4.6. See the contact activation sequence specified in section I-2.1.2. The terminal shall limit the current flowing into or out of the I/O contact to ±15 mA at all times.

1.4.2.1 Transmission Mode When in transmission mode, the terminal shall send data to the ICC with the characteristics shown in Table I-7: Symbol VOH VOL tR and tF Signal perturbations Conditions 0 < IOH < 20 µA, VCC = min. - 0.5 mA < IOL < 0, VCC = min. CIN(ICC) = 30 pF max. Signal low Minimum 0.8 x VCC 0 - 0.25 Maximum VCC 0.4 0.8 0.4 Signal high 0.8 x VCC VCC + 0.25 Unit V V µs V V Table I-7 - Electrical Characteristics of I/O for Terminal Transmission Unless transmitting, the terminal shall set its I/O line driver to reception mode.

1.4.2.2 Reception Mode When in reception mode, the terminal shall correctly interpret signals from the ICC having the characteristics shown in Table I-8: Symbol VIH VIL tR and tF Minimum 0.6 x VCC 0

  • Maximum VCC 0.5 1.2 Unit V V µs Table I-8
  • Electrical Characteristics of I/O for Terminal Reception May 31, 1998 Part I
  • Electromechanical Characteristics and Protocols I-9 1.4.3 Programming Voltage (VPP) The terminal shall not generate a VPP (see section I-1.3.3).

1.4.4 Clock (CLK) The terminal shall generate a CLK signal having the characteristics shown in Table I-9: Symbol VOH VOL tR and tF Signal perturbations Conditions 0 < IOH < 50 µA, VCC = min. - 50 µA < IOL < 0, VCC = min. CIN(ICC) = 30 pF max. Signal low Signal high Minimum VCC – 0.5 0 - - 0.25 VCC – 0.5 Maximum VCC 0.4 8% of clock period 0.4 VCC + 0.25 Unit V V V V Table I-9 - Electrical Characteristics of CLK from Terminal Duty cycle shall be between 45% and 55% of the period during stable operation. Frequency shall be in the range 1 MHz to 5 MHz and shall not change by more than ± 1% throughout a card session (see section I-2).

1.4.5 Reset (RST) The terminal shall generate a RST signal having the characteristics shown in Table I-10: Symbol VOH VOL TR and tF Signal perturbations Conditions 0 &lt; IOH &lt; 50 µA, VCC = min. - 50 µA &lt; IOL < 0, VCC = min. CIN(ICC) = 30 pF max. Signal low Signal high Minimum VCC - 0.5 0 - 0.25 Maximum VCC 0.4 0.8 0.4 VCC – 0.5 VCC + 0.25 Table I-10

  • Electrical Characteristics of RST from Terminal Unit V V µs V V I-10 Part I
  • Electromechanical Characteristics and Protocols May 31, 1998 1.4.6 Supply Voltage (VCC) The terminal shall generate a VCC of 5 V ± 0.4 V DC and shall be capable of delivering steady state output current in the range 0 to 55 mA whilst maintaining VCC within these tolerances. The terminal shall contain protection circuitry to prevent damage occurring to it in the event of fault conditions such as a short circuit to GND or VCC. This supply shall be protected from transients and surges caused by internal operation of the terminal and from external interference introduced via power leads, communications links, etc. VCC shall never be negative with respect to ground. During normal operation of an ICC, current pulses cause voltage transients on VCC as measured at the ICC contacts. The power supply shall be able to counteract transients in the current consumption of the ICC up to a maximum charge of 40 nAs with no more than 400 ns duration and a maximum amplitude of 100 mA, ensuring that VCC remains within the range specified. Note: Terminals may be designed to be capable of delivering more than 55 mA if required, but it is recommended that terminals limit the steady state current that can be delivered to a maximum of 200 mA.

1.4.7 Contact Resistance The contact resistance as measured across a pair of clean IFD and clean nominal ICC contacts shall be less than 500 mΩ throughout the design life of a terminal (see ISO/IEC DIS 7816-1 for test method). Note: A nominal ICC contact may be taken as 1.25 µm of gold over 5.00 µm of nickel.

1.4.8 Short Circuit Resilience The terminal shall be capable of sustaining a short circuit of any duration between any or all contacts without suffering damage or malfunction, for example, if a metal plate or an ICC with a metallic surface is inserted.

1.4.9 Powering and Depowering of Terminal with ICC in Place If the terminal is powered on or off with an ICC in place no spurious signals or power perturbations shall appear at the interface contacts. Contact activation and deactivation sequences and timings, as described in sections I-2.1.2 and I-2.1.5 respectively shall be respected.

May 31, 1998 Part I - Electromechanical Characteristics and Protocols I-11 2. Card Session This section describes all stages involved in a card session from insertion of the ICC into the IFD through the execution of the transaction to the removal of the ICC from the IFD.

2.1 Normal Card Session This section describes the processes involved in the execution of a normal transaction.

2.1.1 Stages of a Card Session A card session is comprised of the following stages: 1. Insertion of the ICC into the IFD and connection and activation of the contacts. 2. Reset of the ICC and establishment of communication between the terminal and the ICC. 3. Execution of the transaction(s). 4. Deactivation of the contacts and removal of the ICC.

2.1.2 ICC Insertion and Contact Activation Sequence On insertion of the ICC into the IFD, the terminal shall ensure that all signal contacts are in state L with values of VOL as defined in section I-1.4 and that VCC is 0.4 V or less before any contacts are physically made. The IFD shall be able to detect when the ICC is seated to within ±0.5 mm of the nominally correct position5 in the direction of insertion/withdrawal. When the IFD detects that the ICC is seated within this tolerance, and when all contacts have been physically made, the contacts shall be activated as follows (see Figure I-4):

  • RST shall be maintained by the terminal in state L throughout the activation sequence.
  • Following establishment of the physical contacts but prior to activation of I/O or CLK, VCC shall be powered.
  • Following verification by the terminal that VCC is stable and within the limits defined in section I-1.4.6, the terminal shall set its I/O line driver to reception mode and shall provide CLK with a suitable and stable clock as defined in section I-1.4.4. The I/O line driver in the terminal may be set to reception mode prior to 5 The ‘nominally correct position’ is when the centres of the IFD contacts are exactly over the centres of the ICC contacts located as specified in ISO/IEC DIS 7816-2. I-12 Part I - Electromechanical Characteristics and Protocols May 31, 1998 application of the clock but shall be set to reception mode no later than 200 clock cycles after application of the clock. Note: The terminal may verify the state of Vcc by measurement, by waiting sufficient time for it to stabilise according to the design of the terminal, or otherwise. The state of the I/O line after the terminal has set its I/O line driver to reception mode is dependent upon the state of the I/O line driver in the ICC (see section I-2.1.3.1). VCC RST CLK I/O Cardinserted here Indeterminate 200cycles Figure I-4 - Contact Activation Sequence 2.1.3 ICC Reset The ICC shall answer to reset asynchronously using active low reset. The means of transportation of the answer to reset (ATR) are described in section I3 and its contents are described in sections I-4.2 and I-4.3.

2.1.3.1 Cold Reset Following activation of the contacts according to section I-2.1.2, the terminal shall initiate a cold reset and obtain an ATR from the ICC as follows (see Figure I-5):

  • The terminal shall apply CLK at a notional time T0.
  • Within a maximum of 200 clock cycles following T0, the ICC shall set its I/O line driver to reception mode. Since the terminal shall also have set its I/O line driver to reception mode within this period, the I/O line is guaranteed to be in state H no later than 200 clock cycles following time T0.
  • The terminal shall maintain RST in state L through time T0 and for a period of between 40,000 and 45,000 clock cycles following time T0 to time T1, when it shall set RST to state H.
  • The answer to reset on I/O from the ICC shall begin between 400 and 40,000 clock cycles after time T1 (time t1 in Figure I-5).
  • If the answer to reset from the ICC does not begin within this time, the terminal shall initiate the deactivation sequence described in section I-2.1.5 (hereafter referred to as the ‘deactivation sequence’) within 50 ms. May 31, 1998 Part I - Electromechanical Characteristics and Protocols I-13 VCC RST CLK I/O Indeterminate 200cycles T0 t1 T1 Answer toReset Figure I-5 - Cold Reset Sequence 2.1.3.2 Warm Reset If the ATR received following a cold reset as described in section I-2.1.3.1 does not conform to the specification in section I-4, the terminal shall initiate a warm reset and obtain an ATR from the ICC as follows (see Figure I-6):
  • A warm reset shall start at a notional time T0’, at which time the terminal shall set RST to state L.
  • The terminal shall maintain VCC and CLK stable and within the limits defined in sections I-1.4.4 and I-1.4.6 throughout the warm reset sequence.
  • Within a maximum of 200 clock cycles following T0’, the ICC and terminal shall set their I/O line drivers to reception mode. The I/O line therefore is guaranteed to be in state H no later than 200 clock cycles following time T0’.
  • The terminal shall maintain RST in state L from time T0’ for a period of between 40,000 and 45,000 clock cycles following time T0’ to time T1’, when it shall set RST to state H.
  • The answer to reset on I/O from the ICC shall begin between 400 and 40,000 clock cycles after time T1’ (time t1’ in Figure I-6).
  • If the answer to reset from the ICC does not begin within this time, the terminal shall initiate the deactivation sequence within 50 ms. I-14 Part I - Electromechanical Characteristics and Protocols May 31, 1998 VCC RST CLK I/O Indeterminate 200cycles T0’ t1’ T1’ Answer toReset Figure I-6 - Warm Reset Sequence 2.1.4 Execution of a Transaction Selection of the application in the ICC and the subsequent exchange of information between the ICC and the terminal necessary to perform a transaction are described in Part III of this specification, and in the ICC Application Specification for Payment Systems.

2.1.5 Contact Deactivation Sequence As the final step in the card session, upon normal or abnormal termination of the transaction (including withdrawal of the ICC from the IFD during a card session), the terminal shall deactivate the IFD contacts as follows (see Figure I-7):

  • The terminal shall initiate the deactivation sequence by setting RST to state L.
  • Following the setting of RST to state L but prior to depowering VCC, the terminal shall set CLK and I/O to state L.
  • Following the setting of RST, CLK, and I/O to state L but prior to galvanic disconnection of the IFD contacts, the terminal shall depower VCC. VCC shall be 0.4 V or less prior to galvanic disconnection of the IFD contacts.
  • The deactivation sequence shall be completed within 100 ms. This period is measured from the time that RST is set to state L to the time that VCC reaches 0.4 V or less. May 31, 1998 Part I - Electromechanical Characteristics and Protocols I-15 VCC RST CLK I/O Indeterminate Cardremoved here Figure I-7 - Contact Deactivation Sequence 2.2 Abnormal Termination of Transaction Process If an ICC is prematurely removed from a terminal during execution of a transaction at speeds of up to 1 m/s, the terminal shall be capable of sensing the movement of the ICC relative to the IFD contacts, and of deactivating all IFD contacts in the manner described in section I-2.1.5 before the relative movement exceeds 1 mm. No electrical or mechanical damage shall be caused to the ICC under these conditions. Note: For ‘sliding carriage’ type IFDs, it may be possible for the terminal to sense the movement of the ICC/IFD contact sub-assembly relative to the main body of the IFD. In this event, it is not mandatory to be able to sense the movement of the ICC relative to the IFD contacts, but deactivation of the contacts shall be complete before any electrical contact is broken between the ICC and IFD. I-16 Part I - Electromechanical Characteristics and Protocols May 31, 1998 3. Physical Transportation of Characters During the transaction process, data is passed bidirectionally between the terminal and the ICC over the I/O line in an asynchronous half duplex manner. A clock signal is provided to the ICC by the terminal, and this shall be used to control the timing of this exchange. The mechanism of exchanging bits and characters is described below. It applies during the answer to reset and is also used by both transmission protocols as described in section I-5.

3.1 Bit Duration The bit duration used on the I/O line is defined as an elementary time unit (etu). A linear relationship exists between the etu on the I/O line and CLK frequency (f). During the answer to reset, the bit duration is known as the initial etu, and is given by the following equation: initial etu = 372 seconds, where f is in Hertz f Following the answer to reset (and establishment of the global parameters F and D, see section I-4), the bit duration is known as the current etu, and is given by the following equation: current etu = F seconds, where f is in Hertz Df Note: For the basic answer(s) to reset described in this specification, only values of F = 372 and 372 D = 1 are supported. Thus the initial and current etus are the same and are given by. In the f following sections of this specification where etu is referred to, it is current etu that is meant unless otherwise specified. Throughout the card session, f shall be in the range 1 MHz to 5 MHz.

3.2 Character Frame Data is passed over the I/O line in a character frame as described below. The convention used is specified in the initial character (TS) transmitted by the ICC in the ATR (see section I-4.3.1). Prior to transmission of a character, the I/O line shall be in state H. A character consists of 10 consecutive bits (see Figure I-8):

  • 1 start bit in state L May 31, 1998 Part I - Electromechanical Characteristics and Protocols I-17
  • 8 bits, which comprise the data byte
  • 1 even parity checking bit The start bit is detected by the receiving end by periodically sampling the I/O line. The sampling time shall be less than or equal to 0.2 etu. The number of logic ones in a character shall be even. The 8 bits of data and the parity bit itself are included in this check but not the start bit. The time origin is fixed as midway between the last observation of state H and the first observation of state L. The existence of a start bit shall be verified within 0.7 etu. Subsequent bits shall be received at intervals of (n + 0.5 ± 0.2) etu (n being the rank of the bit). The start bit is bit 1. Within a character, the time from the leading edge of the start bit to the trailing edge of the nth bit is (n ± 0.2) etu. The interval between the leading edges of the start bits of two consecutive characters is comprised of the character duration (10 ± 0.2) etu, plus a guardtime. Under error free transmission, during the guardtime both the ICC and the terminal shall be in reception mode (I/O line in state H). For T=0 only, if the ICC or terminal as receiver detects a parity error in a character just received, it shall set I/O to state L to indicate the error to the sender (see section I-5.2.3) H I/O L Start 8 data bits Parity Start 10 ± 0.2 etu Character Duration Guardtime Figure I-8 - Character Frame At the terminal transport layer (TTL), data shall always be passed over the I/O line most significant (m.s.) byte first. The order of bits within a byte (that is, whether the least significant (l.s.) or m.s. bit is transferred first) is specified in character TS returned in the answer to reset (see section I-4.3). I-18 Part I - Electromechanical Characteristics and Protocols May 31, 1998 4. Answer to Reset After being reset by the terminal as described in section I-2.1.3, the ICC answers with a string of bytes known as the ATR. These bytes convey information to the terminal that defines certain characteristics of the communication to be established between the ICC and the terminal. The method of transporting these bytes, and their meaning, is described below. Note: In sections I-4 and I-5, the m.s. bit of a character refers to bit b8 and the l.s. bit refers to bit b1. A value in inverted commas is coded in hexadecimal notation, for example, ‘3F’.

4.1 Physical Transportation of Characters Returned at Answer to Reset This section describes the structure and timing of the characters returned at the answer to reset. The bit duration is defined in section I-3.1, and the character frame is defined in section I-3.2. During the answer to reset, the minimum interval between the leading edges of the start bits of two consecutive characters shall be 12 initial etus, and the maximum interval between the leading edges of the start bits of two consecutive characters shall be 9600 initial etus. The ICC shall transmit all the characters to be returned during an answer to reset (warm or cold) within 19,200 initial etus6. This time is measured between the leading edge of the start bit of the first character (TS) and 12 initial etus after the leading edge of the start bit of the last character.

4.2 Characters Returned by ICC at Answer to Reset The number and coding of the characters returned by the ICC at the answer to reset varies depending upon the transmission protocol(s) and the values of the transmission control parameters supported. This section describes two basic answers to reset, one for ICCs supporting T=0 only and the other for ICCs supporting T=1 only. It defines the characters to be returned and the allowable ranges of values for the transmission control parameters. ICCs returning one of the two answers to reset described here are assured correct operation and interoperability in terminals conforming to this specification. For proprietary reasons ICCs may optionally support more than one transmission protocol, but one of the supported protocols shall be T=0 or T=1. The first offered protocol shall be T=0 or T=1, and the terminal shall continue the card session using 6 The maximum time allowed for the answer to reset varies according to clock frequency, since the period represented by an etu is frequency dependent (see section 3.1).

May 31, 1998 Part I - Electromechanical Characteristics and Protocols I-19 the first offered protocol unless for proprietary reasons it supports a mechanism for selecting an alternative protocol offered by the ICC. Support for such a mechanism is not required by, and is beyond the scope of these specifications. Note: This specification does not support ICCs having both T=0 and T=1 protocols present at the same time. This can only be achieved by proprietary means beyond the scope of this specification. Also for proprietary reasons ICCs may optionally support other values of the transmission control parameters at the issuer’s discretion. However, such support is considered outside the scope of this specification and such ICCs may be rejected at terminals conforming to this specification, which need not have the corresponding additional proprietary functionality required to support the ICC. The characters returned by the ICC at the answer to reset for the two basic answers to reset are shown in Tables I-11 and I-12. The characters are shown in the order in which they are sent by the ICC, that is, TS first. If protocol type T=0 only is supported (character-oriented asynchronous transmission protocol), the characters returned shall be as shown in Table I-11: Character TS T0 TB1 TC1 Value ‘3B’ or ‘3F’ ‘6x’ ‘00’ ‘00’ to ‘FF’ Remarks Indicates direct or inverse convention TB1 and TC1 present; x indicates the number of historical bytes present VPP not required Indicates the amount of extra guardtime required. Value ‘FF’ has a special meaning (see section I4.3.3.3) Table I-11 - Basic ATR for T=0 Only

I-20 Part I - Electromechanical Characteristics and Protocols May 31, 1998 If protocol type T=1 only is supported (block-oriented asynchronous transmission protocol), the characters returned shall be as shown in Table I-12: Character TS T0 TB1 TC1 TD1 TD2 TA3 TB3 TCK Value ‘3B’ or ‘3F’ ‘Ex’ ‘00’ ‘00’ to ‘FF’ ‘81’ ‘31’ ‘10’ to ‘FE’ m.s. nibble ‘0’ to ‘4;’ l.s. nibble ‘0’ to ‘5’ See section I-4.3.4 Remarks Indicates direct or inverse convention TB1 to TD1 present; x indicates the number of historical bytes present VPP not required Indicates amount of extra guardtime required. Value ‘FF’ has special meaning - see section I4.3.3.3 TA2 to TC2 absent; TD2 present; T=1 to be used TA3 and TB3 present; TC3 and TD3 absent; T=1 to be used Returns IFSI, which indicates initial value for information field size for the ICC and IFSC of 16254 bytes BWI = 0 to 4 CWI = 0 to 5 Check character Table I-12 - Basic ATR for T=1 Only 4.3 Character Definitions This section provides detailed descriptions of the characters that may be returned at the answer to reset. The presence or absence of a character, and the allowable range of values it may take (if present) if it is to conform to one of the basic ATRs is indicated by ‘basic response’ in the description of each character. The description of a basic response (even though indicated by ‘shall’) is not intended to preclude the use of other values of the characters, nor the omission/inclusion of a character at the issuer’s discretion. For example, the ICC may return additional characters if it supports more than one transmission protocol (see section I-5). However, only ICCs returning a basic ATR, or an ATR supported by the minimum required terminal functionality described below, are guaranteed to be supported correctly in interchange. Terminals conforming to this specification are only required (as a minimum) to support the basic ATRs described here together with any additional requirements specified in ‘terminal behaviour’. Terminals may thus reject an ATR not supported by this required functionality. However, terminals may, in addition, be capable of correctly interpreting an ATR that does not conform to this specification but that is returned by an ICC for proprietary (for example, national) use. Such terminal functionality is not mandatory and is beyond the scope of this specification. As a general principle, a terminal should accept a non basic ATR if it is able to function correctly with the ATR that was returned.

May 31, 1998 Part I - Electromechanical Characteristics and Protocols I-21 The maximum number of characters returned in the answer to reset (including the historical bytes but not including TS) shall be 32. Terminals shall be capable of checking the parity of characters returned in the answer to reset, but not necessarily as they are received. In the following character descriptions, if it is indicated that a terminal shall:

  • reject an ATR, it means that the terminal shall issue a warm reset if it is rejecting a cold ATR, or terminate the card session by deactivating the ICC contacts if it rejecting a warm ATR
  • reject an ICC, it means that the terminal shall terminate the card session by deactivating the ICC contacts
  • accept an ATR, it means that the terminal shall accept the ATR, but only if the requirements specified in this section for all other characters are also met. Each character description is structured in the following way:
  • title
  • explanation of usage as described in ISO/IEC 7816-3
  • EMV basic response. This response should always be used in a warm ATR to ensure interoperability
  • required terminal behaviour in the event that a terminal receives characters outside the range allowed by EMV 4.3.1 TS - Initial Character TS performs two functions. It provides a known bit pattern to the terminal to facilitate bit synchronisation, and it indicates the logic convention to be used for the interpretation of the subsequent characters. Using inverse logic convention, a low state L on the I/O line is equivalent to a logic one, and the m.s. bit of the data byte is the first bit sent after the start bit. Using direct logic convention, a high state H on the I/O line is equivalent to a logic one, and the l.s. bit of the data byte is the first bit sent after the start bit. The first four bits LHHL are used for bit synchronisation. Basic responses: The ICC shall return an ATR containing TS having one of two values:
  • (H)LHHLLLLLLH - inverse convention, value ‘3F’
  • (H)LHHLHHHLLH - direct convention, value ‘3B’ I-22 Part I - Electromechanical Characteristics and Protocols May 31, 1998 Terminal behaviour: The terminal shall be capable of supporting both inverse and direct convention and shall accept an ATR containing TS having a value of either ‘3B’ or ‘3F’. An ICC returning an ATR containing TS having any other value shall be rejected. Note: It is strongly recommended that a value of ‘3B’ is returned by the ICC since a value of ‘3F’ may not be supported in future versions of this specification.

4.3.2 T0 - Format Character T0 is comprised of two parts

The m.s. nibble (b5-b8) is used to indicate whether the subsequent characters TA1 to TD1 are present. Bits b5-b8 are set to the logic one state to indicate the presence of TA1 to TD1, respectively. The l.s. nibble (b1-b4) indicates the number of optional historical bytes present (0 to 15). (See Table I-13 for the basic response coding of character T0.) Basic responses: The ATR shall contain T0 = ‘6x’ if T=0 only is to be used, indicating that characters TB1 and TC1 are present. The ATR shall contain T0 = ‘Ex’ if T=1 only is to be used, indicating that characters TB1 to TD1 are present. The value of ‘x’ represents the number of optional historical bytes to be returned. Terminal behaviour: The terminal shall accept an ATR containing T0 of any value provided that the value returned correctly indicates and is consistent with the interface characters TA1 to TD1 and historical bytes actually returned b8 b7 b6 b5 b4 b3 b2 b1 T=0 only 0 1 1 0 x x x x T=1 only 1 1 1 0 x x x x Table I-13

  • Basic Response Coding of Character T0 4.3.3 TA1 to TC3
  • Interface Characters TA1 to TC3 convey information that shall be used during exchanges between the terminal and the ICC subsequent to the answer to reset. They indicate the values of the transmission control parameters F, D, I, P, and N, and the IFSC, block waiting time integer (BWI), and character waiting time integer (CWI) applicable to T=1 as defined in ISO/IEC 7816-3. The information contained in TA1, TB1, TC1, TA2, and TB2 shall apply to all subsequent exchanges irrespective of the protocol type to be used.

4.3.3.1 TA1 TA1 conveys the values of FI and DI where:

  • FI is used to determine the value of F, the clock rate conversion factor, which may be used to modify the frequency of the clock provided by the terminal subsequent to the answer to reset May 31, 1998 Part I - Electromechanical Characteristics and Protocols I-23
  • DI is used to determine the value of D, the bit rate adjustment factor, which may be used to adjust the bit duration used

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