This post has been updated to include the patent number.
Pomcor has been granted US patent 10,825,025 on the method of cardholder authentication that I have discussed before on this blog. The Cardholder Authentication page has links to earlier materials. Actually, the patent was granted on November 3, 2020, but I was busy working on TLS traffic visibility at the time.
3-D Secure 2 purports to reduce the friction created by 3-D Secure 1 as it redirects the cardholder browser to the card issuer’s site for authentication. But it does so by omitting cardholder authentication altogether for transactions deemed low risk, and may increase friction for other transactions.
Eliminating friction with a Service Worker
We eliminate friction instead, for all transactions, by using a Service Worker registered with the browser by the issuer to intercept the redirected request and authenticate the user by proof of possession of a private key, which is used to sign a description of the transaction and thus provide a defense against transaction repudiation to the merchant.
The private key is associated with a credit card certificate that contains the corresponding public key and a cryptographic hash of the data printed on the credit card. The card data is not included in the certificate to avoid exposing it to an attacker who uses malware or physical capture of the cardholder’s device to obtain the certificate. When the merchant’s site or native app receives the certificate along with signature, it verifies the hash against the printed card data entered by the cardholder.
We originally used the idea of intercepting an authentication request with a Service Worker in connection with Rich Credentials, then presented it in general terms at ICMC 2017.
Are Service Workers still usable?
People have been telling us recently that Service Workers can no longer be used because WebKit deletes Service Worker registrations, along with first-party data stored in the browser, after seven days of non-use. This is an unfortunate complication, but it does not mean that Service Workers and first-party data can no longer be used. It just means that the web app that registers the Service Worker, in this case the issuer’s web app, must be added to the home screen, as explained in this WebKit blog post.
This blog post has been coauthored with Karen Lewison
The 2nd Payment Services Directive
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
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
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
dated 21 June 2019:
Continue reading “PSD2 Is In Trouble: Will It Survive?”
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
The directive was issued four years ago, Regulatory Technical
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.
announcing the postponement, the EBA cited as a reason for the
pushback the fact that 3-D Secure 2
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 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.
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
report, that may allow a malicious merchant to impersonate the
Continue reading “3-D Secure 2 May Allow the Merchant to Impersonate the Cardholder”
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
Last August we wrote
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
version of the paper with major improvements to the scheme. The
paper will be presented next month
at HCII 2019 in
Continue reading “Online Cardholder Authentication without Accessing the Card Issuer’s Site”
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
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
Continue reading “Frictionless Secure Web Payments without Giving up on Cardholder Authentication”
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?”
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
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”
In a comment on an
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
Started with Apple Pay,
Framework Reference and
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
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”
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,
Pay announcement was accompanied by an
of a token service provided by MasterCard and a similar
of another token service provided by Visa.
Tokenization is not a new concept. Token services such as the
offering of First Data have been commercially available for years.
But as I explained in a
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”