A Secure Agent-Mediated Payment Protocol Xiaolin Pang, Kian–Lee Tan, Yan Wang, and Jian Ren Department of Computer Science National University of Singapore 3 Science Drive 2, Singapore 117543 Republic of Singapore _TERK\MESXEROP][ERKVIRNMERa$GSQTRYWIHYWK

Abstract. While software agents have been employed in payment protocols, they are largely passive entities, i.e., they participate in the payment protocol but do not make decision. In this paper, we propose an agent-assisted payment protocol called LITESET/A+ that empowers the payment agent (PA) to perform encryption operation for its owner. This is realized by introducing a Trusted Third Party (TTP) in the payment system based on the SET protocol (Secure Electronic Transaction) and a novel signcryption-threshold scheme. In LITESET/A+, the PA and TTP collaborate together to ensure the same level of security as the SET specification. At the same time, with the signcryptionthreshold scheme, the PA is more flexible and autonomous during trading.

1

Introduction

Although the Internet is now becoming an important environment for e-commerce, the public is still wary of buying goods and also paying for them on-line. For example, there is concern that credit card information, when submitted on-line, may be eavesdropped despite the fact that very few of those attacks have actually succeeded. Even the deployment of secure servers, based on protocols such as SSL [1] or SHTTP [2], is not considered to be secure enough to protect the credit card information since it is deposited on the sever, where it can potentially be read by anyone who have access to the server. To protect the user’s credit card information over open network like the Internet, the SET (Secure Electronic Transaction) protocol [3] has been developed mainly by credit card industry such as VISA and MasterCard, in association with major software and cryptography companies. SET provides many important secure properties – such as authentication of participants, confidentiality of information, integrity of data and non-repudiation, etc. In the payment system, each participant can only obtain the information that is necessary for it to perform its own function. For example, the merchant never gets the buyer’s credit card information, and the financial institution authorizing the transaction never knows the details of the purchase like the nature of the products, quantities, etc. Nevertheless, SET is a complex protocol and may be unsuitable under some technical conditions. Several extensions of the SET protocol have been proposed. The SET/A [4] protocol dispatches an agent to the merchant server so that all operations can be performed R. Deng et al. (Eds.): ICICS 2002, LNCS 2513, pp. 422–433, 2002. © Springer-Verlag Berlin Heidelberg 2002

A Secure Agent-Mediated Payment Protocol

423

there. In this way, the user no longer needs to connect to the Internet when the transaction is running. The SET/A+[5] protocol removes the requirement of SET/A for a secure agent execution environment by adding a Trust Verification Center (TVC) in the payment system. TVC keeps the sensitive information and provides verification services for cardholder and merchants. But the payment agent of SET/A+ is not authorized to certain functions, e.g., to ensure that some operations are performed in a non-repudiable way or to encrypt certain important information. To improve the flexibility of mobile agents and the efficiency of SET/A+ protocol, a LITESET/A+ protocol based on LITESET system (Light-Weight Secure Electronic Transaction) is proposed in this paper. By using a new cryptography technique –signcryption [6], LITESET protocol reduces the heavy computation and message overhead in the employment of SET, the implementation of which is based on traditional RSA signature and encryption scheme [7]. In LITESET/A+ protocol, we introduce a Trusted Third Party (TTP) and a newly proposed signcryption-threshold scheme. TTP and payment agent collaborate together to protect the sensitive information such as credit card information and the signature private key carried by the agent during the whole payment process. The rest of this paper is organized as follows. Section 2 reviews related work. Section 3 describes a proposed signcryption-threshold scheme, and Section 4 presents the LITESET/A+ payment protocol. Security issues are discussed in section 5. Finally, Section 6 concludes this work.

2

Related Work and Background

2.1

Related Work of Payment Protocol

2.1.1 SET Protocol There are five participants in SET protocol: cardholder, issuer, merchant, acquirer and payment gateway. Each participant possesses two distinct asymmetric key pairs. One is used for performing encryption and decryption function and its public key is authenticated by key- exchange certificate ( C K ). The other is used for generation and verification of signatures and its public key is authenticated by signature certificate ( C S ). Since the phase on purchase request is the core of the whole transactions, only this phase is emphasized and described in detail in this work (see Fig. 1). 2.1.2 LITESET Protocol Although SET is treated publicly as one of the important protocols for electronic payments, a straightforward implementation incur significant computation and message overhead, primarily because it uses traditional techniques such as RSA digital signature and encryption scheme [7]. LITESET [6], a lightweight secure electronic transaction protocol, improves the efficiency by using signcryption– a new cryptographic scheme. For the same level of security as the SET specification, LITESET shows a 53.7% reduction in the computational time in message generation/verification and a 79.9% reduction in communication overhead [6].

424

Xiaolin Pang et al.

C

M C: Cardholder M: Merchant PG: Payment Gateway

Purchase Request

C S ( M ), C K ( PG ) P

C S (C ), OI , E PG {K , PI }

E PG {K , PI } Authorization

Response, C S (M ) Fig. 1. SET purchase request transaction

2.1.3 SET/A Protocol Since SET is very complex and may not be suitable under some technical conditions, SET/A protocol [4] is proposed to make SET adaptable to the mobile computing environments. Based on the principles used in purchase phase of SET, SET/A improve its performance only by adding a mobile agent for the cardholder to fulfill payment transaction. Also it is a practical technique since the cardholder need not frequently connect to Internet during the whole transaction phase. SET/A performs the same function of transaction as that in SET except that mobile agent of SET/A replaces the cardholder of SET in the purchase phase. However, SET/A protocol also has its drawbacks: it has to rely on a secure execution environment or hidden computation on the merchant server since all the critical data carried by agent are deposited on it. 2.1.4 SET/A+ Protocol SET/A+ protocol [5] removes the security requirement of agent’s running environment on merchant server by adding a Trust Verification Center (TVC) in the payment system. The TVC keeps the sensitive information and charges cardholders or merchants by providing verification service. However, the agents are limited in their functionalities. For example, an agent cannot sign and perform encryption for the owner during trading (since it requires the secret key of the owner).

3

Signcryption-Threshold Scheme

In this paper, a signcryption-threshold scheme is proposed, which is based on the special case of shamir-threshold scheme (t=w) that protects the secret K by distributing w secret shares from the secret to t users. We also extend the scheme to work with signature-only mode of signcryption scheme, namely signature-threshold scheme. 1. In the scheme, there are three public parameters ( p, q, g ) , two public hash functions (hash, KH) and one pair of encryption/decryption algorithms (E, D).

A Secure Agent-Mediated Payment Protocol

425

The notations of the above parameters are: p- a large prime q- a large prime factor of p-1 g- an integer chosen randomly from [1,…,p-1] with order q modulo p hash- a one-way hash function whose output has ,say, at least 128 bits KH - a keyed one-way hash function, which is for secure message authentication. (E, D)- the encryption and decryption algorithms of a private key cipher 2. Each entity in the payment system owns a key pair. For example, entity A has a key pair ( y a , x a ) , where y a = g a (mod p ) and the private key xa is chosen uniformly at random from [1,…,q-1] . 3. To protect one entity’s private key, we assume several parties share it using the special case of shamir-theshold scheme (t=w). For example, to protect entity A’s signature private key xa , t parties ( A1 , A2 ,..., At ) will share the private key and have x

secret shares xa1 , xa2 ,..., xat respectively, where xa = xa1 + xa2 + .... + xat (mod p ) . 4. We are ready to describe the signcryption-threshold scheme: In the scheme, there are several participants: sender A, recipient B and t sharingparties ( A1 , A2 ,..., At ) to share the secret for A. Sender A :

Private key - xa Public key - y a , ( y a = g

Sharing-Parties:

xa

mod p )

The private key xa is shared by t parties ( A1 , A2 ,..., At ), each of which has the secret share xa1 , xa2 ,..., xat respectively and

x a = x a1 + x a2 + .... + x at (mod p) Recipient B:

.

Private key - xb

Public key - yb , ( yb = g b mod p ) Two modes of the scheme (i.e. signcryption-threshold scheme and signaturethreshold scheme) are described in detail below: (1) Signcryption-threshold on a message m (Sender: A1 , A2 ,..., At , Recipient: B) x

a) Signcrypting m by sharing-parties ( A1 , A2 ,..., At ):

