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.
In the original scheme the private key was stored in the cardholder’s browser, but the certificate was kept by the issuing bank and had to be retrieved at transaction time. There was no friction because the cardholder was automatically authenticated by a signature on the transaction computed with the private key. The user experience was the same as in an ordinary credit card payment, except that the confirmation page was displayed in a bank page rather than a merchant page. But the roundtrip to the bank had a latency cost and required the issuing bank to maintain a highly available service capable of providing the certificate for every payment transaction made with a card issued by the bank.
The reason for keeping the certificate in the issuer’s site rather than storing it in the browser together with the private key was to protect the data in the certificate from an adversary who might physically capture the cardholder’s device. We have now found a way of protecting the data while keeping the certificate in the browser.
In the revised scheme the certificate binds the public key to a cryptographic hash of credit card data rather than to the data itself. Since the user experience is the same as in an ordinary credit card payment, the cardholder submits the credit card data to the merchant. The merchant can thus provide the data to the browser, which verifies that it matches the hash of the data included in the certificate. More precisely, the merchant redirects the browser to a URL belonging to the DNS domain of the issuer, but the redirected request is intercepted by a service worker, which compares the data to the hash, signs the transaction, and redirects back to the merchant’s site, conveying the signature which the merchant retains for non-repudiation purposes.
The revised scheme also includes a technique for taking advantage of a native app provided by the issuing bank to further authenticate the cardholder biometrically, using a biometric facility such as fingerprint scanning or face recognition provided by the cardholder’s device. 3-D Secure version 2 also proposes using a bank app for biometric authentication, but without providing any details and with poor usability. 3-D Secure version 2 suggests that, after the merchant has redirected the cardholder to the issuer’s web site, the issuer would instruct the cardholder to manually open the bank’s native app to be authenticated. In our scheme the merchant takes the cardholder directly to the bank’s app using a custom URL scheme registered by the app with the operating system of the cardholder’s device, using the service worker as an intermediary unseen by the cardholder.