Employ a mobile agent for making a payment

. The mobile agent paradigm offers ﬂexibility and autonomy to e-commerce applications. But it is challenging to employ a mobile agent to make a payment due to the security consideration. In this paper, we propose a new agent-assisted secure payment protocol, which is based on SET payment protocol and aims at enabling the dispatched consumer-agent to autonomously sign contracts and make the payment on behalf of the cardholder after having found the best merchant, without the possibility of disclosing any secret to any participant. This is realized by adopting the Signature-Share scheme, and employing a Trusted Third Party (TTP). In the proposed protocol, the principle that each participant knows what is strictly necessary for his/her role is followed as in SET. In addition, mechanisms have been devised for preventing and detecting double payment, overspending and overpayment attacks. Finally the security properties of the proposed protocol are studied analytically. In comparison with other existing models, the proposed protocol is more efﬁcient and can detect more attacks.


Introduction
Autonomous agents, stationary or mobile, offer new paradigms with autonomy, intelligence and flexibility.Autonomous agent based e-commerce technologies have drawn attentions from both the research community [7,11,15] and applications (e.g., Amazon [1] and eBay [2]).The introduction of autonomous agents acting on behalf of end-consumers could reduce the effort required from users to conduct e-commerce transactions by automating a variety of activities, such as, looking for and filtering out online shops selling the specified products, requesting offers, negotiating with shops and even completing payments [4,7,22].Due to the feature of mobile agent paradigm, an agent can be taken as a special service integrated as part of web services, namely mobile service, that is more suitable for handheld devices (e.g.PDA) with the interface of wireless communication [8,9].In the mobile agent paradigm, the network connection is required only when the agent is dispatched to remote servers and the result collected by the dispatched agent is sent back to the agent server/owner.For handheld devices, they are powered by batteries.Each battery can supply power for a few hours.In addition, the capacity of the CPU and RAM is limited too.Due to these features, it is a good choice to leave the computation task to other servers, during which the network connection is not necessary.The mobile agent paradigm is the right choice to bridge the handheld devices and remote servers.The latter can be the platforms of merchants in an e-commerce environment.
However, with respect to security, the introduction of mobile agents increases the risk as each agent is exposed to the visited servers [6,17,19].Some studies have been done for protecting the offers carried by a roaming buyer agent [5,19].But employing a mobile agent for making payment is always a challenging issue as it is not feasible to ask the agent to carry critical/confidential information (e.g.credit card information) even secret keys when visiting a set of remote hosts as this will expose sensitive data to potentially hostile environments [10].
In applications, most online payment protocols are based on SSL or S-HTTP.But as credit card information is stored on the merchant server, they are not considered secure enough.SET (Secure Electronic Transaction) protocol developed by VISA and MasterCard is regarded as a better protocol [3] aiming at protecting users' credit card information with important properties, such as authentication of the participants, data integrity and confidentiality.In SET, the credit card information is encrypted by the public key of the payment gateway.Therefore it is protected against the merchant and other parties.
In the literature, some protocols have been proposed aiming at employing one mobile agent to fulfill the payment task, such as SET/A [16], SET/A+ [25], LITESET/A+ [14] and LITESET/A++ [20].In the best case, one mobile agent is expected to be employed for searching shops/offers, negotiate with shops and complete the transaction including payment with the best seller with the best offer.
However, as we analyzed in Section 5 in this paper, the above agent-based payment protocols have various problems.For example, all protocols lack the mechanism preventing overspending and over payment problems.Most protocols except LITESET/A++ have no mechanism preventing double payment.
In this paper, we proposed a new protocol based on SET aiming at enabling a mobile agent to automatically and autonomously make final transactions and payment with the "best" merchant with the best offer without interacting with the end-consumer after having performed all kinds of tasks including asking for offers, and negotiating with merchants.This requires the capability of the agent in the protocol to dynamically sign with the "best" merchant, which is not determined in advance.Then the payment instruction is dynamically passed to the payment gateway (P G), which can be determined only after the interaction with the merchant according to the brand of the credit card.Hence encrypting everything in advance is impossible while asking the agent to carry any key for encryption is certainly a risk.The proposed protocol is based on Signcryption algorithm [26], which alleviates the burden for encryption and signature generation consuming less resource and hence is more suitable to mobile agent environments.Meanwhile, by adopting the Signature-Share scheme, the agent can sign contracts and pass the payment instruction to the P G in cooperation with independent TTP without the possibility of disclosing any secret to other participants.In the proposed protocol, a symmetric key is used to encrypt the payment instruction (P I), which is more efficient than the public key scheme used in LITESET/A++.In addition, in the proposed protocol, we have designed mechanisms preventing overspending and over payment problems.
The rest of this paper is organized as follows.Section 2 briefly reviews SET and Signature-Share scheme.The proposed protocol is presented in Section 3 and its features and security properties are analyzed in Section 4. In Section 5, we analyze existing agent-based secure payment protocols and compare them with the proposed protocol.Section 6 finally concludes our work in this paper.

