PayPass – Mag Stripe - cardzone.cz Mag Stripe - Security... · MasterCard PayPass™ technology...

PayPass – Mag Stripe Security Architecture

Version 1.3 – November 2007

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 E-mail: [email protected]

Version 1.3 - November 2007 © 2007 MasterCard 2 PayPass – Mag Stripe Security Architecture

Confidential

Table of Contents

Using this Manual ................................................................................. 5

Scope ...........................................................................................................................5

Audience......................................................................................................................5

Contents.......................................................................................................................5

Related Publications ....................................................................................................6

Abbreviations ..............................................................................................................7

1 PayPass Payments .................................................................... 9

1.1 Security in Traditional Environments................................................................9 1.1.1 Magnetic Stripe Environment ..........................................................................9 1.1.2 Virtual Environment ......................................................................................10

1.2 PayPass Security Architecture Requirements .................................................10 1.2.1 PayPass Environment....................................................................................10 1.2.2 Business requirements ...................................................................................11 1.2.3 Security Requirements ...................................................................................12

2 Security Analysis ..................................................................... 13

2.1 Fraud ................................................................................................................13 2.1.1 Guessing Attacks ...........................................................................................13 2.1.2 Passive Attacks ..............................................................................................14 2.1.3 Active Attacks................................................................................................14 2.1.4 Real-time Active Attacks...............................................................................15

2.2 Denial of Service..............................................................................................15

2.3 Privacy Invasion...............................................................................................16

3 The Dynamic CVC3 Technique ............................................... 17

3.1 Introduction......................................................................................................17

3.2 Purpose of Mechanism.....................................................................................17

3.3 Data Requirements...........................................................................................18 3.3.1 Card Data .......................................................................................................18 3.3.2 Data Elements ................................................................................................18

3.4 Flow description...............................................................................................19 3.4.1 Card processing..............................................................................................20 3.4.2 Terminal processing.......................................................................................21 3.4.3 Issuer processing............................................................................................21

3.5 Cryptographic Algorithms ...............................................................................22 3.5.1 KDCVC3 Derivation .........................................................................................23 3.5.2 IVCVC3 computation........................................................................................23

© 2007 MasterCard Version 1.3 - November 2007 PayPass – Mag Stripe Security Architecture 3 Confidential

Table of Contents

3.5.3 CVC3 Computation .......................................................................................23

4 Dynamic CVC3 Assessment ................................................... 25

4.1 Security Considerations ...................................................................................25

4.2 Fraud Attacks ...................................................................................................25 4.2.1 CVC3 Guessing Attacks ................................................................................25 4.2.2 Replay Attacks...............................................................................................26 4.2.3 Preplay attacks ...............................................................................................26 4.2.4 Relay Attacks.................................................................................................27

4.3 Denial of Service Attacks ................................................................................27

5 Security Recommendations.................................................... 29

5.1 Issuer ................................................................................................................29 5.1.1 Allocation of Discretionary Data Digits ........................................................29 5.1.2 ATC Windowing Strategies...........................................................................30 5.1.3 Fraud Detection..............................................................................................31

5.2 Acquirer ...........................................................................................................31

5.3 Summary of Recommendations.......................................................................32

6 PayPass – Mag Stripe Risk Model .......................................... 33

6.1 Risks to PayPass..............................................................................................33 6.1.1 Guessing Attacks ...........................................................................................33 6.1.2 Replay Attacks...............................................................................................33 6.1.3 Preplay Attacks ..............................................................................................34 6.1.4 Relay Attacks.................................................................................................34 6.1.5 Risks to Other Environments .........................................................................34 6.1.6 Lack of Cardholder Approval ........................................................................35 6.1.7 Lack of Cardholder Authentication ...............................................................36 6.1.8 Lack of Terminal Authentication...................................................................37 6.1.9 Data Privacy...................................................................................................37 6.1.10 Denial of Service ...........................................................................................37

7 Conclusions ............................................................................. 39


Confidential

PayPass PaymentsSecurity 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 high-level 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.


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 14443 PAYPASS] PayPass – ISO/IEC 14443 Implementation Specification, Version 1.1, March 2006

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

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

[ISO 8731-1:1987] ISO 8731-1:1987, Banking -- Approved algorithms for message authentication -- Part 1: DEA