(k1 , k 2 ) = hash( yb mod p) x

(1)

c = E k1 ( m)

(2)

r = KH k2 (m)

(3)

si = x /(r + xai ) mod q

(4) x

Where equation (1) uses a hash function- hash( yb mod p ) and splits the result into k1 and k 2 of appropriate length. The key k1 is used to encrypt message m by equation (2) and a key hash function - KH k2 (m) - performs hash

426

Xiaolin Pang et al.

function on message m using key k 2 by equation (3). From the results of (2) and (3), each party computes si = x /(r + xai ) mod q , where 1 ≤ i ≤ t , and generates a part of signature respectively. In above equations, x is a random number chosen from [1,…,q-1] , but its value keeps the same for each sharing- party. The difference of signcryption operation among each party is the last equation (4) used to produce signature si because the secret share xai may be different to each party. After the signcrypted text (c, r, si ) is generated, it is sent to B by each party. b) Unsigncryption of (c, r, si ) by B involves the followings: t

(k1 , k 2 ) = hash(( y a ⋅ g ) nr

( ∑ si −1 ) −1 ⋅ xb i =1

mod p )

m = Dk1 (c)

(5) (6)

?

KH k2 (m) = r

(7)

Where equation (5) performs the public hash functiont

( ∑ si −1 ) −1 ⋅ xb

hash(( y a ⋅ g ) mod p ) to recover (k1 , k 2 ) from input signature parts (c, r, si ) sent by each sharing-party. Then B decrypts c using key k1 to get message m by equation (6) and verifies it by checking if KH k2 (m) = r . nr

i =1

(2) Signature-threshold on a message m (Sender: A1 , A2 ,..., At , Recipient: B) a) Signature part (r, si ) on a message m generated by sharing-parties ( A1 , A2 ,..., At ):

r = hash( g x mod p, m)

(8) (9)

si = x /(r + x ai ) mod q

Where equation (8) performs hash function- hash( g x mod p, m) and gets r, then si = x /(r + xai ) mod q is computed by each party to get the A’s signature part, where 1 ≤ i ≤ t . After the signature part (m, r, si ) is generated, it is sent to B by each party. b) Verification of signature (r, si ) of A can be performed as follows: t

v = hash( y a ⋅ g nr )

( ∑ si −1 ) −1 i =1

mod p

(10)

?

hash(v, m) = r

(11)

A Secure Agent-Mediated Payment Protocol

427

Where equation (10) performs public hash functiont

v = hash( y a ⋅g ) nr

( ∑ si −1 ) −1 i =1

mod p and B checks if hash(v, m) = r with equa-

tion (11).

4

LITESET/A + Protocol

In this section we present the payment protocol LITESET/A+, where the agent acting on behalf of the cardholder is much more capable than that in SET/A+. Once the agent is authorized to buy certain kind of product, all further activities such as appropriate decision of buying, negotiation and signing for certain action, will be performed without the cardholder’s assistance. We propose the LITESET/A+ protocol by adding a trusted third party (TTP) in LITESET based on the proposed signcryption-threshold scheme. The TTP can be assumed as a trusted agent to perform partial functions for the cardholder. The TTP also contributes to support non-repudiation between cardholder and merchant. In our approaches, payment agent and TTP share the randomly generated symmetric key K for the encryption of credit card information (i.e., E k (PI ) ), which is based on the special case of shamir-threshold scheme (t=w=2). At the same time, they also share the signature private key x SC for signing messages on behalf of cardholder, which is based on the special case of the signcryption-threshold protocol (t=w=2). They share the two kinds of keys. Any one of them cannot retrieve the secret keys and therefore the credit card information and private signature key could be protected. The notation of the certificate, signature key pair and key-exchange key pair of each participant is illustrated in Table 1. Table 1. Two Distinct Key Pairs & Certificates of Participants Name Cardholder (C) Merchant (M) Payment Gateway (PG) Trust Third Party (TTP) Payment Agent (PA)

4.1

Signature Certificate, Public key & Private Key

Key-exchange certificate, Public key & Private Key

C S (C ) , y SC , x SC C S (M ) , y SM , x SM C S (PG ) , y SPG , x SPG

C K (C ) , y KC , x KC C K (M ) , y KM , x KM C K (PG ) , y KPG , x KPG

