PayPass Mag Stripe. Security Architecture

Transcription

1 PayPass Mag Stripe Security Architecture Version 1.3 November 2007

2 Copyright The information contained in this manual is proprietary and confidential to MasterCard International Incorporated or one of its affiliated entities (collectively MasterCard ) and its customer financial institutions. This material may not be duplicated, published, or disclosed, in whole or in part, without the prior written permission of MasterCard. Trademarks Trademark notices and symbols used in this manual reflect the registration status of MasterCard trademarks in the United States. Please consult with the Customer Operations Services team or the MasterCard Law Department for the registration status of particular product, program, or service names outside the United States. All third-party product and service names are trademarks or registered trademarks of their respective owners. Media This document is available in both electronic and printed format. MasterCard Worldwide - Chip Center of Excellence Chaussée de Tervuren, 198A B-1410 Waterloo Belgium specifications@paypass.com Version November MasterCard 2 PayPass Mag Stripe Security Architecture

3 Table of Contents Using this Manual... 5 Scope...5 Audience...5 Contents...5 Related Publications...6 Abbreviations PayPass Payments Security in Traditional Environments Magnetic Stripe Environment Virtual Environment PayPass Security Architecture Requirements PayPass Environment Business requirements Security Requirements Security Analysis Fraud Guessing Attacks Passive Attacks Active Attacks Real-time Active Attacks Denial of Service Privacy Invasion The Dynamic CVC3 Technique Introduction Purpose of Mechanism Data Requirements Card Data Data Elements Flow description Card processing Terminal processing Issuer processing Cryptographic Algorithms KD CVC3 Derivation IV CVC3 computation MasterCard Version November 2007 PayPass Mag Stripe Security Architecture 3

4 Table of Contents CVC3 Computation Dynamic CVC3 Assessment Security Considerations Fraud Attacks CVC3 Guessing Attacks Replay Attacks Preplay attacks Relay Attacks Denial of Service Attacks Security Recommendations Issuer Allocation of Discretionary Data Digits ATC Windowing Strategies Fraud Detection Acquirer Summary of Recommendations PayPass Mag Stripe Risk Model Risks to PayPass Guessing Attacks Replay Attacks Preplay Attacks Relay Attacks Risks to Other Environments Lack of Cardholder Approval Lack of Cardholder Authentication Lack of Terminal Authentication Data Privacy Denial of Service Conclusions Version November MasterCard 4 PayPass Mag Stripe Security Architecture

5 PayPass Payments Security in Traditional Environments Using this Manual This chapter contains information that helps you understand and use this document. Scope MasterCard PayPass technology enables fast, easy and globally accepted payments through the use of contactless chip technology on the traditional MasterCard card platform. PayPass Mag Stripe is designed specifically for authorization networks that presently support magnetic stripe card authorizations for credit or debit applications. This document provides a risk and threat analysis of credit and debit PayPass Mag Stripe payments. It uses the results of that analysis as the basis of an analysis of the PayPass Mag Stripe security features, mainly those based on the use of dynamic CVC3. The following steps are performed to conduct this analysis: Identification and analysis of security threats related to PayPass environment and of the vulnerabilities specific to PayPass. Description and analysis of a PayPass security solution based on dynamic CVC3. Security recommendations for use of PayPass dynamic CVC3. Analysis of the overall PayPass risk model. Audience This document is intended for use by acquirers acquiring PayPass Mag Stripe transactions and issuers issuing PayPass Mag Stripe cards. It is assumed that the audience already has an understanding of chip card technology in general. Contents A brief introduction to PayPass is provided, which forms the basis of the review of highlevel threats to PayPass payments. The security-relevant parts of the dynamic CVC3 technique, which is the main focus of this document, are described. This includes descriptions of the data elements, the main data flows, the cryptographic computations, and the processing by the card, the terminal and the issuer MasterCard Version November 2007 PayPass Mag Stripe Security Architecture 5

6 PayPass Payments Security in Traditional Environments Using that description, an analysis of the PayPass dynamic CVC3 mechanism is provided. This analysis is followed by detailed recommendations on system design and parameter choice arising from the analysis of possible attacks. The next part of the document provides a view of PayPass risk model, including a risk assessment and a description of other PayPass security measures. The last part of the document provides some conclusions. Related Publications The following publications contain information directly related to the contents of this specification. [FIPS PUB 46-3] FIPS PUB 46-3, Data Encryption Standard (DES), 25 October 1999 [ISO/IEC PAYPASS] PayPass ISO/IEC Implementation Specification, Version 1.1, March 2006 [ISO/IEC 7811/2] Identification cards Recording technique Part 2: Magnetic stripe [ISO/IEC 7813:1995] [ISO :1987] [ISO ] Identification cards Financial transaction cards ISO :1987, Banking -- Approved algorithms for message authentication -- Part 1: DEA ISO , Information Processing - Modes of Operation for a 64-Bit Block Cipher Algorithm [ISO/IEC ] ISO/IEC :1999, Information technology -- Security techniques -- Message Authentication Codes (MACs) -- Part 1: Mechanisms using a block cipher [ISO/IEC ] ISO/IEC :2005, Information technology -- Security techniques -- Encryption algorithms -- Part 3: Block ciphers [PAYPASS MAG] PayPass Mag Stripe Technical Specifications, Version 3.2, October 2006 Version November MasterCard 6 PayPass Mag Stripe Security Architecture

