1 Introduction

With the development of network technologies, more and more traditional transactions are implemented on the Internet, which is so-called electronic commerce (e-commerce). In e-commerce, the electronic transaction (e-transaction) mechanism [1–4] is the most important tool because it can be applied to many applications, such as online shopping, online TV, and online music. On the other hand, cloud computing [5–7] is another popular network technology because it can store huge data for users in the remote server. That is, the cloud user does not need to speed lots of money to expand the storage space in their own devices. In addition, the user’s secret information can be protected in the cloud server. Due to the above reasons, many e-transaction mechanisms for cloud computing have been proposed [8, 9]. In recent years, more and more user utilizes the mobile device to accomplish all e-transactions on the Internet. Thus, the e-transaction mechanism for cloud computing become a popular research topic in e-commerce applications.

In 2013, Yang et al. [8] proposed an electronic payment system for cloud computing. There are five roles in their e-payment system: the client, the shop, the bank, the cloud registration center (CRC), and the trusted authority (TA). They designed the e-payment system in the secure cloud area, which contains the personal cloud and the public cloud. The personal cloud stores the user’s registration and payment information, and the public cloud stores the shop’s and the bank’s transaction information. Before the e-transaction begins, the client, the shop, and the bank have to register to TA to get their certificates. Then, the transaction participants can use the certificates to prove their identities in the cloud environments. Because all transactions are performed in the secure cloud area, the user’s payment and purchasing information can be well-protected in their e-payment system.

However, we find that Yang et al.’s e-payment system has some drawbacks. First, their system uses the certificate to authenticate each participant. This causes additional computation costs for each participant in their system. Second, each participant has to share a symmetric key with the other participant for authentication and encryption. If the client wants to purchase from several shops, then the client has to maintain many symmetric keys for different shops. This causes the key management problem for client. Third, their system still has large computation costs so it is not suitable for mobile users in the cloud environments.

To solve the above problems, we propose a new e-transaction mechanism using mobile devices for cloud computing in this paper. The proposed mechanism does not require any certificate for authentication. In addition, the user only needs to keep one secret value to transact with different venders. Besides, the proposed mechanism uses the one-way hash function [10, 11] and exclusive-or operation to design so the computation costs can be greatly reduced. According to the above advantages, the proposed e-transaction mechanism satisfies the security requirements of integrity, authentication, and non-repudiation. Compared with the related works, the proposed mechanism are more efficient and securer. Therefore, it is very suitable for the e-transaction using mobile devices in cloud computing.

2 Review of Yang et al.’s Mechanism

In this section, we review Yang et al.’s e-payment system. Their system has five participants: the client, the shop, the bank, the cloud registration center (CRC), and the trusted authority (TA). Besides, their system is divided into five phases: the registration phase, login phase, certificate issuing phase, withdrawing phase, and payment phase. The notations used in their system are shown in Table 1. Note that all the transaction steps are performed in the cloud. Then, the steps of the five phases in Yang et al.’s e-payment system are shown as follows.

Table 1 The notations of Yang et al.’s system
Full size table

Registration phase

Step 1.:

The client computes H 3 (PW) and sends (ID C , H 3 (PW)) to CRC

Step 2.:

CRC checks ID C and stores (ID C , H 3 (PW)) in its database

Login phase

Step 1.:

The client chooses a random number r c in \({\text{Z}}_{q}^{ *}\) and computes M 1 = F P (ID C , r c ). Then, the client sends M 1 to the personal cloud for the user authentication

Step 2.:

The personal cloud decrypts F P (·) to get ID C and r c and uses ID C to obtain H 3(PW) from the cloud database. Then the personal cloud chooses a random number r s in \({\text{Z}}_{q}^{ *}\) and computes M 2 = E H3(PW )(r s ) and Mac 1 = H 4 (H 3 (PW), r c ). Finally, it sends Mac 1 and M 2 to the client

Step 3.:

The client computes H 4 (H 3 (PW), r c ) and checks if it is equal to Mac 1. If they are equal, then the client decrypts M 2 to get r s and computes Mac 2 = H 4 (H 3 (PW), r c , r s )). Then, the client computes M 3 = F P (Mac 2) and sends it to the personal cloud. Finally, the personal cloud can decrypt M 3 to get Mac 2, and then the personal cloud checks if H 4 (H 3 (PW), r c , r s ) is equal to Mac 2. If they are equal, then the client is a legal cloud user

Certificate issuing phase

Step 1.:

TA chooses the system parameters G 1, G 2, e, H 1(·), H 2(·), H 3(·), and H 4(·). Besides, TA also chooses a random number s in \({\text{Z}}_{q}^{ *}\) as its private key and computes P pub  = sP as its public key. Finally, TA publishes {G 1, G 2, q, P, P pub , e, H 1, H 2, H 3, E, D}