C S (TTP ) , y STTP , x STTP

C K (TTP ) , y KTTP , x KTTP

C S (PA) , y SPA , x SPA

C K (PA) , y KPA , x KPA

Secret-Sharing of Symmetric Key K

The symmetric key K used to encrypt the credit card information is divided into: KS PA - the shared secret of payment agent, and KSTTP - the shared secret of TTP. The construction can be seen in the following formula:

428

Xiaolin Pang et al.

KS PA = K − x + R KS TTP = x + I C + T

(12)

Where x, R are random numbers chosen from [1,…,q-1] , I C is the transaction identifier assigned by cardholder and T is timestamp. Reconstruction of the key K is described in Section 4.3.

4.2

Secret-Sharing of Cardholder’s Signature Private Key x SC

The payment agent and TTP share cardholder’s signature private key x SC are based on shamir-threshold scheme. See formula (13):

xs PA = x ’ xsTTP = x SC − x ’

(13)

Where x ’ is a random number chosen from [1,…,q-1] . Verification of the cardholder’s signature can be obtained from the above signcryption-threshold scheme in Section 3. 4.3

Procedure of Payment Transaction

In this section, we focus on the purchase request in LITESET/A+ protocol and the procedure is sketched in Fig. 2. Following is the detailed procedure of payment transaction in LITESET/A+: Step1. The cardholder C builds a purchase description with the same elements of SET. Then an agent A(C) on behalf of the cardholder is dispatched to search the required goods, perform negotiation with merchants and pay for goods finally. The cardholder’s agent contains: the cardholder’s signature certificate ( C s (C ) ), the request information, the information for TTP, the digest of payment instructions (PI)(i.e. H (PI)) and the encrypted payment instructions ( E k (PI ) ). The information for TTP includes: x ( k1 , k 2 ) = hash ( y KTTP mod p )

c = E k1 ( m || KS TTP || xs TTP ) r = KH

k2

( m || KS TTP || xs TTP || Customer _ Info )

s = x /( r + x c ) mod q Notes: m is the message for TTP, including the transaction identifier I C assigned by cardholder , the merchant host name and the time stamp T.

A Secure Agent-Mediated Payment Protocol

429

Customer_Info contains the data of C s (C ) , hash(Constra int) , where Constraint is the cardholder’s buying constraint on mobile agent, such as certain goods’ brand, the goods’ quantities, the maximum money allowed to be spent, etc. C

Merchant Server Create Request

A

M

PinitRequest PinitResponse

TTP

C: M: A: PG: TTP:

Cardholder Merchant Payment Agent Payment Gateway Trust Third Party

SerRequest SerResponse PurRequest Final Response

PurResponse

PG AuthRequest AuthResponse

Fig. 2. LITESET/A+ purchase request transaction