7 PayPass Payments Security in Traditional Environments Abbreviations The following abbreviations are used in this specification: Abbreviation Description 3DES Triple-DES ATC Application Transaction Counter BCD Binary Coded Decimal CVC1 Card Validation Code 1 CVC2 Card Validation Code 2 CVC3 Card Validation Code 3 DD Discretionary Data DES Data Encryption Standard DoS Denial of Service EMV Europay MasterCard Visa ICC Integrated Circuit Card ISO International Organization for Standardization MAC Message Authentication Code MO/TO Mail Order / Telephone Order NFC Near Field Communication PAN Primary Account Number PIN Personal Identification Number SSL Secure Socket Layer UN Unpredictable Number 2007 MasterCard Version November 2007 PayPass Mag Stripe Security Architecture 7

8 PayPass Payments Security in Traditional Environments Version November MasterCard 8 PayPass Mag Stripe Security Architecture

9 PayPass Payments Security in Traditional Environments 1 PayPass Payments A PayPass payment is a payment made using a chip card that does not need to be in physical contact with a card reader. That is, the card communicates with a merchant terminal via wireless means, instead of via chip card electrical contacts or via the reading of a magnetic stripe. Clearly, the wireless nature of the communication between the card and the terminal may introduce new threats to the system security. These new threats have to be tackled adequately by the PayPass security architecture. The purpose of PayPass Mag Stripe is to allow contactless chip payments to use authorization networks (proprietary and shared) that support magnetic stripe authorizations for credit or debit applications. In the text below, a number of assumptions are stated regarding the nature of the environments in which various types of payment are conducted. In particular the environmental conditions for traditional and virtual payments are contrasted with those arising for the PayPass environment. This enables the security vulnerability analysis to distinguish the different vulnerabilities arising from the PayPass environment. 1.1 Security in Traditional Environments Magnetic Stripe Environment Authentication In the traditional magnetic stripe environment both the card (credit or debit) and the cardholder are present at the merchant premises. The authentication process has the following characteristics. Card authentication: in magnetic stripe environments, the physical characteristics of the card such as embossing, hologram and/or brand logo may be checked by the merchant if present. In the case of an online transaction, mechanisms like the Card Validation Code (CVC1) give some level of assurance that the card is genuine. In practice, the possession of a valid card, i.e., a card containing the necessary data to conduct a payment, is often enough to complete a successful transaction. Cardholder authentication: this may be achieved through entry of a Personal Identification Number (PIN) or a signature by the cardholder. Some merchants require the cardholder to provide other evidence, e.g. the cardholder s passport, to demonstrate that the cardholder is the genuine owner of the card. However, in many cases where signature is used, merchants do not even compare the signature provided by the cardholder with the one on the back of the card. Hence, in practice, the authentication process is minimal when PIN is not used, and the possession of a valid card, i.e., a card containing the necessary data to conduct a payment, is often enough to complete a successful transaction MasterCard Version November 2007 PayPass Mag Stripe Security Architecture 9

10 PayPass Payments PayPass Security Architecture Requirements Terminal authentication: no mechanism exists to allow the cardholder to authenticate the terminal. Cardholders build a trust relationship with the merchant, and as a result trust that the merchant terminal is legitimate and has not been modified. If terminals are unattended, cardholders should verify by some means that the terminal is legitimate Payment Data The card provides a means of payment. In magnetic stripe environments, the necessary data to conduct a transaction include the Primary Account Number (PAN), the card expiry date, and the CVC1 of the card. These data are all contained in the card s magnetic stripe Virtual Environment In the virtual environment, neither the card (typically a credit card) nor the cardholder are present at the merchant site. The lack of human involvement in the transaction is one of the greatest benefits of e-commerce, as it allows the merchant to handle more transactions, more quickly and more cheaply. However, this benefit is also a source of security vulnerabilities Authentication In many cases there is neither card authentication nor cardholder authentication. Cardholder authentication is only available when security mechanisms like SecureCode are used, and is usually provided through password provision. The equivalent of terminal authentication is typically poor, although it can be supported by technical mechanisms like Secure Socket Layer (SSL) server authentication Payment Data Today s payments in the virtual world (including those made via the Internet as well as MO/TO transactions) usually require only the PAN and expiry date of the card, and optionally require the merchant to get the CVC2 of the card. The payment instructions are often transmitted over the Internet without any real protection, and card and payment data stored in merchant databases are often poorly protected. 1.2 PayPass Security Architecture Requirements PayPass Environment The PayPass environment can be regarded as a special case of the traditional environment, but has different characteristics, as follows. PayPass card: a card into which integrated circuit(s) and coupling means have been placed that allow communication with a PayPass coupling device (i.e., terminal) through inductive coupling. PayPass coupling device: a reader/writer device that uses inductive coupling to provide power to the PayPass card, and also to control the data exchange with the PayPass card. Version November MasterCard 10 PayPass Mag Stripe Security Architecture