Step 2.:

The client sends the requirement message to TA to get his public key, private key the certificate. Then, TA computes Q C  = H 1(ID C ) and S C  = sQ C as the client’s public and private keys, respectively. Besides, TA chooses a random number y in \({\text{Z}}_{q}^{ *}\) and computes U C  = E s (ID C  ⊕ y) and V C  = s(H 1(U C ) + Q C ). Finally, TA stores (U C , y) in its database and sends (Q C , S C , U C , V C ) to the client in a secure channel

Step3.:

After receiving Q C , S C , U C , and V C , the client checks the validities of U C and V C . Note that the shop and the bank also use the above steps to get their certificates (U S , V S ) and (U B , V B )

Withdrawing phase

Step1.:

The bank service server chooses two random numbers r and k in \({\text{Z}}_{q}^{ *}\) to compute R = rP, Q C  = H 1(ID C ), kQ C , K BC  = H 2 (e(S B , kQ C )), and M 4 = E KBC (ID B , U B , V B , R). Then, the server sends M 4 and kQ B to the personal cloud

Step 2.:

The personal cloud computes K CB  = H 2(e(S C , kQ B )) to get (ID B , U B , V B , R) from M 4. Besides, the personal cloud computes Q B  = H 1 (ID B ) to verify the bank’s certificate (U B , V B ) by checking if e(V B , P) = e(H(U B ) + Q B , P pub ). If the equation holds, then the personal cloud chooses two random numbers a and b in \({\text{Z}}_{q}^{ *}\) to compute R′ = aR + bP, h = H 3(m, R), h = h′/a mod q, and M 5 = E KCB (ID C , ID B , h, U C , V C ). Then, the personal cloud sends M 5 to the bank service server

Step 3.:

The bank service server uses K BC to get (ID C , ID B , h, U C , V C ) from M 5 and checks if e(V C , P) = e(H 1(U C ) + Q C , P pub ). If the equation holds, then the bank server computes S = rQ B  + hS B and M 6 = E KBC (ID B , S) and sends M 6 to the personal cloud

Step 4.:

The personal cloud uses K CB to get (ID B , S) from M 6 and computes S′ = aS + bQ B . In addition, the personal cloud verify (R′, S′) by checking if e(S′, P) = e(Q B , h′Ppub + R′). If the equation holds, then the personal cloud obtains a valid e-cash (m, R′, S′)

Payment phase

Step 1.:

The personal cloud chooses a random number t to compute tQ C and sends it to the shop service server

Step 2.:

The shop service server computes K SC  = H 2(e(S S , tQ C )) and M 7 = E KSC (ID S , U S , V S ). Then, the shop server sends M 7 to the personal cloud

Step 3.:

The personal cloud computes K CS  = H 2(e(S C , tQ S )) and Q S  = H 1(ID S ) to verify (U S , V S ) by checking if e(V S , P) = e(H 1(U S ) + Q S , P pub ). If the equation holds, then the personal cloud computes M 8 = E KCS ((m, R′, S′), U C , V C ) and sends it to the shop service server

Step 4.:

The shop service server uses K SC to get ((m, R′, S′), U C , V C ) from M 8 and checks if e(V C , P) = e(H 1(U C ) + Q C , P pub ). If the equation holds, then the shop server computes Q B  = H 1(ID B ) and h′ = H 3(m, R′). To verify the validity of the e-cash, the shop server checks if e(S′, P) = e(Q B , h′P pub  + R′). If the above equation holds, then the shop server ensures the payment is valid and successful

According to the above steps, we find that Yang et al.’s system uses the certificate to authenticate each participant. This causes large computation costs for each participant in the system. In addition, each participant in their system has to share a symmetric key with the others for authentication and encryption. This causes the key management problem for users. Besides, their system has large computation costs so it is not suitable for mobile user in cloud environments. To solve the above problems, we propose a new e-transaction mechanism in the next section.

3 The Proposed e-Transaction Mechanism

The proposed e-transaction mechanism has four participants: the trust authority (TA), the client, the vender, and the bank. Note that the client, the vender, and the bank have to register to TA before the transaction starts (Fig. 1). The operation flow of the proposed mechanism is shown in Fig. 2. The notations used in the proposed mechanism are listed in Table 2.

Fig. 1
figure 1

The operation flow of Yang et al.’s e-payment system

Full size image
Fig. 2
figure 2

The operation flow of the proposed e-transaction mechanism

Full size image
Table 2 The notations of the proposed mechanism
Full size table

Registration phase

Step 1.:

