Secure e-Payment Protocol with New Involved Entities

Secure E-Payment Protocol with New Involved Entities Mildrey Carbonell, Joaquín Torres, Diego Suárez, José M. Sierra Carlos III University of Madrid. Spain {mcarbone, jtmarque, sierra, dsuarez}@ inf.uc3m.es Jesús Téllez University of Carabobo. Venezuela [email protected]

ABSTRACT

1. INTRODUCTION

Most of the secure electronic payment solutions that have been proposed in the last years are focused on the traditional payment model: one customer buys goods/services to one merchant, and a payment etransaction is performed via a processor and banking institutions. However, nowadays, more versatile ecommerce scenarios could be considered with different constraints but with interesting challenges and advantages. On one hand, new customers habits and new connectivity solutions and technologies such as hotspots in public wireless LANs, enough band-width in 3G cellular networks, powerful smart-phones, embedded browsers, etc. are adapting the current market offers. On the other hand, new intermediate entities aim to participate in the purchase transaction by providing value-added and customized services to the different parties, with the corresponding benefits. An important assumption for our proposal is that this intermediary is an a priori untrustworthy entity for the customer. In this paper, we describe a new e-payment model with an intermediary that links one customer with multiple merchants. Additionally, this model considers merchants and intermediaries with Internet connectivity constraints; therefore our solution is based on a client-centric approach, i.e. only the client equipment has the capability of online communicating with the banking networks by means of a payment service provider. For that reason, our solution is focused on the protection of the end-to-end e-payment transactions that are transmitted through a powerful client handheld device.

From the appearance of electronic and m-commerce, a significant work that has aimed to find a standard model of e-payment has been done. This model usually describes the main involved entities and the flow of transactions between them. Secure protocols such as SET [8] or iKP [11] and standardized specifications such as 3D-Secure standard [3] have attempted to specify these circumstances in a global way. All of them consider a classical e-payment model with the interaction of five basic entities. In the business domain, a customer in the client side (C) and a virtual merchant (M). In the banking domain, the issuer bank (I) and the acquirer bank (A). And finally, a payment system provider (PSP) that links those, as a secure entity which transports e-payment transactions on behalf of banks towards the Internet side and on behalf of clients and merchants towards the banking network side. In addition, these known model determine the possible interactions among such entities. For instance, an electronic transaction by which C places an order to purchase goods/services to M (usually known as payment ordering), or the transaction to request the corresponding payment authorizations to the banks. Despite the fact of being widely used, this classical model presents some limitations when attempting to integrate new habits and emerging trends in the current e-payment systems. How should be this model adapted to integrate an intermediary with customized payment services?. Moreover, and with multiple merchants?. Is this model enough flexible and robust if certain entities have not direct access to Internet (disconnected scenario)?. Does this model envisage a communication solution when the client handheld device is the unique access point to proceed with the payment through Internet (client-centric approach)?.

KEYWORDS: e-payment, e-commerce, intermediary, mobile commerce, e-transactions.

978-1-4244-2249-4/08/$25.00 ©2008 IEEE

103

Authorized licensed use limited to: Univ Carlos III. Downloaded on April 14,2010 at 11:38:38 UTC from IEEE Xplore. Restrictions apply.

In this paper, we describe a new e-payment model, which considers all these circumstances. The intermediary entity IN links one customer to multiple merchants, and she unifies the multiples payment transactions. Additionally in our model, the client application running in the customer’s device provides the access point to Internet and, therefore, the connection with the payment service provider PSP. All the transactions between merchants and PSP have to be transported through an untrustworthy intermediary IN. As consequence, a robust end-to-end secure protocol is proposed in this work.

simulators, conducting online auctions or protecting transactions. In the payment process, the intermediary is usually considered as an entity, which concretely guarantees the security and correctness of payment transaction by means of different strategies: secure payment gateways (e.g. Paypal or Authorized.net) or trusted third parties (TTP). However, an intermediary involved in the payment process should be capable of decreasing the number of customer operations [21], managing a purchase with multiple merchants (M+) simplifying the amount of transactions [20], or providing a framework to centralizes the connection with the PSP [4], among other functionalities.

The remainder of paper is organized as follows. In section 2, we present the related work. In section 3, we define a new e-payment model and the corresponding flow of transactions. Afterwards, in section 4, a secure e-payment protocol based on the previous model is proposed. Finally, a security analysis of this protocol is detailed in section 5.

Consequently, given the benefits that an intermediary provides during the payment transaction, she should be considered as a new entity in the e-payment model. This fact modifies the traditional steps and flows of the transaction between the involved entities and it could derive in several different scenarios [6].