[ISO 8372-1987] ISO 8372-1987, Information Processing - Modes of Operation for a 64-Bit Block Cipher Algorithm

[ISO/IEC 9797-1] ISO/IEC 9797-1:1999, Information technology -- Security techniques -- Message Authentication Codes (MACs) -- Part 1: Mechanisms using a block cipher

[ISO/IEC 18033-3] ISO/IEC 18033-3:2005, Information technology -- Security techniques -- Encryption algorithms -- Part 3: Block ciphers

[PAYPASS MAG] PayPass – Mag Stripe Technical Specifications, Version 3.2 , October 2006


Confidential


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



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


PayPass Payments Security in Traditional Environments


Confidential


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

1.1.1 Magnetic Stripe Environment

1.1.1.1 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.


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.

1.1.1.2 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.

1.1.2 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.

1.1.2.1 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

1.1.2.2 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

1.2.1 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.


Confidential

PayPass PaymentsPayPass 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.

1.2.2 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 14443 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.


PayPass Payments PayPass Security Architecture Requirements

1.2.3 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.


Confidential

Security AnalysisFraud

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.

2.1.1 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.


Security Analysis Fraud

2.1.2 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-the-shelf 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.

2.1.3 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 14443 PAYPASS] power requirements.


Confidential

Security AnalysisDenial 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.

2.1.4 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.


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 cardholder-related information, their capture may cause a threat to the cardholder’s privacy.


Confidential

The Dynamic CVC3 TechniqueIntroduction

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.


The Dynamic CVC3 Technique Data Requirements

3.3 Data Requirements

3.3.1 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 KDCVC3, derived from the Issuer Master Key IMKCVC3, as per Section 3.5.1

• 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 3.5.2

• 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)

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


Confidential

The Dynamic CVC3 TechniqueFlow 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 3.5.3.

• 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.


The Dynamic CVC3 Technique Flow description

PayPass Card PayPass Terminal

1. SELECT (AID)

2. FCI

3. GET PROCESSING OPTIONS

4. AIP, AFL

7. COMPUTE CRYPTOGRAPHIC CHECKSUM

8. [CVC3TRACK1], CVC3TRACK2, ATC

(UN)

(PDOL RELATED DATA)

5. READ RECORD

6. [TRACK 1 DATA], TRACK 2 DATA, [PUNATCTRACK1], PUNATCTRACK2, [PCVC3TRACK1], PCVC3TRACK2, [NATCTRACK1], NATCTRACK2, [UDOL], ...

Figure 1: PayPass Mag Stripe transaction flow

3.4.1 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'.


Confidential

The Dynamic CVC3 TechniqueFlow 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.

3.4.2 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

3.4.3 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 KDCVC3 from the issuer master key IMKCVC3 and the card PAN received in the authorization request, using the method specified in Section 3.5.

2. 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 two-byte IVCVC3 value, using the method specified in Section 3.5.2.

3. Reconstruct the 8-digit UN from the n digits in the DD by padding them with leading zeroes.


The Dynamic CVC3 Technique Cryptographic Algorithms

4. Compare the t ATC digits extracted from the DD with the stored ATC value for this card (ATCstored). Let ATCmin be the smallest 16-bit number with the property that ATCmin > ATCstored and such that its decimal representation matches the t ATC digits in its least significant t positions.

5. Compute s = ⎡ w / 10t ⎤ , where w represents the ATC window size, that is, how many ATCs greater than ATCstored 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 ATCmin + i . 10t > ATCstored + w the transaction is rejected and the checking process terminates.

b. Create a 64-bit block from the recomputed IVCVC3 (16 bits), the UN (32 bits), and the binary representation of ATCmin + i .10t (16 bits).

c. Encrypt the 64-bit block with KDCVC3, 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 ATCstored for this card to the value of ATCmin + i . 10t, 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 ATCstored.

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 purpose1.

