# An e-payment architecture ensuring a high level of privacy protection

Aude Plateaux, Patrick Lacharme, Vincent Coquet, Sylvain Vernois, Kumar Murty, Christophe Rosenberger

<figure><img src="image_1.png" /></figure>

## To cite this version:

Aude Plateaux, Patrick Lacharme, Vincent Coquet, Sylvain Vernois, Kumar Murty, et al. An e-payment architecture ensuring a high level of privacy protection. International Conference on Security and Privacy in Communication Networks (SecureComm), 2013, Sydney, Australia. 10.1007/978-3-319-04283-1_19. [hal-01001929]

HAL Id: hal-01001929

https://hal.science/hal-01001929v1

Submitted on 7 Apr 2025

HAL is a multi-disciplinary open access archive for the deposit and dissemination of scientific research documents, whether they are published or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est destinée au dépôt et à la diffusion de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

<figure><img src="image_2.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
# An e-payment architecture ensuring a high level of privacy protection

Aude Plateaux¹,², Patrick Lacharme¹, Vincent Coquet², Sylvain Vernois¹, Kumar Murty³, and Christophe Rosenberger¹

¹ ENSICAEN, 17 rue Claude Bloch, 14000 Caen, France
[aude.plateaux, patrick.lacharme, sylvain.vernois, christophe.rosenberger]
@ensicaen.fr,

² BULL SAS, Avenue Jean Jaurès, 78340 Les Clayes-sous-Bois, France
vincent.coquet@bull.net,
Department of Mathematics, 40 St. George Street, Toronto, Canada
murty@math.toronto.edu

**Abstract.** Online shopping is becoming more and more interesting for clients because of the ease of use and the large choice of products. As a consequence, 2.3 billion online clients have been identified in 2011. This rapid increase was accompanied by various frauds, including stolen smart cards or fraudulent repudiation. Several e-payment systems have been proposed to reduce these security threats and the 3D-Secure protocol is becoming a standard for the payment on the Internet. Nevertheless, this protocol has not been studied in-depth, particularly in terms of privacy. This paper proposes a detailed description and an analysis of the 3D-Secure protocol, through a new privacy-orienting model for e-payment architectures. Some improvements of 3D-Secure protocol, concerning the protection of banking information, are also presented. Then, this article presents and analyses a new online payment architecture centered on the privacy of individuals.

**Key words:** Electronic payment, privacy and security

## 1 Introduction

In recent years, e-commerce has considerably grown with the democratization of the Internet. Thus, online payments were adopted by 69% of Internet users in 2011. Fraud amount in e-payment has increased with the same regularity and become now a major concern for financial institutions and web clients [20]. Indeed, although the online payment only represents a small percentage of transactions, it concentrates, for instance, 40% of the amount of fraud in France and 54% in United Kingdom [23]. Clients and merchant websites are not always the only actors in the electronic payment architecture. In addition to the two banks, the security problem is sometimes modified by the introduction of another actor, the third-party cashiers, as Paypal or Amazon payment (called Cashier as a Service in [35]), but it is not the scope of this paper.
Many directives are related to the security of online payments, as for instance, the European Directive 2000/31/EC on e-commerce security [13]. In the same way, the Directive on Payment Services, [14], provides an european wide single market for payments and a legal platform for SEPA (Single Euro Payment Area, [16]). The banking industry strategy is centered on identity spoofing and user authentication. The first protocol proposed to securize electronic transactions was SET (Secure Electronic Transactions, [32]). Standard e-payment protocols are later enhanced by an additional secret, sent by mobile phone, as for the 3D-Secure protocol [33] or an additional device as a CAP reader [25]. However, the results in terms of security of these responses are mitigated [28, 18]. Moreover, if the SET protocol has been extensively studied by the academic literacy (for instance [27, 8, 9, 10]), the 3D-Secure protocol is surprisingly overlooked, excepted in the security analysis of Murdoch and Anderson [28] and Pasupathinathan et al. [30].

Security and authentication in e-business should not be strengthened to the detriment of users' privacy [26]. There are a lot of personal information involved in all steps of a payment on the Internet and these data should be protected. Principles of user centric architecture and *privacy by design* are more and more accepted by numerous organizations and actors of various areas. For example, the European Commission has strengthened in 2010 the principle of data minimization, requiring that the personal data disclosure should be limited to adequate, relevant and non-excessive data [15]. Another important aspect of user's privacy concerns the data sovereignty principle: the personal data belong to an individual, with a control and a consent on the use of data and their purposes. Finally, the data sensitivity principle applies personal data must be considered as sensitive and requires a decentralized structure for their storage. These principles should be applied to e-payment systems.

The e-payment development has strongly modified the traditional relationship between a bank and its clients. During these transactions, a large amount of user's personal information is requested and stored. It is therefore essential to focus on user privacy in online payments and services. Surprisingly, the e-payment industry seems not concerned by privacy. PCI/DSS is a first step of payment industry into personal data protection [19]. However, this norm is mainly concerned by data security in payment systems. User's privacy protection has been completely disappeared in e-payment protocols on the Internet by the transition from SET to 3D-Secure [28]. Some existing publications deal with e-payment protocol generally focused on the security of service providers and users without talking about the user's privacy. The aim of the proposed architecture is to meet all the requirements in terms of security and privacy protection.

**Our contribution.** We propose a list of necessary requirements for security and privacy protection of users and merchants during online payments. Then, using these requirements, we analyze the level of privacy protection of the current 3D-Secure protocol and propose an improvement of the protocol in order to enhance some privacy criteria. Our main contribution is the proposition of an e-payment architecture providing security for the actors and more privacy pro-
tection for the users and the service providers. The presented solution allows the users to make a purchase on the Internet, with the generation of an electronic bank cheque. More precisely, the proposed solution ensures the data minimization, sensitivity and sovereignty principles without disclosing any user's banking information.