Then, the agent on behalf of the cardholder is dispatched to one of merchant servers. Step2. After the agent finishes searching and negotiation phase, it decides to pay required goods of certain merchant M. To make purchase and payment, it arrives at the merchant server and submits cardholder’s signature certificate (C s (C )) . Merchant M verifies them. If correct, it supplies the agent an execution environment. Step3. The agent residing on the merchant server then sends information (c, r, s) to TTP (See Step1) and also the purchase initial request (PInitReq) to merchant locally including the card brand name. It also asks the merchant to respond with a copy of the payment gateway’s key-exchange certificate C k (PG ) . Step4. Upon receiving the information from payment agent, TTP unsigncrypts it as: (k1 , k 2 ) = hash(( y C ⋅ g r )

s⋅ xKTTP

mod p and get m, KS TTP , xsTTP from Dk1 (c) .

TTP accepts only if KH k 2 (m, KS TTP , xsTTP , Customer _ Info) = r and it keeps Customer_Info, m, r and s as the non-repudiation evidence. Step5. When merchant receives the request, it returns a purchase initial response (PinitRes), containing a signed message with its signature certificate C s (M ) , the payment gateway key-exchange certificate C k (PG ) , and a unique transaction identifier ( I M ) to the payment agent.

430

Xiaolin Pang et al.

Step6. The agent verifies the merchant’s certificate C s (M ) and the signature. After verification, agent generates the order information (OI) and the half dual signature of the cardholder on them (i.e. xs PA [ H ( H ( PI ) || H (OI ))] ), etc. The payment agent sends message to the TTP including the payment gateway key-exchange certificate C k (PG ) , C s (M ) and also the shared secret key KS PA used to protect the credit card information. Step7. Upon obtaining the above information, TTP generates another half dual signature of the cardholder on the OI and the PI (i.e. xsTTP [ H ( H ( PI ) || H (OI ))] ) and reconstructs the symmetric key K: KS TTP + KS PA = K + I C + T + R . And TTP keeps C s (M ) + I M as the non-repudiation service. It then gives information to payment agent including y KPG ( K + I C + T + I M + R) . Step8. When the payment agent obtains the above information, the agent creates the digital envelope E PG for the payment gateway: E PG = { y KPG ( K + I C + I M + T

+ R), I C , I M , T , R, E K ( PI )} . And the purchase request (PReq (PIData, OIData)) for the merchant includes: C s (C ), H ( PI ), OI , xs PA [ H ( H ( PI ) || H (OI ))], xsTTP [ H ( H ( PI ) || H (OI ))]E PG Step9. After receiving the purchase request, the merchant M checks the cardholder’s certificate C s (C ) and verifies the dual signature of the cardholder (i.e. xs PA [ H ( H ( PI ) || H (OI ))], xsTTP [ H ( H ( PI ) || H (OI ))] ) with H (PI) and OI. It is obvious that merchant M cannot get PI during the verification. If verification succeeds, merchant M sends the rest information (i.e. E PG , xs PA [ H ( H ( PI ) || H (OI ))], xsTTP [ H ( H ( PI ) || H (OI ))], C S (C ) ) to payment gateway for authorization. Step10. The payment gateway obtains the symmetric key K from E PG if

I C , I M , T are not abused and hereby gets PI. Then the payment gateway verifies C S (C ) and the dual signature (i.e. xs PA [ H ( H ( PI ) || H (OI ))], xsTTP [ H ( H ( PI ) || H (OI ))] ) by applying PI and H (OI). If all these are correct, payment gateway sends authorization response. Step11.After processing the order, the merchant generates and signs a purchase response, and sends it to the agent along with its signature certificate. If the payment is authorized, the merchant will fulfill the order, by delivering the products bought by the cardholder. Step12.The agent verifies the merchant signature certificate, checks the digital signature of the response, and then returns back to its owner. The owner takes any appropriate actions based on its contents. From the above we can see that LITESET/A+ has only two steps more than SET/A+. In LITESET/A+, the agent not only has the function of doing payment for cardholder, it also searches goods information and negotiates with merchants in pervious steps. And since the agent and TTP share the signature private key of the cardholder, they generate half of the dual signature on OI and PI for cardholder respec-

A Secure Agent-Mediated Payment Protocol

431

tively. This inevitably adds steps in payment process. We can see it doesn’t significantly affect the efficiency of LITESET/A+ but can improve the security level.

5

Security Issues

5.1

Security of Proposed Signcryption Scheme

The security of Signcryption is based on the discrete logarithm problem. It satisfies unforgeability, non-repudiation and confidentiality conditions [12][13]. And the security of Shamir-threshold scheme relies on the provable assumptions [10][11]. As for the proposed signcryption scheme that is based on Shamir-threshold scheme, each sharing party won’t know secret shares except its own share. For example, when an attacker wants to forge the cardholder’s signature by performing signature-threshold scheme, he/she must get each share part from each sharing-party and it is almost impossible except they conspire together. 5.2

Protection of the Credit Card Information

Since the agent perhaps runs on a hostile server, the sensitive information such as credit card information should not be disclosed on any other environment except to payment gateway in LITESET. In our approach, the payment agent and the TTP will collaborate together to protect the credit card information to fulfill the payment transaction. The proposed LITESET/A+ protocol achieves such objective by using signcryption-threshold scheme. Even TTP and merchant taking part in the process cannot retrieve encrypted credit card information. For example, when TTP reconstructs the secret information of symmetric key K ( KS TTP + KS PA = K + I C + T + R ), it can only obtain K + I C + T + R and cannot obtain K since payment agent keeps the random number R. And also when merchant gets the E PG , it cannot decrypt the encrypted PI and y KPG ( K + I C + T + I M + R) .

5.3

Protection of the Private Key Carried by Agent

To protect the owner’s private key carried by agent, Kotzanikolaou [8] presented a solution to the hostile host by encrypting a signature function based on RSA signature scheme. Although the scheme protects cardholder’s private key successfully, it doesn’t ensure non-repudiation property. Since the signature can be computed by any party, the merchant server can repudiate the cardholder’s signature generation later. Another solution [9] is to issue proxy certificate [14][15] to an agent, which is based on delegation type as partial delegation (issuing a new key pair to the agent), and the agent will sign for its owner using the new private key. But this solution has obvious limitations since the private key of the agent can also be attacked at any time. In this paper, our approach to solve this problem is that agent and TTP will share the cardholder’s private key to protect the signature key from detecting. The proposed signcryption-threshold scheme is adopted to protect owner’s private key. Agent has one

432

Xiaolin Pang et al.

share of the private key xs PA (i.e. x ’ ) and TTP owes the other share xsTTP (i.e. ( x SC − x ’ )). Even the TTP cannot retrieve the private key except agent and TTP conspire together. It can only be known to its owner. In this proposed approach, both agent and TTP perform signing or signcryption based on threshold-signcryption scheme for cardholder when needed.

6

Conclusions

In this paper, we have proposed a LITESET/A+ payment protocol that is based on Shamir-threshold scheme and a newly proposed signcryption-threshold scheme, and employs a Trusted Third Party. It allows an agent to perform sign/signcryption operations for its owner during purchase. The mobile agent automatically roams among some on-line merchants, finds the most suitable sites, negotiates with them and then purchases satisfied goods by using LITESET/A+ protocol on behalf of cardholder. In this approach, a cardholder need not frequently connect to Internet and only need to wait for the purchase response at last. LITESET/A+ protocol is also computationally efficient as it is based on signcryption-threshold scheme. In view of above discussions, we believe LITESET/A+ is acceptable for both cardholder side and merchant side. The future work will consider optimizing the secure payment protocol and achieving the combination of the payment protocol with the searching information and negotiation protocol in reality. The agent will automatically and independently fulfill the whole business transaction for its owner.

References 1. URL: http://www.netscape.com/eng/ssl3/ssl-toc.html 2. URL: http://www.terisa.com/shttp/current.txt 3. VISA INTERNATIONAL, and MASTERCARD INTERNATIONAL. Secure Electronic Transaction (SET) Specification. Version 1.0, (1997) 4. Romao, A., M. M. da. Sliva: “ An agent-based secure Internet payment system for mobile computing”, TREC’98, LNCS 1402, (1998) 80-93 5. Yi, X., Siew, C. K., Wang, X. F., Okamoto, E.: “A secure Agent-based Framework for the Internet Trading in Mobile Computing Environments”, in Distributed and Parallel Databases, 8. (2000) 85-117 6. Hanaoka, G., Zheng, Y., Imai, H.: “LITESET: a light-weight secure electronic transaction protocol”, Proc. ACISP'98, Lecture Notes in Computer Science, vol.1438. SpringerVerlag. (1998) 215-226 7. Rivest, R. L., Shamir, A., Adleman, L.: “ A method for obtaining digital signatures and public-key cryptosystems”, Communications of the ACM, 21. (1978) 120-126 8. Kotzanikolaou, P., Burmester, M., Chrissikopoulos, V.: “Secure Transactions with Mobile Agents in Hostile Environments”, ACISP 2000,LNCS 1841. (2000) 289-297 9. Romao, A., Sliva, M. M. da.: “ Secure mobile agent digital signatures with proxy certificates”, E-Commerce Agents, LNAI 2033. (2001) 206-220 10. Stinson, D. R.: “ Secret Sharing Schemes”, Cryptography-Theory and Practice, CRC Press. (1995) 326-331

A Secure Agent-Mediated Payment Protocol

433

11. Menezes, A., Van Oorschot, P., Vanstone, S.: “Threshold Schemes”, Handbook of Applied Cryptography, CRC Press. (1996) 12. Zheng, Y.: “Signcryption and Its Applications in Efficient Public Key Solutions”, Information Security Workshop (ISW '97), Springer-Verlag, LNCS 1397. (1998) 291-312 13. Zheng, Y.: “Digital Signcryption or How to Achieve Cost (Signature& Encryption)

Abstract. While software agents have been employed in payment protocols, they are largely passive entities, i.e., they participate in the payment protocol but do not make decision. In this paper, we propose an agent-assisted payment protocol called LITESET/A+ that empowers the payment agent (PA) to perform encryption operation for its owner. This is realized by introducing a Trusted Third Party (TTP) in the payment system based on the SET protocol (Secure Electronic Transaction) and a novel signcryption-threshold scheme. In LITESET/A+, the PA and TTP collaborate together to ensure the same level of security as the SET specification. At the same time, with the signcryptionthreshold scheme, the PA is more flexible and autonomous during trading.

1

Introduction

Although the Internet is now becoming an important environment for e-commerce, the public is still wary of buying goods and also paying for them on-line. For example, there is concern that credit card information, when submitted on-line, may be eavesdropped despite the fact that very few of those attacks have actually succeeded. Even the deployment of secure servers, based on protocols such as SSL [1] or SHTTP [2], is not considered to be secure enough to protect the credit card information since it is deposited on the sever, where it can potentially be read by anyone who have access to the server. To protect the user’s credit card information over open network like the Internet, the SET (Secure Electronic Transaction) protocol [3] has been developed mainly by credit card industry such as VISA and MasterCard, in association with major software and cryptography companies. SET provides many important secure properties – such as authentication of participants, confidentiality of information, integrity of data and non-repudiation, etc. In the payment system, each participant can only obtain the information that is necessary for it to perform its own function. For example, the merchant never gets the buyer’s credit card information, and the financial institution authorizing the transaction never knows the details of the purchase like the nature of the products, quantities, etc. Nevertheless, SET is a complex protocol and may be unsuitable under some technical conditions. Several extensions of the SET protocol have been proposed. The SET/A [4] protocol dispatches an agent to the merchant server so that all operations can be performed R. Deng et al. (Eds.): ICICS 2002, LNCS 2513, pp. 422–433, 2002. © Springer-Verlag Berlin Heidelberg 2002

A Secure Agent-Mediated Payment Protocol

423

there. In this way, the user no longer needs to connect to the Internet when the transaction is running. The SET/A+[5] protocol removes the requirement of SET/A for a secure agent execution environment by adding a Trust Verification Center (TVC) in the payment system. TVC keeps the sensitive information and provides verification services for cardholder and merchants. But the payment agent of SET/A+ is not authorized to certain functions, e.g., to ensure that some operations are performed in a non-repudiable way or to encrypt certain important information. To improve the flexibility of mobile agents and the efficiency of SET/A+ protocol, a LITESET/A+ protocol based on LITESET system (Light-Weight Secure Electronic Transaction) is proposed in this paper. By using a new cryptography technique –signcryption [6], LITESET protocol reduces the heavy computation and message overhead in the employment of SET, the implementation of which is based on traditional RSA signature and encryption scheme [7]. In LITESET/A+ protocol, we introduce a Trusted Third Party (TTP) and a newly proposed signcryption-threshold scheme. TTP and payment agent collaborate together to protect the sensitive information such as credit card information and the signature private key carried by the agent during the whole payment process. The rest of this paper is organized as follows. Section 2 reviews related work. Section 3 describes a proposed signcryption-threshold scheme, and Section 4 presents the LITESET/A+ payment protocol. Security issues are discussed in section 5. Finally, Section 6 concludes this work.

2

Related Work and Background

2.1

Related Work of Payment Protocol

2.1.1 SET Protocol There are five participants in SET protocol: cardholder, issuer, merchant, acquirer and payment gateway. Each participant possesses two distinct asymmetric key pairs. One is used for performing encryption and decryption function and its public key is authenticated by key- exchange certificate ( C K ). The other is used for generation and verification of signatures and its public key is authenticated by signature certificate ( C S ). Since the phase on purchase request is the core of the whole transactions, only this phase is emphasized and described in detail in this work (see Fig. 1). 2.1.2 LITESET Protocol Although SET is treated publicly as one of the important protocols for electronic payments, a straightforward implementation incur significant computation and message overhead, primarily because it uses traditional techniques such as RSA digital signature and encryption scheme [7]. LITESET [6], a lightweight secure electronic transaction protocol, improves the efficiency by using signcryption– a new cryptographic scheme. For the same level of security as the SET specification, LITESET shows a 53.7% reduction in the computational time in message generation/verification and a 79.9% reduction in communication overhead [6].

424

Xiaolin Pang et al.

C

M C: Cardholder M: Merchant PG: Payment Gateway

Purchase Request

C S ( M ), C K ( PG ) P

C S (C ), OI , E PG {K , PI }

E PG {K , PI } Authorization

Response, C S (M ) Fig. 1. SET purchase request transaction

2.1.3 SET/A Protocol Since SET is very complex and may not be suitable under some technical conditions, SET/A protocol [4] is proposed to make SET adaptable to the mobile computing environments. Based on the principles used in purchase phase of SET, SET/A improve its performance only by adding a mobile agent for the cardholder to fulfill payment transaction. Also it is a practical technique since the cardholder need not frequently connect to Internet during the whole transaction phase. SET/A performs the same function of transaction as that in SET except that mobile agent of SET/A replaces the cardholder of SET in the purchase phase. However, SET/A protocol also has its drawbacks: it has to rely on a secure execution environment or hidden computation on the merchant server since all the critical data carried by agent are deposited on it. 2.1.4 SET/A+ Protocol SET/A+ protocol [5] removes the security requirement of agent’s running environment on merchant server by adding a Trust Verification Center (TVC) in the payment system. The TVC keeps the sensitive information and charges cardholders or merchants by providing verification service. However, the agents are limited in their functionalities. For example, an agent cannot sign and perform encryption for the owner during trading (since it requires the secret key of the owner).

3

Signcryption-Threshold Scheme

In this paper, a signcryption-threshold scheme is proposed, which is based on the special case of shamir-threshold scheme (t=w) that protects the secret K by distributing w secret shares from the secret to t users. We also extend the scheme to work with signature-only mode of signcryption scheme, namely signature-threshold scheme. 1. In the scheme, there are three public parameters ( p, q, g ) , two public hash functions (hash, KH) and one pair of encryption/decryption algorithms (E, D).

A Secure Agent-Mediated Payment Protocol

425

The notations of the above parameters are: p- a large prime q- a large prime factor of p-1 g- an integer chosen randomly from [1,…,p-1] with order q modulo p hash- a one-way hash function whose output has ,say, at least 128 bits KH - a keyed one-way hash function, which is for secure message authentication. (E, D)- the encryption and decryption algorithms of a private key cipher 2. Each entity in the payment system owns a key pair. For example, entity A has a key pair ( y a , x a ) , where y a = g a (mod p ) and the private key xa is chosen uniformly at random from [1,…,q-1] . 3. To protect one entity’s private key, we assume several parties share it using the special case of shamir-theshold scheme (t=w). For example, to protect entity A’s signature private key xa , t parties ( A1 , A2 ,..., At ) will share the private key and have x

secret shares xa1 , xa2 ,..., xat respectively, where xa = xa1 + xa2 + .... + xat (mod p ) . 4. We are ready to describe the signcryption-threshold scheme: In the scheme, there are several participants: sender A, recipient B and t sharingparties ( A1 , A2 ,..., At ) to share the secret for A. Sender A :

Private key - xa Public key - y a , ( y a = g

Sharing-Parties:

xa

mod p )

The private key xa is shared by t parties ( A1 , A2 ,..., At ), each of which has the secret share xa1 , xa2 ,..., xat respectively and

x a = x a1 + x a2 + .... + x at (mod p) Recipient B:

.

Private key - xb

Public key - yb , ( yb = g b mod p ) Two modes of the scheme (i.e. signcryption-threshold scheme and signaturethreshold scheme) are described in detail below: (1) Signcryption-threshold on a message m (Sender: A1 , A2 ,..., At , Recipient: B) x

a) Signcrypting m by sharing-parties ( A1 , A2 ,..., At ):

(k1 , k 2 ) = hash( yb mod p) x

(1)

c = E k1 ( m)

(2)

r = KH k2 (m)

(3)

si = x /(r + xai ) mod q

(4) x

Where equation (1) uses a hash function- hash( yb mod p ) and splits the result into k1 and k 2 of appropriate length. The key k1 is used to encrypt message m by equation (2) and a key hash function - KH k2 (m) - performs hash

426

Xiaolin Pang et al.

function on message m using key k 2 by equation (3). From the results of (2) and (3), each party computes si = x /(r + xai ) mod q , where 1 ≤ i ≤ t , and generates a part of signature respectively. In above equations, x is a random number chosen from [1,…,q-1] , but its value keeps the same for each sharing- party. The difference of signcryption operation among each party is the last equation (4) used to produce signature si because the secret share xai may be different to each party. After the signcrypted text (c, r, si ) is generated, it is sent to B by each party. b) Unsigncryption of (c, r, si ) by B involves the followings: t