The client sends ID C , PW C , and the registration request to TA. Then, TA computes NID C  = h(ID C ∥ x) and A = h(NID C ∥ PW C ) and stores ID C , PW C , and NID C in its database. Finally, TA sends NID C and A to the personal cloud

Step 2.:

TA computes P = h(h (NID C ∥ PW C ) ∥ ID B ) and sends P and NID C to the bank service server

Step 3.:

TA computes Q = h(h (NID C ∥ PW C ) ∥ ID V ) and sends Q and NID C to the vender service server

The steps of the registration phase are illustrated in Fig. 3.

Fig. 3
figure 3

Registration phase of the proposed mechanism

Full size image

Withdrawing phase

Step 1.:

The personal cloud chooses a random number y to compute D = h(P ∥ TS C )⊕y and G = h(y⊕TS C ) and sends {NID C , D, G, TS C } to the bank service server

Step 2.:

The bank service server checks the validity of the timestamp TS C . If TS C is valid, then the server computes y′ = h(P ∥ TS C )⊕D and G′ = h(y′⊕TS C ). The bank server also checks if G = G′ for the authentication. If the equation holds, then the bank server ensures the personal cloud is valid. Thus, the bank server computes CB = h(y′ ∥ G′ ∥ TS B ∥ TS C ) and BC = h(CB ∥ TS B ) and sends (BC, TS B ) to the personal cloud

Step 3.:

The personal cloud checks the validity of the timestamp TS B . If it is valid, the personal cloud computes CB′ = h(y ∥ G ∥ TS B ∥ TS C ) and BC′ = h(CB′ ∥ TS B) . The personal cloud also checks if BC′ = BC for the authentication. If the equation holds, then the personal cloud ensures the bank is valid. Then, the personal cloud performs any elliptic curve blind signature scheme (such as [11]) to create a blind message M for the e-cash information m. Finally, the personal cloud sends M to the bank

Step 4.:

The bank service server generates the blind signature S for M and sends S to the personal cloud

Step 5.:

The personal cloud computes the signature s from the blind signature S to get the signed e-cash

Payment phase

Step 1.:

The personal cloud computes H = h(Q ∥ TS C ∥ a)⊕goods and F = h(goods⊕TS C ) and sends {NID C , H, F, a, TS C } to the vender service server

Step 2.:

The vender service server checks the timestamp TS C . If it is valid, then the vender server computes goods′ = h(Q ∥ TS C ∥ a)⊕H and F′ = h(goods′⊕TS C ) and checks if F = F′. If the equation holds, then the vender server computes CV = h(goods′ ∥ F′ ∥ TS V ∥ TS C ) and VC = h(CV ∥ TS V ) and sends (VC, TS V ) to the personal cloud

Step 3.:

The personal cloud checks TS V . If it is valid, then the personal cloud computes CV′ = h(goods ∥ F ∥ TS V ∥TS C ) and VC′ = h(CV′∥ TS V ). Besides, the personal cloud checks if VC′ = VC. If the equation holds, then the personal cloud ensures the vender is valid and sends (m, s) to the vender service server

Step 4.:

Finally, the vender service server verifies (m, s) using the bank’s public key. In addition, the vender server sends (m, s) to the bank service server for checking the amount of the payment and the double spending. If the bank server responds a legal payment message to the vender server, then the vender sends the goods to the client

Unlike Yang et al.’s scheme [9], the proposed mechanism does not need the certificate for each participant’s authentication. Thus, the computation cost can be reduced. In addition, each participant does not share the symmetric keys with other participant so the key management problem can be solved. Besides, the proposed mechanism uses the one-way hash functions and XOR operations so the computation cost is very low. On the other hand, any digital signature scheme can be easily applied to the proposed mechanism. This increases the flexibility of the proposed mechanism to implement the e-transaction in cloud computing environments. According to the above reasons, the proposed mechanism is efficient and flexible for the e-transaction using mobile devices in cloud computing (Figs. 4, 5).

Fig. 4
figure 4

Withdrawing phase of the proposed mechanism

Full size image
Fig. 5
figure 5

Payment phase of the proposed mechanism

Full size image

4 Discussion

In this section, we present the security and performance analyses to show that the proposed mechanism is secure and efficient. The analyses are shown as follows.

4.1 Security Analyses

We utilize some typical attacks on the proposed mechanism to analyze its security and show that the proposed mechanism is secure as follows.

4.1.1 Impersonating Attack

