Skip to main content
SpringerLink
Log in

Design of electronic payment system based on authenticated key exchange

  • Published:
Electronic Commerce Research Aims and scope Submit manuscript

Abstract

This paper proposes an electronic payment system based on authenticated key exchange protocol. In this scheme, an effective owner tracing mechanism is introduced to identify a malicious customer. Moreover, every participant can mutually authenticate each other. The security of the scheme is mainly based on the hardness assumption of computational Diffie–Hellman and discrete logarithm problems. Furthermore, the security of our scheme is simulated in the automated validation of Internet security protocols and applications tool and proved that the scheme is secure against replay and man-in-the-middle attacks.

This is a preview of subscription content, log in via an institution to check access.

Access this article

Log in via an institution

Price excludes VAT (USA)
Tax calculation will be finalised during checkout.

Instant access to the full article PDF.

Institutional subscriptions

Fig. 1
Fig. 2
Fig. 3
Fig. 4
Fig. 5
Fig. 6
Fig. 7
Fig. 8

Similar content being viewed by others

Notes

  1. A protocol is said to be fair if it ensures that all the participants involved in communication do not gain a significant advantage over the other, even though the protocol is halted for any reason.

References

  1. Chaum, D. (1983). Blind signatures for untraceable payments. In Advances in cryptology (pp. 199–203). Boston: Springer.

  2. Doug Tygar, J. (1996). Atomicity in electronic commerce. In Proceedings of the fifteenth annual ACM symposium on principles of distributed computing (pp. 8–26). New York: ACM Press.

  3. Medvinsky, G, & Neuman, C. (1993). Netcash: A design for practical electronic currency on the internet. In Proceedings of the 1st ACM conference on computer and communications security (pp. 102–106). New York: ACM.

  4. Chaum, D., Fiat, A., & Naor, M. (1990). Untraceable electronic cash. In Proceedings on advances in cryptology (pp. 319–327). New York: Springer.

  5. Hirschfeld, R. (1992). Making electronic refunds safer. In Advances in cryptology–CRYPTO’92 (pp. 106–112). Berlin: Springer.

  6. Brands, S. (1993). Untraceable off-line cash in wallet with observers. In Advances in cryptology–CRYPTO’93 (pp. 302–318). Berlin: Springer.

  7. Brands, S. (1995). Restrictive binding of secret-key certificates. In Advances in cryptology–EUROCRYPT’95 (pp. 231–247). Berlin: Springer.

  8. Chan, A., Frankel, Y., MacKenzie, P., & Tsiounis, Y. (1996). Mis-representation of identities in e-cash schemes and how to prevent it. In Advances in cryptology–ASIACRYPT’96 (pp. 276–285). Berlin: Springer.

  9. Fujisaki, E., & Okamoto, T. (1996). Practical escrow cash systems. In Security protocols (pp. 33–48). Berlin: Springer.

  10. Okamoto, T. (2006). Efficient blind and partially blind signatures without random oracles. In Theory of cryptography (pp. 80–99). Berlin: Springer.

  11. Shi, L., Carbunar, B., & Sion, R. (2007). Conditional e-cash. In Financial cryptography and data security (pp. 15–28). Berlin: Springer.

  12. Blanton, M. (2008). Improved conditional e-payments. In Applied cryptography and network security (pp. 188–206). Berlin: Springer.

  13. Popescu, C. & Oros, H. (2007). An off-line electronic cash system based on bilinear pairings. In Systems, signals and image processing, 2007 and 6th EURASIP conference focused on speech and image processing, multimedia communications and services. 14th international workshop on (pp. 438–440). IEEE.

  14. Wang, S., Chen, Z., & Wang, X. A new certificateless electronic cash scheme with multiple banks based on group signatures. In Electronic commerce and security, 2008 international symposium on (pp. 362–366). IEEE.

  15. Chou, J.-S., Chen, Y., Cho, M.-H., & Sun, H.-M. (2009). A novel id-based electronic cash system from pairings. IACR Cryptology ePrint Archive, 2009, 339.

    Google Scholar 

  16. Chen, Y., Chou, J.-S., Sun, H.-M., & Cho, M.-H. (2011). A novel electronic cash system with trustee-based anonymity revocation from pairing. Electronic Commerce Research and Applications, 10(6), 673–682.

    Article  Google Scholar 

  17. Isaac, J. T., & Zeadally, S. (2012). An anonymous secure payment protocol in a payment gateway centric model. Procedia Computer Science, 10, 758–765.

    Article  Google Scholar 

  18. Yang, J.-H., & Lin, P.-Y. (2015). A mobile payment mechanism with anonymity for cloud computing. Journal of Systems and Software.

  19. Lin, P., Chen, H.-Y., Fang, Y., Jeng, J.-Y., & Lu, F.-S. (2008). A secure mobile electronic payment architecture platform for wireless mobile networks. Wireless Communications, IEEE Transactions on, 7(7), 2705–2713.

    Article  Google Scholar 

  20. Yang, J.-H., & Chang, C.-C. (2012). A low computational-cost electronic payment scheme for mobile commerce with large-scale mobile users. Wireless Personal Communications, 63(1), 83–99.

    Article  Google Scholar 

  21. Eslami, Z., & Talebi, M. (2011). A new untraceable off-line electronic cash system. Electronic Commerce Research and Applications, 10(1), 59–66.

    Article  Google Scholar 

  22. Li, Y.-F., & Chang, Y.-F. (2012). A security flaw of a bilinear-pairing-based electronic cash scheme with trustee-based anonymity revocation. In Genetic and evolutionary computing (ICGEC), 2012 sixth international conference on (pp. 71–74). IEEE.

  23. Chen, C.-L., & Liao, J.-J. (2011). A fair online payment system for digital content via subliminal channel. Electronic Commerce Research and Applications, 10(3), 279–287.

    Article  Google Scholar 

  24. Zhang, Y., Li, H., Li, X., & Zhu, H. (2013). Provably secure and subliminal-free variant of schnorr signature. In Information and communication technology-EurAsia conference (pp. 383–391). Berlin: Springer.

  25. Xiang, L., Xie, Y., Luo, G., & Wang, W. (2015). On the existence of subliminal channel in instant messaging systems. International Journal of Security and Its Applications, 9(3), 353–362.

    Article  Google Scholar 

  26. Yang, J.-H., Chang, Y.-F., & Chen, Y.-H. (2013). An efficient authenticated encryption scheme based on ecc and its application for electronic payment. Information Technology and Control, 42(4), 315–324.

    Article  Google Scholar 

  27. Ashraf Chaudhry, S., Sabzinejad Farash, M., Naqvi, H., & Sher, M. (2015). A secure and efficient authenticated encryption for electronic payment systems using elliptic curve cryptography. Electronic Commerce Research, 1–27.

  28. Discrete logarithm problem. http://www.doc.ic.ac.uk/~mrh/330tutor/ch06s02.html.

  29. Van Tilborg, H. C. A., & Jajodia, S. (2014). Encyclopedia of cryptography and security. Heidelberg: Springer.

    Google Scholar 

  30. Bakhtiari, S., Safavi-Naini, R., & Pieprzyk, J., et al. Cryptographic hash functions: A survey.

  31. Tokenization product security guidelines. (2015). www.pcisecuritystandards.org/documents/Tokenization_Product_Security_Guidelines.

  32. Otway, D., & Rees, O. (1987). Efficient and timely mutual authentication. ACM SIGOPS Operating Systems Review, 21(1), 8–10.

    Article  Google Scholar 

  33. Sun, H.-M., & Hsieh, B.-T. (2003). Security analysis of shim’s authenticated key agreement protocols from pairings. IACR Cryptology ePrint Archive, 2003, 113.

    Google Scholar 

  34. Viganò, L. (2006). Automated security protocol analysis with the avispa tool. Electronic Notes in Theoretical Computer Science, 155, 61–86.

    Article  Google Scholar 

  35. Avispa web tool: Automated validation of internet security protocols and applications. (2015).

  36. Hlpsl tutorial. (2006). http://www.avispa-project.org/package/tutorial.

  37. Dolev, D., & Yao, A. C. (1983). On the security of public key protocols. IEEE Transactions on Information Theory, 29(2), 198–208.

    Article  Google Scholar 

