Secure and Optimized Mobile Based Merchant Payment Protocol using Signcryption

2.1 Gaps Found in Related Work

• a)

  Protocols proposed (Téllez & Sierra, 2007c; Téllez et al., 2006a) employs symmetric-key operations and (Téllez & Sierra, 2007a, 2007b; Téllez et al., 2006b, 2008) employs Digital Signature with Message Recovery using Self-Certified public keys schemes based on RSA (which consumes more computational and communication cost compared with ECC).

• b)

  The no of Client interactions with other engaged parties are more.

• c)

  Protocols proposed (Téllez & Sierra, J. 2007a, 2007b, 2007c; Téllez et al., 2006a, 2006b, 2008) do not ensure forward secrecy and Public Verification.

• d)

  In Téllez and Sierra (2007a, 2007b, 2007c) and Téllez et al. (2006a, 2006b) protocols every Client C needs to register itself with merchant in merchant registration protocol thereby consuming lot of resources.

• e)

  Téllez and Sierra (2007c) and Téllez et al. (2006a) protocols does not ensure non repudiation.

• f)

  Téllez and Sierra (2007a, 2007b) and Téllez et al. (2006b) protocols cannot withstand Replay attack, Impersonation attack, and MITM attack. Téllez et al. (2008) protocol cannot withstand MITM attack.

• g)

  Merchant communicating Payment Gateway is not realistic in Téllez and Sierra (2007a, 2007b) and Téllez et al. (2006b, 2008)

• h)

  Security protocols are error prone and are not easy to identify errors and prove their correctness. Mobile Payment Protocols proposed by Tellez et.al. were not verified using Manual Formal verification methods (like BAN Logic, SVO Logic) or using Automated Formal verification Tools like AVISPA, Scyther and CryptoVerif.