PSD2 Is In Trouble: Will It Survive?

This blog post has been coauthored with Karen Lewison

The 2nd Payment Services Directive (PSD2) of the European Union went into effect on September 14, but one of its most prominent provisions, the Strong Customer Authentication (SCA) requirement, was postponed until December 31, 2020 by an opinion dated 16 October 2019 of the European Banking Authority (EBA). The EBA cited pushback from the National Competent Authorities (NCAs) of the EU member countries as the reason for the postponement, and the fact that version 2 of the 3-D Secure protocol (3-D Secure 2) is not ready as a reason for the pushback.

PSD2 is supposed to be technology neutral, but the EBA has unequivocally endorsed 3-D Secure as the way to implement the SCA requirement for online credit card transactions, as stated in another opinion, dated 21 June 2019:

Continue reading “PSD2 Is In Trouble: Will It Survive?”

Will Cardholder Authentication Ever Come to the US?

This blog post has been coauthored with Karen Lewison

You may have heard that the EU is struggling to implement the Strong Customer Authentication (SCA) requirements of Payment Services Directive 2 (PSD2). The directive was issued four years ago, Regulatory Technical Standards (RTS) followed two years later, and the SCA requirements went into effect on September 14. But on October 16 the European Banking Authority (EBA) had to postpone enforcement until December 31, 2020, due to pushback from the National Competent Authorities (NCAs) of the EU member countries. In an opinion announcing the postponement, the EBA cited as a reason for the pushback the fact that 3-D Secure 2 (3DS2) is not ready.

The problems that the EBA is having with the SCA requirements have more to do with the bureaucratic formulation of the requirements in PSD2, than with the technical difficulty of providing strong security. We will discuss this in another post, but first we want to ask here whether cardholder authentication will ever come to the US.

Continue reading “Will Cardholder Authentication Ever Come to the US?”

3-D Secure 2 May Allow the Merchant to Impersonate the Cardholder

3-D Secure is a protocol that provides security for online credit card payments by redirecting the cardholder’s browser to the web site of the bank that has issued the credit card, where the cardholder is authenticated by methods such as username-and-password or a one-time password. 3-D Secure is rarely used in the US because the cardholder authentication creates friction that may cause transaction abandonment, but it is used more frequently in other countries. The credit card networks have been working on a new version of the protocol, called 3-S Secure 2, where the issuing bank assesses fraud risk based on information received from the merchant through a back channel and waives authentication for low-risk transactions.

In a paper presented at HCII 2019 we showed that 3-D Secure 2 has serious privacy and usability issues and we proposed an alternative protocol that provides strong security without friction for all transactions by cryptographically authenticating the cardholder. We have now looked in more detail at a particular configuration of 3-D Secure 2 where the cardholder uses a native app instead of a browser to access the merchant’s site, and we have found security flaws, described in detail in a technical report, that may allow a malicious merchant to impersonate the cardholder.

Continue reading “3-D Secure 2 May Allow the Merchant to Impersonate the Cardholder”

Online Cardholder Authentication without Accessing the Card Issuer’s Site

One of the saddest failings of Internet technology is the lack of security for online credit card transactions. In in-store transactions, the cardholder authenticates by presenting the card, and card counterfeiting has been made much more difficult by the addition of a chip to the card. But in online transactions, the cardholder is still authenticated by his or her knowledge of credit card and cardholder data, a weak secret known by many.

Credit card networks have been trying to provide security for online transactions for a long time. In the nineties they proposed a complicated cryptographic protocol called SET (Secure Electronic Transactions) that was never deployed. Then they came up with a simpler protocol called 3-D Secure, where the merchant redirects the cardholder’ browser to the issuing bank, which asks the cardholder to authenticate with a password. 3-D Secure is rarely used in the US and unevenly used in other countries, due to the friction that it causes and the risk of transaction abandonment; lately some issuers have been asking for a second authentication factor, adding more friction. Now the networks have come up with version 2 of 3-D Secure, which removes friction for low risk transactions by introducing a “frictionless flow”. But the frictionless flow does not authenticate the cardholder. Instead, the merchant sends device and cardholder data to the issuer through a back channel, potentially violating the cardholder’s privacy.

Last August we wrote a blog post and a paper proposing a scheme for authenticating the cardholder without friction using a cryptographic payment credential consisting of a public key certificate and the associated private key. We have recently written a revised version of the paper with major improvements to the scheme. The paper will be presented next month at HCII 2019 in Orlando.