Download references

Author information

Authors and Affiliations

  1. Department of Computer Science and Engineering, National Institute of Technology Rourkela, Rourkela, Odisha, India

    Susmita Mandal, Sujata Mohanty & Banshidhar Majhi

Authors
  1. Susmita Mandal
    View author publications

    You can also search for this author in PubMed Google Scholar

  2. Sujata Mohanty
    View author publications

    You can also search for this author in PubMed Google Scholar

  3. Banshidhar Majhi
    View author publications

    You can also search for this author in PubMed Google Scholar

Corresponding author

Correspondence to Susmita Mandal.

Appendices

Appendices

Appendix A In this appendix, we discussed the HLPSL verification code using AVISPA toolkit for the proposed electronic payment scheme. The HLPSL specifications are currently outlined or standardized by organizations like the IETF. The role specification of customer, bank and merchant is represented using given codes as follows.

1.1 Role specification of customer

role client(C,B,M:agent,

SKc,Key,Kcb,SKcm,Kcm,Km,SKm:symmetric_key,

Mul,Sub,H:hash_func,

Pubc,Mpk,Pubm:public_key,

Snd,Rcv:channel(dy))

played_by C

def=

local State:nat,

Xc,G,IDc,IDb,Msk,Nb,IMEI,W,V,Dc,Kc,K1,N,Ts,Vc,Rvc,Rwc,Rc,E,R,M1,M2,M3,Z,Alpha,CNO,C1,TDc,Amt,A,U,S,K2,K3,K,Y,D,K4,K5,R1,Invno,Proddet,Nm,IDm,Nc,Reqconf,Ecash,Beta,Tnew,Q,Xm,V1,Vm, Vz,K6,K7,F1,Gamma,Succ,Bill,Phoneno,Accno,L,Dm :text

