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.