Background
In this section, we will briefly review SET [3] and Signature-Share scheme [14].The notations and symbols used in this paper are listed in Table 1.

SET
The SET protocol [3] is composed of several kinds of transactions, ranging from registration of participants, to purchase request and payment processing.There are different roles in SET.They are cardholder (C), credit card issuer, merchant, acquirer and payment gateway (P G) [3].P G is a device of acquirer where the merchant has an account.As requested by the P G, successful payment should be finally authorized by the card issuer whereafter the issuer will pay on behalf of the cardholder and the money will be deposited to the merchant's account at the acquirer.
SET uses two distinct asymmetric key pairs for each party, one for key-exchange.The corresponding public key y K A is contained in public key certificate C K (A) of participant A. The key pairs (y K A , x K A ) are used for encrypting and decrypting messages.Another key pair is used for the creation and verification of signatures.The signature public key of participant A is included in the signature certificate C S (A). Figure 1   In SET, the key issue is to pass the payment instruction (P I) including card number, cardholder's name and expiry date to the payment gateway (P G) determined according to the brand of the cardholder's credit card that is included in purchase request (in step 1 in Fig. 1).P I is encrypted by a symmetric session key K that is contained in a digital envelope E P G {K, P I} passed to P G via merchant M .Finally the payment can be completed by P G without the possibility of disclosing P I to M .Due to the limited space, readers can refer to [3] for more details.

Signature-Share scheme
The Signature-Share scheme [14] (see Fig. 2) is based on Signcryption public key algorithm (see Appendix 1).In this scheme, the sender A wants to send a message m to recipient B through t sharing parties, say A i (i = 1, . . ., t).The signature key of A is shared by t parties, namely, x A = x A 1 + x A 2 + . . .+ x At .Each party generates the shared signature s i on the hash value r of message m, and all shared signatures are sent to B. With all (r, s i ), B can verify the signature and hence check the data integrity of m.
Details of the Signature-Share scheme are described in Appendix 2.

The proposed protocol
In the proposed protocol, Signature-Share scheme is adopted for passing securely the order information to the merchant.The cardholder's signature secret key is divided into two parts.The first part is kept by the cardholder.The second part is encrypted using the public key of the TTP and will be passed to the TTP for generating shared signatures.The dispatched agent does not carry any shared signature secret key.Instead it only carries one half shared signature signed on the order information (OI) and payment instruction (P I) respectively by the cardholder that should be sent to the merchant M .The other half shared signature is generated with the assistance of the TTP.On obtaining the two shared signatures (i.e.s 1 →M and s 2 →M ), the merchant M can verify the order information (OI) and check the data integrity.Meanwhile the payment instruction (P I) is encrypted by a symmetric session key, It can be passed to P G via the merchant and can be decrypted by P G only.Additionally, in the proposed protocol, mechanisms are also provided for preventing and detecting double payment, overspending and overpayment attacks.

Secret-sharing of cardholder's signature secret key x S C
In the proposed protocol, the cardholder and TTP share the cardholder's signature secret key x S C based on Shamir-threshold scheme [12].
According to the two share schemes presented in Section 2.2, A 1 = C and A 2 = T T P .x S C 1 is kept by C as a secret key always while x S T T P can be carried by the agent after being encrypted using the TTP's public key and will be passed to the TTP for generating the second shared signature that will be passed to M .