11 PayPass Payments PayPass Security Architecture Requirements The device produces an energizing radio frequency field which couples to the card to transfer power and which is modulated for communication. A PayPass coupling device has typically an operating range of less than 4 cm. A PayPass coupling device may be part of a merchant terminal. Over-the-air transfer of data: card and payment data are transmitted over-the-air between a PayPass card and a PayPass coupling device integrated into a terminal. PayPass payments are designed with the following business drivers in mind: User convenience: PayPass payments are intended to be simple and fast, the tap and go description captures the ease and speed benefits to both cardholder and merchant. Merchants in particular may win significant process improvements as a result of increased transaction speed. Backwards compatibility: support of PayPass payments does not require significant modifications to acquirer, issuer or payment system infrastructure. Support of new form factors: PayPass payments allow for form factors that cannot be used with traditional cards, for instance key fobs or watches. PayPass design intends to fully deliver these benefits. However, this may cause some limitations to the PayPass security architecture, as the above business drivers may conflict with some potential security measures. Whenever required, the PayPass security architecture must accommodate appropriate trade-offs between security and functionality as is usual in any service Business requirements The choice of a particular security architecture for PayPass payments is driven by the following business requirements: The overall fraud in the system relating to the PayPass should not damage consumers trust in brand. PayPass should re-use and/or converge with existing and developing MasterCard programs. PayPass technology components must conform to international standards. These standards refer to ISO/IEC but also to security standards, e.g. for cryptographic algorithms. Risks levels should not be higher for PayPass transactions than for conventional magnetic stripe card based transactions. PayPass security architecture should be designed such as to minimize changes to acquirer s and issuer s operational processes and infrastructure. PayPass payment process must be quicker than cash, cheque and existing credit or debit card payment processes. This is an important requirement that implies that the processing time for each cryptographic operation and the number of computations required must be carefully considered MasterCard Version November 2007 PayPass Mag Stripe Security Architecture 11

12 PayPass Payments PayPass Security Architecture Requirements Security Requirements The security requirements are the starting point for the design of the security architecture. These requirements determine the security measures that have to be implemented to remove or reduce the vulnerabilities arising from the particular properties of the PayPass environment. In order for PayPass to provide a security level similar to the security level of magnetic stripe, it is mandatory to: Introduce an efficient anti-replay mechanism for PayPass transactions, and Limit the impact of fraudulent capture of PayPass data by fraudsters, both in the PayPass environment and in other environments. Version November MasterCard 12 PayPass Mag Stripe Security Architecture

13 Security Analysis Fraud 2 Security Analysis The threats and attacks that are identified and analyzed in this document are only the ones that derive from the particular nature of the PayPass environment. The analysis does not include threats that may already be found in other environments. It is not the intention of this document to try to address all the threats applicable to a payment environment, magnetic stripe, virtual, PayPass or other. The intention is instead to identify the new threats specific to the PayPass environment, and to analyze possible countermeasures. The characteristics of the PayPass environment and of its business drivers may result in potential vulnerabilities that may be exploited by fraudsters and lead to the following threats: Fraud, Denial of service (DoS), and Privacy invasion. 2.1 Fraud Fraudsters may attempt to conduct fraud, that is, generating fraudulent payment transactions, by using the following potential vulnerabilities: It may be possible to generate data as transmitted between card and terminal. Such a possibility might be exploited by fraudsters in guessing attacks. It may be possible to capture data transmitted between card and legitimate terminal during a genuine transaction. Such a possibility might be exploited by fraudsters in passive attacks. It may be possible to capture data transmitted between card and illegitimate terminal during an attacker-forced transaction. Such a possibility might be exploited by fraudsters in active attacks. It may be possible to use an illegitimate terminal in the proximity of genuine card to force fraudulent transaction without cardholder s consent. Such a possibility might be exploited by fraudsters in real-time active attacks Guessing Attacks It is feasible to guess or predict data to be transmitted between a card and legitimate terminal during a genuine transaction, without the need for eavesdropping actual transactions. This vulnerability may enable a fraudster to conduct fraudulent PayPass transactions MasterCard Version November 2007 PayPass Mag Stripe Security Architecture 13

14 Security Analysis Fraud Passive Attacks It is feasible to capture data transmitted over-the-air between a PayPass card and a legitimate terminal during a genuine transaction. This could, for example, be through the use of an illicit antenna and reader device that is either: Mobile and carried by the fraudster (e.g., in a rucksack) in the proximity of the genuine card and cardholder, such as in the queue of a fast food restaurant, or Fixed and placed in the proximity of the legitimate terminal, such as under an unattended terminal in a petrol station. This vulnerability may enable a fraudster to capture data that could be re-used to conduct either fraudulent PayPass transactions or fraudulent magnetic stripe card, contact chip card or electronic commerce transactions. Such attacks are also known as replay attacks. PayPass cards could be read from distances larger than the ranges supported by off-theshelf readers. However, long-distance receivers would require specific development, and their actual operating range would depend on receiver cost and antenna size. Reports indicate that receivers costing around $10K and featuring fairly large antennas and a large and heavy power supply may capture card data within a range of 1-2 meters. Smaller, "suitcase" readers would be limited to a range of half a meter. While in theory it is feasible to build a mobile antenna and for the fraudster to carry it, in practice this imposes severe constraints on the operational distance and on the dimensions of the antenna, since otherwise the noise received by the antenna is likely to be too great to enable data capture. A fixed antenna may be placed by the fraudster in the direct proximity of a legitimate terminal, but the success of this operation probably relies on there being poor physical protection for the legitimate terminal, since otherwise the noise received by the antenna is again likely to be too great to enable data capture. When installed at merchant locations, such fixed antennas are likely to be detected by classical fraud forensic mechanisms already in place Active Attacks It is possible that a legitimate or illegitimate terminal and/or reader device in the possession of a fraudster could be used to force the PayPass card to produce data, without the cardholder s consent (e.g., by placing a fraudulent terminal in proximity to a genuine card, e.g. in a crowded train or bus). The captured data could be used subsequently to conduct a fraudulent transaction. This vulnerability would enable the fraudster to capture data that could be re-used to conduct either a fraudulent PayPass transaction or a fraudulent magnetic stripe, contact chip or electronic commerce transaction. Such attacks are also known as preplay attacks. Clearly, to exploit this vulnerability, the only requirement for the fraudster is to possess a legitimate terminal or to build an illegitimate one. Note that such an illegitimate device may conduct PayPass transactions at greater operating distances then a legitimate device can, since it does not have to comply with [ISO/IEC PAYPASS] power requirements. Version November MasterCard 14 PayPass Mag Stripe Security Architecture