3DES is included in [ISO/IEC 18033-3], standardized in [FIPS PUB 46-3], based on the Data Encryption Standard (DES) which is standardized in [ISO 8731-1:1987] and [ISO 8731-1: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.


Confidential

The Dynamic CVC3 TechniqueCryptographic Algorithms

3.5.1 KDCVC3 Derivation As specified in the PayPass – Mag Stripe Technical Specifications [PAYPASS MAG], the ICC derived key for CVC3 generation (KDCVC3) is a 16-byte 3DES key, derived from the Issuer Master Key for CVC3 generation (IMKCVC3) 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 number2 (if any), and right-padding with zeroes or right-truncating if needed..

• Let XL be the 3DES encryption of the 64-bit block obtained from the PAN in the previous step, using IMKCVC3 as the key. If necessary, modify the least significant bit in every byte of XL to enforce odd parity. Note that parity adjustment is only needed when the underlying platform requires it.

• Let XR be the 3DES encryption of the bit-complement of the 64-bit block obtained from the PAN in the first step, using IMKCVC3 as the key. If necessary, modify the least significant bit in every byte of XR to enforce odd parity. Again, note that parity adjustment is only needed when the underlying platform requires it.

• Put KDCVC3 := XL || XR.

3.5.2 IVCVC3 computation As specified in [PAYPASS MAG], the IVCVC3 is derived using the following procedure.

• Using the key KDCVC3, 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 9797-1], 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) IVCVC3.

3.5.3 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 KDCVC3.

• 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.


The Dynamic CVC3 Technique Cryptographic Algorithms


Confidential

Dynamic CVC3 AssessmentSecurity 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 3.4.2.

4.2 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.

4.2.1 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.


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 3.4.3 (for simplicity, it is assumed here that w is a multiple of 10t, 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.

4.2.2 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 4.2.1. 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.

4.2.3 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 + 10-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 + 10-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 .


Confidential

Dynamic CVC3 AssessmentDenial 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).

4.2.4 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.

4.3.1.1 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 × 10t false transactions. Hence, if s = t = 2, then this attack would require 200 false transactions.

4.3.1.2 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.


Security Recommendations Denial of Service Attacks


Confidential

Security RecommendationsIssuer

5 Security Recommendations

5.1 Issuer

5.1.1 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 nUN,

• 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

5 1 1 3

6 1 2 3

7 2 2 3

8 3 2 3

9 4 2 3

10 4 2 4

11 4 3 4

12 5 3 4

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


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)


7 1 3 3

8 2 3 3

9 3 3 3

10 4 3 3

11 4 3 4

12 5 3 4

Table 3: Recommended choices for n, t and q for stand-in (window: 10,000 transactions)


8 1 4 3

9 2 4 3

10 3 4 3

11 4 4 3

12 4 4 4

5.1.2 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.


Confidential

Security RecommendationsAcquirer

When stand-in services are used that do not process all transactions, and when it is acceptable for the stand-in service to perform several CVC3 validations for a single CVC3, it might be more secure to increase the value of s and to use larger value for q and a smaller for t. This has the benefit of keeping a large q (hence better security) for most transactions (the ones sent to the issuer), while slightly degrading the security for a few transactions (the ones processed by the stand-in service). Table 4 provides recommended choices for q, t, n and s in that option.

Table 4: Recommended choices for n, t, q and s for stand-in when s>0 is allowed (window: 1,000 transactions)

Number of available DD digits n t q s (issuer)

s (stand-in)

6 1 2 3 1 10

7 1 2 4 1 10

8 2 2 4 1 10

9 3 2 4 1 10

10 4 2 4 1 10

11 5 2 4 1 10

12 5 2 5 1 10

5.1.3 Fraud Detection Although the probability that a fraudster can guess the correct CVC3 is small, fraudsters might still attempt sending CVCs until a valid one is found. Hence, the issuer should set up a fraud detection system, which should stop accepting transactions from a particular card once too many invalid CVCs have been received. In such a case, the issuer must not increment the ATC in his tables, otherwise he is likely to decline further CVCs received from the genuine card.

5.2 Acquirer As described in Section 4.2.2, one strategy for a rogue card (equipped with one or more valid ATC/UN/CVC3 triplets) is to repeatedly conduct (and abort) transactions with a terminal until the terminal chooses a UN value for which the card knows the correct CVC3 value. That is, at no stage will the false card provide an incorrect CVC3 value, and hence the attack cannot be detected by the issuer. It is thus important that the terminal also implements a fraud detection strategy based on consecutive aborted transactions, where a card behaving in this way is prevented from conducting more than a (small) number of aborted transactions.