**Organization.** The reminder of this paper is organized as follows: Actors of the system and the security and privacy requirements are presented in Section 2. In Section 3, a description of existing e-payment solutions are presented, with a detailed focus on the 3D-Secure protocol, as well as an improvement of this latter. Finally, the context and the new solution are proposed and explained in Section 4, then analyzed in Section 5.

## 2 Security and privacy requirements of e-payment systems

Four actors are present in electronic payments: The **client C** wants to purchase an online service with a credit card, through the website of a **service provider SP**. These two actors have one payment provider: the **debit account bank** and **credit account bank**, called respectively in this paper *client's bank* and *SP bank*. In most of e-payment architectures, a fifth actor is involved, the trusted part as a third-party cashier or the Directory used in 3D-Secure. The role of this fifth actor is consequently various. However, the security analysis of the payment scheme is generally similar and allows to authenticate the banks. The proposed architecture is concentrated on the payment phase. Thus, in the case where the authentication and/or the registration with the *SP* is required, we assume it is properly conducted. The protocol should securely ensures that the client is debited and the *SP* is paid, but the *SP* has not to know inadequate client's information.

Several personal data are involved during an online payment. These data must be protected against numerous threats. A list of these potential threats has been presented by Antoniou and Batten in [5]. These threats notably concern the information revealed by a client to the *SP*. In order to ensure the minimization principle, the personal information must be divided in different parts. Indeed, function of the data owner, the information will be differently protected. However, the data sovereignty and data sensitivity principles must also be applied to any e-payment architecture. In the proposed approach, the personal information is divided in three parts:

1. The identity information *Id* includes the information allowing to know the client's identity, for instance, his/her name.

2. The order information *OI* includes the detailed basket and other data linked to the expected service, as the *SP* name. These data are known by the *SP*.

3. The banking information *BI* is, for instance, composed of client's bank name, the personal account number (*PAN*) or the cryptogram *CVX2*. These data are known by the client's bank. As an indication, it is necessary to take note that the *PAN* can also allow to identify a client.
A list of fifteen requirements $R_i$ including all privacy principles, as well as the risks raised in the literature, is established. These requirements should be taken into account by the e-payment architectures:

- $R_1$: The **confidentiality of transactions** requires that each exchanged data must be encrypted in order to protect these data against external entities.

- $R_2$: The **integrity of transmitted information** allows the accuracy of the content and so the non-alteration of data during transmission or storage.

- $R_3$: The **confidentiality of client's identity towards the SP** ensures that a client can access to a service without disclosing his/her identity to the SP. This requirement is waived if the customer wants a home delivery service.

- $R_4$: The **confidentiality of client's identity towards the SP bank** ensures that a client can access to a service without disclosing his/her identity to the SP bank.

- $R_5$: The **client's authentication** by a trusted part ensures the identity of the client. Function of cases, the trusted part can ideally be the client's bank or another trusted part where the client is registered.

- $R_6$: The **SP authentication** by the client or by a trusted part ensures the identity of the SP.

- $R_7$: The **banks authentication** by a trusted part ensures the identity of SP bank and client's bank.

- $R_8$: The **unlinkability** of transmitted information (banking or other) allows to have unique and non-reusable transactions.

- $R_9$: The **confidentiality of order information** $OI$ ensures that only authorized persons have access to order information. This requirement includes that the client's basket is unknown to the client's bank.