Assume that an attacker impersonates the personal cloud to withdraw the e-cash from the bank service server. Then, the attacker randomly generate A″ and y″ to compute P″ = h(A″ ∥ ID B ), D″ = h(P″ ∥ TS C )⊕y″ and G″ = h(y″⊕TS C ), and he sends {NID C , D″, G″, TS C } to the bank service server. However, the attacker cannot be authenticated by the bank server because of the following reason: After receiving the messages from the attacker, the bank server computes y′ = h(P ∥ TS C )⊕D″ and G′ = h(y′⊕TS C ) and checks if G′ is equal to G″. Nevertheless, G′ is not equal to G″ because of P″ ≠ P and y″ ≠ y′. Thus, we have G″ = h(y″⊕TS C ) ≠ G′ = h(y′⊕TS C ). According to the above analysis, the proposed mechanism can prevent the impersonating attack since the attacker does not know the authentication information A = h(NID C ∥ PW C ).

4.1.2 Server Spoofing Attack

Assume that an attacker wants to pretend that he is a bank server, and then he generates the forged messages: CB″ = h(y″ ∥ G″ ∥ TS B ∥ TS C ) and BC″ = h(CB″ ∥ TS B ) and sends (BC″, TS B ) to the personal cloud. However, this attack cannot succeed because of the following reason: After receiving (BC″, TS B ), the personal cloud computes CB′ = h(y ∥ G ∥ TS B ∥ TS C ) and BC′ = h(CB′ ∥ TS B) and checks if BC′ = BC″ for the authentication. Nevertheless, the personal cloud will find that BC′ ≠ BC″ because BC′ = h(CB′ ∥ TS B)  ≠ BC″ = h(CB″ ∥ TS B ). Therefore, the person cloud will know these messages are sent by the attacker. That is, the server spoofing attack is infeasible for the proposed mechanism.

4.1.3 Insider Attack

Assume that a malicious client tries to obtain TA’s secret key x, then he may computes x from his NID C  = h(ID C ⊕x). However, computing x from NID C  = h(ID C ⊕x) is impossible because x is protected by a one-way hash function. Similarly, the bank server cannot obtain the user authentication information A = h(NID C ∥ PW C ) from P = h(h (NID C ∥ PW C ) ∥ ID B ). This is because that A is also protected by the one-way hash function. Therefore, the insider attack is impossible for the proposed mechanism.

4.1.4 Outsider Attack

Assume that an attacker wants to obtain the secret value P, then he intercepts D = h(P ∥ TS C ) from the communications between the personal cloud and the vender service server in the withdrawing phase. Then, the attacker tries to obtain P from D = h(P ∥ TS C )⊕y. However, it is impossible because the attacker does not know the random number y. In addition, P is also protected by the one-way hash function. According to the above reason, the outsider attack is infeasible for the proposed mechanism.

4.1.5 Replay Attack

Assume that an attacker wants to impersonate a client, then he intercepts {NID C , H, F, a, TS C } from the communications between the personal cloud and the vender service server. Thus, the attacker generates a fake timestamp TS C ′ and re-sends {NID C , H, F, a, TS C ′} to the vender to impersonate a legal client. However, this attack is impossible because F = h(goods⊕TS C ) contains the real timestamp TS C . The vender server will find that TS C ′ is not the same with TS C . That is, the proposed mechanism can prevent from the replay attack.

4.1.6 Anonymity

The client uses an anonymous identity NID C to perform the transaction with the vender in the proposed mechanism. Thus, the vender does not know who the client is. That is, the client’s privacy can be protected. If the disputation occurs, then the vender can send NID C to TA for the judgment. TA can trace the real identity of the malicious client in its database. Therefore, the proposed mechanism can provide the anonymity for the user to protect the buying privacy in the e-transaction.

4.2 Performance Analyses

In the subsection, we present the performance analyses of the proposed mechanism and the related works [9, 12]. Table 3 illustrates the computation costs of the proposed mechanism and the related works as follows.

Table 3 The computation costs of the related works
Full size table

In Table 3, BP, PM, SY, HA, and XR are bilinear pairing of ECC, point multiplication of ECC, symmetric en/decryption, one-way hash function, and exclusive or computations, respectively. According to [10], the magnitude comparison of the above computation costs can be denoted as BP > PM > SY > HA > XR in practice. Table 3 shows that the computation cost of the proposed scheme is much less than those of the related works [9, 12]. Therefore, the proposed mechanism is more efficient than the related works.

5 Conclusions

In this paper, we propose an e-transaction mechanism using mobile devices for cloud computing. The proposed mechanism has low computation and communication costs because it uses lightweight operations and less pre-shared keys to design. In addition, the client only needs to keep one secret value to transact with different venders so the key management problem can be solved. Moreover, the proposed mechanism provides the anonymity for clients to protect their buying privacy. According to the above reasons, the proposed mechanism is more efficient and suitable for the e-transactions using mobile devices in cloud computing.