15 Security Analysis Denial of Service In addition to simply reading data from the card, the fraudster could attempt to force the conduct of a full fraudulent transaction by the PayPass card, without the cardholder s consent. The fraudster would then need to be able to submit the transaction to a legitimate terminal, using for instance a rogue PayPass card. This vulnerability could enable the conduct of a fraudulent transaction in the PayPass environment. The feasibility of active attacks depends largely on whether terminal authentication by the card takes place during a transaction. This is typically not the case because of backwards compatibility reasons, as the magnetic stripe environment does not provide support for terminal authentication Real-time Active Attacks When there are two fraudsters, one possessing a rogue card in the proximity of a legitimate terminal and the other possessing an illegitimate reader device in the proximity of a genuine card, and where a real-time communication link exists between the two fraudsters, so-called relay attacks may be set up. When the legitimate terminal initiates the transaction, the first fraudster forwards the commands sent to his rogue card to the second fraudster who makes the genuine card generate the necessary response. These data are forwarded to the first fraudster, who finalizes the transaction. In order to perform relay attacks, fraudsters need: A rogue card, An illicit reader, and A real-time communication means between the rogue card and the illegitimate reader. The data exchanges on that link have to comply with the PayPass timing requirements for the card-terminal communication. If the fraudster is him/herself a fraudulent merchant, this vulnerability is neither new nor specific to the PayPass environment. Such a merchant is likely to be identified by today s fraud detection mechanisms, as many complaints will be received from cardholders for a particular terminal and merchant. If the fraudster is not a merchant, this vulnerability may be harder to fix. However, exploiting it requires significant technical expertise, and a number of technological barriers (e.g., timing requirements) would have to be overcome. Note that the rollout of non-card form factor devices (especially those equipped with integrated communication capabilities, e.g., NFC-capable mobile phones) may make relay attacks easier to mount. However, they may also provide support for protection mechanisms. 2.2 Denial of Service It is possible that a legitimate or illegitimate terminal and/or reader device in the possession of a fraudster could be to conduct DoS attacks, in which they seek preventing a genuine card from being used to conduct (genuine) transactions MasterCard Version November 2007 PayPass Mag Stripe Security Architecture 15

16 Security Analysis Privacy Invasion 2.3 Privacy Invasion It is feasible to capture data transmitted over-the-air between a PayPass card and a legitimate terminal during a genuine transaction, or it may be possible to force a PayPass card to produce data, without the cardholder s consent. As such data carry cardholderrelated information, their capture may cause a threat to the cardholder s privacy. Version November MasterCard 16 PayPass Mag Stripe Security Architecture

17 The Dynamic CVC3 Technique Introduction 3 The Dynamic CVC3 Technique 3.1 Introduction The security requirements listed in Section 1.2 are the starting point for the design of the PayPass Mag Stripe security architecture. This section describes in detail the resulting dynamic CVC3 mechanism, which is an essential component of that architecture. For the sake of simplicity, the description of the dynamic CVC3 mechanism is limited to Track 2 data. The detailed specification covering both Track 1 and Track 2 data can be found in [PAYPASS MAG]. This online card authentication mechanism is designed to meet the following security requirements: Introduce an efficient anti-replay mechanism for PayPass transactions, and Limit the impact of fraudulent capture of PayPass data by fraudsters, both in the PayPass and other environments. This objective can be achieved in the PayPass environment by proving the legitimacy of the data transmitted over-the-air. This can be done through mechanisms requiring the card to authenticate itself dynamically. Hence for each transaction the card performs a unique dynamic action such that only the genuine card could perform this action and any replays of this action would be detected. 3.2 Purpose of Mechanism The dynamic CVC3 technique is a means to make the card perform a unique dynamic action per transaction and thereby to ensure the legitimacy of the transmitted data. It assumes online transactions. This mechanism is based on a challenge-response protocol, where a Message Authentication Code (MAC), referred to below as dynamic CVC3, is computed by the PayPass card as a function of several data elements, using a unique key shared between the card and the issuer. The data elements used as input in the MAC computation include the card PAN, a card-stored Application Transaction Counter (ATC) and an unpredictable number (UN) generated by the terminal. The ATC, UN and MAC, which are unique for each transaction, are sent by the terminal to the issuer for verification. There are actually two CVC3s calculated by a card at each transaction, the Track 1 CVC3 and the Track 2 CVC3. Both CVC3s are computed using the same technique. For the sake of clarity, the description below refers to Track 2 CVC3 only MasterCard Version November 2007 PayPass Mag Stripe Security Architecture 17

