8.2 Security aspects of remote card payments

The e-/m-commerce is a risky business environment. This is the consequence of the inherent lack of security of the networks sustaining the remote interaction between cardholders and merchants : no confidentiality of the transmitted data, no authentication of the sender or receiver, and no integrity of the transmitted data. Moreover, in a remote card payment neither the cardholder nor the card is present. Since there is no physical proximity of the cardholder and merchant or of the card and the terminal, like in a face-to-face transaction, card and cardholder impersonation is easy.

In this section we identify possible threats associated with remote transactions carried out on open networks. The analysis concentrates on the cardholder-merchant interface, which is most vulnerable to attacks. We determine appropriate security services that can counteract these threats. We show that the use of an EMV ¢ chip card in the configuration of the cardholder access device can improve the implementation of the card authentication and cardholder authentication services, as well as the nonrepudiation service. Then, we review the structure of a communication protocol stack, and the possibilities for the realization of these security services at various levels of this stack.

8.2.1 Threats environment

The cardholder-merchant interface can be conventionally divided into three distinct security domains: the cardholder access device, the merchant access device, and their communication channel(s) [3]. We now look to some security threats in connection with remote transactions that characterize each domain.

8.2.1.1 Communication channel

Considering that many network technologies broadcast information to every computer located on a local area network or over an air interface, the threat analysis assumes that an attacker can intercept every message.

Sniffing or eavesdropping (see Appendix B) is the most obvious threat on the communication channel. Referring to Figure 8.1, the channels that are the most exposed to sniffing are channel 1 and channel 2, when they are used for both browsing/ordering and paying (i.e., the payment information of the card is included in the order forms).

T1: The attacker sniffs the browsing/ordering channel. The goal is to obtain as much information as possible about the consumer's commercial habits. Sometimes, the term "snooping" is used to refer to gathering consumer's habits on the Internet [4]. The attacker can derive consumers' profiles, which he can then sell to shopkeepers. These attempts not only attack the cardholder's privacy but also render him or her vulnerable to excessive and targeted advertising campaigns , which expose the cardholder to the risk of high consumption. Consumers associations have become more and more aware about this side effect of e-commerce. This kind of threat has received a lot of attention in the media.
T2: The attacker sniffs the payment channel. He tries to filter out financial data in connection with credit and debit cards. The attacker can use this information for performing fraudulent transactions (see Section 2.6.2). This is an "electronic" waiter attack. While an investigation could have traced fraud back to the physical waiter, the electronic waiter is unnoticed and untraceable, because he was not directly involved in the transaction. Since the liability of the cardholder is limited, the issuer and the merchant dispute the loss generated by the fraudulent transactions. The merchant has limited payment guarantee, similar to the transactions performed in distance selling with MO/TO. Cardholders, even though they are not exposed to financial loss, feel a great inconvenience in having fraudulent payments linked to their cards. Consequently, the sniffing of the payment channel greatly concerns payment system operators and card associations. They see that their clients , cardholders, merchants, and financial institutions are reluctant to use payment cards in the e-/m-commerce environment due to the high rate of disputes.

Another important threat is data modification by an active attacker (see Appendix B), which mounts, for example, a man-in-the-middle attack (see Appendix D, Section D.4.1).

T3: The attacker intercepts the browsing/ordering channel and modifies the order sent by the consumer to the merchant. The merchant delivers wrong items to his customer, who will refuse the reception . Besides the direct loss determined by the shipping costs, this attack degrades the quality of the service provided by the merchant, as perceived by his customers. The consequence is that the merchant can lose his customers.
T4: The attacker intercepts the browsing/ordering channel and modifies the content of the merchant's Web/WAP page, with a twofold purpose.
1. The most obvious purpose for doing so is to modify the merchant's offer, such that a competitor of the merchant gains advantage of misinforming the consumer.
2. Another reason for modifying the merchant's content is less obvious. The attacker inserts in the modified page a Trojan horse, which is an executable program. The attacker instructs this program that once downloaded in the cardholder's browser and running in the cardholder access device, it tries to identify sensitive information and transmit it back to the attacker. The most sensitive information searched for is represented by cryptographic parameters (e.g., secret keys and private keys) used by other payment channels, like the channel 1bis in Figure 8.1, facilitating a SET payment protocol.
T5: The attacker intercepts the payment channel and modifies the payment card data sent by the cardholder to the merchant. With high probability, false card data will lead to the rejection of the transaction by the issuer, which will treat it as an attempt of counterfeit transaction. Consequently, the service that is provided by the payment system operator or card association disappoints the cardholder. The cardholder may stop using the payment card in remote transactions, which is a loss to the payment system operator or card association.