Continue reading “Online Cardholder Authentication without Accessing the Card Issuer’s Site”

Frictionless Secure Web Payments without Giving up on Cardholder Authentication

The 3-D Secure protocol version 1.0, marketed under different names by different payment networks (Verified by Visa, MasterCard SecureCode, American Express SafeKey, etc.) aims at reducing online credit card fraud by authenticating the cardholder. To that purpose, the merchant’s web site redirects the cardholder’s browser to the issuing bank, which typically authenticates the cardholder by asking for a static password and/or a one-time password delivered to a registered phone number. 3-D Secure was introduced by Visa in 1999, but it is still unevenly used in European countries and rarely used in the United States. One reason for the limited deployment of 3-D Secure is the friction caused by requiring users to remember and enter a password and/or retrieve and enter a one-time password. Consumers “hate” 3-D Secure 1.0, and merchants are wary of transaction abandonment. Another reason may be that it facilitates phishing attacks by asking for a password after redirection, as discussed here, here, and here.

3-D Secure 2.0 aims at reducing that friction. When 3-D Secure 2.0 is deployed, it will introduce a frictionless flow that will eliminate cardholder authentication friction for 95% of transactions deemed to be low risk. But it will do so by eliminating cardholder authentication altogether for those transactions. The merchant will send contextual information about the intended transaction to the issuer, including the cardholder’s payment history with the merchant. The issuer will use that information, plus its own information about the cardholder and the merchant, to assess the transaction’s risk, and will communicate the assessment to the merchant, who will redirect the browser to the issuer for high risk transactions but omit authentication for low risk ones.

This new version of 3-D Secure has serious drawbacks. It is privacy invasive for the cardholder. It puts the merchant in a bind, who has to keep customer information for the sake of 3D-Secure while minimizing and protecting such information to comply with privacy regulations. It is complex for the issuer, who has to set up an AI “self-learning” risk assessment system. It requires expensive infrastructure: the contextual information that the merchant sends to the issuer goes through no less than three intermediate servers—a 3DS Server, a Directory Server and an Access Control server. And it provides little or no security benefit for low risk transactions, as the cardholder is not authenticated and the 3-D Secure risk assessment that the issuer performs before the merchant submits the transaction to the payment network is redundant with the risk assessment that it performs later before authorizing or declining the submitted transaction forwarded by the payment network.

There is a better way. In a Pomcor technical report we propose a scheme for securing online credit card payments with two-factor authentication of the cardholder without adding friction.

Continue reading “Frictionless Secure Web Payments without Giving up on Cardholder Authentication”

What kind of “encrypted fingerprint template” is used by MasterCard?

In a press release, MasterCard announced yesterday an EMV payment card that features a fingerprint reader. The release said that two trials have been recently concluded in South Africa and, after additional trials, a full roll out is expected this year.

In the United States, EMV chip cards are used without a PIN. The fingerprint reader is no doubt intended to fill that security gap. But any use of biometrics raises privacy concerns. Perhaps to address such concerns, the press release stated that a fingerprint template stored in the card is “encrypted”.

That’s puzzling. If the template is encrypted, what key is used to decrypt it before use?

Continue reading “What kind of “encrypted fingerprint template” is used by MasterCard?”

Virtual Tamper Resistance is the Answer to the HCE Conundrum

Host Card Emulation (HCE) is a technique pioneered by SimplyTapp and integrated by Google into Android as of 4.4 KitKat that allows an Android app running in a mobile device equipped with an NFC controller to emulate the functionality of a contactless smart card. Prior to KitKat the NFC controller routed the NFC interface to a secure element, either a secure element integrated in a carrier-controlled SIM, or a different secure element embedded in the phone itself. This allowed carriers to block the use of Google Wallet, which competes with the carrier-developed NFC payment technology that used to be called ISIS and is now called SoftCard. (I’m not sure if or how they blocked Google Wallet in devices with an embedded secure element.) Using HCE, Google Wallet can run on the host CPU where it cannot be blocked by carriers. (HCE also paves the way to the development of a variety of NFC applications, for payments or other purposes, as Android apps that do not have to be provisioned to a secure element.)