Security Recommendations Summary of Recommendations

5.3 Summary of Recommendations The following recommendations must be followed to ensure an appropriate level of security.

• The issuer must keep track of the entire ATC in some way, i.e. must be able to find the complete ATC when receiving truncated ATC in the discretionary data (see also Section 3.4.3).

• The issuer must fix an appropriate strategy for managing and using the ATC (see Sections 3.4.2 and 5.1.2).

• If the dynamic CVC3 received by the issuer is invalid, the issuer must decline or block the card after a certain number of consecutive errors (see Section 5.1.2).

• The terminal must monitor the number of aborted transactions (as it is likely that someone is trying to get a specific value of UN) and take appropriate measures, e.g. introduce wait times after three aborted transactions (see Section 5.2).


Confidential

PayPass – Mag Stripe Risk ModelRisks to PayPass

6 PayPass – Mag Stripe Risk Model

6.1 Risks to PayPass

6.1.1 Guessing Attacks This refers to the possibility that an attacker, by choosing a CVC3 value at random, will guess the correct value for a particular transaction. Section 4.2.1 provides a detailed analysis of this attack.

The ease with which such an attack can be conducted is to some extent independent of how the CVC3 is computed. Assuming a 3-digit CVC3, such an attack has a probability of success of 10-3 Note that because the ATC is included in the CVC3 calculation, the fraudster needs to guess both the correct CVC3 value and also a plausible value for the ATC (that is, in line with the last transaction performed by the genuine cardholder). However, whether guessing a correct ATC presents an obstacle to the fraudster depends very much on the windowing strategy used by the card issuer when checking the CVC3 value. In the method outlined in Section 4.2.1, any partial ATC value will be accepted by the issuer, as long as, when combined with the ‘guessed’ high order digits, it yields the guessed CVC3.

The level of risk associated with this type of attack is similar to the level of risk of such an attack for magnetic stripe cards.

6.1.2 Replay Attacks This refers to the possibility that an attacker will intercept a valid CVC3 sent in a previous genuine transaction from a card to a terminal and will successfully use this, in some way, to conduct a fraudulent transaction.

While in theory it is feasible to build a mobile antenna to be carried by a fraudster, in practice this imposes severe constraints on the operational distance and on the dimensions of the antenna, since otherwise the signal received by the antenna is likely to be too noisy 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. When installed at merchant locations, such fixed antennas are likely to be detected by classical fraud forensics aiming at identifying dishonest merchants.

The risk of a successful replay attack is mitigated by use of the dynamic CVC3. The risk of such an attack is less than the risk of a skimming attack for a magnetic stripe card. From the analysis in Section 4.2.2, the probability of a successful attack is at little as 1 in 1000 if a 3-digit CVC3 is used.


PayPass – Mag Stripe Risk Model Risks to PayPass

6.1.3 Preplay Attacks This refers to the case where an attacker is able to obtain (manufacture or acquire) a fraudulent PayPass terminal, and then use this to initiate a transaction with a card while it is in the cardholder’s possession and without the cardholder’s knowledge.

Preplay attacks require technology similar to eavesdropping technology. The fake terminal device should be small and portable. It does not have to be installed at a merchant, but can remain with the fraudster. The probability of success of such an attack is made small by use of the dynamic CVC3, which forces fraudster to preplay a significant number of transactions.

Assuming that the ATC will not ‘cycle’ back to a previously used value within the period between a preplay and an attack, preplayed data will be of no use to an attacker unless it can be used before the card is used for a genuine transaction. Even if the preplayed data is used for an attack before the card is employed for a genuine transaction, then the attack can only work if the UN is correct and such an attack will only work once (since once an attack has been performed then the ATC held by the issuer will be updated, preventing further successful use of this data) – see Section 4.2.3.

6.1.4 Relay Attacks Relay attacks are not a new vulnerability or one specific to the PayPass environment. However, this vulnerability has a bigger impact in PayPass, as access to the card can potentially happen at any time, without the cardholder's knowledge and consent. In the classical chip payment environments, only legitimate yet fraudulent merchants may commit relay attacks. Such fraudulent merchants are easily identified and shut down.

