Evaluación del impacto de las actuaciones

In an account-based payment system, money is represented by account (or credit) balance in bank accounts and it is transferred among engaging par- ties’ accounts established with their banks. Generally, account-based payment systems can be divided into two categories depending on payment clearing periods: credit-based and debit-based payment systems.

In a credit-based payment system, a client has credits authorized by her issuer to spend with merchants without being charged any cent from her ac- count during purchases. The credits can be more than the current balance of the client’s account depending on the account standing. To make a pay- ment to a merchant, the client is required to have payment authorization from the issuer, and she is billed periodically e.g. monthly. The examples of this kind of payment systems are a credit-card payment scheme over SSL protocol [FKK96], the payment systems based on SET (Secure Electronic Transaction) protocol [Mas97] and iKP (Internet Key Protocol) [BGH+_{00], VISA’s 3D Se-} cure [VIS02], Shamir’s web-based payment system using disposable credit-card numbers [Sha02], Muet al.’s system [MV02], Huming et al.’s payment system based on bank accounts [GCW01], and various kinds of electronic check pay- ment systems [DK01, And98].

According to a debit-based payment system, a client is allowed to spend the money up to her current balance. The examples of debit-based payment systems are Visa Electron [VIS04] and EFTPOS [Com04, Rea89].

It can be noted that the client in both credit and debit-based payment systems is required to have payment authorization from her issuer in every transaction. This may incur high administrative cost, which is not suitable for low-valued transactions.

It can also be noted that the difference between credit-based and debit- based payment systems is only billing periods. Thus, an account-based pay- ment system can operate both kinds of payment transactions by specifying the period when the money is deducted from the client’s account. In partic- ular, one account-based payment system can operate in two modes. That is, to work as a credit-based payment system, the client is billed after specified period and she has to pay for the transactions by the due date, whereas to work as a debit-based payment system, the money in the client’s account is deducted immediately after the payment authorization for each transaction has been approved.

In any payment system, the payment protocol plays the most important role. In this thesis, we focus our consideration on the payment protocols and their applicability to wireless environments. In this section, we present SET [Mas97] and iKP [BGH+_{00] protocols as examples of account-based payment} protocols.

SET and iKP Protocols

SET protocol and its ancestor, iKP protocol, are the most well-known credit- card payment protocols. Three main parties are involved in both protocols: client, merchant, and payment gateway. They interact with one another over the Internet side. The client presents her credit card while purchasing goods or services from the merchant. The merchant is a party authorized by the payment gateway to be a merchant in the payment system. In SET and iKP protocols, the payment gateway can be a credit-card company or the client’s issuer who offers its own credit-card service. Based on the payment model

presented in section 2.2, the actual fund transfer is performed between the issuer and the acquirer over a banking private network.

Both SET and iKP protocols are credit-based in that the client is allowed to perform payment transactions up to credit limit specified by the issuer without paying any cents during the purchases. The client will be billed at the end of specified period. However, the client is required to have payment authorization from the issuer before making each payment. The purpose of the payment authorization is to check credit availability of the client. If the client has sufficient credits, her payment request will be approved.

As the ancestor of SET protocol, most of the structures of iKP protocol are similar to that of SET protocol. In SET protocol, all parties are required to possess their own public-key certificates, whereas iKP protocol consists of three versions depending on the number of certificates possessed by engaging parties: 1KP, 2KP, and 3KP. In 1KP, only the payment gateway is required to have its own certificate. Both the client and the merchant can authenti- cate themselves to the payment gateway and each other using PINs (Private Identification Numbers). In 2KP, only the client is not required to possess the certificate. Finally, 3KP protocol requires all engaging parties to possess their own certificates. The protocol descriptions of SET protocol are given as follows:

PinitReq: C→M: InitialRequest

PinitRes: M→C: {T ID}_K−1

A , CertM, CertP G

PReq: C→M: OI,h(PI),{h(OI), h(P I)}K1,{K1}K_C−1, {h(OI), P I}K2,{K2}KP G, CertC

AuthReq: M→PG: {{T ID, P rice, Date, h(OI),(OI),{h(OI), h(P I)}K1, {K1}_K−1

C ,{h(OI), P I}K2,{K2}KP G}KM−1}KP G

AuthRes: PG→M: {{T ID, P rice, Date, Y es/No}_K−1

P G}KM

PRes: M→C: {T ID, Date, Y es/No}_K−1

where,

