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.

Merchant Interaction with Apple Pay for Internet Payments

A merchant app running on the phone shows an Apple Pay button on its
user interface. When the user taps the button, the app makes a
payment request to the Apple Pay API, specifying the amount of the
payment and a description of the transaction. Apple Pay displays to
the user a payment sheet including the description of the
transaction, the payment amount, and a prompt to Pay with Touch
ID. When the user touches the fingerprint sensor and a valid
fingerprint is recognized, Apple Pay creates a payment token,
which it returns to the merchant app. (This payment token is not to
be confused with the payment token of the
EMV
Tokenisation Specification which I discussed in the
previous
post; the payment token of that specification is a replacement for
the primary account number, whereas the payment token of the
Apple Pay developer documentation is a description of a payment
transaction. To disambiguate, I will refer to the payment token of
the developer documentation as an iOS payment token.) The
merchant app may send the iOS payment token to a merchant server,
which passes it through a network API to a payment processor, which
uses it to create an authorization request that it forwards to the
acquiring bank. Alternatively, the merchant app may use an SDK
supplied by the processor, which sends the iOS payment token directly
to a processor server as described for example in the
Apple
Pay Getting Started Guide of
Authorize.Net,
which is one of the
processors listed in the Apple Pay developer site.

The iOS payment token includes, among other things, a header and
encrypted payment data, which are signed together by Apple Pay
with an asymmetric signature. The payment data is encrypted under a
symmetric key derived from an Elliptic-Curve Diffie-Hellman (ECDH)
shared secret, which is itself derived from an ephemeral ECDH key pair
generated by Apple Pay and a long term ECDH key pair belonging to the
merchant. (Apple Pay computes the shared secret from the ephemeral
private key and the merchant public key, while the merchant computes
it from its private key and the ephemeral public key, which is
included in the header. An encryption method that uses an ephemeral
Diffie-Hellman key pair of the encryptor with a long term
Diffie-Hellman key pair of the decryptor may be viewed as a variant of
El Gamal
encryption.)

After receiving the iOS payment token from the merchant, the processor
verifies the Apple Pay asymmetric signature on the header and
encrypted payment data, and decrypts the payment data using the
private key of the merchant. To the latter purpose the processor may
generate the ECDH key pair on behalf of the merchant and keep the
private key.

The decrypted payment data may consist of an “EMV payment
structure“, described as “output from the Secure Element“;
unfortunately, the documentation does not provide any details about
the structure, so the Apple Pay developer documentation does not shed
light on the details of Apple Pay payment transactions over NFC as had
been hoped by R Stone. The decrypted payment data may also consist of
an “online payment cryptogram, as defined by 3-D Secure” plus
an “optional ECI indicator, as defined by 3-D Secure“. Whether
3-D Secure or EMV is used, the developer documentation does not
provide enough information to create an authorization request that can
be submitted to the acquiring bank. Unless additional information can
be obtained from other sources, the merchant will have to contract out
transaction processing to one of the processors listed in the
Apple Pay developer
site, which will have received the necessary information from
Apple.

3-D Secure in a nutshell

The 3-D Secure protocol, which is rarely used in the US but commonly
used in other countries, improves security for Internet payments by
authenticating the cardholder. It was developed by VISA, and it is
used by VISA, MasterCard, JCB and American Express under the
respective names Verified by VISA, MasterCard
SecureCode, J/Secure and American Express SafeKey.
The protocol is proprietary, but I have found some information about
it in a
Wikipedia page
and in merchant implementation guides published
by
VISA and
by MasterCard.

Ordinarily, 3-D Secure is used for web payments. The merchant site
redirects the user’s (i.e. the cardholder’s) browser to an Access
Control Server (ACS) operated by the issuing bank, or more commonly by
a third party on behalf of the issuing bank, which authenticates the
user. Redirection is often accomplished by including in a merchant
web page an inline frame whose URL targets the ACS. As is usually the
case for web authentication protocols that redirect the browser to an
authentication server, such as OpenID, OAuth, OpenID Connect, or the
SAML Browser SSO Profile, the method used to authenticate the user in
3-D Secure is up to the server (the ACS) and is not prescribed by the
protocol. Typically the ACS displays a Personal Assurance Message
(PAM) to authenticate itself to the user and mitigate the risk of
phishing, then prompts the user for an ordinary password agreed upon
when the user enrolls for 3-D Secure, or for a one-time password (OTP)
that is delivered to the user or generated by the user using a method
agreed upon at enrollment time.