The risk of relay attacks can be mitigated in two ways:

• By cardholder approval or authentication: if the cardholder must approve each transaction or authenticate himself/herself at each transaction, then it is very unlikely, although not infeasible, to synchronize the rogue payment transaction with what the cardholder would see as a genuine payment. One way of enforcing cardholder approval could be the use of on/off switches on the PayPass card or on the PayPass-carrying device when other form factors than cards are used

• By using an anti-relay transaction protocol validating strict timing constraints.

The former technique is not supported for reasons listed above. The latter would have a major impact on the card and terminal infrastructures. Hence, it is not supported in the current version of PayPass.

6.1.5 Risks to Other Environments A number of countermeasures may be used to avoid that data captured from PayPass cards is used for conducting fraudulent magnetic stripe transactions or e-commerce transactions.


Confidential


6.1.5.1 Use of PayPass-specific PANs

It is recommended that issuers use specific PAN ranges for their PayPass cards. Using such PANs ensures that PayPass sensitive data transmitted over-the-air are useless for the fraudster planning to perform fraudulent transactions in MO/TO or magnetic stripe acceptance environments.

6.1.5.2 Use of SecureCode

SecureCode implements a cardholder authentication mechanism. Hence, the capture of data from PayPass cards does not affect issuers using SecureCode.

6.1.5.3 Use of CVC2 for MO/TO

For a MO/TO transaction, as long as the merchant insists on CVC2 entry and uses the address verification service, the information obtained from eavesdropped or preplayed transactions is not sufficient for a fraudster to perform a transaction.

6.1.5.4 Support of DE22

When dynamic CVC3 is used, fraudsters may attempt to encode on magnetic stripe cards data eavesdropped or preplayed from PayPass transactions, and to present such cards to a magnetic stripe terminal. The terminal would accept the transaction as a magnetic stripe transaction, and request online authorization without performing the UN generation and Track2 formatting that should normally occur with PayPass transactions. The issuer would process the transaction as if it were a PayPass transaction.

Another risk is that fraudster could replay skimmed magnetic stripe data through the PayPass channel. The issuer would see such transactions as magnetic stripe transactions, and thus would validate the CVC1. By doing so, the fraudster would defeat any (or part of) the physical checks normally applied to magnetic stripe cards, e.g., hologram checks. This may be an issue for PayPass in classical card form factor, but it will become a greater concern when alternative form factors will emerge, as the nature of these form factors will make checking of their physical characteristics somewhat loose.

As a countermeasure, MasterCard mandates PayPass terminals to support the POS entry mode (DE22) data elements in the authorization messages, indicating whether the card has been actually read from the PayPass reader or from a magnetic stripe reader.

6.1.6 Lack of Cardholder Approval Typically, cardholder approval may not be required to complete a PayPass payment.



The absence of a cardholder approval mechanism in the PayPass environment may result in:

• The conduct of fraudulent transactions without the cardholder’s consent,

• The capture of data without the cardholder’s consent, and

• DoS attacks on the card.

Note that, even when a cardholder approval mechanism is used, the cardholder has no means of verifying that he is approving the expected transaction. This is essentially linked to the absence of terminal authentication.

Without a cardholder approval mechanism, any reader device in proximity of the card may activate the card. The card may then perform certain actions, e.g. produce transaction data, increment its ATC, etc.

The absence of cardholder approval is therefore a vulnerability that needs to be taken into account. Note that if terminal authentication is performed, only legitimate merchants may use a reader device, and hence only fraudulent merchants may benefit from the absence of a cardholder approval mechanism unless sophisticated relay attacks take place.

There exist several methods of implementing cardholder approval:

• The use of on/off switches on the PayPass card or on the PayPass-carrying device when other form factors than cards are used

• The protection of the card from any energizing radio frequency field unless the cardholder removes this protection, e.g. an envelope around the card, a mechanism present in the wallet, etc.

While the former method would make the cards more expensive and less reliable, the latter method may efficiently be used to reduce the risks of data capture during mailing, while the card is in transit to the cardholder.