Impersonating (see Appendix B) is easy in a remote transaction carried out on open networks. Any crook can pretend to be a famous mall. The crook displays the electronic decals of many credit cards, as icons inserted in his Web page. The consumer has no suspicion about this impersonation and forwards card details to the crook. Symmetrically, the use of a stolen credit card or of an invalid branded payment card account number raises no suspicion to the shopkeeper . The attacker cannot betray his nervous behavior on the wires.

T6: The attacker impersonates the electronic decal of a payment card brand. The attacker runs a Web server that presents besides the commercial offer the icons of many credit cards, which his imaginary shop accepts for paying. Each icon can be assimilated with an electronic decal in the virtual window of this shop. The attacker collects the payment card data from as many cardholders as possible, mounting a massive electronic waiter attack. The attacker can sell the collection of card data to a malicious organization, which can subsequently attempt a large number of fraudulent transactions.
T7: An attacker impersonates a valid payment card on a payment channel. The attacker hopes that the electronic shopper will authorize the counterfeit transaction and deliver the goods before the counterfeit card is recognized by the payment system.
T8: A thief impersonates the legitimate cardholder on a payment channel. The attacker makes a payment with a stolen, lost, or card-not-received card, whose payment card account number is correctly branded. This attack leads to fraudulent transactions.

If the consumer changes his or her mind after ordering the purchases and effecting the corresponding payment, she tries to repudiate the transaction with the hope that she will recover her money.

T9: Although a valid branded payment card account number is used by the legitimate cardholder, he or she may latter deny his or her participation in a remote transaction with the merchant. This leads to a dispute and loss by the merchant due to supplementary shipping costs. In case the merchant sells entertainment on demand, the cardholder attempts to enjoy the service without paying.

While the aforementioned threats are related to security, the denial-of-service attack attempts to deny the availability of a communication channel between the cardholder access device and the merchant access device.

T10: The attack consists of flooding the merchant's access device with false requests coming from an automated bogus cardholder access device. This attack discourages a real cardholder from buying from the unavailable merchant, which leads to financial loss for the latter.

8.2.1.2 Cardholder access device

There are many possible penetration attacks depending on the nature of the access device and of its access control system. For the purpose of our analysis, however, we are concerned only with the Trojan horse threat described below.

T11: The browser running in the cardholder access device interprets the content of a Web/WAP page, which might also contain executable programs. The downloaded program can be a Trojan horse that tries to take advantage of some security weaknesses of the browser (see also threat T4, number 2). If the attack succeeds, the program may identify secret cryptographic parameters stored in the cardholder access device, which can serve for implementing security services used by other payment applications.

8.2.1.3 Merchant access device

The threat we are concerned with here is a massive waiter attack as described below.

T12: The attacker succeeds in breaking into the logical access control system of the merchant access device. The goal is to obtain the card financial data of as many cards as possible, which can be used in mounting a large number of fraudulent transactions. This attack can produce a high loss to the merchant, which can be held liable for the fraudulent transactions.

As can be seen, the threats of using payment cards in the e-/m-commerce environment are not new compared with face-to-face transactions, but they are easier to mount on open networks. The successful mounting of the corresponding attacks can lead to high volume and automated fraud, which unacceptably increases the loss of various participants in the e-/m-commerce business.

8.2.2 Security services for remote transactions

Security, or the perceived lack of it, is often mentioned as a reason of holding back on e-/m-commerce. This is the number one concern stated by consumers for hesitating to use their credit cards to make purchases over the Internet or GSM networks. In this section we identify appropriate security services that are able to counteract the threats identified in Section 8.2.1. A detailed definition of the security services is given in Appendix C, Section C.1.

Surfing the Web does not seem to endanger the consumer's privacy. The consumer feels anonymous while browsing the Web, like listening to the radio or browsing in a bookstore. In fact, Web surfers leave identifiable tracks at every Web site they visit [4].

AnS1 ”Anonymity: This is the security service that addresses the protection of the consumer while browsing various shops ' Web sites. Sometimes, visiting a certain Web site reveals some of the consumer preferences, even if the consumer does not order anything in that shop. The tool used for rendering the browsing anonymous is sometimes referred to as an anonymizer [4]. This service addresses threat T1.

Confidentiality services (CS) are intended to counteract the sniffing threats.