(k1 , k 2 ) = hash(( y a ⋅ g ) nr

( ∑ si −1 ) −1 ⋅ xb i =1

mod p )

m = Dk1 (c)

(5) (6)

?

KH k2 (m) = r

(7)

Where equation (5) performs the public hash functiont

( ∑ si −1 ) −1 ⋅ xb

hash(( y a ⋅ g ) mod p ) to recover (k1 , k 2 ) from input signature parts (c, r, si ) sent by each sharing-party. Then B decrypts c using key k1 to get message m by equation (6) and verifies it by checking if KH k2 (m) = r . nr

i =1

(2) Signature-threshold on a message m (Sender: A1 , A2 ,..., At , Recipient: B) a) Signature part (r, si ) on a message m generated by sharing-parties ( A1 , A2 ,..., At ):

r = hash( g x mod p, m)

(8) (9)

si = x /(r + x ai ) mod q

Where equation (8) performs hash function- hash( g x mod p, m) and gets r, then si = x /(r + xai ) mod q is computed by each party to get the A’s signature part, where 1 ≤ i ≤ t . After the signature part (m, r, si ) is generated, it is sent to B by each party. b) Verification of signature (r, si ) of A can be performed as follows: t

v = hash( y a ⋅ g nr )

( ∑ si −1 ) −1 i =1

