8.5 TLS versus SET or wallet servers and EMV(TM) cards

8.5 TLS versus SET or wallet servers and EMV ¢ cards

For the scope of remote card payments in the e-commerce environment, at the moment there are two competing trends. Those who are partisans of decreasing fraud at the cost of enforcing security prefer SET, while those who are aiming at a faster increase of the e-commerce volume at the cost of accepting a higher business risk prefer TLS. In fact, the use of a wallet server architecture and the integration of an EMV ¢ chip card in the configuration of the cardholder access device increase the competitiveness of both methods , improving the security of TLS-based solutions and decreasing the operational overhead of SET. This architecture leads in fact to a unified framework for remote transactions.

8.5.1 Security makes the difference

In Section 8.3.3 we show that TLS does not provide appropriate authentication services for payment: merchant authentication (ES3), cardholder account authentication (ES4), and cardholder authentication (ES5). Therefore, using TLS-based payment card methods in remote transactions may still generate a high number of disputes. Electronic waiter attacks are also more likely to appear, since there is no cryptographic protection of the card data stored in the merchant access device (CS3). Not only is the level of fraud a concern, but also the prestige of the payment card brand, considering that fraud on the Internet is intensively publicized.

Therefore, SET appears to be a reasonable alternative for increasing the security of the remote card payments. SET appropriately implements the cardholder account authentication (ES4), the cardholder authentication (ES5), the cardholder non-repudiation (NS1), the merchant authentication (ES3), and the confidentiality of the card data in the merchant access device (CS3). We mentioned in Section 8.4.4 that the successful implementation of the cardholder authentication and cardholder non- repudiation services is dependent on the degree to which the cardholder's private signing key is securely generated and stored in the cardholder access device. Table 8.1 comparatively presents the range of security services offered by the TLS-based methods and the SET method.

Table 8.1: Comparison of the Security Services Offered by TLS and SET

Security Service	Phase	Threats	TLS	SET
AnS1 ”Anonymity	Browsing/ordering (B/O)	T1	No	No
CS1 ”Confidentiality of the ordering phase	(B/O)	T1	Yes	No
CS2 ”Secure messaging for confidentiality	Payment	T2	Yes	Yes
CS3 ”Confidentiality of stored card data with the merchant	Payment	T12	No	Yes
AS1 ”Data authentication of exchanged messages	B/O	T3, T4	Yes	No
	Payment	T5	Yes	Yes
AS2 ”Authenticode	B/O	T4, T11	No	No
ES1 ”Server authentication	B/O	T4	Yes	No
ES2 ”Client authentication	B/O	T3	Yes	No
	Payment	T5	Yes	Yes
ES3 ”Merchant authentication	Payment	T6	No	Yes
ES4 ”Cardholder account authentication	Payment	T7	No	Yes
ES5 ”Cardholder authentication	Payment	T8	No	Yes
NS1 ”Cardholder non-repudiation	Payment	T9	No	Yes
TS1 ”Tamper-resistance security service	Payment	T11	No	No

By analyzing Table 8.1, it can be seen that SET better addresses the security of the payment phase than TLS. This is the premise on which payment card brands can guarantee the payment of the authorized transactions for SET-enabled merchants . This is a considerable advantage compared to the TLS payment method, which still complies with the same rules and regulations as the MO/TO transactions.

Since SET addresses only security issues during the payment phase, it cannot counter threats during the browsing/ordering phase, for which the cardholder access device and the merchant access device must establish a TLS channel.

8.5.2 Acceptability is a main concern

When it comes to the acceptability of e-commerce, the payment method plays an important role. Cardholders are naturally attracted by the payment method providing the easiest way of using their credit cards or debit cards for remote payments on the Internet. Both the cardholder and the merchant are also attracted by a payment method that does not require investments in software and hardware, or high operational costs. The participation of either the cardholder or the merchant in any complex decision-making process, especially related to the enrollment of participants in the payment method, increases the reluctance of even experienced Internet users.

Thus, those who prefer the TLS-based payment card solutions, despite their security limitations, invoke their high acceptability from both cardholders and merchants. Their main argument is that this transport layer security protocol is user friendly and does not require deployment efforts, since they are implemented in the majority of browsers and servers interacting through the HTTP on the Web. Thus, neither cardholders nor merchants are compelled to buy supplementary software for payment applications. The involvement of these network protocols in transactions is transparent to cardholders. Moreover, participants do not undergo complicate registration procedures.