2. RELATED WORK Early in research on electronic markets seemed to suggest that e-commerce transactions would decrease traditional costs for buyers and sellers alike, and would ultimately lead to the elimination of complex intermediaries, by reducing this entity to a digital shop (e-shop) like a mediator between virtual and real worlds [15]. However, a careful analysis of the structure and functions of electronic marketplaces reveals a different picture. The intermediary have appeared by providing many value-added functions that cannot be easily substituted or ‘internalized’ through direct supplier-buyer dealings, and hence she may continue to play a significant role in the e-commerce world, by mediating parties [9].

Regarding protocols designed for payment systems with handheld devices are commonly based on a scenario where all entities are directly interconnected to another one. This full-connectivity model offers advantages to protocol designers because it allows them to simplify the design and development of payment protocols without losing security guarantees. Nevertheless, this scenario is not versatile and it does not consider situations in which one of the engaging entities (e.g. merchants) can not directly communicate with another one (e.g. PSP), due to the impossibility of one of them to connect to Internet, caused by any permanent or temporal constraints. In addition, the full-connectivity model does not consider the high cost and disadvantages of using alternative infrastructures [1] to solve a potential disconnected situation, such as: SMS, phone call, etc. Considering previous works [5], these models can be classified, depending on connectivity conditions, as:

The integration of the intermediary within electronic commerce was initially described as an application to facilitate the connection between clients and merchants [3] [14] in numerous classical business models such as portals, virtual malls and marketplaces or even in more complex models such as auctions (Ebay ), stop shops (BuySell) , offer-demand, etc.. In [16], the Infomediary is presented as intermediary that participates as an electronic third party that assists customers and/or merchants in understanding a given market. The deployment of intermediaries between wired and wireless networks (known as brokers [7]) has been very common as well. In this case, she offers some basic connectivity services, or even middleware services to facilitate the interaction between different communication interfaces (Web, UMTS, infrared, etc.). And finally, in the agent-mediated commerce [10, 12,13] the intermediary is represented as agents, which have been used for searching, products comparison, price adjustments, decision making, calculating market strategies, optimizing orders, running

• • • • •

Disconnected: C and M are disconnected from the PSP and they directly communicate with each other by a local link. Server-Centric: The PSP is connected to both C and M but they are not directly connected with each other. Client-Centric [17]: C is connected to both M and the PSP but they are not directly connected with each other. Kiosk-Centric [18]: M is connected to both C and the PSP but they are not directly connected with each other. Full-Connectivity: All the entities are directly connected to another one.

104


Constrained connectivity is one of the more important issues which will determine the design of future security solutions for electronic payment, especially in the mobile context. This concept implies new secure protocols and more robust and flexible protection mechanisms compared to the traditional payment transactions.

corresponding flow of messages to the previous model with the aforementioned constraints is represented in Figure 2. Thus the payment process occurs in the following way: Payment Order, PO. The client application sends the payment order (PO) to IN. In this case, this payment order should be compounded by a number i of payment orders POi , which are addressed to the corresponding merchants Mi∈M’, such that M’ is the sub-set of chosen merchants by the customer for a concrete multi-purchase.

In the following sections, we present our proposal to deal with these defiant issues.

3. CLIENT-CENTRIC APROACH WITH MULTIPLE MERCHANTS AND INTERMEDIARY

Multi-Payment Orders, POi, distribution. Once the intermediary IN receives the payment order PO, she establishes the POi orders and distributes them to the corresponding Mi merchants.

3.1. E-Payment Model and Flow of Messages In the proposed e-payment model illustrated in Figure 1, the participating entities are: a customer in the client side(C), an intermediary (IN) that collaborates in the multiple payments transaction, a number of merchants (Mi for i = 1..n where n is number of merchants) and a payment services provider (PSP), which actually provides them with communications to the banking domain (issuer and acquirer banks). Multiple merchants offer their products/services to the customer through the intermediary, which additionally acts as mediator between those entities by facilitating the multi-payment process. Hence, the customer C delegates to an authoritative IN, which proceed with the distribution of payment messages to Mi and she is in charge of compounding the merchants' responses as a unique message to C. As is shown in Figure 1, our model considers that merchants, Mi, and IN have not direct connection to PSP. Thus, all the payments authorization information should be transmitted to the payment processor through the client application (clientcentric payment). Finally, another constraint should be taken into account to study our model: from the customer's point of view, all the involved entities except for PSP are untrustworthy.