mod p

(10)

?

hash(v, m) = r

(11)

A Secure Agent-Mediated Payment Protocol

427

Where equation (10) performs public hash functiont

v = hash( y a ⋅g ) nr

( ∑ si −1 ) −1 i =1

mod p and B checks if hash(v, m) = r with equa-

tion (11).

4

LITESET/A + Protocol

In this section we present the payment protocol LITESET/A+, where the agent acting on behalf of the cardholder is much more capable than that in SET/A+. Once the agent is authorized to buy certain kind of product, all further activities such as appropriate decision of buying, negotiation and signing for certain action, will be performed without the cardholder’s assistance. We propose the LITESET/A+ protocol by adding a trusted third party (TTP) in LITESET based on the proposed signcryption-threshold scheme. The TTP can be assumed as a trusted agent to perform partial functions for the cardholder. The TTP also contributes to support non-repudiation between cardholder and merchant. In our approaches, payment agent and TTP share the randomly generated symmetric key K for the encryption of credit card information (i.e., E k (PI ) ), which is based on the special case of shamir-threshold scheme (t=w=2). At the same time, they also share the signature private key x SC for signing messages on behalf of cardholder, which is based on the special case of the signcryption-threshold protocol (t=w=2). They share the two kinds of keys. Any one of them cannot retrieve the secret keys and therefore the credit card information and private signature key could be protected. The notation of the certificate, signature key pair and key-exchange key pair of each participant is illustrated in Table 1. Table 1. Two Distinct Key Pairs & Certificates of Participants Name Cardholder (C) Merchant (M) Payment Gateway (PG) Trust Third Party (TTP) Payment Agent (PA)

4.1

Signature Certificate, Public key & Private Key

Key-exchange certificate, Public key & Private Key

C S (C ) , y SC , x SC C S (M ) , y SM , x SM C S (PG ) , y SPG , x SPG

C K (C ) , y KC , x KC C K (M ) , y KM , x KM C K (PG ) , y KPG , x KPG

C S (TTP ) , y STTP , x STTP

C K (TTP ) , y KTTP , x KTTP

C S (PA) , y SPA , x SPA