- $R_{10}$: The **confidentiality of banking information** $BI$ (or client's data minimization principle) ensures that only authorized persons have access to banking data. This requirement includes the fact that the SP does not know the client's banking information.

- $R_{11}$: The **client's anonymity** is ensured if the requirements $R_3, R_4, R_9$ and $R_{10}$ are fulfilled. Indeed, one of information included in $OI$ or $BI$ partially allows to identify the client.

- $R_{12}$: The **SP's data minimization** principle includes the fact that the client does not know the SP bank. This condition is very important when the SP is a very small organisation, for instance one person. Indeed, in this case, the SP bank is the same bank than the manager's personal bank. Moreover, the SP's data minimization principle includes the requirement $R_4$. The SP bank has not to know the client.

- $R_{13}$: The **data sovereignty** principle involves the personal data are associated to the client with his/her control and consent on the use of data.

- $R_{14}$: The **data sensitivity** principle involves that the personal data are considered as sensitive and requires a de-centralized structure for data storage.

- $R_{15}$: The **ownership of a certificate** for the client **should not be required** in order to facilitate the e-payment. This last requirement concerns the usability of payment systems.
# 3 Existing e-payment architectures

## 3.1 Introduction and related works

An online service generally begins with an authentication and a secure connection between the client and the SP website, using a protocol such as SSL/TLS [22, 17]. This protocol involves the client trusting in the SP to keep this payment information and is aware of known published browser attacks [34, 24, 3]. However, the client can use a trusted partner, such as Paypal. This service implies the creation of a Paypal account for the client and, consequently, a large amount of personal data is registered: name, email, address, PAN, CVX2 and expiration date. Then, the client can send and receive online payments without providing new data, through the Paypal platform. Nevertheless, although Paypal specifies not sell or rent this information, its privacy policy [31] adds it can share some of your personal information with third parties in the world. If the client does not use a trusted partner, he/she must supply the SP bank, through the SP website, his/her banking information: PAN, CVX2 and expiration date. Client's banking information is so directly sent to the SP.

Several payment schemes have been recently proposed. For instance, a secure payment protocol managing different aspects such as smart card with network capabilities or the multiplicity of entities is proposed in [11]. However, these scenarios do not manage user's privacy. Antoniou and Batten are interested in enforcing trust in e-commerce systems [5]. They propose four models with four levels of privacy protection. However, these protocols are centered around one deliverer which knows all stakeholders of the process. Another scheme is suggested by Ashrafi and Ng in [6], by using a non-reusable password based authentication. The process ensures the client's privacy and minimizes the SP business risks. This protocol uses the card company with an optional payment gateway and has the same complexity as the 3D-Secure protocol. However, all the security is based on the card company which stores all the client's payment details in a local centered database.

The SET protocol [32] was developed by a consortium of credit card companies, such as VISA [1] and MasterCard [2], and software corporations. It is a protocol for securing e-payment transactions by credit card which runs in two steps: registration and purchase. This protocol ensures the data confidentiality and integrity and provides a mutual authentication between the SP and the client, through a trusted third party, the SP bank. This secure protocol has many advantages considering client's and SP privacy. The SP does not know the client's banking information. The client bank does not see the contents of the order. And finally, the client does not know the identity of the SP bank. However, in terms of client's privacy, the client does not necessarily trust the SP bank which authenticates him/her. Therefore, the SP bank knows the client's identity. In addition, although the client's bank does not know the contents of the client's order, it knows the SP identity. SET has been extensively analyzed in the beginning of the 2000s and improved [8, 7, 21]. Thus, the client's consent to send his/her credit card details cannot be proved [9]. Moreover, this protocol is
complex from the client perspective and expensive for the *SP* Indeed, a specific software must be installed by the client in order to prove card detention with an electronic signature. In addition, card readers and distribution of certificates by the *SP* are inevitable. Consequently, the successor of the SET protocol is the 3D-Secure protocol where the few parts concerning privacy of SET are simply deleted. The Fig.1 quickly analyses this protocol.

## 3.2 Description of the 3D-Secure protocol

The 3D-Secure protocol [33] is the commonly used two-factors authentication system for e-payment, developed by VISA in 2001. Other financial organizations also developed their own implementations of VISA's 3D-Secure licensed architecture, such as MasterCard with its MasterCard SecureCode, American Express with SafeKey [30]. In order to use the 3D-Secure protocol, a dedicated module called MPI (Merchant Plug In) is implemented into the *SP* website. Moreover, a dedicated server (the Directory) is made available for this system. This scheme processed as after-specified (see Fig.4 in the Section Annexes):

A. The client sends to the *SP* his/her purchase intention, with his/her banking information: *PAN*, expiration date and *CVX2*.

B. MPI queries the Directory server with the VEReq (Verify Enrollment request) message.

C. The Directory server checks the *SP* identity, the card number and the client's bank. The Directory recovers the ACS (Access Control Server) managing the card and transfers the VEReq message. The *PAN* allows the Directory server to identify the ACS.

D. The ACS checks if the client's card is enrolled in the 3D-Secure program and sends the cardholder authentication URL to the MPI through the VERes (Verify Enrollment Result) message.

E. MPI sends the PAReq (Payer Authentication Request) message to the previous URL. This message contains the details of the authorized purchase and requests the ACS to authenticate the cardholder. The authentication protocol depends on the cardholder's bank.

F. The client provides the necessary information for authentication to the bank.

G. ACS sends to MPI a confirmation of client's authentication through PARes (Payer Authentication Responses) message.

H. MPI records PARes message as confirmation of client's authentication by ACS.

I. *SP* authenticates to the bank. The bank checks the nature of the transaction from the client's bank and confirms the payment authorization from the *SP*. The *SP* gets his/her payment and the client's bank stores payment information to ensure non-repudiation of the transaction.

The main security flaw of 3D-Secure implementations, underlined in [28], has been corrected by many banks. The client authentication with his/her date of birth or other trivial secrets is consequently replaced by an One Time Password
sent to user's mobile phone. As an indication, the complete payment phase is not
described. Thus, the entire payment system using 3D-Secure protocol contains
more than nine steps.

3.3 Privacy analysis and improvements of 3D-Secure

In a first step (step A), the client sends his/her banking information to the
*SP* bank. However, this information can identify him/her. Consequently, the
requirements *R*<sub>3</sub> and *R*<sub>10</sub> can not be guaranteed. The requirements *R*<sub>4</sub> and *R*<sub>12</sub>
are also not respected given that the client's bank knows the *SP* identity and
the *SP* bank knows the client's identity. Then, even if the client's authentication
is realized by his/her bank, this authentication is also realized by the Directory
server.step C). Consequently, *R*<sub>5</sub> is partially ensured. Similarly, the *SP* authen-
tication is not realized by the client or by a client's trusted part (step C. and
I.), and *R*<sub>6</sub> is not respected. In addition, the order information is contained in
the *PAReq* message sent to ACS (step E.), these data are consequently not
confidential (*R*<sub>9</sub>). Thus, the requirements *R*<sub>3</sub>, *R*<sub>4</sub>, *R*<sub>9</sub> and *R*<sub>10</sub> are not ensured,
the requirement of anonymity *R*<sub>11</sub> cannot be respected. Finally, *R*<sub>13</sub> is only par-
tially respected. Indeed, the client has not total control over these data which
passes through many entities. In addition, in terms of privacy, the sensitivity of
exchanged information is not enough taken into account. Therefore, *R*<sub>14</sub> is not
ensured. The 3D-Secure protocol ensures therefore only six of the fifteen require-
ments. However, the privacy protection of 3D-Secure can easily be improved by
using the *SP* bank certificate. Indeed, in the 3D-Secure protocol, *CVX2* and the
expiration date are not necessary. These data are only use for the compatibility
with classic existing payment systems. Thus, given that the client's authentica-
tion from his/her bank is strong, these two elements are unnecessary. The *SP*
bank certificate contains the standard information, as well as the Directory pub-
lic key. Only two steps must so be modified (the other seven steps are the same
as above):