18 The Dynamic CVC3 Technique Data Requirements 3.3 Data Requirements Card Data In order to support the dynamic CVC3 computation, each PayPass card is equipped with the following dynamic data: An Application Transaction Counter (ATC), initially set by the card issuer, and which is incremented at every transaction. The ATC value for each card is also maintained by the card issuer. The following static data are also stored by the card to support the CVC3 computation: A secret 3DES key KD CVC3, derived from the Issuer Master Key IMK CVC3, as per Section A Track 2 template (see Section 3.3.2) A static IVCVC3 value, computed as a function of the Track 2 template stored on the card, as per Section The PUNATC and PCVC3 bitmaps (see Section 3.3.2) The NATC value specifying the number of digits from the ATC that must be transmitted to the card issuer for dynamic CVC3 validation (see Section 3.3.2) Data Elements The data elements used for the dynamic CVC3 computation or processing are detailed below: The Track 2 template is coded as follows: PAN FS ED SC DD where: PAN is the Primary Account Number, and contains up to 19 digits. FS is the Separator and has the value D. ED is the Expiration Date and contains 4 digits. SC is the Service Code and contains 3 digits. DD is the Discretionary Data, is BCD encoded and has a variable length of up to 13 digits. The PUNATC field is a card-provided bit string, where a mapping is defined between every bit in PUNATC and a digit position in the DD field. PUNATC carries a one in precisely those positions corresponding to digits of the DD field which are available for use in carrying digits from the UN and from the ATC. We write k for the number of ones in PUNATC. The PCVC3 field is a card-provided bit string, where a mapping is defined between every bit in PCVC3 and a digit position in the DD field. The PCVC3 carries a one in Version November MasterCard 18 PayPass Mag Stripe Security Architecture

19 The Dynamic CVC3 Technique Flow description precisely those positions corresponding to digits of the DD field which are available for use in carrying CVC3 digits. Thus, no bit position should be set to one in both the PUNATC and the PCVC3. We write q for the number of ones in the PCVC3 field. Note that this means that the CVC3 will consist of q digits (typically q=3). NATC is used to indicate the number of digits of the ATC that should be set by the terminal in the DD field (this number is also referred to as t). The UN field is an 8-digit number that contains up to 8 BCD digits randomly generated by the terminal. The most significant 8-n digits of UN, where n = k t, are set to zeroes, and are not sent to the issuer in the DD field. The ATC field contains the ATC value maintained by the card and is provided to the terminal each time a CVC3 is generated. The CVC3 is a 2-byte value computed by the card as a function of data both stored by the card and supplied to it by the terminal. The procedure used to compute the CVC3 is detailed in Section The DD field is computed by the terminal as a function of some or all of: The static part of the DD provided by the card to the terminal The value of n computed by the terminal from the values of k and t supplied The CVC3 and ATC supplied by the card to the terminal The UN generated by the terminal 3.4 Flow description A number of messages are exchanged between card and terminal before the actual sending of the UN by the terminal and the dynamic CVC3 by the card. This is illustrated in Figure 1. Only elements that are important for the security analysis of the online dynamic CVC3 mechanism are documented in this section. On receipt of the 'Get Processing Options' command, the card increments its transaction counter (ATC). In response to a 'Read Record' command, the card provides the Track 2 template, together with the PCVC3 and PUNATC bitmaps. It is important to note that all these values are fixed, i.e. the same values are supplied for every transaction. These values will be known to the card issuer, and the PUNATC, the PCVC3 and the NATC together define the positions of the digits within the DD which are free for use in the transaction authorization system. However, as mentioned above, the terminal will have no way of verifying the correctness of any of this data (except to check that the data is in the correct format). In response to a 'Compute Cryptographic Checksum' command containing the UN data element, the card computes a CVC3 value and returns it to the terminal, along with the card s ATC value. The terminal formats an authorization request message. This message contains a number of fields, including the DD value, as well as the card PAN and transaction-specific data. The terminal sends the authorization request message as formatted at the previous step to the card issuer MasterCard Version November 2007 PayPass Mag Stripe Security Architecture 19

20 The Dynamic CVC3 Technique Flow description PayPass Card PayPass Terminal 1. SELECT (AID) 2. FCI 3. GET PROCESSING OPTIONS (PDOL RELATED DATA) 4. AIP, AFL 5. READ RECORD 6. [TRACK 1 DATA], TRACK 2 DATA, [PUNATC TRACK1 ], PUNATC TRACK2, [PCVC3 TRACK1 ], PCVC3 TRACK2, [NATC TRACK1 ], NATC TRACK2, [UDOL], COMPUTE CRYPTOGRAPHIC CHECKSUM (UN) 8. [CVC3 TRACK1 ], CVC3 TRACK2, ATC Figure 1: PayPass Mag Stripe transaction flow Card processing The card increments the ATC value on receipt of the 'Get Processing Options' command from the terminal. The card returns the Track 2 template to the terminal in response to the 'Read Record Command'. Version November MasterCard 20 PayPass Mag Stripe Security Architecture