const client_xc,bank_msk, merchant_xm,subs1,subs2,subs3,subs4,subs5,subs6,subs7,subs8:protocol_id

init State := 0

transition

1. State =0 /\(\backslash \)Rcv(start)\(=|>\)

State’:=1/\(\backslash \)IMEI’:=new()

/\(\backslash \)IDc’:=xor(H(IMEI),Phoneno)

/\(\backslash \)Xc’:=new()

/\(\backslash \)Pubc’:=exp(G,Xc)

/\(\backslash \)Snd(IDc.Pubc)

/\(\backslash \)secret(Xc,subs1,C,B)

/\(\backslash \)secret(Xc,subs2,C,M)

2. State=1/\(\backslash \)Rcv(IDb.Mpk.Nb)\(=|>\)

State’:=2/\(\backslash \)W’:=xor(H(IMEI),Accno)

/\(\backslash \)V’:=H(Xc.IDc)

/\(\backslash \)Dc’:=xor(H(Xc.IDc),H(IMEI))

/\(\backslash \)Kc’:=H(IMEI.Pubc.Xc)

/\(\backslash \)Snd(IDc.IDb.Dc.K1.W.Nb)

/\(\backslash \)secret(IMEI,subs3,C,B)

3. State=2/\(\backslash \)Rcv(IDc.TDc_Key)\(=|>\)

State’:=3/\(\backslash \)SKc’:=exp(Mpk,Xc)

/\(\backslash \)Key’:=H(SKc’.Dc.Kc)

/\(\backslash \)N’:=new()

/\(\backslash \)U’:=new()

/\(\backslash \)Ts’:=new()

/\(\backslash \)Vc’:=H(W.Xc.V)

/\(\backslash \)E’:=H(Vc.N)

/\(\backslash \)A’:=exp(G,U)

/\(\backslash \)Rwc’:=H(N.H(Amt).SKc)

/\(\backslash \)Rvc’:=xor(A,Rwc)

/\(\backslash \)K1’:=exp(G,Mul(E,Xc))

/\(\backslash \)K2’:=Sub(Mul(E,Xc),Mul(U,Rwc))

/\(\backslash \)Z’:=xor(H(K1.K3),H(U))

/\(\backslash \)Alpha’:=H(K1.Rwc.Kcb)

/\(\backslash \)Kcb’:=H(K2.Ts.Mpk)

/\(\backslash \)Snd(Dc.H(Amt).A.K2.Rvc.Alpha.Ts_Key.Amt.TDc.Z_Kcb)

/\(\backslash \)secret(Vc,subs4,C,B)

4. State=3/\(\backslash \)Rcv(IDb.M1.M3.H(CNO).CNO.TDc.K3_Kcb)\(=|>\)

State’:=4/\(\backslash \)L’:=xor(Z,M1)

/\(\backslash \)M2’:=Mul(exp(G,K3),exp(Pubc,M1))

/\(\backslash \)Nc’:=new()

/\(\backslash \)Snd(Dc.Pubc.Nc.Pubc.Dc.Invno.Proddet_H(Dc.Pubc.Nc))

5. State=4/\(\backslash \)Rcv(IDm.Pubm.Nm.Pubm.IDm.Reqconf_H(IDm.Pubm.Nm))\(=|>\)

State’:=5/\(\backslash \)K’:=new()

/\(\backslash \)Tnew’:=new()

/\(\backslash \)Y’:=exp(G,K)