A. The *SP* provides **the SP bank certificate** to the client. Thus, the client sends to the *SP* his/her purchase intention, **with only his/her PAN encrypted by the Directory public key.** These data are intended for a dedicated module MPI implemented into the *SP* website.

C. The Directory server **decrypts the PAN with its private key** and checks the *SP* identity, the card number and the client's bank. The Directory recovers the ACS managing the card and transfers the VEReq message.

These small changes do not involve significant modifications in the 3D-Secure
architecture. Moreover, these improvements involve none of the client's banking
information is visible by the *SP* and thus ensure *R*<sub>10</sub>. Indeed, through the *SP*
bank certificate, the encryption of *PAN* is possible and use of *CVX2* is avoided.
In addition, only relevant data and useful data pass through the Directory server.
The requirement *R*<sub>14</sub> can be taken into account, as well as *R*<sub>5</sub>. Indeed, the client
is only authenticated by his/her bank. The Fig.1 shows the increase of the privacy
protection level thanks to these modifications.
<table><caption>Fig. 1. Properties of the 3D-Secure protocols and comparison with SET</caption><thead><tr><th>R<sub>i</sub></th><th>Properties</th><th>3D-Secure Protocol</th><th>3D-Secure Improvement</th><th>SET Protocol</th></tr></thead><tbody><tr><td>R<sub>1</sub></td><td>Confidentiality of transactions</td><td>Yes</td><td>Yes</td><td>Yes</td></tr><tr><td>R<sub>2</sub></td><td>Integrity</td><td>Yes</td><td>Yes</td><td>Yes</td></tr><tr><td>R<sub>3</sub></td><td>Confidentiality of client's identity for SP</td><td>No</td><td>No</td><td>No</td></tr><tr><td>R<sub>4</sub></td><td>Confidentiality of client's identity for SP bank</td><td>No</td><td>No</td><td>No</td></tr><tr><td>R<sub>5</sub></td><td>Client's authentication</td><td>Partial</td><td>Yes</td><td>No (by SP bank)</td></tr><tr><td>R<sub>6</sub></td><td>SP authentication</td><td>No</td><td>No</td><td>No (by SP bank)</td></tr><tr><td>R<sub>7</sub></td><td>Banks authentication</td><td>Yes</td><td>Yes</td><td>Partial</td></tr><tr><td>R<sub>8</sub></td><td>Unlinkability</td><td>Yes</td><td>Yes</td><td>No</td></tr><tr><td>R<sub>9</sub></td><td>Confidentiality of OI</td><td>No</td><td>No</td><td>Partial</td></tr><tr><td>R<sub>10</sub></td><td>Confidentiality of BI</td><td>No</td><td>Yes</td><td>Yes</td></tr><tr><td>R<sub>11</sub></td><td>Client's anonymity</td><td>No</td><td>No</td><td>No</td></tr><tr><td>R<sub>12</sub></td><td>SP data minimization</td><td>No</td><td>No</td><td>No</td></tr><tr><td>R<sub>13</sub></td><td>Data sovereignty</td><td>No</td><td>No</td><td>Partial</td></tr><tr><td>R<sub>14</sub></td><td>Data sensitivity</td><td>No</td><td>Partial</td><td>Partial</td></tr><tr><td>R<sub>15</sub></td><td>Ownership of certificate not necessary</td><td>Yes</td><td>Yes</td><td>No</td></tr></tbody></table>

Nevertheless, this improved protocol does not fulfill all requirements described in Section 2. The minimization principle, specially $R_9$, is not respected. For example, the client's bank knows the purchases of the client or at least the merchant category. The bank is so able to deduce the purchases type. Consequently, the anonymity principle is not respected. Moreover, as often in the existing e-payment architectures, the fifth actor always takes place in the middle of the transaction, for instance, the Directory server in 3D-Secure or the card company in the Ashrafi and Ng's model [6]. Thus, the privacy is always exposed to an impossibility of complete protection.

## 4 The new e-payment architecture

The proposed architecture combines the advantages of electronic cheque systems and easy-to-use of online payment systems related in Section 3.1. However, the architecture is not considered as an electronic cheque scheme [4] which are often difficult to use for the average user. Indeed, these systems lead to the use of client's certificate and an electronic checkbook card. Many computations and storages by the client's bank are also required, even if [12] proposes a small improvement. Finally, these schemes do not generally take into account privacy protection, excepted in [29].

Thus, our new architecture involves five actors: the client, the merchant SP, both banks and an additional entity, the interbank system IS. The goal of this interbank trusted third party is detailed later. Each bank generates a key pair, where the public key is certified by the IS. This latter publishes these certificates which contain the following: its name; its public key; the hash function
algorithm; the signature algorithm and the name of certification authority. Similarly, the SP has a key pair, where the public key is certified by the trusted third party contractualized with, for instance the interbank system. These certificates are composed by the following data: its name; its public key; the hash function algorithm; the signature algorithm; the name of certification authority and the parameters describing the payment scheme recognizing the SP and allowing to secure the future payment (American Express, VISA, MasterCard,...). In addition, as explained in the sequel, the new architecture allows the SP not to reveal the identity of its bank. Thus, in order to add privacy for the SP, the generation of the SP certificate by a trusted part different from the SP bank is preferable. For instance, the interbank trusted part could play this role.