Description of the protocol
Step 1: Cardholder C (i.e.C's software) generates a temporary session key K →P G for the payment gateway.

1)
Then C uses K →P G to encrypt the payment instruction (P I): and generate ciphertext where -R is a random number chosen from [1, . . ., q]; -I C is the transaction identifier assigned by cardholder C; -T C is the timestamp at C when to complete the encryption and shared signature generation; -T e (T e > T C ) is the timestamp when the purchase request expires.It is unique to each purchase order.2) Meanwhile, C generates the first half shared signature s 1 →M on the hash value that will be passed to merchant M : where -OI is the description and constraint for the order of Product, namely,  3) Then C dispatches the consumer agent CA encapsulating the following arguments C S (C), The dispatched agent will visit a set of merchants asking offers and negotiating with them.An offer evaluation model and negotiation model can be found in [22].
Step 2: After completing the negotiation with some merchants, the agent chooses the best one -M -with the best offer to make the deal and send M the purchase request (see Fig. 3).The request contains the brand of the credit card that will be used for payment.
CA → M : C S (C), purchase request, T e Step 3: After receiving the request, M verifies C S (C) and reply CA.
where -I M is a unique transaction number issued by M and is the signature generated by M ; -P G is the payment gateway that is determined according to the brand of C's credit card, which is contained in the purchase request.
Step 4: From M 's reply, CA obtains the public key certificate of the payment gateway.Then CA sends TTP a message so that s 2 →M can be generated by TTP.
where -Amount = Price.Price is the price of the Product, which is determined by CA and M after the negotiation between them.Amount is the variable sent by CA.Price is the variable sent by M in Step 7.Here we distinguish Amount and Price as both of them will be passed to the P G where a consistency verification will be performed (in Step 8).
Step 5: On receiving the message, TTP verifies the validation of C S (C), C S (M ), C K (M ) and C K (P G), checks whether the current time T < T e and Amount PriceLimit.If all are correct, TTP decrypts the ciphertext from CA obtaining z and x S T T P , generates the 2nd half shared signature on hash value r →M , and generates Hereafter TTP keeps as a transaction record and sends a message to CA.

T T T P , SIG T T P
where -T T T P is the timestamp at TTP when to generate the shared signature (i.e.s 2 →M ); is the signature generated by TTP that can be kept by the cardholder as a non-repudiation receipt.
Step 6: Once receiving the message from TTP, CA sends a message to the merchant.
Step 7: After having received the message, M computes v by applying the Signature-Share scheme Then M sends a message to P G.
Step 8: From the message, P G obtains After decryption, it obtains K →P G and Amount.Hereafter P G can decrypt c →P G and thus obtain P I: If current time T < T e and Amount = Price, P G will send M an authorization response.
Step 9: After processing the order, the merchant generates and signs a purchase response, and sends it to the agent.
is the signature generated by M at time T 2 M .It will be finally passed to the cardholder as a non-repudiation receipt by the agent.
If the payment is authorized, the merchant will fulfill the order by delivering the product bought by the cardholder.
Step 10: The agent verifies the merchant signature certificate, checks the digital signature of the response, and then returns back to its owner carrying The owner takes appropriate actions based on the obtained contents.

Security analysis
From the above description, we could observe that in cooperation with TTP, the agent can sign contracts with the dynamically chosen merchant M and make payment.In this section, we will analyze the security properties of the proposed protocol focusing on the following possible issues.
-whether it is possible for any participant to re-generate the secret signature key of the cardholder (ATK1); -whether it is possible for any participant except P G to obtain the payment instruction (ATK2); -whether it is possible for any participant to re-perform the payment (double payment, ATK3); -whether it is possible for the agent to pay more than required by the cardholder (overspend, ATK4), and