/\(\backslash \)Ecash’:=H(CNO.L.M2.Nm.Nc.Tnew)

/\(\backslash \)D’:=H(Vc.K)

/\(\backslash \)K4’:=exp(G,Mul(D.Xc))

/\(\backslash \)K5’:=Sub(Mul(D,Xc),Mul(R1,Tnew,K))

/\(\backslash \)R1’:=H(Dc.Invno.H(CNO))

/\(\backslash \)SKcm’:=exp(Pubm,Xc)

/\(\backslash \)Kcm’:=H(SKcm.IDm.IDc.Nc.Nm)

/\(\backslash \)Beta’:=H(K4.Kcm.R1)

/\(\backslash \)Snd(IDc.IDm.Tnew.CNO.K5.R1.Y.Ecash.H(CNO).Beta.Ecash.TDc.Nm.Tnew_Kcb_K4_Kcm)

6. State =5/\(\backslash \)Rcv(Succ.Bill.Invno_Kcm)\(=|>\)

State’:=6/\(\backslash \)request(C,M,client_xc,Xc’)

end role

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

1.2 Role specification of bank

role bank(C,B,M:agent,

SKc,Key,Kcb,SKcm,Kcm,Km,SKm:symmetric_key,

Mul,Sub,H:hash_func,

Pubc,Mpk,Pubm:public_key,

Snd,Rcv:channel(dy))

played_by B

def=

local State:nat,

Xc,G,IDc,IDb,Msk,Nb,IMEI,W,V,Dc,Kc,K1,N,Ts,Vc,Rvc,Rwc,Rc,E,R,M1,M2,M3,Z,Alpha,CNO,C1,TDc,Amt,A,U,S,K2,K3,K,Y,D,K4,K5,R1,Invno,Proddet,Nm,IDm,Nc,Reqconf,Ecash,Beta,Tnew,Q,Xm,V1,Vm,Vz,K6,K7,F1,Gamma,Succ,Bill,Phoneno,Accno,L,Dm :text

const client_xc,bank_msk, merchant_xm,subs1,subs2,subs3,subs4,subs5,subs6,subs7,subs8:protocol_id

init State := 0

transition

1. State =0 /\(\backslash \)Rcv(IDc,Pubc)\(=|>\) State’:=1/\(\backslash \)IDb’:=new()

/\(\backslash \)Msk’:=new()

/\(\backslash \)Nb’:=new()

/\(\backslash \)Mpk’:=exp(G,Msk)

/\(\backslash \)Snd(IDb.Mpk.Nb)

/\(\backslash \)secret(Msk,subs3,B,C)

/\(\backslash \)secret(Msk,subs4,B,M)

2. State=1 /\(\backslash \)Rcv(IDc.IDb.Dc.Kc.W.Nb)\(=|>\)

State’:=2/\(\backslash \)TDc’:=xor(IDc,xor(Accno,H(Msk)))

/\(\backslash \)SKc’:=exp(Pubc,Msk)

/\(\backslash \)Key’:=H(SKc.Dc.Kc)

/\(\backslash \)Snd(IDc.TDc_Kc)

3. State=2/\(\backslash \)Rcv(Dc.H(Amt).A.K2.Rvc.Ts_Key.Amt.TDc.Z_Kcb)\(=|>\)

State’:=3/\(\backslash \)Rwc’:=xor(Rvc,A)

/\(\backslash \)K1’:=Mul(exp(G,K3),exp(A,Rwc’))

/\(\backslash \)Kcb’:=H(K1’.Mpk.Ts)

/\(\backslash \)Alpha’:=H(K1’.Rwc’.Kcb’)

/\(\backslash \)R’:=new()

/\(\backslash \)CNO’:=new()

/\(\backslash \)L’:=H(R)

/\(\backslash \)M1’:=xor(Z,L’)

/\(\backslash \)M2’:=exp(G,Mul(R,H(CNO)))

/\(\backslash \)K3’:=Sub(Mul(R,H(CNO)),Mul(M1,Msk))

/\(\backslash \)M3’:=xor(H(Kc.K2),M2)

/\(\backslash \)Snd(IDb.M1.M3.H(CNO).CNO.TDc.K3_Kcb)

4. State=3/\(\backslash \)Rcv(IDm.IDc.Pubm.H(Q).H(CNO).Gamma.Vz.K7.Nm.Ecash.TDc.Nc.Tnew_Kcb_Km)\(=|>\)

State’:=4/\(\backslash \) F1’:=H(CNO.H(Q))

/\(\backslash \)SKm’:=exp(Pubm,Msk)