21 The Dynamic CVC3 Technique Flow description Following receipt of the 'Compute Cryptographic Checksum' command from the terminal, the card computes the CVC3 using the method described in Section 3.5.3, and returns it to the terminal Terminal processing The terminal performs the following checks on the Track 2 template received from the card in response to the 'Read Record' command. The terminal checks that k (the number of ones in the PUNATC bitmap) is greater than or equal to t. The terminal also checks that k t is at most 8 The terminal checks that q (the number of ones in the PCVC3 bitmap) is greater than or equal to 3 The terminal then generates an n-digit random value for the UN data element, left-pads it with zeroes up to 8-digits if needed, and sends it to the card. Following receipt of CVC3 and ATC from the card (sent in response to the 'Compute Cryptographic Checksum' command) the terminal constructs the DD by taking the static DD and making the following modifications: The value of n (1 decimal digit) is copied into the least significant digit position of the DD The q least significant decimal digits from CVC3 are copied into the positions indicated by the PCVC3 bitmap The n least significant decimal digits from UN are copied into the least significant n positions of the n+t positions indicated by the PUNATC bitmap The t least significant decimal digits from ATC are copied into the most significant t positions of the n+t positions indicated by the PUNATC bitmap Issuer processing The issuer recovers n, CVC3, the least significant n digits of UN, and the least significant t digits of the ATC from the DD received in the authorization request. The issuer checks that the value of n recovered is the expected value. The issuer conducts the CVC3 verification procedure. This procedure operates as follows: 1. Derive the card key KD CVC3 from the issuer master key IMK CVC3 and the card PAN received in the authorization request, using the method specified in Section Disassemble the Track 2 data received in the authorization request into the Track 2 template and the other data. Use the Track 2 template to recompute the twobyte IV CVC3 value, using the method specified in Section Reconstruct the 8-digit UN from the n digits in the DD by padding them with leading zeroes MasterCard Version November 2007 PayPass Mag Stripe Security Architecture 21

22 The Dynamic CVC3 Technique Cryptographic Algorithms 4. Compare the t ATC digits extracted from the DD with the stored ATC value for this card (ATC stored ). Let ATC min be the smallest 16-bit number with the property that ATC min > ATC stored and such that its decimal representation matches the t ATC digits in its least significant t positions. 5. Compute s = w / 10 t, where w represents the ATC window size, that is, how many ATCs greater than ATC stored are accepted by the issuer as valid ATCs for a particular card. 6. Perform the following steps for i = 0, 1,, s-1. a. If ATC min + i. 10 t > ATC stored + w the transaction is rejected and the checking process terminates. b. Create a 64-bit block from the recomputed IV CVC3 (16 bits), the UN (32 bits), and the binary representation of ATC min + i.10 t (16 bits). c. Encrypt the 64-bit block with KD CVC3, and truncate to the 2 least significant bytes. Compare the q least significant decimal digits from that result with the CVC3 obtained from the DD in the authorization request. d. If they agree, the transaction is authorized, the issuer should update the card ATC stored for this card to the value of ATC min + i. 10 t, and the checking process terminates. e. Proceed to the next value of i. f. The transaction is rejected and the checking process terminates without changing ATC stored. 3.5 Cryptographic Algorithms All cryptographic processes use a 3DES encryption function with two keys. The 3DES function is a good compromise between security and performance, and is sufficiently secure for the intended purpose 1. 3DES is included in [ISO/IEC ], standardized in [FIPS PUB 46-3], based on the Data Encryption Standard (DES) which is standardized in [ISO :1987] and [ISO :1987], and is recommended as the block cipher in EMV for the generation of Application Cryptograms, Issuer Authentication and Secure Messaging. Other algorithms may be faster but both their security and complexity of implementation are still under consideration. Note that key diversification is used thereby ensuring that each card contains a different key. 1 Use of two-key 3DES is currently believed to be secure until 2030, if by system design it cannot generate more than a few ciphertext under a single key. That is the case of dynamic CVC3 generation, as die to the size of the ATC each card can only generate 65,536 dynamic CVC3s. Version November MasterCard 22 PayPass Mag Stripe Security Architecture