But the advantages of HCE are offset by a serious disadvantage. An HCE application cannot count on a secure element to protect payment credentials if the device is stolen, which is a major concern because more then three million phones where stolen last year in the US alone. If the payment credentials are stored in ordinary persistent storage supplied by Android, a thief who steals the device can obtain the credentials by rooting the device or, with more effort, by opening the device and probing the flash memory.

Last February Visa and MasterCard declared their support for HCE. Continue reading “Virtual Tamper Resistance is the Answer to the HCE Conundrum”

How Apple Pay Uses 3-D Secure for Internet Payments

In a comment on an earlier post on Apple Pay where I was trying to figure out how Apple Pay works over NFC, R Stone suggested looking at the Apple Pay developer documentation (Getting Started with Apple Pay, PassKit Framework Reference and Payment Token Format Reference), guessing that Apple Pay would carry out transactions over the Internet in essentially the same way as over NFC. I followed the suggestion and, although I didn’t find any useful information applicable to NFC payments in the documentation, I did find interesting information that seems worth reporting.

It turns out that Apple Pay relies primarily on the 3-D Secure protocol for Internet payments. EMV may also be used, but merchant support for EMV is optional, whereas support for 3-D Secure is required (see the Discussion under Working with Payments in the documentation of the PKPaymentRequest class). It makes sense to rely primarily on a protocol such as 3-D Secure that was intended specifically for Internet payments rather than on a protocol intended for in-store transactions such as EMV. Merchants that only sell over the Internet should not be burdened with the complexities of EMV. But Apple Pay makes use of 3-D Secure in a way that is very different from how the protocol is traditionally used on the web. In this post I’ll try to explain how the merchant interacts with Apple Pay for both 3-D Secure and EMV transactions over the Internet, then how Apple Pay seems to be using 3-D Secure. I’ll also point out a couple of surprises I found in the documentation. Continue reading “How Apple Pay Uses 3-D Secure for Internet Payments”

Making Sense of the EMV Tokenisation Specification

Apple Pay has brought attention to the concept of tokenization by storing a payment token in the user’s mobile device instead of a card number, a.k.a. a primary account number, or PAN. The Apple Pay announcement was accompanied by an announcement of a token service provided by MasterCard and a similar announcement of another token service provided by Visa.

Tokenization is not a new concept. Token services such as the TransArmor offering of First Data have been commercially available for years. But as I explained in a previous post there are two different kinds of tokenization, an earlier kind and a new kind. The earlier kind of tokenization is a private arrangement between the merchant and a payment processor chosen by the merchant, whereby the processor replaces the PAN with a token in the authorization response, returning the token to the merchant and storing the PAN on the merchant’s behalf. In the new kind of tokenization, used by Apple Pay and provided by MasterCard, Visa, and presumably American Express, the token replaces the PAN within the user’s mobile device, and is forwarded to the acquirer and the payment network in the course of a transaction. The purpose of the earlier kind of tokenization is to allow the merchant to outsource the storage of the PAN to an entity that can store it more securely. The purpose of the new kind of tokenization is to prevent cross-channel fraud or, more specifically, Continue reading “Making Sense of the EMV Tokenisation Specification”

Which Flavor of Tokenization is Used by Apple Pay

I’ve seen a lot of confusion about how Apple Pay uses tokenization. I’ve seen it stated or implied that the token is generated dynamically, that it is merchant-specific or transaction-specific, and that its purpose is to help prevent fraudulent Apple Pay transactions. None of that is true. As the Apple Pay press release says, “a unique Device Account Number is assigned, encrypted and securely stored in the Secure Element on your iPhone or Apple Watch”. That Device Account Number is the token; it is not generated dynamically, and it is not merchant-specific or transaction-specific. And as I explain below, its security purpose is other than to help prevent fraudulent Apple Pay transactions.

Some of the confusion comes from the fact that there are two very different flavors of tokenization. That those two flavors are confused is clear in a blog post by Yoni Heisler that purports to provide “an in-depth look at what’s behind” Apple Pay. Heisler’s post references documents on both flavors, not realizing that they describe different flavors that cannot possibly both be used by Apple Pay.

In the first flavor, described on page 7 of a 2012 First Data white paper referenced in Heisler’s post, the credit card number is replaced with a token in the authorization response. The token is not used until the authorization comes back. Tokenization is the second component of a security solution whose first component is encryption of credit card data from the point of capture, Continue reading “Which Flavor of Tokenization is Used by Apple Pay”