/\(\backslash \)Km’:=(SKm’.F1’.IDm)

/\(\backslash \)Vm’:=xor(Vz,F1’)

/\(\backslash \)K6’:=Mul(exp(G,K7),exp(Pubm,Vm))

/\(\backslash \)Gamma:=H(K6’.Vm’.IDm.IDc.IDb)

/\(\backslash \)Succ’:=new()

/\(\backslash \)Bill’:=new()

/\(\backslash \)Snd(Succ.Bill.IDb_Km)

end role

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

1.3 Role specification of merchant

role merchant(C,B,M:agent,

SKc,Key,Kcb,SKcm,Kcm,Km,SKm:symmetric_key,

Mul,Sub,H:hash_func,

Pubc,Mpk,Pubm:public_key,

Snd,Rcv:channel(dy))

played_by M

def=

local State:nat,

Xc,G,IDc,IDb,Msk,Nb,IMEI,W,V,Dc,Kc,K1,N,Ts,Vc,Rvc,Rwc,Rc,E,R,M1,M2,M3,Z,Alpha,CNO,C1,TDc,Amt,A,U,S,K2,K3,K,Y,D,K4,K5,R1,Invno,Proddet,Nm,IDm,Nc,Reqconf,Ecash,Beta,Tnew,Q,Xm,V1,Vm,Vz,K6,K7,F1,Gamma,Succ,Bill,Phoneno,Accno,L,Dm :text

const client_xc,bank_msk, merchant_xm,subs1,subs2,subs3,subs4,subs5,subs6,subs7,subs8:protocol_id

init State := 0

transition

1.State =0 /\(\backslash \)Rcv(Dc.Pubc.Nc.Pubc.Dc.Invno.Proddet_H(Dc.Pubc.Nc))\(=|>\)

State’:=1/\(\backslash \)Xm’:=new()

/\(\backslash \)Pubm’:=exp(G,Xm)

/\(\backslash \)IDm’:=xor(H(IMEI),Phoneno)

/\(\backslash \)Nm’:=new()

/\(\backslash \)Snd(IDm.Pubm.Nm.Pubm.IDm.Reqconf_H(IDm.Pubm.Nm))

/\(\backslash \)secret(Xm,subs5,M,C)

/\(\backslash \)secret(Xm,subs6,M,B)

2. State =1/\(\backslash \)Rcv(IDc.IDm.Tnew.CNO.K5.R1.Y.Ecash.H(CNO).Beta.Ecash.TDc_Kcb_K4_Kcm)\(=|>\)

State’:=2/\(\backslash \)SKcm’:=exp(Pubc,Xm)

/\(\backslash \)Kcm’:=H(SKcm.IDm.Dc.Nc.Nm)

/\(\backslash \)K4’:=Mul(exp(G,K5),exp(Y,Mul(R1,Tnew)))

/\(\backslash \)Beta’:=HH(K4’.Kcm’.R1)

/\(\backslash \)Q’:=new()

/\(\backslash \)V1’:=H(IDm.Xm)

/\(\backslash \)Vm’:=H(V1.Q)

/\(\backslash \)F1’:=H(CNO.H(Q))

/\(\backslash \)Vz’:=xor(F1,Vm)

/\(\backslash \)K6’:=exp(G,Ecash)

/\(\backslash \)K7’:=Sub(Ecash,Mul(Vm,Xm))

/\(\backslash \)SKmb’:=exp(Mpk,Xm)

/\(\backslash \)Kmb’:=H(SKm.Dm.Km)

/\(\backslash \)Gamma’:=H(K6.Vm.IDm.IDc.IDb)

/\(\backslash \)Snd(IDm.IDc.Pubm.H(Q).H(CNO).Gamma.Vz.K7.Nm.Ecash.TDc.Nm.Tnew_Kcb_Km)

3. State=2/\(\backslash \)Rcv(Succ.Bill.IDb_Km)\(=|>\)

State’:=3/\(\backslash \)Snd(Succ.Bill.Invno_Kcm)

end role

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

Rights and permissions

Reprints and permissions

About this article

Check for updates. Verify currency and authenticity via CrossMark

Cite this article

Mandal, S., Mohanty, S. & Majhi, B. Design of electronic payment system based on authenticated key exchange. Electron Commer Res 18, 359–388 (2018). https://doi.org/10.1007/s10660-016-9246-3

Download citation

  • Published:

  • Issue Date:

  • DOI: https://doi.org/10.1007/s10660-016-9246-3

Keywords

Search

Navigation