23 The Dynamic CVC3 Technique Cryptographic Algorithms KD CVC3 Derivation As specified in the PayPass Mag Stripe Technical Specifications [PAYPASS MAG], the ICC derived key for CVC3 generation (KD CVC3 ) is a 16-byte 3DES key, derived from the Issuer Master Key for CVC3 generation (IMK CVC3 ) using the following procedure. Obtain a 64-bit block from the PAN by BCD-encoding the concatenation (from left to right) of the PAN digits and of the PAN sequence number 2 (if any), and right-padding with zeroes or right-truncating if needed.. Let X L be the 3DES encryption of the 64-bit block obtained from the PAN in the previous step, using IMK CVC3 as the key. If necessary, modify the least significant bit in every byte of X L to enforce odd parity. Note that parity adjustment is only needed when the underlying platform requires it. Let X R be the 3DES encryption of the bit-complement of the 64-bit block obtained from the PAN in the first step, using IMK CVC3 as the key. If necessary, modify the least significant bit in every byte of X R to enforce odd parity. Again, note that parity adjustment is only needed when the underlying platform requires it. Put KD CVC3 := X L X R IV CVC3 computation As specified in [PAYPASS MAG], the IV CVC3 is derived using the following procedure. Using the key KD CVC3, compute a CBC-MAC on the static part of the Track 2 template seen as a byte-string. The method used to compute the MAC is the ANSI Retail MAC, i.e., MAC Algorithm 3 specified in [ISO/IEC ], using the add a single 1 and as many zeros as necessary padding method (Padding Method 2). The two least significant byte of the MAC form the card-specific (static) IV CVC CVC3 Computation As specified in [PAYPASS MAG], the CVC3 is computed using the following procedure. A 64-bit block is assembled from three separate values, as follows: a. 16 bits from the (static) IVCVC3 value held by the card, and computed as a function of the Track 2 template (see Section 3.5.2), b. 32 bits are obtained from the 8 decimal digits of the UN, and c. 16 bits are obtained from the card ATC. The above 64-bit block is 3DES-encrypted using the card key KD CVC3. The two least significant bytes of the 64-bit ciphertext block resulting from the above encryption are used to form the CVC3. 2 The PAN sequence number is sometimes also called the card sequence number. If the PAN sequence number is supported, then it is stored in the discretionary data of the Track 1 Data and Track 2 Data at a location proprietary to the issuer MasterCard Version November 2007 PayPass Mag Stripe Security Architecture 23

24 The Dynamic CVC3 Technique Cryptographic Algorithms Version November MasterCard 24 PayPass Mag Stripe Security Architecture

25 Dynamic CVC3 Assessment Security Considerations 4 Dynamic CVC3 Assessment 4.1 Security Considerations Possible attacks on the dynamic CVC3 mechanism are divided into two main categories: Fraud attacks, in which a third party seeks to use a bogus card to conduct a fraudulent transaction, and DoS attacks, in which a third party seeks preventing a genuine card from being used to conduct (genuine) transactions. Other possible attacks (e.g. those involving use of a stolen or borrowed card) are not considered since these are not directly related to the method used to compute the dynamic CVC3 value. Similarly, threats to privacy are not considered as they are not addressed by the dynamic CVC3 technique. Note that throughout this chapter the term CVC3 refers to the n digit value as stored by the terminal in the DD as described in section Fraud Attacks The four types of fraud attacks identified in section 2.1 and their relation to the dynamic CVC3 technique are analyzed separately. The four types are: CVC3 guessing attacks, in which the fraudulent card supplies a random CVC3 value in response to a 'Compute Cryptographic Checksum' command. Replay attacks, in which the fraudulent card uses a (valid) CVC3 value intercepted (using a passive attack) from a previous valid transaction between a card and a terminal. Preplay attacks, in which the fraudulent card uses a (valid) CVC3 value obtained from a valid card using a fraudulent terminal (using an active attack). Relay attacks, in which an active attack is mounted in real-time CVC3 Guessing Attacks For this attack to have any chance of success the attacker needs to have access to the Track 2 template for a genuine card. This can be obtained by various means, including, but not limited to, eavesdropping of legitimate transactions. Only the probability of success in using a random CVC3 value is considered here MasterCard Version November 2007 PayPass Mag Stripe Security Architecture 25

26 Dynamic CVC3 Assessment Fraud Attacks The probability that the issuer verification of the CVC3 value will give a positive outcome is: 1 (1 10 -q ) s s 10 -q, where s is the windowing parameter, used to allow for ATC resynchronization, as described in section (for simplicity, it is assumed here that w is a multiple of 10 t, the probability above might slightly differ if that is not the case). As an example, if the CVC3 has q=3 digits, then the probability of a successful attack is 1 in 1000 for s=1, 1 in 500 for s=2, and 1 in 250 for s=4. This indicates that the choice of s is critical for determining the security of the mechanism Replay Attacks Again, the attacker is assumed to have access to the Track 2 template for the card being attacked (this could be obtained by monitoring one complete card/terminal data exchange). Even if the attacker has a number of sets of data derived from genuine transactions, i.e., the attacker knows a number of matching (ATC, UN, CVC3) triplets, the attacker can do no better than choose a random CVC3, i.e. the attack success probabilities are essentially the same as listed in Section This holds under the assumption that the attacker cannot afford to wait until the ATC value has recycled to its original value, or that the ATC does not recycle Preplay attacks Again, the attacker is assumed to have access to the Track 2 template for the card being attacked (this could be obtained by monitoring one complete card/terminal interchange). If the attacker has a single set of data derived from a genuine transaction, i.e., the attacker knows a matching (ATC, UN and CVC3) triplet, he/she may design a bogus card to output the known CVC3 value regardless of what the value of UN is. The probability that the issuer verification of the CVC3 value will give a positive outcome is simply: 10 -n + (1 10 -n ) 10 -q 10 -n q, i.e., 1 in 100 if n=2 and q=3, 1 in 500 if n=q=3, and 1 in 1000 if n>3 and q=3. If the attacker has r sets of data derived from r genuine transactions, i.e., the attacker knows r matching (UN, CVC3) pairs, he/she may equip a bogus card with these pairs and design it to output the correct CVC3 value if it is given a UN it knows otherwise it outputs a random CVC3 value. The probability that the issuer verification of the CVC3 value will give a positive outcome is simply r 10 -n + (1 r 10 -n ) 10 -q r 10 -n q (for small r), i.e. 1 in 50 if r=n=2 and q=3, 1 in 250 if r=2 and n=q=3, and nearly 1 in 1000 if r is small (say r<5), n>3 and q=3. Version November MasterCard 26 PayPass Mag Stripe Security Architecture