CA TTP M
Step 4: E y K TTP {x S TTP //z//(K x PG +R+I C +T C +T e )}, r ®M Step 5: E y K M {s 2 ®M } Step 6: r ®M , s 1 ®M , E y K M {s 2 ®M }, OI, H(PI) Step  -whether it is possible for the merchant to pass a wrong price to the P G (overpayment, ATK5).
1.In this protocol, the dispatched agent CA does not have any task for encryption, decryption or signing.So it is not necessary for it to carry any key.Therefore, the agent in the transaction is more of a messenger.Most of the encryption and signing works are done by TTP.What the agent should do is to communicate with different participants sending relevant messages to them.2. CA carries one shared half signature -s 1 →M .But it is generated by cardholder C and the shared secret key x S C 1 is kept by C. No irrelevant party could obtain both of the two shared signatures (i.e.s 1 →M and s 2 →M ) together with some arguments (i.e.r and z); so it is not possible for any party to obtain two shared secret keys so as to generate the secret signature key of the cardholder (i.e.x S C ).For instance, for the merchant, it can obtain the r →M , s 1 →M , s 2 →M , c →P G and H(P I), but cannot obtain P I. Argument z is also protected against the merchant.So it is not possible for M to obtain x S C (ATK1) (see Fig. 4).Likewise, TTP knows is not passed to TTP.As s 1 →M is not passed to TTP, TTP cannot generate x S C 1 so as to re-generate x S C .In the proposed protocol, the cardholder's secret signature key can be re-generated only if M and TTP collude.But it is impossible regarding the nature of TTP.

||Amount}, P G can decrypt it and obtain
K →P G .Thus P G can decrypt E →P G (P I) and obtain the payment instruction P I. M knows The property of non-repudiation has been improved.In terms of non-repudiation, timestamps are important in many electronic transactions indicating the time when a particular event or action has taken place [27].T e makes each purchase request from C unique preventing the re-payment attack.In addition, more timestamps are added in different stages, such as T C , T T T P , T 1 M and T 2 M .In the message from TTP to CA (in Step 5) and the message from M to CA (in Step 9), signatures are added including timestamps.These signatures adopt nested structure that can show message exchange processes among CA, TTP and M .These signatures prevent the replay attack (double payment) (ATK3).Meanwhile the generation of signatures will not significantly increase the burden of the agent to migrate back to the cardholder since the signatures are generated on the hash value, which has a fixed length. 5.In the proposed protocol, Amount, the amount of the transaction that will be charged to the cardholder's account is first passed to the TTP by CA, which checks it with the limit of current transaction (i.e.PriceLimit) (ATK4).Moreover, the amount is included in the ciphertext by the TTP that will be passed to the P G where the comparison will be conducted with the price (i.e. Price) from M .This can prevent the overspending and overpayment attacks (ATK5).

SET/A
SET/A protocol [16] is proposed to make SET adaptable to the mobile computing environments.Based on the principles used in purchase phase of SET, SET/A improves its performance only by adding a mobile agent for the cardholder to fulfill payment transaction 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 the mobile agent of SET/A replaces the cardholder of SET in the purchase phase.
For the protocol to be secure, aspects, such as, where the agent should execute securely, how to decrypt the encrypted information on OI and P I (i.e.E K ?{OI P I data} in Step 1) and where to generate the symmetric key to encrypt the P I (Step 4), are critical to a secure protocol.SET/A suggests running the agent in a tamper-proof environment [23] or a secure coprocessor [24] to protect the agent against malicious merchants.However, from the point of view the cardholder, it is insecure to expose some confidential information, such as the credit card information in the P I, to any merchant environment.
An alternative approach based on software using hidden computations [18] is also suggested in [16] without the cost of additional investment in hardware from each merchant.Another solution is given in [13], where an encrypted signature function is used so that a signature can be generated by the agent without the risk carrying and disclosing the secret signature key.But in this scheme, the function cannot be prevented from being abused and hence it is not secure and the non-repudiation property can hardly be ensured.If the cardholder gets P G's public key by sending a request to the merchant, the protocol is essentially the same as SET losing the autonomy and flexibility of mobile agents, which are the motivations of SET/A.

SET/A+
SET/A+ [25] is a more complex protocol, which adds a Trust Verification Center (T V C) in the payment system.The T V C keeps the sensitive information and charges cardholders or merchants by providing verification service.
The focus of SET/A+ is on how to pass securely the symmetric key K generated by the cardholder to P G so that P G can obtain P I that is encrypted by K (i.e.E K {P I}).
In SET/A+, T V C is not only used for verification but also used for encrypting information.However, the agents are limited in their functionalities.For example, an agent cannot sign dynamically and perform encryption for the owner during trading (since it requires the secret key of the owner).The agent carries the cardholder's signature -x S C (H(H(OI)||H(P I)))-generated in advance and passes it to the merchant to make a final deal.This is not flexible.In a malicious merchant environment, the signature can be abused easily and no sufficient non-repudiation mechanism is provided preventing the replay attack.This may cause the disputes between participants and result in the loss of the cardholder.