**Notations:** The notations for the proposed e-payment protocol are:

- $Sign_X(m)$: Signature of message $m$ by the actor $X$;

- $[m]_{K_{PU_X}}$: Encryption of message $m$ by the public key $K_{PU}$ of the actors $X$;

- $[m]_{K_{S_X}}$: Encryption of message $m$ by the session key $K_S$ of the actors $X$;

- $N_i$: Random number $i$ used to guarantee the freshness of messages.

- $H(m)$: Hashing of message $m$;

The online payment architecture respecting the users' privacy proposed in this article is based on the generation of two documents: a contract between the SP and the client, and another electronic bank document, called electronic bank cheque or cheque to simplify. As explained in the beginning of this section, this latter document is different from the cheque generated in the electronic cheque architecture. The interbank system IS plays the role of a trusted third party. It enables communication between banks without revealing information about the other actors. The new solution is summarized in Fig.2. First, the client creates his/her basket and sends it to the SP with a random number $N_1$, as well as a session key $K_{S_1}$ (Step 1). $N_1$ ensures the freshness of message and $K_{S_1}$ encrypts data between the client and the SP. In the case where the client has a certificate, the session key is replaced by his/her public key.

$$ \text{Client} \to \text{SP} : [\text{Basket}, N_1, K_{S_1}]_{K_{PU_{SP}}} \quad (1) $$

The SP then generates a contract with its client (Step 2), containing:

- The total amount *Amount* of purchases;

- A random order number *Order* generated by the SP. This number has not to link to the SP identity;

- A symmetric random key $K_{S_2}$ encrypted by the public key of the SP bank $K_{PU_{Bank_{SP}}}$;

- The beneficiary's name *Benef* encrypted by the previous symmetric key $K_{S_2}$;

- The URL of the SP in order to return to the payment page;

- The detailed shopping list *Basket*, such as quantity or unit price.

$$ SP : Contract = Amount, Order, [K_{S_2}]_{K_{PU_{Bank_{SP}}}}, [Benef]_{K_{S_2}}, URL \quad (2) $$
<figure><img src="image_3.png" /><figcaption>Fig. 2. The proposed e-payment architecture.</figcaption></figure>

To avoid the non-repudiation and ensure the SP authenticity, the SP signs the contract. This latter is then sent to the client with the hash of Basket and $N_1$ (Step 3).

$$Client \leftarrow SP : [Sign_{SP}(Contract, H(N_1, Basket))]_{K_{S_1}} \quad (3)$$

Then, the client connects to his/her bank, using a macro of its Internet browser (Step 4). The macro establishes the HTTPS connection and sends a filtered contract. The authentication protocol depends on the client's bank. But, a strong authentication is recommended. The filtered contract only contains the necessary information of the contract for the client's bank: the whole amount, the currency, the encrypted symmetric key, the encrypted beneficiary's name and the random order number. Thus, the client's bank does not know the SP identity. Moreover, a random number $N_2$ ensures the freshness of messages. The client has no public key certificate, his/her bank will consequently use the session key $K_{S_3}$ to encrypt the messages with his/her client. To encrypt the beneficiary's name, a session key is favoured in order to reduce the computation complexity.
$$ \begin{aligned} \text{Client} \to \text{Bank}_C : & [\text{Amount}, \text{Order}, [K_{S_2}]_{K_{PUBank_{SP}}}, [\text{Benef}]_{K_{S_2}}, \\ & N_2, K_{S_3}]_{K_{PUBank_C}} \end{aligned} \quad (4) $$

Then, if the authentication is successful and the client is creditworthy, the bank positively responds to the client's request. The bank generates an electronic bank cheque to the SP (Step 5). This electronic cheque includes: the total; the currency; the random order number; the encrypted beneficiary's name; the encrypted symmetric key; the information of the client's bank and the signature of the client's bank. Thus, the cheque does not contain client's banking information.

$$ \text{Bank}_C : \text{Cheque} = \text{Sign}_{\text{Bank}_C}(\text{Amount}, \text{Order}, [K_{S_2}]_{K_{PUBank_{SP}}}, \quad (5) \\ [\text{Benef}]_{K_{S_2}}, \text{DueTimeDate}, \text{BankDetails}) $$

The client's bank signs the cheque and encrypts it with the interbank system public key. Thus, IS could check the banks identities and the cheque validity. The cheque is sent to the client (Step 6) who forwards it to SP (Step 7). N₂ and N₃ ensure the freshness of transactions. N₂ also gives the identity of the request. The result being encrypted, the SP cannot know client's banking information.

$$ \text{Client} \leftarrow \text{Bank}_C : [[\text{Cheque}]_{K_{PUIS}}, N_2]_{K_{S_3}} \quad (6) $$

$$ \text{Client} \to \text{SP} : [[\text{Cheque}]_{K_{PUIS}}, N_3]_{K_{PU_{SP}}} \quad (7) $$

Then, the SP obtains [Cheque]_{K_{PUIS}} and N₃ thanks to its private key. So, the SP authenticates to its bank (Step 8) and provides its filtered contract, the signed and encrypted electronic bank cheque. As previously, the authentication protocol depends of the SP bank. However, a strong authentication is recommended. The SP filtered contract contains: the whole amount, the currency, the beneficiary's name and the random number.

$$ \text{SP} \to \text{Bank}_{SP} : [\text{Amount}, \text{Order}, \text{Benef}, [\text{Cheque}]_{K_{PUIS}}, N_4]_{K_{PUBank_{SP}}} \quad (8) $$