27 Dynamic CVC3 Assessment Denial of Service Attacks Of course the situation may become worse if it is practical for the attacker to obtain a large number of (UN, CVC) pairs. For example, if r=100 and n=q=3, then the probability of success is around 1 in 10. The probabilities given above apply to a single transaction and all of the ATC values are accepted by the issuer as the next transaction. Of course an attacker s bogus card can repeatedly attempt to conduct a transaction with a terminal, and abort each transaction until the terminal provides a UN for which the card knows the correct response. This means that it is important that the terminal monitors the number of aborted transactions (see also Section 5.2). Clearly, the false card will only work once (or a small number of times) since once an (ATC, UN, CVC3) triple is used, it cannot be used again (nor can any older values) Relay Attacks The CVC3 technique does not protect against relay attacks. However, conducting such attacks would require significant technical expertise, and a number of technological barriers (e.g., timing requirements) would have to be overcome by the fraudster. 4.3 Denial of Service Attacks We now consider the two following types of DoS attack: Attacks on the (genuine) card, and Attacks on the card issuer DoS Attacks on the Card A malicious party could seek rendering a card invalid by using an illicit terminal in the proximity of a valid card. One obvious attack is to cause the card to keep incrementing its ATC until it goes beyond the limit at which the issuer will accept the ATC value. This would require s 10 t false transactions. Hence, if s = t = 2, then this attack would require 200 false transactions DoS Attacks on the Issuer A malicious entity cound seek rendering a card invalid by causing the issuer to increment its ATC so that it is larger than the value held by the card. In such a case all card transactions will be rejected until the card ATC value catches up with the card issuer. However, there seems no obvious way to launch such an attack unless the issuer increments its ATC without first checking the validity of a transaction or the attacker is prepared to perform a very large number of random CVC3 transactions, causing the ATC value held by the issuer to be incremented every time a random CVC3 is accepted. However such an attack is likely to be detected MasterCard Version November 2007 PayPass Mag Stripe Security Architecture 27

28 Security Recommendations Denial of Service Attacks Version November MasterCard 28 PayPass Mag Stripe Security Architecture

29 Security Recommendations Issuer 5 Security Recommendations 5.1 Issuer Allocation of Discretionary Data Digits DD digits are used for four different purposes by PayPass. The last position is used for n, referred to in [PAYPASS MAG] as n UN, n digits are used to carry the digits of the UN (where n = 0 or 1 n 8), t digits are used to carry the least significant t digits of the ATC, and q digits are used to carry the CVC3 values (where q 3). In addition, issuers may use some of the DD digits for proprietary purposes. Hence, the allocation of the digits available for PayPass results from a trade-off between functionality and security. Taking into account the fact that the last position of the DD is always used to carry n, a maximum of 12 digits is available and must be split between n, t and q. The variable parameters are n, t and q. In this case it would appear dangerous to use the ATC with t = 0 or 1, since the risk of a DoS attack would be high (or the value of s would be set so high as to increase the risk arising from other attacks, see section 5.1.2), although if there are very limited numbers of digits available then there is clearly no alternative. The recommended choices for n, t and q are then as indicated in Table 1. Table 1: Recommended choices for n, t and q Number of available DD digits n t q Note that it is assumed that choosing t=2 will mean that s can be chosen to be very small (i.e. 1 or 2) without an unacceptably high risk of accidental DoS. If choosing t=2 means that 2007 MasterCard Version November 2007 PayPass Mag Stripe Security Architecture 29

30 Security Recommendations Issuer s still has to be relatively large (say 3 or more), then it would be better to choose t=3 when 6 or more digits of the DD are available for use. In specific cases, e.g., when stand-in services are used that do not process all transactions, it might be required to use a larger value of t than recommended above, so as to allow for a larger ATC window from the last known ATC. The recommended choices for q, t and n are then as indicated in Table 2 and Table 3. Table 2: Recommended choices for n, t and q for stand-in (window: 1,000 transactions) Number of available DD digits n t q Table 3: Recommended choices for n, t and q for stand-in (window: 10,000 transactions) Number of available DD digits n t q ATC Windowing Strategies The parameter s (described in Section 3.4.3) may be needed to allow for resynchronization between the ATC value held in the card and the value held by the issuer. Although the issuer value cannot be increased (except through the receipt of a valid transaction) the value held by the card can be increased simply by a rogue terminal initiating a transaction. The choice of s will depend on a variety of factors, including the speed and ease with which the card ATC can be accidentally or deliberately incremented and the number of digits available for the ATC. However, use of a large value for s is potentially dangerous since, as described in Section 4.2.1, the probability of success of random CVC3 attacks can be significantly increased by allowing s to be large. Also, it should be noted that increasing s is sometimes a paradoxical way of coping with the lack of digits in the DD for storing the ATC. Multiplying s by 10 is functionally equivalent to decrementing q by 1, and decrementing q allows for incrementing t, which in turn reduces the need for increasing s. Version November MasterCard 30 PayPass Mag Stripe Security Architecture