CS1 ”Confidentiality of the ordering phase: This confidentiality service is essential for impeding attackers from deriving consumers' profiles. It should be implemented by the browsing/ordering channel, and it should be provided regardless of the type of channel used to perform the payment itself. This security service addresses threat T1.
CS2 ”Secure messaging for confidentiality: This confidentiality service concerns the financial messages "on the fly" from the cardholder to the merchant, transmitted on the payment channel for completing the payment phase of a remote transaction. A financial message includes the payment card data, as the credit card number, the account number to which a debit card is linked, and the expiration date. This security service addresses threat T2.
CS3 ”Confidentiality of stored card data: This service refers to the confidentiality of the card data while it is stored in the permanent storage space of the merchant access device, prior to being submitted to the acquirer for clearing and settlement . This security service addresses threat T12.

Data authentication services (AS), which provide both data origin authentication and data integrity, are intended to counteract simultaneously the impersonation and data modification threats on a communication channel (see Appendix C, Section C.1).

AS1 ”Data authentication of the exchanged messages: This security service refers to the authentication and integrity of the transaction messages exchanged between the cardholder and the merchant. This security service is implemented on both the browsing/ordering channel and on the payment channel. The transaction messages protected by this service are:
- The message that includes the order sent by the consumer to the merchant on the browsing/ordering channel. This counters threat T3;
- The message that includes the offer provided by the merchant to the consumer. This counters threat T4;
- The message that includes the payment card data sent by the cardholder to the merchant. This counters threat T5.
AS2 ”Authenticode: This security service refers to providing enough evidence about the authenticity and integrity of an executable program that is downloaded from a Web page. Even though it does not prevent the potential hostile actions of the executable program, it guarantees its linkage to the content of a Web page, and thus it offers accountability in case hostile actions are identified. This service protects against threats T4 and T11.

Entity authentication (ES) allows for the identification of the entities participating in a remote transaction.

ES1 ”Server authentication: Cardholders need to identify merchants with whom they can securely conduct e-commerce. Server authentication is a security service that allows a Web server to produce enough evidence to any WEB browser that is a genuine server on the WEB, with which secure remote transactions can be carried out. This evidence is guaranteed by a third party, which is trusted by both the consumer and the merchant. The trusted third party (TTP) can be a certification authority broadly accepted on the Internet (e.g., VeriSign [5]). This service counters threat T4.
ES2 ”Client authentication: This security service is similar to the server authentication but it concerns the client side. This service counters threats T3 and T5.
ES3 ”Merchant authentication: This security service confirms that a merchant has a relationship with a financial institution, allowing the merchant to accept payment cards of a certain brand. This service provides the authenticity of the electronic brand decal displayed in the "virtual window" of an electronic shop. The service is intended to counter the impersonation attack T6.
ES4 ”Cardholder account authentication: This security service ensures that the cardholder uses a valid branded payment card account number for completing the payment phase. This security service is intended to counter counterfeit transactions, which is threat T7.
ES5 ”Cardholder authentication: This security service ensures the merchant that for each remote transaction the person providing the data of the payment card in the remote transaction is the legitimate cardholder of that card. The successful implementation of this service annihilates threat T8, which decreases the number of fraudulent transactions.

The implementation of the cardholder account authentication can rely on a set of verifiable secret card data, which is brand specific and is stored in the cardholder access device. One could say that proving the knowledge of this secret card data provides enough evidence for the cardholder authentication too. However, this is not true. To support this statement, we observe that a successful execution of a Trojan horse (see threats T4, 2 and T11) on the target cardholder access device reveals to the attacker the secret card data, which he can fraudulently use. This is the reason why the security services ES4 and ES5 are separately identified. Thus, there is no physical proof that the legitimate cardholder is interacting with the merchant while probating the authenticity of the cardholder account.

TS1: A supplementary level of trust for cardholder authentication can be provided in case the set of verifiable secret card data is provided to the legitimate cardholder in a tamper-resistant token, working in combination with the cardholder access device. This token can be an EMV ¢ chip card, which is uniquely linked to the cardholder. Therefore, the tamper-resistance security service can be used to provide a physical proof of the cardholder's identity. If this physical proof is combined with something the legitimate cardholder knows , like a PIN, then this combination is accepted as sufficient to prove the presence of the cardholder in the remote transaction. The tamperresistance security service directly counters threat T11 and helps enforce the cardholder authentication service (ES5).

Non- repudiation of the origin (see Appendix C, Section C.1) is the security service that counters the threat of denying the participation in a transaction by the initiator of the remote transaction.

