Frictionless Web Payments with Cryptographic Cardholder Authentication

1. Frictionless Web Payments with Cryptographic Cardholder Authentication Francisco Corella, fcorella@pomcor.com Karen Lewison, kplewison@pomcor.com Presented July 28 at HCII 2019 Updated August 1, 2019

2. The security of online credit card transactions is an unsolved problem • Credit card chips have increased security and reduced fraud for in-store transactions • But the fraud rate has increased for online transactions • In most online transactions, the cardholder is still authenticated by knowledge of credit card data, which is known by thousands; we refer to this as ½F authentication • Reducing the fraud rate for online transactions will require much stronger authentication of the cardholder

3. Credit card networks have been trying to improvethe security of online transactions for a long time • In the nineties: SET (Security Electronic Transactions) • Cardholder authentication • Non-repudiation • Cardholder privacy by minimizing the amount of cardholder and transaction data disclosed to each participant in the transaction on a need-to-know basis • Abandoned

4. Then: 3-D Secure, version 1 • Merchant redirects browser to issuing bank for authentication with a password, before submitting the transaction to the payment network for authorization processing as usual • Limited adoption due to poor usability • Having to enter a password causes “friction”, which may result in transaction abandonment => Rarely used in US, unevenly used in other countries

5. 2014 news item from The Guardian reporting on plans to introduce 3-D Secure version 2, which has not been deployed yet, five years later

6. 3-D Secure version 2 • Goal 1: eliminate friction for 95% of transactions deemed to be “low risk” • How? • The merchant sends “contextual data” to the issuing bank through a back channel in a “frictionless flow” • The issuing bank decides whether to continue with a “challenge flow” that authenticates the cardholder • 3-D Secure version 2 eliminates friction for 95% of transactions, but does so by giving up on authentication for those 95% of transactions • And the back channel has a latency cost and a privacy cost for all transactions

7. What “contextual data” is sent through the back channel?

8. What payment history is included in the contextual data? • The issuing bank does not need data about payments made with the current credit card • So, to be useful, the payment history should involve transactions made with other cards • But that would be a violation of the cardholder’s privacy by the merchant • In fact, the current version of the specification does not include a payment history in the contextual data, but that part of the specification is still in flux

9. An expensive infrastructure

10. 3-D Secure version 2, continued • Goal 2: Authenticate the cardholder using device biometrics such as face recognition or fingerprint scanning • This is accomplished using a native app provided by the issuing bank, if one is available on the cardholder’s device

11. But with very poor usability

12. It is possible to do much better • It is possible to eliminate friction without giving up on authenticating the cardholder, and to authenticate the cardholder biometrically with good usability

13. We propose a cardholder authentication solution with the following features • Strong cryptographic authentication with non-repudiation for all transactions • Without privacy violations • Without friction • Without involvement of the issuer at transaction time • With usable biometric authentication if a bank app is available • And with minimal infrastructure

14. Ingredients of the solution • Credit card credential • Consisting of an X.509 certificate and its associated private key • Stored in the browser or in a bank app • Modern web and mobile technology • Service workers • Custom schemes • JavaScript URLs Update: As discussed in the paper and the blog post, the certificate contains a cryptographic hash of the credit card data rather than the data itself, thus protecting the data against an adversary who obtains the certificate. This is possible because the cardholder submits the credit card data to the merchant.

15. In a nutshell • After the cardholder submits the credit card data to the merchant • The merchant redirects the browser to an issuer URL, • but the redirected request is intercepted by a service worker, • which signs the transaction with the private key • 1½F authentication, with non-repudiation

16. If the issuer has a bank app in the cardholder’s device: • The credential is stored in the app, and • after the service worker intercepts the request to the issuer URL, it further redirects the browser to the app, • which uses the private key to sign the transaction, • and further authenticates the cardholder with platform biometrics => 2½F authentication, with non-repudiation If the cardholder uses a merchant app: • The app uses a JavaScript URL to direct the default browser to an issuer URL. • The request is intercepted by a service worker • and the cardholder is authenticated as in the other cases. • Then the signature and the certificate are sent to a custom scheme registered by the merchant’s app.

17. Minimal infrastructure • Table mapping the Issuer Identification Number (IIN) of each participating issuer (first 6 digits of credit card number) to: • The URL of the redirected request that will be intercepted by the service worker • The public key associated with the private key that the issuer uses to sign the certificate Easy implementation and deployment • Trivial development effort by the merchant or merchant processor • Issuer does not need to provide a highly available service

18. Thank you for your attention!For additional information: • Web site with blog: pomcor.com • Slides: https://pomcor.com/techreports/frictionless-cardholder-authentication.ppt • Author’s version of paper https://pomcor.com/techreports/frictionless-cardholder-authentication.pdf • Blog post: https://pomcor.com/2019/06/23/online-cardholder-authentication-without-accessing-the-card-issuers-site/ • Contact us: fcorella@pomcor.com kplewison@pomcor.com