LITESET/A+
LITESET/A+ is based on Signcryption public-key algorithm [26] and Signature-Share scheme (called Signature-Threshold scheme in [14]).It employs a mobile agent and a Trusted Third Party (TTP).The role of TTP is the same as the T V C in SET/A+.The TTP can do both verification and encryption when necessary.
In this scheme, the most significant difference with SET/A+ is that it uses a Signature-Share scheme based on Shamir-threshold scheme [12,14].The signature secret key of cardholder-x S C -is divided into two shared parts, say x S A for agent and x S T T P for TTP.
x S A = x , x S T T P = x S C − x where x is a random number chosen from [1, . . ., q].By carrying x S A , the agent A can sign over the order information OI and the hash value of payment instruction P I, yielding x S A (H(H(OI)||H(P I))) Another shared signature x S T T P (H(H(OI)||H(P I))) can be generated by TTP after it obtains its shared signature secret key x S T T P .Once obtaining the two shared signatures, by applying Signature-Share scheme, the merchant can verify the dual hash value H(H(OI)||H(P I)) and hence check the validity of the order and the payment data.It is equivalent to obtaining the cardholder's signature x S C (H(H(OI)||H(P I))) as in SET/A+.But without the involvement of TTP, the merchant cannot obtain both shared signatures.
The aim of LITESET/A+ is to make the agent sign flexibly on behalf of the cardholder in cooperation with the TTP.This can be done after the process of negotiation with a set of merchants.So one consumer agent works well instead of dispatching a payment agent after the negotiation agent completes its tasks.By using Signature-Share scheme, the dispatched agent does not need to carry the cardholder's secret signature key.Instead, it carries its shared signature key x S A .
Thereafter the problem comes as the agent carries the shared secret key x S A and executes on a server provided by the chosen merchant where to make the final deal.For generating a shared signature s A on a hash value r, the agent should also carry r and argument z (q is public), so as to compute This means x S A , r and z will be exposed to the merchant.Once the merchant obtains the shared signatures s T T P from TTP (Step 8 in LITESET/A+), it can easily compute x S T T P because s T T P = z/(r + x S T T P ) mod q Hence the merchant can obtain the cardholder's signature secret key Moreover, the non-repudiation mechanism is weak in LITESET/A+.In addition to the obtained messages, a participant keeps I C or I M only as non-repudiation receipts.Though these identifiers are unique, no receipt can show when a transaction is completed.So I C and I M are not strictly non-repudiation receipts.This problem exists in SET/A and SET/A+ too.

LITESET/A++
LITESET/A++ [20] is based on Signcryption public-key algorithm [26], Signature-Share scheme and Signcryption-Share scheme (called Signature-Threshold scheme and Signcryption-Share scheme proposed in [14]).It solves the problem in LITESET/A+ that a shared secret key is carried by the dispatched agent.Instead, it is kept by the cardholder.LITESET/A++ keeps using Signature-Share scheme so that the dispatched agent has the capability to sign with the merchant chosen after dispatch in corporation with TTP.In addition, LITESET/A++ uses Signcryption-Share scheme to encrypt the payment instruction P I.In Signcryption-Share scheme, the secret signature key of sender A is shared by t parties.Each party generates the shared signature s i on hash value r obtained from A, and all the shared signatures are sent to recipient B with the ciphertext c.With c and all (r, s i ), B can decrypt c, obtain the plaintext m and verify the signature.
In LITESET/A++, P I is encrypted by a session public key.The session secret key is encrypted by the cardholder.In corporation with TTP, P G can obtain the two shared signatures, hash value and ciphertext and thus decrypt the ciphertext and obtain the session secret key, with which P G can obtain the P I.
In terms of security, LITESET/A++ is a good protocol.But it has a few problems.
1.As Signcryption-Share scheme is a public key algorithm, it is less efficient than a symmetric key algorithm; 2. No mechanism is devised for preventing double payment, overspending attack and over-payment attack.This problem exists in all the above protocols.