NS1 ”Cardholder non-repudiation: This security service ensures the merchant that for each remote transaction the cardholder cannot deny his or her participation in the transaction. The successful implementation of this service annihilates threat T9, which can lead to a decreasing number of disputes between the merchant and the cardholder.

Note that the implementation of the cardholder non-repudiation service also relies on a set of secret card data, which is uniquely linked to the cardholder. The cardholder access device uses this secret data to produce a nonrepudiation proof verifiable by the merchant access device or by a third party. Therefore, the irrefutability of this proof depends on the secure storage of the cardholder's secret data. A solution could be that an EMV ¢ chip card hosts this secret data and produces the non-repudiation proof. The EMV ¢ chip card is part of the hardware configuration of the cardholder access device.

Alternatively, the cardholder's secret data is kept in a secure wallet server run by the issuer, which computes the non-repudiation proof on behalf of the cardholder. This computation is triggered by a successful authentication of the cardholder (see Section 8.5.3).

By using the EMV ¢ chip cards, an issuer leverages its investment in the EMV ¢ chip migration by providing a reliable and trusted mechanism for remote card and cardholder authentication [6].

8.2.3 Security services realization

Networks are typically specified in layers [7]. Each layer defines protocols for communication between peers at the same level. The Internet protocol suite is a four-layer system, as shown in Figure 8.2, where the communication subsystem (see Appendix C, Section C.2) consists of the link layer, the network layer, and the transport layer.

Figure 8.2: Internet protocol suite.

The meaning of each layer and the representative protocols are listed below [8]:

The link layer provides the physical interfacing with the communication medium (e.g., the Ethernet cable).
The network layer handles the movement of packets around the network. The Internet protocol (IP) provides unreliable data transmission between nodes. It also defines the basis for the Internet addressing.
The transport layer assures the data flow between two hosts, for the communication of the peer applications, one layer above. Most Internet applications use the transport control protocol (TCP), which is a connection-oriented data flow that provides transmission reliability. Multicast applications use a connectionless data flow that provides no reliability, called the user datagram protocol (UDP).
The most common applications implemented on the TCP/IP stack are the Telnet for remote login, file transfer protocol (ftp), the simple mail transfer protocol (SMTP), and the HTTP.

The realization of security services protecting remote transactions and remote card payments can be achieved at various levels of the Internet protocol stack (see also Appendix C, Section C.2).

8.2.3.1 Security for the Internet Protocol

The IP security architecture [9] describes security mechanisms for the IP version 4 (IPv4) and IP version 6 (IPv6). It defines two specific security headers. The first is called the Authentication Header, which provides integrity and authentication [10]. The second is called the Encapsulating Security Payload (ESP), which provides confidentiality, and may also provide integrity and authentication [11].

8.2.3.2 Transport layer security protocols

There are several security protocols for adding security services to TCP. The most known representatives of the transport layer security protocols are Netscape's SSL, Microsoft's Private Communication Technology (PCT), and the TLS, elaborated by the Internet Engineering Task Force (IETF), which is the standardization organization of the Internet. The advantage of the transport layer security protocols is that they are application protocol independent. Used for remote e-commerce transactions and remote payments, a transport layer security protocol establishes a secure channel on the Internet (see Appendix C, Section C.2) between the access devices of a cardholder and a merchant, which can protect the card data on transit from one to another. Section 8.3 presents a payment method based on TLS.

8.2.3.3 Application layer security protocols

The most cited example of an application layer security protocol is the Secure HTTP (S-HTTP), which is a message-oriented communication protocol for securing messages that are transmitted using the HTTP. S-HTTP provides security services for confidentiality, data integrity, and nonrepudiation of origin.

There are many proposals for secure payment applications, like First Virtual, CyberCash, NetBill, NetCheque, to name only a few. Each of these payment applications proposes its own registration procedures for participants and its secure payment protocol. However, none of these Internet payment applications have achieved widespread acceptance. One possible reason is their limited scalability. We will not go into further detail on any of them in this book. The interested reader can find a comprehensive overview of these Internet payment applications and protocols in [12]. Rather, we are interested in the SET secure payment application [13 “15]. SET proposes a standardized, industry-wide secure payment protocol at the level of the application layer, which establishes a secure communication over an insecure channel (see Appendix C, Section C.2). Visa and MasterCard elaborated the SET standard with collaboration from a consortium of leading technology companies including Microsoft, Netscape, VeriSign, RSA, to name only a few. The SET designers overtook and developed a number of principles previously proposed by other payment and security standards, among which are the Internet Keyed Payment Protocols (iKP) [16]. Section 8.4 presents the payment method based on SET.