• {C, M, P G, I, A}: the set of client, merchant, payment gateway, issuer, and acquirer, respectively.

• OI: order information. OI ={T ID, h(OD, P rice)}

• P I: payment information which contains credit-card information (CCI). P I ={T ID, h(OD, P rice), IDM, P rice, CCI}

• OD: order descriptions which contain goods descriptions. • P rice: amount and currency.

• T ID: identity of transaction which contains the time and date of trans- action Date.

• Y es/No: status of the transaction approved/rejected. • {K1, K2}: the set of session keys generated by the client.

In this thesis, we focus on 3KP protocol because it provides the highest security in its family. The descriptions of 3KP protocol are demonstrated as follows.

Initiate: C→M: IDC

Invoice: M→C: IDM, h(OI), Date

Payment: C→M: P I,{P I, h(OI)}_K−1

C

AuthReq: M→PG: IDM, h(OI), Date, h(OD), P I,{h(OI)}K−1

M ,

{P I, h(OI)}_K−1

C

AuthRes: PG→M: AI,{AI, h(OI)}_K−1

P G

Confirm: M→C: AI,{h(OI)}_K−1

M ,{AI, h(OI)}K

−1

P G

• P I ={P rice, h(OI), CCI}KP G

• OI ={T ID, P rice, IDC, IDM, Date, h(OD)}

• AI: authorization information which contains Y es/No.

From the SET and iKP protocol descriptions, in PinitReq (or Initiate) and PinitRes (or Invoice), the client and the merchant exchange the infor- mation to start a payment session. In PReq(or Payment), the client starts making a payment to the merchant. The content inPReq(orPayment) con- sists of two parts for two purposes; one signed with the client’s private keyK−1 C is considered as Payment Request (referred to the payment model described in section 2.2) to purchase goods or services from the merchant, and the other encrypted with the payment gateway’s public keyKP G is considered asValue-

Subtraction Request which is a request to the payment gateway to deduct the requested amount from the client’s account. Note that, in SET protocol, the latter part is not directly encrypted withKP G. It is first symmetric-encrypted with the session key K2 generated by the client, and then the key K2 is en- crypted withKP G.

After receiving PReq(or Payment), the merchant retrievesOI and then the goods descriptions (OD) and the requested amount (P rice) in OI. The merchant sendsAuthReqwhich is a request to the payment gateway to trans- fer the requested amount to the merchant’s account. AuthReq is signed and encrypted with the merchant’s private key K−1

M and the payment gateway’s public key KP G, respectively. Note that AuthReq contains not only Value-

Claim Request which is a request from the merchant to the payment gateway to transfer the requested amount to the merchant’s account, but also the for- warded client’s Value-Subtraction Request.

The payment gateway decrypts AuthReq, verifies the merchant’s signa- ture, and retrieves P I which contains the client’s credit-card information. It consults the issuer and the acquirer about the validity and credit availability of

the client’s account. After the requested payment has been approved, the pay- ment gateway sends AuthRes which represents the commitments to deduct the requested amount from the client’s account (Value-Subtraction Response) and to transfer the money to the merchant’s account (Value-Claim Response), respectively, to the merchant. AuthRes contains T ID, price, and status of transactionapproved/rejected.

The merchant decrypts the message and retrieves the result of her request. The merchant then sends PRes (or Confirm) which is a receipt of the pay- ment and the commitment to deliver goods or services to the client. The client then verifies the merchant’s signature and retrieves the result of her request.

Note that the analyses done by Herreweghen [Her01] and Kungpisdan et al. [KP02] have shown that SET protocol does not guarantee the client about the money deduction. That is, the message sent to the client inPRescontains no evidence from the issuer to confirm that the requested amount has been deducted from the client’s account, whereas in iKP protocol,Confirmcontains a part of the message signed with the payment gateway’s private key K−1

P G. It can be considered as a commitment from the payment gateway (on behalf of the issuer) to deduct the requested amount from the client’s account.

SET and iKP protocols offer secure payment transactions. They satisfy all transaction security properties mentioned in section 1.4. However, they are not suitable for wireless environments due to a number of limitations which have been discussed in section 1.3. In particular, they are complex protocols which are based public-key infrastructure (PKI). In order to achieve sufficient security, all engaging parties are required to possess public-key certificates. In wireless environments, the implementation of PKI requires high capability mo- bile devices. In the case of wireless networks, in addition to higher operational cost compared to the fixed ones, the wireless networks also have limitations on lower bandwidth and reliability.