© Aconite, October 2001 www.aconite.net Aconite Whitepaper E-payments: Credit Cards on the Internet Richard Jewson October 2001 Aconite richard.jewson@aconite.net Contents ! Introduction ! Part 1: Overview of Payments ! Part 2: Payments Technologies Past & Present ! Part 3: Current Developments ! Conclusion ! References Introduction Commerce involves the exchange of value. By the end of 20 th century, the exchange of financial value had evolved from coins, notes and other instruments to sophisticated e- payment systems. In e-payments, the exchange of value is represented by the exchange of data. It is easy, fast and cheap to transfer data, but these benefits come at a cost. The physical authenticity of payment instruments such as notes and coins can be checked. In e-payments, the parties involved will probably never even see or talk to each other. Proving the authenticity of the payment, payer and payee are fundamental to the widespread adoption of e-payments. This paper is the first in a series which looks at e-payments technology and solutions. This article introduces the basic components of any B2C e- payment system: the protocols by which the payer and payee establish trust in each other and exchange value electronically across open, insecure channels such as the Internet. In this paper we concentrate on credit card payments, the most popular method of payment for goods, information or services on the Internet. Despite numerous technical advances, credit card payments have remained fundamentally unchanged since the early 80’s. So have the risks. Any business that accepts credit cards has to accept a certain level of fraud. In the real world, you can manage and mitigate this risk with physical, policy and infrastructure controls. This is true for face-to-face or card-present transactions, despite recent marked increases in real world fraud such as card cloning. It is less true for card-not-present transactions Credit card payments have remained fundamentally unchan g ed since the early 80’s. So have the risks. Aconite Whitepaper E-payments: Credit Cards on the Internet © Aconite, October 2001 www.aconite.net used for mail and telephone orders (known as MO/TO). The use of the Web for commerce means that there are now new ways to commit fraud. Part 1: Overview of Payments The Issues To exchange value in a secure and trusted manner using credit cards, you must consider a number of factors: • Card Validation: Is the presented card valid? • Cardholder Authentication: Is the cardholder genuine? • Merchant Authentication: Is the merchant a bona fide member of a payment scheme (eg. Visa, Mastercard)? • Privacy: Are the details provided during the transaction handled securely and not available to unauthorized parties? • Interoperability: Is the system compatible with a variety of vendor solutions and does it use open standards? • Ease of use: How visible is the system to the cardholder? • Easy to implement: Is the system cost effective to the merchants and financial institutions (FIs)? • Future proof: Is the system able to use emerging technologies? Solutions must address many of these factors, with ease of use the most important for customers. The principle of ‘Risk vs. Reward’ is central to the payments world. Attempts to produce a very low risk system have largely failed and produced no reward. The SET protocol is an example and we discuss it later. On the other hand, higher risk solutions such as simpler SSL-based systems are widely used and have enabled the growth of e-commerce. Managing the risks associated with making payments is not covered in this paper, but is important in defining a usable solution. Risk management looks at the whole picture, not just the technical aspects. Real World Card Payments Let us review ‘real world’ credit card payments. A credit card is a certificate: a statement made to a merchant about the holder of the card by a third party, the issuer of the card. In a card-present transaction the merchant can rely on the measures built into the card to prove the authenticity of both card and cardholder (see Figure 1). Authenticity of the card: • Complex images printed on the card. • Hard to forge holograms. • Magnetic stripe (although this is relatively easy to duplicate). Authenticity of the cardholder: Aconite Whitepaper E-payments: Credit Cards on the Internet © Aconite, October 2001 www.aconite.net • Signature stripe, which provides a sample of the cardholder’s signature. This must be duplicated in front of the merchant. In some cases this is printed on the card to stop their replacement. • Photograph of the cardholder. • Face-to-face contact between the cardholder and merchant. With card-not-present transactions, although the merchant cannot physically see the card or the cardholder he can still use certain methods of authentication: • Address verification: Allows the merchant to match the cardholder’s address to an online database. • Cardholder verification values: A 3-digit number printed on the signature stripe that is not included on the magnetic stripe. • Human interaction. A well-trained salesperson can identify a fraudulent transaction. A N Other A N Other A N Other AbcBank AbcBank A N Other AbcBank 666 A N Other AbcBank 666 Acme Bank 1234 5678 9101 1234 MR A N OTHER Acme Bank 1234 5678 9101 1234 MR A N OTHER Acme Bank MR A N OTHER 1234 5678 9101 1234 Acme Bank MR A N OTHER Exp 07/03 Exp 07/03 Exp 07/03 Acme Bank MR A N OTHER Exp 07/03 1234 5678 9101 1234 1234 5678 9101 1234 ! Chip ! Hologram! Magnetic stripe ! Card ! Embossing ! Signature ! Card Verification Code (CVC) Figure 1: Evolution of Credit Card Security Features Virtual Payments A virtual payment at an Internet retailer is similar to a card-not-present transaction. The retailer has to trust that the payer is the authorised holder of the card. If not, the retailer relies on the acquirer’s authorization and fraud systems to reject the transaction. There is one fundamental difference however: the complete automation of the processing on the merchant’s side. The lack of human involvement in the transaction is one of the greatest benefits of e- commerce. Automation allows the retailer to handle more transactions, more quickly and more cheaply. But this benefit is also a security flaw. Whilst the automation of the sales process has opened up new commerce opportunities, it has also opened up new scope for payment fraud: • More opportunities for would-be fraudsters • Technology which protects anonymity • Many attempts in a very short time The automation of the sales process has opened up new commerce opportunities - it has also opened up new scope for payment fraud Aconite Whitepaper E-payments: Credit Cards on the Internet © Aconite, October 2001 www.aconite.net • Very little prosecution • Successful fraudulent payment methods can be used at other sites simultaneously The Internet, like MO/TO transactions, also presents another problem: the authenticity of the merchant. With a card-present transaction the customer can take up problems with the merchant face-to-face. On the Internet there are fewer avenues available to help the customer resolve problems. Other threats exist, such as ‘spoofing’ a legitimate retailer to deceive users and gain cardholder details. Who can you trust? Part 2: Payments Technologies Past & Present An Introduction to Secure Sockets Layer (SSL) SSL establishes a secure communication channel between two computers. Communicating parties use that channel to exchange data in a confidential manner. SSL also enables both parties to check the integrity of that data and optionally, to authenticate each other. SSL was designed to be a generic secure communication protocol - not a payment protocol. Why is SSL so widely used? Why is it not good enough for e-payments? SSL is the foundation of most secure e-commerce transactions today. From encrypting sensitive payment details to verifying the authenticity of a web site, SSL provides sufficient security for e-commerce. In the context of electronic payments, SSL allows the cardholder to transmit their payment details to the merchant’s server in a secure manner. SSL-based e-payments suffer from the same problems as MO/TO transactions, as well as others more relevant to electronic channels: • No mechanism to provide strong authentication of the cardholder or merchant • No controls over what that merchant does with the cardholder’s payment details. This problem was highlighted recently by the much-publicised theft of credit card details from several online retailers. [5] • Lack of policy and legal frameworks to allow a customer to trust a merchant. Despite these issues, SSL is now a de facto standard in the payments industry. An Introduction to Secure Electronic Transaction (SET) In 1996 Visa and MasterCard developed the SET protocol. It was designed to provide trusted electronic transactions. This would provide security to all parties involved in the transaction and address many of the limitations associated with an SSL-only transaction. SET is an open standard, now managed by SETCo LLC [1]. SET defines four components – a Certificate Authority, Cardholder Wallet, Merchant SET Modules and Payment Gateways - any of which a technology vendor may implement. Aconite Whitepaper E-payments: Credit Cards on the Internet © Aconite, October 2001 www.aconite.net SET requires cardholder, merchant and acquirer software, and some components of a Public Key Infrastructure (PKI) to support the trust architecture. SET allows the cardholder and merchant to authenticate each other with digital certificates before a transaction. The cardholder is sure they are dealing with a legitimate merchant, and the merchant has proof that the cardholder is authorized to use the selected card. Once this trust is established, both parties can exchange transaction information. SET uses a ‘fat wallet’: a large application installed on the cardholder’s PC to hold payment details and perform the SET transaction for the cardholder. See Figure 2 for an overview. What Happened to SET? There are many reasons why SET failed. Here we highlight the more important technical reasons: • Distribution and portability of cardholder certificates. A full implementation of SET requires that each cardholder has a digital certificate. Issuing and installing these on cardholder PC’s was difficult. A certificate installed at the customer’s home PC could not be used on any other PC – a major issue for cardholders. • Software distribution and maintenance. 1. Purchase Request 6. Receipt 2. Authorisation Request 5. Authorisation Response 3. Authorisation Request Acquirer Issuer Cardholder Merchant Payment Gateway Cardholder Wallet Merchant Server 4. Authorisation Response Mutual Authentication Figure 2: The SET Protocol Aconite Whitepaper E-payments: Credit Cards on the Internet © Aconite, October 2001 www.aconite.net The installation and maintenance of wallet software on customer PCs requires support from the issuer. Infrastructure at merchants and financial institutions is also required. • Interoperability. Incompatibility of different components from different vendors hindered uptake despite interoperability assurance provided by SETCo though their ‘SET Mark program’. • Co-operation from all parties. SET requires buy-in from FIs, merchants and consumers. Without a clear business benefit for merchants such as reduced chargebacks, and similar benefits for consumers, uptake was limited. Implementation costs were not justified. • Constraints on gathering market intelligence. Design limitations imposed by SET, such as the hiding of cardholder details, prevented merchants from tracking customers. Technically, SET is a sound protocol which answers most of the issues that the industry faces. Its failure was due to the complexities of deployment. 3D SET SET never reached critical mass. In the US, interest was almost non-existent while in Europe and the Far East, there was only limited success with pilot projects. These have since been shut down one by one. To address this lack of success and to promote SET further, Visa introduced ‘3D SET’ in 2000. 3D SET was introduced to drive the use of credit card payments online, lower the complexities of the original SET protocol and simplify the chargeback mechanisms. Two of the core aims for 3D SET were to: • reduce the effort of performing a SET payment on behalf of the cardholder • allow the cardholder to use their certificate from any device with Internet access. With 3D SET, the cardholder’s wallet is moved to a central server and maintained by the card issuer or bank. This vastly simplifies the cardholder subscription process and requires only a small application on the cardholders PC – a ‘thin wallet’ architecture. 3D SET incorporates the SET protocol into the Three Domain Model: 1. Acquirer Domain. The parties who acquire transactions, such as merchants and transaction services. 2. Issuer Domain. The parties who issue payment instruments that are used in the Acquirer Domain, such as FIs and other scheme operators. 3D SET provides a flexible framework that allows banks and acquirers to use their own methods to authenticate cardholders and merchants in a transaction Aconite Whitepaper E-payments: Credit Cards on the Internet © Aconite, October 2001 www.aconite.net 3. Interoperability Domain. The area between the Issuer and Acquirer domains that governs how a payment is made and how they operate with each other. The original SET protocol fits into the Interoperability Domain. It is unchanged from the original SET protocol. The 3D SET model provides a flexible framework that allows banks and payment acquirers to use their own methods to authenticate cardholders and merchants in a transaction. Each party uses the secure and complex interoperability protocol to communicate with the others. As an example, let’s consider 3D SET within an issuing bank. A SET Wallet resides on a central bank server and provides the SET transactional capability. The bank’s cardholders who have SET certificates also have accounts within that central wallet. The issuing bank can decide how to authenticate its own cardholders because it owns the wallet. This removes the need for specialised software on the cardholders PC and allows the cardholder to use many different payment channels from PC to mobile phones. 3D SET has gained ground in Europe and South America but not yet in the US. As supporting products mature, deployment of the solution will become easier and cheaper. The jury is still out on its future. Part 3: Current Developments Given the size of the US e-commerce market, the lack of real payment security presents huge risks to payment scheme operators. It comes as no surprise that efforts are being made to address these risks. Both Visa and MasterCard have developed competing payer authentication standards. Both use SSL and provide additional mechanisms to authenticate the cardholder and merchant. Visa: Payer Authentication Service 3D Secure [3] is a payer authentication service. First, a cardholder enrols for the scheme at their issuing bank’s site. This enables payments to be made with their card. During enrolment, the cardholder registers a password. Next, a cardholder visits the site of a merchant which participates in the scheme. He clicks the ‘Buy’ button on this site and is prompted to enter his password. Finally, the issuing bank verifies the cardholder’s password and if successful, passes the payment details to the merchant. MasterCard: Secure Payment Application Like the Visa initiative, MasterCard’s Secure Payment Application (SPA) [2] standard is a payer authentication service. First, the cardholder registers for the service with their issuing bank. They then set a password and downloads a Java applet. Next, during a The lack of payment security presents hu g e risks to scheme operators - it comes as no surprise that efforts are bein g made to address the risks Aconite Whitepaper E-payments: Credit Cards on the Internet © Aconite, October 2001 www.aconite.net purchase, they enter the password for the service. The issuer authenticates the cardholder and generates an authentication value which is returned to the applet. The applet incorporates this value into a hidden part of the payment details form which is sent to the merchant. Finally, this value is then used during when the merchant processes the purchase transaction, and is verified by the issuing bank. From the second half of 2001, online retailers will need to to support both authentication methods [4]. This is meeting with a less than warm reception and some sources warn that the competing services may see no more acceptance than SET did. Table 1 gives a summary of the benefits provided by the different payment schemes: SSL SET 3D SET 3D Secure SPA Authentication Card - *** *** ** ** Cardholder - *** *** ** ** Merchant * *** *** ** ** Privacy ** *** *** ** ** Interoperability *** ** *** * * Ease of Use **** * *** *** *** Ease of Implementation *** * ** *** ** Future Proof? ** ** ** ** ** Key to matrix - Not applicable * Basic or Poor ** Moderate *** Good **** High or Strong Table 1: Payment Schemes Benefits Matrix Other Technologies Numerous other payment technologies are being promoted both as partial and full solutions to the problems faced. Smart card technology is becoming more prevalent and will have many implications for e-payments. These portable cards can store information such as signing keys, provide digital signing capabilities and authenticate the cardholder using a PIN or password. Issuers are slowly replacing magnetic stripe cards by smart cards with payment applications loaded. EMV, a joint initiative between Europay, Mastercard and Visa, is one scheme using smart cards. Although EMV provides some security against fraud in the real and virtual worlds, it still leaves some questions unanswered. These technologies undoubtedly provide many benefits but only when used in conjunction with a secure, widely accepted protocol. Until then, consumers and merchants will not fully trust e-payments. Other technologies deal with other areas of e-payments. These include: • Micro payments, for very low value transactions; • Surrogate card numbers - a new credit card number for each transaction the cardholder performs. • Mobile payments, to pay for services from a mobile handset or PDA; Aconite Whitepaper E-payments: Credit Cards on the Internet © Aconite, October 2001 www.aconite.net Operators of payment schemes need to reinforce the position of credit cards as the preferred way to pay online, by raisin g consumer and merchant confidence • Person-to-person and B2B payments; • Advances in cryptography such as elliptic curve methods (ECC) which improve the performance and efficiency of cryptographic processing also help to shape new and innovative e-payments capabilities. ECC is better suited to constrained devices such as smart cards and mobile phones. Articles later in the series cover many of these themes and emerging technologies. Conclusion It’s been 5 years since the payment industry made the first concerted efforts to make paying by credit card on the Internet straightforward and secure. Ultimately, the real purpose of developing an e-payments protocol is to promote the use of the card. Operators of payment schemes need to reinforce the position of credit cards as the preferred way to pay online, by raising consumer and merchant confidence. There is no serious competition to the credit card for e- payments, and the industry is dragging its feet over co-operation and promotion of a globally accepted solution. Today we are no closer to this goal and there remains serious fragmentation of the industry. This is a particular problem when you consider more complex issues, such as cross border payments. For example, what happens when a US cardholder wants to purchase goods in the EU and his issuer’s authentication method is not recognized? Who accepts the risk for that transaction? Five years on, issues regarding technical interoperability and mutually accepted levels of authentication are being addressed, but a universally accepted solution is yet to arrive. Recent initiatives such as EMV are gaining widespread support amongst merchants and consultancies such as Aconite are seeing growing demand from clients determined to make them work. After a number of false starts, payments processing on the Internet is about to enter a new era. About the author Richard is a consultant specializing in secure e-commerce payments, digital trust and cryptography technologies. He provides technical consultancy on secure payment protocols and products, e-commerce and security to major financial services and telecommunication clients, both in the UK and worldwide. About Aconite Aconite provides consultancy and solutions to clients worldwide. Aconite’s consultants each have ten years experience drawn from the financial services and retail sectors and specialise in smart cards, e-trust and security, and e-business systems integration. For further information, contact Andy Davies, andy.davies@aconite.net or visit www.aconite.net. Aconite Whitepaper E-payments: Credit Cards on the Internet © Aconite, October 2001 www.aconite.net Use & Distribution Use of this article is free of charge provided that the following citation is included wherever it is referenced: “Aconite Whitepaper, E-payments: Credit Cards on the Internet, October 2001, www.aconite.net ”. For questions regarding the use of this article, contact Andy Davies, andy.davies@aconite.net . References Web site references valid as of 6 th October 2001. [1] SETCo LLC www.setco.org [2] Mastercard Secure Payment Application (SPA) http://www.mastercardintl.com/about/press/pressreleases.cgi?id=423 [3] 3D Secure from Visa http://www-s2.visa.com/av/news/press_release.ghtml?pr_form_edit=671 [4] Competing payment standards http://news.zdnet.co.uk/story/0,,s2094952,00.html [5] SecurityFocus news item on credit card fraud http://www.securityfocus.com/news/111 . © Aconite, October 2001 www.aconite.net Aconite Whitepaper E-payments: Credit Cards on the Internet Richard Jewson October 2001 Aconite richard. jewson@ aconite.net Contents. Response Mutual Authentication Figure 2: The SET Protocol Aconite Whitepaper E-payments: Credit Cards on the Internet © Aconite, October 2001 www.aconite.net The installation and maintenance. Credit Cards on the Internet © Aconite, October 2001 www.aconite.net purchase, they enter the password for the service. The issuer authenticates the cardholder and generates an authentication