Compared with TLS, installing, registering, and running SET is more difficult. After buying the specialized SET software, a cardholder must install it on his or her machine, connect to the appropriate CCA (e.g., the card's issuing bank), and request a certificate. Before a certificate is issued, the cardholder has to prove his or her identity to the CCA, according to a procedure that is not specified by SET but is established by each payment card brand. Added to these registration-related inconveniences are the differences a cardholder perceives related to the browsing/ordering phase and the choice of the payment method. The SET does not specify the way a cardholder connects to the merchant's Web site, selects the goods to purchase, makes the choice about the payment option, and how the cardholder's SET application is invoked by the merchant. Therefore, someone can expect that the use of a SET package will appear different for cardholders, depending on the software provider offering the SET integrated solution and on the specific registration procedure of each card brand. Moreover, since the digital certificates are at the core of the SET security solution, each cardholder has to take care about renewing his or her certificate after its expiration date. These could be some of the reasons why the acceptance of SET is still poor among both cardholders and merchants. This is at least the case for the thick wallet configuration of the SET software.

In the remainder of this section we refer to the thick wallet configuration. The SET application running in the cardholder's PC is sometimes referred to as a SET wallet, or simply a wallet. In the "software only" case, this wallet consists of four functional components that are presented in Figure 8.8.

Figure 8.8: SET functional components.

The cardholder interface and I/O device is responsible for the system input/output, such as the keyboard, screen, and graphic user interface. The cardholder database is responsible for the management of the cardholder's payment-related data, like the signature public key certificate and card data (e.g., the PAN and the expiration date), but also for personal data of the cardholder, like delivery address and telephone number. The cardholder database must be stored such that the confidentiality and integrity of the data is ensured. The SET private key manager is responsible for the secure storage and use of the cardholder's private signing key. The integrity and confidentiality of this key has to be guaranteed to enforce the cardholder authentication and non-repudiation services. The SET message manager deals with the interaction between the cardholder's PC and the merchant's Web server during a payment transaction and between the cardholder's PC and the CCA server during a certificate issuing transaction, according to the SET protocols. The SET private key manager in conjunction with the SET message manager must process the generation of the cardholder's signature key pair, signature public key certificate request, and purchase request signing operations in a manner that assures the security of the private key.

In a thick wallet configuration, all the aforementioned functional components are installed and run in the cardholder's PC. In this case the cardholder is responsible for the management of all these components, according to their required level of security. This operational overhead appears to be a barrier against the acceptance of the SET payment method, at least by the cardholders.

8.5.3 Improved solutions with wallet servers and EMV ¢ cards

Acknowledging the wide acceptability of the TLS-based payment method, but recognizing its security weaknesses, the first trend is to improve its security to answer the high demands of remote card payments, especially considering card and cardholder authentication. At present, the most cited example is the Visa initiative 3-D Secure ^TM [20]. This solution provides authentication of participants in remote card payments, besides the confidentiality and integrity of the payment information. It is important to note that 3-D Secure can be implemented without requiring specialized cardholder software or hardware. A similar proposal by MasterCard is called the Secure Payment Application (SPA ¢ ) [21].

Since basing the management of the SET payment system entirely on the cardholder access device (e.g., the thick wallet approach) determines serious acceptability barriers, the second trend is the adoption of "simplified" SET solutions. When we refer to "simplified" SET, the meaning is that this should be the perception of the cardholder. An example of such a solution is the Visa initiative 3-D SET ^TM [22], which is a major evolution of the original SET within the distributed structure of the Three Domain Model. Within this model, the cardholder and her bank form the issuer domain, the merchant and his bank form the acquirer domain, while the cardholder's bank and the acquirer's bank are interacting in the interoperability domain.

The competitiveness of both TLS-based solutions and SET can be improved, admitting that there is no way to base the management of a payment method entirely on the cardholder access device. The issuer, or a payment system operator acting on behalf of the issuer, must establish a remote wallet server at an intermediate level between the cardholder device and the issuer. On the one hand, the wallet server talks to the cardholder access device for the cardholder authentication, and on the other hand the wallet server talks to the merchant access device for the completion of a payment method. The payment management is now based on the combination cardholder access device and wallet server. This architecture also confers the advantage that the cardholder can use the same type of payment experience, regardless of the type of access device (i.e., whether it is a PC or a mobile phone), and the type of interconnection channel. In this case, the initial model of the payment card processing in remote transactions, which is presented in Figure 8.1, is modified as shown in Figure 8.9.

Figure 8.9: Wallet server in remote payment card processing.

In this model the ordering/browsing phase is still carried out directly between the cardholder and the merchant. However, the wallet server, acting on behalf of the cardholder, completes the payment phase with the merchant access device. The wallet server triggers the payment phase only following a successful authentication of the cardholder. Thus, the remote transaction is carried out in three distinct phases, browsing/ordering, cardholder authentication, and payment, which are completed in different sessions. The interaction between the wallet server and the merchant to complete the payment phase is carried out on a TCP/IP channel on the Internet (channel 1bis). The types of channels used for the interaction between the cardholder and the merchant access devices for completing the browsing/ordering phase, and between the cardholder access device and the wallet server for completing the cardholder authentication depend on the type of the cardholder access device:

• Dual Internet channel device (channel 1 and channel 5): The browsing/ordering phase (channel 1) and the cardholder authentication phase (channel 5) are carried out on different TCP/IP channels.

• Dual channel/dual network device (channel 1 and channel 3): The browsing/ordering phase is completed on a TCP/IP channel (channel 1), while the cardholder authentication phase is carried out on a PP-SMS channel (channel 3).

• Dual mobile channel device (channel 2 and channel 3): The browsing/ordering phase is completed on a WAP channel (channel 2), while the cardholder authentication phase is carried out on a PP-SMS channel (channel 3).

In the remainder of this section, we present the thin client architecture for the SET payment method [1]. It is derived from the wallet server architecture presented in Figure 8.9 in the following way. The implementation and operation of the SET functional components presented in Figure 8.8 (except for the cardholder interface) are transferred from the cardholder access device, which can be regarded as a client, to the wallet server. This can facilitate the update and management of a large number of cardholder access devices by the issuer or its delegated payment system operator, since their major SET functionality is concentrated on the server. Since the installation of the remaining SET components on the cardholder access device is less complex, we can assume that the acceptability of cardholders will increase. In the thin client architecture, the cardholder access device can be implemented with lower software and hardware resources (e.g., a mobile phone).

The thin client running on the cardholder access device consists of the SET cardholder interface component and a software/hardware component, for the cardholder authentication to the wallet server. In the simplest case, the cardholder's authentication mechanism can be implemented with a user ID and a password. The identification information of the cardholder is transmitted on a confidential and authentic channel from the issuer to the cardholder during the setup of the system. The cardholder presents the identification information to the wallet server during the authentication phase of each remote transaction, assuming also that the authentication channel (channel 3 or 5 in Figure 8.9) is confidential. There is also the possibility of using a one-time password scheme, which would confer the dynamic dimension of the cardholder authentication mechanism, while still remaining in the software only domain.

Concerning the transaction flow of the SET payment method in the thin client configuration, this is overviewed in Figure 8.10, only for that part of the transaction flow that is modified compared to the original SET transaction flow as presented in Figure 8.7.

Figure 8.10: SET transaction flow in the thin client architecture.

After the completion of the browsing/ordering phase, the merchant server sends to the cardholder access device the SET Initiation message (1), describing the conditions of the transaction (see Section 8.4.6.1). The cardholder forwards this description of the purchase together with enough identification information to the wallet server (2). The wallet server conducts the cardholder authentication either locally, if the issuer delegated to it the necessary identification information of cardholders, or through an out of band mechanism that is connected directly to the issuer. If the wallet server correctly identifies the cardholder, it will trigger a SET payment phase with the merchant on behalf of the cardholder. To this end, the wallet server and the merchant exchange their certificates and realize the purchase transaction initialization with the pair of messages PInitReq(3)/PinitRes(4). Then, the wallet server produces the transaction dual signature on behalf of the cardholder and forwards the PReq (5) message to the merchant. The merchant authorizes the transaction with the payment gateway (AuthReq). The payment gateway inquires of the appropriate issuer (1100 message) and receives the appropriate response (1110 message), based on which it elaborates the authorization response (AuthRes) towards the merchant. The merchant finally transmits the PRes (6) to the wallet server, which further informs the cardholder about the status of the transaction with a purchase acknowledgment message (7).

In the password mechanisms mentioned above, the authenticity of the cardholder is reduced to a set of data in his or her possession, which can be easily copied or stolen. There is no physical proof that the legitimate cardholder is interacting with the wallet server. A better level of confidence can be provided with verifiable secret data from a cardholder specific token. This token is uniquely linked to the cardholder. The EMV ¢ chip card can serve as such a token, since its tamper-resistance impedes attackers from easily counterfeiting it or copying its secret data. The AC produced by the EMV ¢ chip can serve as an on-line CAM, which can prove without any doubt that the card is not counterfeit (ES4). If the production of the AC is combined with a DDA, the signature produced by the card can be used as an irrefutable proof of the cardholder's participation in a certain transaction. This provides an optimal implementation of the cardholder non-repudiation service (NS1). Moreover, when the computation of the combined AC/DDA is conditioned by the correct verification of a PIN, then the physical presence of the cardholder in the remote transaction is assured, which implements the cardholder authentication (ES5).

The cost paid for these security improvements is the need to integrate the EMV ¢ message manager component in the structure of the SET thin client, coordinating both the ICC interface device and, optionally , the (secure) PIN entry device. If the PIN entry is not included in the configuration, then once again the cardholder authentication is linked to the on-line CAM, which does not really prove the physical presence of the cardholder in the remote transaction. Only the combination between something the cardholder has (the EMV ¢ chip card) and something the cardholder knows (PIN) is accepted to prove the physical presence of the cardholder.