In order to validate the banks identities and the cheque, the SP bank authenticates to the interbank system and transfers the cheque (Step 9) in using N₅ for the freshness of the transaction.

$$ \text{Bank}_{SP} \to \text{IS} : [[\text{Cheque}]_{K_{PUIS}}, N_5]_{K_{PUIS}} \quad (9) $$

The interbank system checks the identity of the SP bank and decrypts the electronic cheque with its private key (Step 10). The validity of this cheque, its signature, and consequently the identity of the client's bank, are checked. Then, if the verifications are correct, the interbank system re-encrypts the cheque with the public key of the SP bank and the cheque is transferred to this bank (Step 11). N₅ is reused to identify the request.

$$ \text{Bank}_{SP} \leftarrow \text{IS} : [\text{Cheque}, N_5]_{K_{PUBank_{SP}}} \quad (11) $$
The SP bank decrypts the cheque with its private key (Step 12). It firstly checks that the cheque amount and currency are similar to those provided by the SP in the filtered contract. Then, the bank decrypts the symmetric key with its private key. Thanks to this symmetric key, the SP bank decrypts the beneficiary's name. Afterwards, the bank compares the beneficiary's name of the filtered contract with the decrypted name of the electronic cheque. As indication, the verification of the client's bank signature by the SP bank is optional. Indeed, the interbank system has processed to this verification. The SP bank can use directly the client's bank information.

Finally, if one verification fails, the transaction is cancelled. However, if all verifications are correct, the SP bank contacts SP and validates the cheque as being authentic; that allows the SP to deliver service for its client (Step 13, 14). The random numbers $N_3$ and $N_4$ allow to identify the requests and to guarantee the freshness of transactions.

$$ SP \leftarrow Bank_{SP} : [Response, Amount, Order, N_4]_{K_{PUSP}} \quad (13) $$

$$ Client \leftarrow SP : [Service, Amount, Order, N_3]_{K_{S1}} \quad (14) $$

The SP bank also contacts the client's bank, located through the electronic cheque. The debit/credit process between banks completes this payment architecture in using the electronic cheque as payment proof. This protocol has a few more steps than the 3D-Secure protocol, but 3D-Secure (and most of the other schemes) does not take into account the payment phase between the client's bank and the SP bank.

# 5 Analysis of the architecture

Most of security and privacy requirements are ensured by the first eight steps of the proposed architecture. The last five steps allow to ensure the banks authentication by the interbank system ($R_7$) and so to avoid the money laundering.

## 5.1 Data security and authentication

The secure channel between actors and the encryption schemes ensure the confidentiality of exchanged data during the protocol. Consequently, the requirement $R_1$ is ensured. The use of random numbers guarantees the freshness of messages, avoids the linkability and ensures the data integrity respecting $R_2$ and $R_8$. Entities authentication is realized through certificates, one for the SP and one for each bank. Thus, contrary to the SET protocol, the trusted third party is not one of banks. The banks own certificates issued by IS. The SP certificate is provided by IS or another trusted authority. These documents allow to sign, encrypt and decrypt information and to prove the validity of the SP and banks. The interbank system manages the bank certificates and authenticates the SP
bank and the client's bank. Moreover, *IS* checks information contained in the signed electronic cheque and gives a validation of cheque for the *SP* bank. The contract signed by the *SP* then allows client to obtain his/her service with indicated conditions. Finally, validation of the client's bank identity by *IS* and verification of transaction information by the *SP* bank ensure the *SP* to be paid once the service provided. Thus, the requirement $R_7$ can be ensured. Moreover, these verifications by *IS* also allow to avoid money laundering by malicious *SP* and malicious *SP* bank.

## 5.2 Privacy analysis

The proposed architecture is more respectful of the users' privacy than the SET protocol and 3D-Secure protocol. The *SP* authentication by the client and then the *SP* bank, ensures the *SP* validity and the client does not provide personal order data as long as he/she is not certain to use a service. The requirement $R_6$ is thus respected. Moreover, the client's identity is never disclosed and the *SP* bank does not know the client. This authentication is realized by the client's bank. Thus, the requirements $R_3, R_4$ and $R_5$ are respectively ensured. More precisely, in order to respect the client's privacy during the transfer of data to different banks, the order number, used in Step (3), has not to contain *SP* information, as the business number. Consequently, it must be random or unidentifiable. As an indication, in the case where the two banks would be the same, all requirements would be preserved except that the bank could know the *SP* and the client. Secondly, the filtered contract, with the encrypted beneficiary's name and the random order number. In addition, the client's bank knows neither contents of the basket, nor the *SP* with whom his/her client deals. The requirement $R_9$ is consequently ensured. This new proposition also solves the other privacy problems of 3D-Secure protocol. The client's banking information is preserved against the *SP* ensuring the requirement $R_{10}$. The encrypted cheque with *IS* private key allows the *SP* not to have knowledge of the client's bank. Moreover, contrary to all the existing e-payment architecture, the client's banking information is never disclosed to the *SP*. Thus, the requirements $R_3, R_4, R_9$ and $R_{10}$ are respected. Consequently, the client can be anonymous and the requirement $R_{11}$ can be ensured. Finally, the cheque encrypted with *IS* public key prevents the client to know the *SP*'s bank. Consequently, the protection of some *SP* personal information, representing the requirement $R_{12}$ is also ensured by this protocol. This requirement is important when the *SP* is a small organisation and consequently, when the *SP* bank is the same bank than the manager's personal bank.