Comparison of protocols
In some sense, the agent in SET/A+ has the same flexibility since the agent carries the cardholder's signature x S C (H(H(OI)||H(P I))) signed on the order information and payment instruction.The signature can be passed to the merchant where the agent wants to make the deal.But the signature may be reused by any malicious merchant where a valid deal has been made.The merchant can mount a replay attack successfully by transferring the copy of a used digital envelope to the payment gateway causing the loss of the cardholder.This is because that its non-repudiation mechanism is weak.In addition, a visited merchant may abuse the pre-generated signature.
In the proposed protocol, the Signature-Share scheme avoids using a pre-generated signature.Meanwhile timestamps from different participants appear in the signatures of message senders.Also a unique expiry timestamp T e appears in the signature from the cardholder and it can be sent to each participant.Hence a replay attack can be detected easily.
As we analyzed in Section 4 and Section 5, both LITESET/A++ and the proposed protocol correct the security flaw in LITESET/A+ so that it is not possible for the merchant to re-generate the signature secret key of the cardholder.Meanwhile the flexibility for the agent to "sign" on behalf of the cardholder and make a deal with the merchant remains unchanged.Moreover, with the involvement of TTP, the agent in the proposed protocol need not to do any encryption and decryption.In contrast, in SET/A+ and LITESET/A+, the agent executes at the merchant's server and completes the encryption operations.
In the proposed protocol, similar to LITESET/A+, Signature-Share scheme is adopted to give the capability of the dispatched agent to sign contract dynamically with M in corporation with TTP.
The proposed protocol inherits good features of LITESET/A++ in terms of the properties listed in Tables 2 and 3 while the focus of LITESET/A++ is how to pass P I securely to P G which is determined afterwards by M according to the brand of the credit card.That means C doesn't know P G beforehand so as to encrypt P I using P G's public key.Regarding the protocol overhead, as analyzed in Section 5.1.4,based on Signcryption -a public key algorithm, the Signcryption-Share scheme is not as efficient as a symmetric key algorithm.In contrast, the proposed protocol adopts a symmetric key algorithm to encrypt PI.This inherits the efficiency property of SET and reduces the overhead at the side of the cardholder.In addition, the Signature-Share scheme is as efficient as a process of signature verification, which is carried out by the PG, not the agent.The proposed protocol needs to employ a TTP and thus leads to some communication with the TTP.But this is essential to an agent based payment protocol and it is the same as SET/A+, LITESET/A+ and LITESET/A++.The proposed protocol does not occur extra overhead than other protocols.
Furthermore LITESET/A++ has the drawback without any mechanism for preventing overspending and overpayment attacks.The problem also exists in other protocols.
In the proposed protocol, Amount, which is the transaction amount that will be charged to the cardholder's account, is first passed to TTP, who checks it with PriceLimit preventing overspending.Meanwhile, Amount is included in the ciphertext generated by the TTP, which is passed to the P G where Amount and Price from M are compared.This prevents the overpayment attack.
Security properties of different protocols are compared in Table 4.

Conclusions
In a mobile computing environment the cardholder's role can be played by an agent, which is dispatched to the merchant's server with the relevant information to perform the necessary operations.Since the cardholder does not need to keep the network connection while the transaction is being completed, this solution contributes to lower cost, higher robustness and autonomy while the requirements for security become more critical.In this paper, we proposed an agent-assisted secure payment protocol adopting Signature-Share scheme and employing a Trusted Third Party (TTP).The dispatched agent can dynamically choose the merchant and sign on behalf of the cardholder in cooperation with the TTP without the possibility of disclosing any secret to the merchant and TTP.In the proposed protocol, the principle that each participant knows what is strictly necessary for his/her role is followed as in SET while the efficiency is improved.In addition, mechanisms have been devised for preventing and detecting double payment, overspending and overpayment attacks.
The proposed protocol can be applied to e-commerce environments, where an agent is employed to collect offers, negotiate with merchants, place an order, and make the payment.For instance, the cardholder/customer using a laptop or PDA with wireless network interface and Internet access can apply this protocol for transactions.This can help reduce the complexity of operations at the side of the cardholder.In addition, the long-term network connection constraint for interactions will not apply.With the development of wireless communication and agent technology, we envisage that the above scenario is becoming applicable in practice.Thus, we expect the proposed protocol can be integrated with an agent-based e-commerce system [21] to enhance the autonomy of transactions and bring more convenience to customers.
and verify signature H(v, H(P I)||H(OI)||H(C S (C)||I C ||T C ||T e )) ?=r →M If it holds and the current time T < T e , M keeps T R M = {C S (C), r →M , s 1 →M , s 2 →M , OI, H(P I), I C , T C , T e } as a transaction record.

Table 1 Notions
K→PGthe session key used for encrypting P I that should be passed to P G.
depicts the purchase request phase of SET.

Table 2
Comparison of agent-based secure payment protocols (part I) The cardholder's secret signature key can be re-generated. 2No authorized party can obtain and re-generate the cardholder's secret signature key.

Table 3
Comparison of agent-based secure payment protocols (part II)

Table 4
Security properties of agent-based secure payment protocols