C K (PA) , y KPA , x KPA

Secret-Sharing of Symmetric Key K

The symmetric key K used to encrypt the credit card information is divided into: KS PA - the shared secret of payment agent, and KSTTP - the shared secret of TTP. The construction can be seen in the following formula:

428

Xiaolin Pang et al.

KS PA = K − x + R KS TTP = x + I C + T

(12)

Where x, R are random numbers chosen from [1,…,q-1] , I C is the transaction identifier assigned by cardholder and T is timestamp. Reconstruction of the key K is described in Section 4.3.

4.2

Secret-Sharing of Cardholder’s Signature Private Key x SC

The payment agent and TTP share cardholder’s signature private key x SC are based on shamir-threshold scheme. See formula (13):

xs PA = x ’ xsTTP = x SC − x ’

(13)

Where x ’ is a random number chosen from [1,…,q-1] . Verification of the cardholder’s signature can be obtained from the above signcryption-threshold scheme in Section 3. 4.3

Procedure of Payment Transaction

In this section, we focus on the purchase request in LITESET/A+ protocol and the procedure is sketched in Fig. 2. Following is the detailed procedure of payment transaction in LITESET/A+: Step1. The cardholder C builds a purchase description with the same elements of SET. Then an agent A(C) on behalf of the cardholder is dispatched to search the required goods, perform negotiation with merchants and pay for goods finally. The cardholder’s agent contains: the cardholder’s signature certificate ( C s (C ) ), the request information, the information for TTP, the digest of payment instructions (PI)(i.e. H (PI)) and the encrypted payment instructions ( E k (PI ) ). The information for TTP includes: x ( k1 , k 2 ) = hash ( y KTTP mod p )

c = E k1 ( m || KS TTP || xs TTP ) r = KH

k2

( m || KS TTP || xs TTP || Customer _ Info )

s = x /( r + x c ) mod q Notes: m is the message for TTP, including the transaction identifier I C assigned by cardholder , the merchant host name and the time stamp T.

A Secure Agent-Mediated Payment Protocol

429

Customer_Info contains the data of C s (C ) , hash(Constra int) , where Constraint is the cardholder’s buying constraint on mobile agent, such as certain goods’ brand, the goods’ quantities, the maximum money allowed to be spent, etc. C

Merchant Server Create Request

A

M

PinitRequest PinitResponse

TTP

C: M: A: PG: TTP:

Cardholder Merchant Payment Agent Payment Gateway Trust Third Party

SerRequest SerResponse PurRequest Final Response

PurResponse

PG AuthRequest AuthResponse

Fig. 2. LITESET/A+ purchase request transaction

