In this section, a SET payment system based on the proposed framework is introduced to illustrate how our framework can overcome the constraints of wireless environments and solve the problems existing mobile payment frame- works [RdS98, WLY99, WSZ01].
We first divide the payment operations in SET protocol [Mas97] into two parts; one is operated at a client’s mobile device, and the other is brought with an agent travelling outside the client. At the client side, we minimize the computational load by performing low computational operations. With the agent travelling to the merchant’s server, we let it perform high computational tasks.
We deploy the concept of using two mobile agents from SET/A+: Infor- mation gathering and Negotiation Agent (INA) which travels to merchants’ sites to collect information and makes the decision on the suitable merchant, and Payment Agent (PA) which performs payment operations by carrying a part of the SET wallet with it.
In the proposed system, all engaging parties except the client are assumed to have powerful computing devices located in a fixed environment. Thus, we do not concern about the computational capability of these parties. The client is assumed to have a low computational capability mobile device which is able to access the Internet. The issuer has the client’s credit-card information, and it is assumed to have powerful computational capability, hence we can have a proxy server maintained by the issuer as the environment where PA performs high computational operations to generate a SET’s purchase request (PReq). Referred to the SET protocol descriptions presented in section 2.3.1, the main task of the client in SET protocol is to generatePReq. Generally,PReq
consists of order information (OI) and payment information (P I). OIis signed by the client’s private key K−1
C . P I is symmetric-encrypted with the session keyK2, and the key K2 is then encrypted with the payment gateway’s public keyKP G. Other computational tasks are operated outside the client. Thus, we divide the SET payment operations into two parts: one in the client’s mobile device signingOIand the other in PA encryptingP I. The proposed framework is diagrammatically shown in Figure 4.2. The details of the proposed system are given as follows.
Client INA PA Issuer Acquirer PG Merchant Merchant 0 - Requirement,
PinitReq 0 - Requirement, PinitReq 0 - PinitRes 0 - PinitRes 1.1 1.2 2 - PReq 3 - AuthReq 4 - AuthRes 5 - PRes 6 - PRes 4 - Money Transfer 4 - Deduction 4 - Deposit
Figure 4.2: The proposed SET payment system
1. Two agents operate in the system: INA and PA. They are generated and owned by a client. The client establishes the requirements regarding the goods to INA. INA then travels to merchants’ sites to search for such information. After INA returns to the client with relevant information including the merchant’s identity, the client runs an authenticated key exchange (AKE) protocol for wireless networks (will be discussed in sec- tion 4.4.9) to establish a secure communication channel between herself and the issuer. After the completion of the AKE protocol, both client and issuer possess a session key Kex.
In our system, the AKE protocol is used to provide the confidentiality of the content in PReqbecause it contains both the client’s public-key certificate and the price of the goods. If they are transmitted in cleartext, an attacker may be able to make the relationship between the client and the price. Then, the payment phase proceeds as follows.
2. As described above, the SET wallet operations are divided into 2 parts; one operates at the client side and the other operates at PA. After getting the key Kex, the SET wallet at the client side constructs a message con- taining necessary information for establishing PReq and then encrypts this message with the key Kex. This information is then passed to PA which then travels to the issuer.
2.1) C→PA(C): {P ReqGen,{IDI, h(P ReqGen)}KC−1}Kex
2.2) PA(C)→I: {P ReqGen,{IDI, h(P ReqGen)}KC−1}Kex
where,
• P ReqGen={OI,{h(OI), h(P I)}K1,{K1}K−1
C , IDM, P rice,
h(CCI), CertP G, CertC}, and
• P A(C) stands for the payment agent PA owned by the client. 3. The issuer decrypts the message with the keyKexshared with the client,
verifies the client’s signature, and compares the received h(CCI) with the one it has. If they are matched, the issuer issues the pre-image of h(CCI) to PA. The SET wallet at PA then performs the following tasks: (i) Generate the session key K2 (for encrypting P I).
(ii) Reconstruct P I by collecting {T ID, h(OD, P rice), IDM, CCI}. (iii) Decrypt {h(OI), h(P I)}K1 to retrieve h(OI), and compare with
the hash value of the receivedOI. If they are matched, the received OI is a valid OI.
(iv) Encrypt {h(OI), P I}with the key K2. (v) Encrypt the key K2 with KP G.
(vi) Collect relevant information to construct the SET’s PReq.
4. The merchant verifies the client’s signature, retrievesOI, and then sends
AuthReq to the payment gateway.
5. The payment gateway verifies the merchant’s and the client’s signatures and then retrievesP I. After receiving the payment information, the pay- ment gateway consults the issuer and the acquirer for payment approval. After getting the approval, the payment gateway sends the merchant
AuthRes.
6. The merchant verifies the payment gateway’s signature and then sends
PRes back to PA.
7. PA verifies the merchant’s signature and then returns to the client with the result of her request.