Multiple Authorizations Request, ARi. Once each merchant receives the payment order POi, they must send to PSP their authorization request ARi. Since merchants have not connectivity to the PSP, they have to do the process through the IN and C entities. Unified Authorization Request, AR. The intermediary IN receives the multiple authorizations request ARi from the involved merchants Mi and builds an unified authorization request AR , which is sent to C with the goal to reach the PSP. Authorization Request, AR, forwarding. C is the only one entity which is able to connect to PSP. Thus, client application is in charge of forwarding the received unified authorization request AR towards the PSP. Unified Authorization Response, ARs. The PSP triggers the adequate mechanisms with the goal to authenticate the customer and merchants, as well as to obtain the corresponding authorization response from the banks side (out of the scope of this work). As result, PSP sends to C an unified authorization response ARs, which actually is built by a number i of authorization responses ARsi. Authorization Response, ARs, forwarding. Since the merchants Mi will be the recipients of such authorization responses. The client application C forwards the received ARs to the intermediary IN. Multiple Authorization Responses, ARsi, distribution. Once the intermediary IN receives the authorization response, ARs, she establishes the multiple ARsi authorizations and distributes them to the corresponding Mi merchants.

Figure 1. Client-Centric Payment with Multiple Merchants and Intermediary

Finally, if the authorization is confirmed, the payment process is ended and other business phases should occur (funds transfer, shipment and delivering, etc.).

Similarly to other e-commerce scenarios, the client application starts the payment process after customer checks out the items in the shopping cart. The

105


PSP

C

M+

IN 1. Payment order (PO)

•

A mechanism to guarantee the security of the message (such as authenticity, integrity and confidentiality), when going through one or many untrustworthy entities in our client-centric model.

•

A secure mechanism to exchange and validate key material without online connectivity (e.g. a public key in absence of a PK infrastructure or a protected symmetric key agreement).

2. Dist. of POi

Divides PO in POi

3. Auth. request ARi Waits for all ARi Create a single AR

5. Fwd. AR

4. PROTOCOL FOR SECURE MULTIPLE EPAYMENT TRANSACTIONS

4. Auth. request AR

Client verification

6. Auth. response ARs

In this section, we describe a protocol for secure epayment transactions based on the model and flow of messages presented in this work. Before to proceed with the protocol description some initial assumptions are stated. With this goal, the following terminology is used.

7. Fwd ARs Divides ARs in ARsi

• • • •

8. Dist. of ARsi

Figure 2. Flow of Message in the Payment Process.

3.2. Requirements

4.1. Initial assumptions

Payment phase probably requires the higher level of security within electronic commerce transactions. Hence, a robust solution is needed to guarantee the confidentiality, authenticity, integrity and non-repudiation of the transactions. Nevertheless, specific requirements are considered in our model, since multiple and untrustworthy entities are involved.

The initial assumptions for our proposed protocol can be stated as follows: Cryptographic mechanism: We use a cryptographic technique of digital signature with message recovery using a self-certified public key, KpX, proposed in [19][22]. An entity X uses this mechanism to sign the message W, SX(W), and unequivocally to sign-encrypt the message W for a concrete entity Y, EX-Y(W). The main motivation for using this mechanism is due to the possibility to authenticate the signer entity X during the signature verification process without additional information and, moreover, because only the specified recipient (verifier) can securely recover the message by means of this mechanism. In order to generate both SX(W) and EX-Y(W), the identifiers belonging to the appropriate entities (i.e IDX and IDY) are used as public keys. As consequence, a large public-key file is avoided. Obviously, this mechanism requires a trusted authority.

An intermediary as a non-trusted entity requires: •

A secure mechanism by which client delegates to an intermediary IN as unique authoritative entity, which may distribute the authorization requests and the next authorization responses to each involved merchant. This delegation mechanism should be protected against possible modifications.

•

A robust mechanism to build an evidence of intermediary participation both in the multipayment orders, POi, distribution and in the authorization responses, ARsi, distribution to each involved merchant. Theses evidences require a mechanism to validate them in case of subsequent disputes.

•

IDx – unique identifier of entity X KpX –public key of entity X SX(W) – digital signature of message W by entity X EX-Y(W) –signature and encryption of message W by the sender X for a specific recipient Y (see details below)

Trusted Authority: She represents an trusted entity that previously and out-of-band generates the appropriate public keys, KpX. It is not required that such an authority is online during the public key validation procedure. This circumstance is a clear advantage, given the disconnection issue that characterizes our model. Thus, authority generates the public key for all involved entities, i.e. C, IN, M+ and PSP.