Then, the agent on behalf of the cardholder is dispatched to one of merchant servers. Step2. After the agent finishes searching and negotiation phase, it decides to pay required goods of certain merchant M. To make purchase and payment, it arrives at the merchant server and submits cardholder’s signature certificate (C s (C )) . Merchant M verifies them. If correct, it supplies the agent an execution environment. Step3. The agent residing on the merchant server then sends information (c, r, s) to TTP (See Step1) and also the purchase initial request (PInitReq) to merchant locally including the card brand name. It also asks the merchant to respond with a copy of the payment gateway’s key-exchange certificate C k (PG ) . Step4. Upon receiving the information from payment agent, TTP unsigncrypts it as: (k1 , k 2 ) = hash(( y C ⋅ g r )

s⋅ xKTTP

mod p and get m, KS TTP , xsTTP from Dk1 (c) .

TTP accepts only if KH k 2 (m, KS TTP , xsTTP , Customer _ Info) = r and it keeps Customer_Info, m, r and s as the non-repudiation evidence. Step5. When merchant receives the request, it returns a purchase initial response (PinitRes), containing a signed message with its signature certificate C s (M ) , the payment gateway key-exchange certificate C k (PG ) , and a unique transaction identifier ( I M ) to the payment agent.

430

Xiaolin Pang et al.

Step6. The agent verifies the merchant’s certificate C s (M ) and the signature. After verification, agent generates the order information (OI) and the half dual signature of the cardholder on them (i.e. xs PA [ H ( H ( PI ) || H (OI ))] ), etc. The payment agent sends message to the TTP including the payment gateway key-exchange certificate C k (PG ) , C s (M ) and also the shared secret key KS PA used to protect the credit card information. Step7. Upon obtaining the above information, TTP generates another half dual signature of the cardholder on the OI and the PI (i.e. xsTTP [ H ( H ( PI ) || H (OI ))] ) and reconstructs the symmetric key K: KS TTP + KS PA = K + I C + T + R . And TTP keeps C s (M ) + I M as the non-repudiation service. It then gives information to payment agent including y KPG ( K + I C + T + I M + R) . Step8. When the payment agent obtains the above information, the agent creates the digital envelope E PG for the payment gateway: E PG = { y KPG ( K + I C + I M + T

+ R), I C , I M , T , R, E K ( PI )} . And the purchase request (PReq (PIData, OIData)) for the merchant includes: C s (C ), H ( PI ), OI , xs PA [ H ( H ( PI ) || H (OI ))], xsTTP [ H ( H ( PI ) || H (OI ))]E PG Step9. After receiving the purchase request, the merchant M checks the cardholder’s certificate C s (C ) and verifies the dual signature of the cardholder (i.e. xs PA [ H ( H ( PI ) || H (OI ))], xsTTP [ H ( H ( PI ) || H (OI ))] ) with H (PI) and OI. It is obvious that merchant M cannot get PI during the verification. If verification succeeds, merchant M sends the rest information (i.e. E PG , xs PA [ H ( H ( PI ) || H (OI ))], xsTTP [ H ( H ( PI ) || H (OI ))], C S (C ) ) to payment gateway for authorization. Step10. The payment gateway obtains the symmetric key K from E PG if

I C , I M , T are not abused and hereby gets PI. Then the payment gateway verifies C S (C ) and the dual signature (i.e. xs PA [ H ( H ( PI ) || H (OI ))], xsTTP [ H ( H ( PI ) || H (OI ))] ) by applying PI and H (OI). If all these are correct, payment gateway sends authorization response. Step11.After processing the order, the merchant generates and signs a purchase response, and sends it to the agent along with its signature certificate. If the payment is authorized, the merchant will fulfill the order, by delivering the products bought by the cardholder. Step12.The agent verifies the merchant signature certificate, checks the digital signature of the response, and then returns back to its owner. The owner takes any appropriate actions based on its contents. From the above we can see that LITESET/A+ has only two steps more than SET/A+. In LITESET/A+, the agent not only has the function of doing payment for cardholder, it also searches goods information and negotiates with merchants in pervious steps. And since the agent and TTP share the signature private key of the cardholder, they generate half of the dual signature on OI and PI for cardholder respec-

A Secure Agent-Mediated Payment Protocol

431

tively. This inevitably adds steps in payment process. We can see it doesn’t significantly affect the efficiency of LITESET/A+ but can improve the security level.

5

Security Issues

5.1

Security of Proposed Signcryption Scheme

The security of Signcryption is based on the discrete logarithm problem. It satisfies unforgeability, non-repudiation and confidentiality conditions [12][13]. And the security of Shamir-threshold scheme relies on the provable assumptions [10][11]. As for the proposed signcryption scheme that is based on Shamir-threshold scheme, each sharing party won’t know secret shares except its own share. For example, when an attacker wants to forge the cardholder’s signature by performing signature-threshold scheme, he/she must get each share part from each sharing-party and it is almost impossible except they conspire together. 5.2

Protection of the Credit Card Information

Since the agent perhaps runs on a hostile server, the sensitive information such as credit card information should not be disclosed on any other environment except to payment gateway in LITESET. In our approach, the payment agent and the TTP will collaborate together to protect the credit card information to fulfill the payment transaction. The proposed LITESET/A+ protocol achieves such objective by using signcryption-threshold scheme. Even TTP and merchant taking part in the process cannot retrieve encrypted credit card information. For example, when TTP reconstructs the secret information of symmetric key K ( KS TTP + KS PA = K + I C + T + R ), it can only obtain K + I C + T + R and cannot obtain K since payment agent keeps the random number R. And also when merchant gets the E PG , it cannot decrypt the encrypted PI and y KPG ( K + I C + T + I M + R) .

5.3

Protection of the Private Key Carried by Agent

To protect the owner’s private key carried by agent, Kotzanikolaou [8] presented a solution to the hostile host by encrypting a signature function based on RSA signature scheme. Although the scheme protects cardholder’s private key successfully, it doesn’t ensure non-repudiation property. Since the signature can be computed by any party, the merchant server can repudiate the cardholder’s signature generation later. Another solution [9] is to issue proxy certificate [14][15] to an agent, which is based on delegation type as partial delegation (issuing a new key pair to the agent), and the agent will sign for its owner using the new private key. But this solution has obvious limitations since the private key of the agent can also be attacked at any time. In this paper, our approach to solve this problem is that agent and TTP will share the cardholder’s private key to protect the signature key from detecting. The proposed signcryption-threshold scheme is adopted to protect owner’s private key. Agent has one

432

Xiaolin Pang et al.

share of the private key xs PA (i.e. x ’ ) and TTP owes the other share xsTTP (i.e. ( x SC − x ’ )). Even the TTP cannot retrieve the private key except agent and TTP conspire together. It can only be known to its owner. In this proposed approach, both agent and TTP perform signing or signcryption based on threshold-signcryption scheme for cardholder when needed.

6

Conclusions

In this paper, we have proposed a LITESET/A+ payment protocol that is based on Shamir-threshold scheme and a newly proposed signcryption-threshold scheme, and employs a Trusted Third Party. It allows an agent to perform sign/signcryption operations for its owner during purchase. The mobile agent automatically roams among some on-line merchants, finds the most suitable sites, negotiates with them and then purchases satisfied goods by using LITESET/A+ protocol on behalf of cardholder. In this approach, a cardholder need not frequently connect to Internet and only need to wait for the purchase response at last. LITESET/A+ protocol is also computationally efficient as it is based on signcryption-threshold scheme. In view of above discussions, we believe LITESET/A+ is acceptable for both cardholder side and merchant side. The future work will consider optimizing the secure payment protocol and achieving the combination of the payment protocol with the searching information and negotiation protocol in reality. The agent will automatically and independently fulfill the whole business transaction for its owner.

References 1. URL: http://www.netscape.com/eng/ssl3/ssl-toc.html 2. URL: http://www.terisa.com/shttp/current.txt 3. VISA INTERNATIONAL, and MASTERCARD INTERNATIONAL. Secure Electronic Transaction (SET) Specification. Version 1.0, (1997) 4. Romao, A., M. M. da. Sliva: “ An agent-based secure Internet payment system for mobile computing”, TREC’98, LNCS 1402, (1998) 80-93 5. Yi, X., Siew, C. K., Wang, X. F., Okamoto, E.: “A secure Agent-based Framework for the Internet Trading in Mobile Computing Environments”, in Distributed and Parallel Databases, 8. (2000) 85-117 6. Hanaoka, G., Zheng, Y., Imai, H.: “LITESET: a light-weight secure electronic transaction protocol”, Proc. ACISP'98, Lecture Notes in Computer Science, vol.1438. SpringerVerlag. (1998) 215-226 7. Rivest, R. L., Shamir, A., Adleman, L.: “ A method for obtaining digital signatures and public-key cryptosystems”, Communications of the ACM, 21. (1978) 120-126 8. Kotzanikolaou, P., Burmester, M., Chrissikopoulos, V.: “Secure Transactions with Mobile Agents in Hostile Environments”, ACISP 2000,LNCS 1841. (2000) 289-297 9. Romao, A., Sliva, M. M. da.: “ Secure mobile agent digital signatures with proxy certificates”, E-Commerce Agents, LNAI 2033. (2001) 206-220 10. Stinson, D. R.: “ Secret Sharing Schemes”, Cryptography-Theory and Practice, CRC Press. (1995) 326-331

A Secure Agent-Mediated Payment Protocol

433

11. Menezes, A., Van Oorschot, P., Vanstone, S.: “Threshold Schemes”, Handbook of Applied Cryptography, CRC Press. (1996) 12. Zheng, Y.: “Signcryption and Its Applications in Efficient Public Key Solutions”, Information Security Workshop (ISW '97), Springer-Verlag, LNCS 1397. (1998) 291-312 13. Zheng, Y.: “Digital Signcryption or How to Achieve Cost (Signature& Encryption)