6.1.7 Lack of Cardholder Authentication In the classical payment environment, a signature (or in some cases a PIN) is required for credit transactions and, for debit transactions, a PIN is typically required. In contrast, and because of the requirements for transaction speed and cardholder convenience, PayPass payments do not require the cardholder to be authenticated. Cardholder authentication would considerably reduce the risk of the conduct of fraudulent transactions, as it would also prevent an illegitimate cardholder from conducting a transaction. However this still does not ensure that the cardholder is really approving the transaction he thinks he is approving (this could partly be achieved through terminal authentication).

Several technical methods could be used to achieve cardholder authentication, for instance:

• The use of a PIN by the cardholder,

• The use of a biometric (e.g., fingerprint) verification mechanism at the card level, and

• The use of a biometric (e.g., retina) verification mechanism at the terminal level.

The implementation of such mechanisms in PayPass would make the cards more expensive, more complex to manufacture and less reliable, or it would increase the transaction time.


Confidential


Therefore, they are not explicitly supported in the current version of PayPass. However, with other form factors, the activation of the PayPass functionality may be subject to local cardholder authentication, based on the capabilities of the PayPass-carrying device.

6.1.8 Lack of Terminal Authentication Terminal authentication may prevent the use of illegitimate coupling devices3 and ensure the confidentiality of data transmitted over-the-air. PayPass does not use terminauthentication, which is not a new vulnerability, or one specific to the PayPass environment. However, the vulnerability cannot be ignored since the introduction of this new environment may induce cardholder confusion. This vulnerability may have a greater impact in the PayPass environment than in ‘traditional’ environments.

al

A terminal authentication mechanism would be complementary to the dynamic CVC3 system. It would enable the card to check the authenticity of the terminal, using for instance asymmetric cryptography. Once the terminal is authenticated, the card may also encrypt all sensitive data (and not part of them) using either the terminal’s public key or a symmetric session key, and the terminal is able to decrypt the data.

Using such a technique would have major impacts on the terminal infrastructures, and could have adverse impact on the card performance. Hence, it is not supported in the current version of PayPass.

6.1.9 Data Privacy Because of the over-the-air nature of their interface to the payment terminals and because of the lack of terminal authentication, PayPass cards may expose cardholder identification data such as the card PAN or the cardholder's name. Such an exposure may raise privacy concerns, as separate purchases made with the same card can be linked, and potentially linked to individuals.

The protection of the card from any energizing radio frequency field unless the cardholder removes this protection, e.g. through a mechanism present in the wallet, etc may mitigate that risk. Similar measures, e.g. a special protective envelope around the card, might be used to protect the cards when in transit to the cardholder during the card distribution phase.

In addition, it is mandated that PayPass card Track1 data do not include the cardholder's name.

6.1.10 Denial of Service Measures similar to the ones described in section 6.1.9 may be used to mitigate DoS risks.

3 At least, outside of relay attacks.




Confidential

ConclusionsRisks to PayPass

7 Conclusions When properly implemented, PayPass Mag Stripe offers a suitable and ‘fit-for-purpose’ trade-off between functionality and security. It delivers the full convenience of tap-and-go payments without any significant impact to acquirer or issuer infrastructure, while providing adequate security. This is achieved through the use of the dynamic CVC3 online card authentication mechanism designed to comply with magnetic stripe transactions requirements. The possible attack scenarios that then remain are generic for transactions that are without cardholder authentication.

The dynamic CVC3 technique ensures an appropriate level of security as long as certain recommendations are followed, as specified in Chapter 5. They include the following:

• The issuer should keep track of the entire ATC

• The issuer should fix appropriate values for the management and use of the ATC if the CVC3 received by the issuer is invalid, the issuer must decline or block the card after a certain number of consecutive errors

• The terminal should monitor the number of aborted transactions and take appropriate measures, e.g. introduce wait times after three aborted transactions

The following additional recommendations are good practices to mitigate risks in general:

• The PAN range for PayPass Mag Stripe should be separate from the PAN range for magnetic stripe and contact chip

• SecureCode should be used for electronic commerce transactions

**** End of Document ****


PayPass – Mag Stripe - cardzone.cz Mag Stripe - Security... · MasterCard PayPass™ technology...

Documents

Transcript of PayPass – Mag Stripe - cardzone.cz Mag Stripe - Security... · MasterCard PayPass™ technology...