The most sensitive data of client and *SP* are protected. The requirement $R_{14}$ is ensured and the client only provides the necessary, appropriate and relevant information (minimization and sensitivity principles). In addition, the fifth part performs at the end of the architecture. Thus, the privacy can be protected at the most without constraint of data disclosure. Once the *SP* has signed the contract, the client should click two times to accept it: one for the confirmation of his/her basket and one for the validation of the payment. Thus, the client has read two times the similar information. These two clicks are used to ensure the
client's consent and, consequently, the requirement $R_{13}$. These clicks could be replaced by a client's signature based on a certificate. In the future, the certificate will be possibly present in the client's identity card or his/her passport. Finally, the ownership of certificate by the client is not necessary ($R_{15}$), contrary to SET protocol for instance. Figure 3 summarizes the analysis of the proposed architecture compared to the existing protocols 3D-Secure and SET protocol.

<table><caption>Fig. 3. Properties of the 3D-Secure, SET and the proposed protocols.</caption><thead><tr><th>R<sub>i</sub></th><th>Properties</th><th>3D-Secure Protocol</th><th>SET Protocol</th><th>The proposed Protocol</th></tr></thead><tbody><tr><td>R<sub>1</sub></td><td>Confidentiality of transactions</td><td>Yes</td><td>Yes</td><td>Yes</td></tr><tr><td>R<sub>2</sub></td><td>Integrity</td><td>Yes</td><td>Yes</td><td>Yes</td></tr><tr><td>R<sub>3</sub></td><td>Confidentiality of client's identity for SP</td><td>No</td><td>No</td><td>Yes</td></tr><tr><td>R<sub>4</sub></td><td>Confidentiality of client's identity for SP bank</td><td>No</td><td>No</td><td>Yes</td></tr><tr><td>R<sub>5</sub></td><td>C's authentication</td><td>Partial</td><td>No (by SP bank)</td><td>Yes</td></tr><tr><td>R<sub>6</sub></td><td>SP authentication</td><td>No</td><td>No (by SP bank)</td><td>Yes</td></tr><tr><td>R<sub>7</sub></td><td>Banks authentication</td><td>Yes</td><td>Partial</td><td>Yes</td></tr><tr><td>R<sub>8</sub></td><td>Unlinkability</td><td>Yes</td><td>No</td><td>Yes</td></tr><tr><td>R<sub>9</sub></td><td>Confidentiality of OI</td><td>No</td><td>Partial</td><td>Yes</td></tr><tr><td>R<sub>10</sub></td><td>Confidentiality of BI</td><td>No</td><td>Yes</td><td>Yes</td></tr><tr><td>R<sub>11</sub></td><td>C's anonymity</td><td>No</td><td>No</td><td>Yes</td></tr><tr><td>R<sub>12</sub></td><td>SP data minimization</td><td>No</td><td>No</td><td>Yes</td></tr><tr><td>R<sub>13</sub></td><td>Data sovereignty</td><td>No</td><td>Partial</td><td>Yes</td></tr><tr><td>R<sub>14</sub></td><td>Data sensitivity</td><td>No</td><td>Partial</td><td>Yes</td></tr><tr><td>R<sub>15</sub></td><td>Ownership of certificate not necessary</td><td>Yes</td><td>No</td><td>Yes</td></tr></tbody></table>

## 6 Conclusion

A lot of sensitive information are transferred during current online payment transaction, introducing strong privacy problems. Current e-payment systems, as 3D-Secure, are not designed to ensure user's privacy. Moreover, even if its proposed improvement is more respectful of the privacy, several underlined requirements are not ensured. The proposed architecture allows to overcome these weaknesses by respecting the client's privacy against the banks and the SP, as well as the SP privacy. This solution is mainly based on the generation of an electronic bank cheque associated with certificates.

This architecture is fully compliant with the data minimization, data sovereignty and data sensitivity principles. More particularly, the payment transaction never discloses any client's banking information. Moreover, the client does not need to have particular knowledges or cryptographic devices. The non-repudiation could be improved by supplying the client with a certificate. Moreover, in order to prove the practicability of the proposed solution, a proof of concept and a statistical study are currently conducted (see Annexes).
# Acknowledgment

The authors would like to thank Gabriel Frey and Arnaud Gouriou for their project concerning the implementation of our proof of concept, Roch Lescuyer for his proofreading, as well as the BULL company and the ANRT organization for their financial support.

# References

1. Visa corporate, 1958. http://corporate.visa.com/index.shtml.

2. Mastercard worldwide, 1966. http://www.mastercard.com/.

3. O. Aciïmez, W. Schindler, and Ç.K. Koç. Improving brumley and boneh timing attack on unprotected ssl implementations. In *Proceedings of the 12th ACM conference on Computer and communications security*, pages 139–146. ACM, 2005.

4. M Anderson. The electronic check architecture. *Financial Services Technology Consortium*, 1998.

5. G. Antoniou and L. Batten. E-commerce: protecting purchaser privacy to enforce trust. *Electronic commerce research*, 11(4):421–456, 2011.

6. M. Ashrafi and S. Ng. Enabling privacy-preserving e-payment processing. In *Database Systems for Advanced Applications*, pages 596–603. Springer, 2008.

7. G. Bella, F. Massacci, and L. Paulson. Verifying the SET purchase protocols. *Journal of Automated Reasoning*, 36(1):5–37, 2006.

8. G. Bella, F. Massacci, L. Paulson, and P. Tramontano. Formal verification of cardholder registration in SET. *Computer Security-ESORICS 2000*, pages 159–174, 2000.

9. G. Bella, L. Paulson, and F. Massacci. The verification of an industrial payment protocol: The set purchase phase. In *ACM CCS*, pages 12–20. ACM, 2002.

10. S. Brlek, S. Hamadou, and J. Mullins. A flaw in the electronic commerce protocol set. *Information Processing Letters*, 97(3):104–108, 2006.