A mechanism for transporting the client authentication token through IN, as well as, to protect the integrity of the content of purchase messages which are send by client.

The disconnection issue requires:

106


After the identification phase, the payment protocol takes place as follows:

Previous merchants Mi identification phase: Before the protocol starts, the involved merchants are identified by IN. In this phase, they send their unequivocal identifier, IDMi, to IN which is protected by the mentioned digital signature mechanism on a random number (rnd). Note that this signature mechanism uses the IDMi as part of the signature key. MiIN

Payment order PO: 1. C IN IDC, EC-IN(AuthTokenIN , M’, PID, PO, Tp) POi distribution process: 2. IN Mi IDIN, KpIN, EIN-Mi(IDPSP, KpPSP, IDC, KpC, Td, AuthTokenIN, PID, POi )

IDMi, rnd, SMi(rnd)

4.2. Protocol Description

Authorization request (from Mi to PSP): 3. Mi IN IDMi, EMi-IN(PID, ARi), such that ARi=EMi-PSP(PID, IDC, Tp, POi.PA)

Once the initial assumptions have been described, we present a security solution for an e-payment transaction in our model: Client-Centric payment with multiple merchants and an intermediary. The following notation is used in the protocol description: • • • • • •

• •

PID - unique identifier of the purchases POi - payment order that is compounded by a list of products and the payment amount POi.PA. The merchant Mi is the recipient. PO - total payment order formed by number i of POi and the total purchase amount PO.PA = Σ POi.PA Td - starting timestamp of distribution process. Tp - starting timestamp of purchase process. Tl - valid time during which IN is authorized by C to proceed with a concrete multiple e-payment. This time represents the available interval [not before, not after] by IN for distributing the payment messages. AuthTokenIN=SC(IDIN, KpIN, PDI, M’, (Mi, H(POi) for each Mi∈M’, Tp, Tl) – token that represents a temporal (Tl) delegation from C to an authoritative intermediary IN. InfoP - Payment information that C sends to PSP in order to obtain the authorization. InfoP is built among others by identifier IDC, as well customer information such as credit/debit card number, expiration date, customer profile, etc.

4. IN C

EIN-C(IDPSP, PID, M’, ARIN) such that ARIN=EIN-PSP(Mi,ARi) for MiЄM’

5.C PSP

EC-PSP(InfoP, M’, IDIN, PID, H(PO), Tp, ((Mi, POi.PA)...), ARIN), AuthTokenIN for MiЄM’

Authorization response (from PSP to Mi): 6. PSP C EPSP-C(status, PID, Tp, PO.PA,ARsIN) such that ARsIN= EPSP-IN(Mi, ARsi…) and ARsi= EPSP-Mi(Status, PDI, Tc, POi.PA) 7. C IN

EC-IN(ARsIN)

ARsi distribution process: 8. IN Mi EIN-Mi(ARsi) In the following paragraphs, a detailed description of the protocol based on our model for secure e-payment transactions is provided. Step 1: C starts the payment order process by generating AuthTokenIN as authorization token for IN. Afterwards, IN is the authoritative entity for distributing the payment information in both directions (that means, the payment orders POi, and the authorization responses ARsi associated to each involved merchant Mi). This authorization token is signed by C and all the final recipient entities could check it. However, C encrypts the AuthTokenIN,, the unique identifier of purchase, PID, the global payment order, PO, and the purchase starting time, Tp, before to send it, with the goal to be only recovered by IN.

Our secure solution starts with an initial phase of identification: Intermediary identification: IN C IDC, IDIN, KpIN , SIN(H(IDC, IDIN, KpIN)) IN sends to C the identifier IDIN and an authentication proof by signing it, along with other public information: IDC, KpIN . Client identification and PSP identification: C IN IDC, IDPSP, KpC, KpPSP, SC(H(IDPSP,KpPSP), SPSP(H(IDC, KpC)

Step 2: IN retrieves the payment orders POi contained in PO and begins the distribution process towards the Mi merchants. This protected message includes cryptographic information of the PSP (IDPSP, KpPSP) and the starting timestamp of distribution process, Td. The participating customer is authenticated by the token AuthTokenIN. The merchants Mi must check the received POi, the identifier

The client application C sends the identifier IDC , the public key KpC, the PSP identifier IDPSP (which one C has connectivity with), and the PSP public key KpPSP. These identifiers and public keys are authenticated by the corresponding client's and PSP's signatures.

107


transaction, therefore merchants have the responsibility to proceed with the next business phases, in order to deliver the products/services.

PID, the authorized IN (IDIN), and the valid time Tl.before