After authenticating the user, the ACS redirects the browser back to
the merchant site, passing a Payer Authentication Response (PARes) that
indicates whether authentication succeeded, failed, or could not be
performed, e.g., because the user has not enrolled in 3-D Secure with
the issuing bank and no password or OTP generation or transmittal
means have been agreed upon. The PARes is signed by the ACS with an
asymmetric signature that is verified by a Merchant Plug-In (MPI)
provided to the merchant by an MPI provider licensed by the payment
network. The PARes comprises an authentication status, and may also
comprise an Electronic Commerce Indicator (ECI) that indicates the
result of the authentication process redundantly with the
authentication status, and a Cardholder Authentication Verification
Value (CAVV) (which MasterCard calls instead an Accountholder
Authentication Value, or AAV). The CAVV includes an Authentication
Tracking Number (ATN) and a cryptographic Message Authentication Code
(MAC), which is a symmetric signature computed by the ACS.

After the MPI has verified the asymmetric signature in the response,
if authentication succeeded, the merchant adds the CAVV and the ECI to
the authorization request that it assembles using the card number,
security code and cardholder data obtained from a web form. The
merchant sends the authorization request to the acquiring bank, which
forwards it via the payment network to the issuing bank. The issuing
bank verifies the MAC in the CAVV, using the same key that was used by
the ACS to compute the MAC after authenticating the user on behalf of
the issuing bank.

Use of 3-D Secure by Apple Pay

An Apple Pay transaction is very different from a traditional 3-D
Secure transaction. It is not a web transaction. No browser is
involved, and no browser redirection takes place. The user is
authenticated by Apple Pay (using the fingerprint sensor, which IMO
provides little security as discussed in earlier posts) rather than by
the issuing bank. And Apple Pay uses tokenization, whereas 3-D Secure
does not. Therefore 3-D Secure must have been modified very
substantially for use with Apple Pay.

The developer documentation does not explain how 3-D Secure has been
modified, but here is a guess.

After verifying the user’s fingerprint, Apple Pay generates the CAVV,
without involvement by an ACS on behalf of the issuing bank or by the
issuing bank itself. As discussed in earlier posts, I believe that
Apple Pay shares a secret with the payment network or token service
provider (here I’m referring to the token of the EMV Tokenisation
Specification) that it uses to derive the symmetric key that is used
to generate the token cryptogram in a tokenized EMV transaction over
NFC. I suppose Apple Pay uses the same symmetric key, or a symmetric
key derived from the same shared secret, to generate the MAC in the
CAVV. The CAVV thus plays a role similar to that of the token
cryptogram, and is verified by the payment network or a token service
provider used by the payment network, just as the token cryptogram is.

In ordinary 3-D Secure the asymmetric signature on the PARes, created
by the ACS and verified by the MPI plug-in, allows the merchant to
verify that the user has been successfully authenticated and it is OK
to make an authorization request. In Apple Pay, the same role is
played by the asymmetric signature included in the iOS payment token.
That signature is verified by the payment processor, which subsumes
the role played by the MPI plug-in in 3-D Secure.

Surprise: is the primary account number present in the phone?

The primary account number (PAN) is not supposed to be present in the
phone. Its absence from the phone was stated in the
Apple
Pay announcement:

When you add a credit or debit card with Apple Pay, the actual card
numbers are not stored on the device nor on Apple servers. Instead, a
unique Device Account Number is assigned, encrypted and securely
stored in the Secure Element on your iPhone or Apple Watch

And I’ve seen it emphasized in many blog posts on Apple Pay. But the
documentation of the
PKPaymentPass class refers both to
a deviceAccountIdentifier, described as “the unique identifier
for the device-specific account number”, and
a primaryAccountIdentifier, described as “an opaque value that
uniquely identifies the primary account number for the payment card”.
This seems to imply that the primary account number is present in the
device, even though it may be hidden from the merchant app by an
opaque value.

Surprise: lack of replay protection?

In the
Payment
Token Format Reference, the instructions on how to verify the
Apple Pay signature on the header and encrypted payment data of the
iOS payment token include the following step:

e. Inspect the CMS signing time of the signature, as defined by
section 11.3 of RFC 5652. If the time signature and the transaction
time differ by more than a few minutes, it’s possible that the token
is a replay attack.

No other anti-replay precautions are mentioned. This seems to
indicate that replay protection relies on the Apple Pay signature not
being more than “a few minutes” old. That is obviously not an
effective protection against replay attacks, nor against bugs or other
glitches that may cause the iOS payment token to be sent twice. I
conjecture that lack of replay protection may have contributed to the
multiple
charges for some purchases that have been reported.