11. M. Carbonell, J. Torres, A. Izquierdo, and D. Suarez. New e-payment scenarios in an extended version of the traditional model. *Computational Science and Its Applications-ICCSA 2008*, pages 514–525, 2008.

12. T.H. Chen, S.C. Yeh, K.C. Liao, and W.B. Lee. A practical and efficient electronic checkbook. *Journal of Organizational Computing and Electronic Commerce*, 19(4):285–293, 2009.

13. European Commission. Directive 2000/31/ec of the european parliament and of the council of 8 June 2000 on certain legal aspects of information society services, in particular electronic commerce, in the internal market ('directive on electronic commerce'), 2000.

14. European Commission. Directive 2007/64/ec of the european parliament and of the council of 13 November 2007 on payment services in the internal market amending directives 97/7/ec, 2002/65/ec, 2005/60/ec and 2006/48/ec and repealing directive 97/5/ec, 2007.

15. European Commission. *Communication from the Commission to the Council, the European Parliament, the European Economic and Social Committee and the Committee of the Regions*. 2010.

16. European Payments Council. Sepa - single euro payment area, 2007. http://www.sepafrance.fr/.
17. T. Dierks. Rfc 5246: The transport layer security (tls) protocol version 1.2, 2008.

18. S. Drimer, S. Murdoch, and R. Anderson. Optimised to fail: Card readers for online banking. *Financial Cryptography and Data Security (FC'09)*, pages 184–200, 2009.

19. PCI DSS. Payment card industry data security standard, 2006. https://www.pcisecuritystandards.org/.

20. Y. Espelid, L.H. Netland, A. Klingsheim, and K. Hole. A proof of concept attack against norwegian internet banking systems. *Financial Cryptography and Data Security (FC'08)*, pages 197–201, 2008.

21. A. Fioravanti and F. Massacci. How to model (and simplify) the set payment phase for automated verification. 2001.

22. A. Freier, P. Kocher, and P. Karlton. Rfc 6101: The secure sockets layer (ssl) protocol version 3.0, 2011.

23. M. Frenkiel. Cybercriminalit et crime organis, 2009. http://www.mag-securs.com/News/tabid/62/articleType/ArticleView/articleId/24583/Cybercriminalite-et-crime-organise.aspx.

24. E. Gabrilovich and A. Gontmakher. The homograph attack. *Communications of the ACM*, 45(2):128, 2002.

25. MasterCard International. Chip authentication program functional architecture, September, 2004.

26. S. Katsikas, J. Lopez, and G. Pernul. Trust, privacy and security in e-business: Requirements and solutions. *Advances in Informatics*, pages 548–558, 2005.

27. C. Meadows and P. Syverson. A formal specification of requirements for payment transactions in the SET protocol. In *Financial Cryptography and Data Security (FC'98)*, 1998.

28. S. Murdoch and R. Anderson. Verified by visa and mastercard securecode: or, how not to design authentication. *Financial Cryptography and Data Security*, pages 336–342, 2010.

29. V. Pasupathinathan, J. Pieprzyk, and H. Wang. Privacy enhanced electronic cheque system. In *E-Commerce Technology, 2005. CEC 2005. Seventh IEEE International Conference on*, pages 431–434. IEEE, 2005.

30. V. Pasupathinathan, J. Pieprzyk, H. Wang, and J.Y. Cho. Formal analysis of card-based payment systems in mobile devices. In *The 2006 Australasian workshops on Grid computing and e-research-Volume 54*, pages 213–220. Australian Computer Society, Inc., 2006.

31. Paypal. Privacy policy for paypal services, 2012.

32. S.E.T. Secure electronic transaction specification. Book 1: *Business Description*. *Version*, 1, 2002.

33. Visa. 3d secure protocol specification, core functions, July 16, 2002.

34. D. Wagner and B. Schneier. Analysis of the ssl 3.0 protocol. In *The Second USENIX Workshop on Electronic Commerce Proceedings*, pages 29–40, 1996.

35. Rui Wang, Shuo Chen, Xiao Feng Wang, and Shaz Qadeer. How to shop for free online security analysis of cashier-as-a-service based web stores. In *IEEE Symposium on Security and Privacy (S&P'11*, 2011.
# Annexes

## 3D-Secure protocol

<figure><img src="image_4.png" /><figcaption>Fig. 4. The 3D-Secure protocol.</figcaption></figure>

## Statistical study

In order to justify the importance of the privacy protection issues during an on-line payment, a statistical study was conducted on a sample of 354 individuals. In particular, for the question "Are you concerned by the issues of privacy protection on the Internet?", 87% of responses are positive and 69% of individuals have apprehensions during this transaction.
Perspectives

A proof of concept has been developed to demonstrate the feasibility of the proposed protocol. The Figures 5, 6, 7, 8, 9 and 10 provide an overview of the current implementation.

<figure><img src="image_5.png" /></figure>

**Fig. 5.** After the registration of the client with only the storage of one pseudonym and one password, the client logs in to the *SP*.

<figure><img src="image_6.png" /></figure>

**Fig. 6.** The client fills his/her basket.

<figure><img src="image_7.png" /></figure>

**Fig. 7.** The recap chart is processed.

<figure><img src="image_8.png" /></figure>

**Fig. 8.** The client chooses his/her delivery option and the contract is generated.

<figure><img src="image_9.png" /></figure>

**Fig. 9.** After the contract uploaded and the cheque has been generated, the cheque is transmitted to the *SP* bank through the *SP*.

<figure><img src="image_10.png" /></figure>

**Fig. 10.** The transaction is concluded and the bill is sent to the client.