1 Introduction

Vehicular Ad hoc NETworks (VANETs), in which vehicles constitute the mobile nodes in the network, aim to provide communications among nearby vehicles (also known as Inter-Vehicle Communication (IVC)) and nearby roadside base-stations (also referred to as Vehicle-to-Roadside Communication (VRC)). Moreover, VANETs are envisioned to play an important role in the enhancement of road safety and driving experiences by providing numerous promising services (such as collision avoidance, cooperative driving, traffic optimization, lane-changing assistance, Payment services, location-based services, and infotainment).

The application space for vehicle-to-vehicle and vehicle-to-roadside communications is vast and opens up tremendous business opportunities for mobile commerce, the automotive industry, and the research community. VANET applications can be broadly divided into two major categories [34, 36, 45, 51], namely, safety-related applications, and comfort-related applications. In recent years, the industry and academia have concentrated their research efforts primarily on safety-related applications because of its importance to the automotive domain. However, it is expected that research on comfort applications (that also offer great business opportunities) will continue to attract the attention of researchers and designers to develop non-safety VANET-based applications.

To enable Payments in VANET environments, we need to design Payment systems that satisfy the additional requirements associated with vehicular ad hoc networks. As mentioned previously, both vehicle-to-vehicle and vehicle-to-roadside communications open up new security challenges [32, 38] that must be considered by Payment system designers to achieve the same security capabilities independent of the scenario where Payments occur.

A real-world scenario where Payments can occur in a vehicle-to-roadside communication can be illustrated as follows: a Client is on the road and stops at a Parking facility where the vehicle is left for a while. If the Client wants to pay with a credit or debit-card and the Merchant (the entity that has products or services to offer or sell) is not able to communicate with the merchants financial institution (also known as the Acquirer) to process the Payment due to the absence of the necessary infrastructure, the Client should take an active role in the Payment process and acts as a proxy to allow the communication between the Merchant and the Acquirer. Note that this situation creates a potential security problem because the Merchant cannot send any kind of messages directly to the Acquirer and has to do it through the Client (who should not be able to change the content of the messages but must keep evidence of the Payment).

Symmetric and asymmetric signature methods have been widely used to provide party authentication in electronic Payment systems (including mobile commerce) [16]. However, for those portable devices (such as the ones typically attached to an On-Board Unit (called OBU) [9, 39]) available on the market and not based on the Texas Instruments TMS320C55x processor family (which delivers high performance, peripheral options, small packaging, and low power dissipation for the implementation of asymmetric operations in a efficient way) [17], traditional asymmetric signature schemes make the signature computations very expensive and not suitable for them [31]. Therefore, asymmetric authentication schemes are not suitable for scenarios where an engaging party has connectivity restrictions, and consequently, communication with other parties (such a Certification Authority for verifying a certificate) is not possible during such Payment transactions.

The Payment protocol we propose in this work is specific for a scenario where there is no direct communication between the Merchant and the acquirer. We exploit a symmetric-based signature scheme to satisfy the security requirements of the protocol proposed in this work. Symmetric cryptography (which employs a shared key between two parties) provides message confidentiality, message integrity, and provide the authentication of participants in, and provides an alternative in the construction of secure protocols for mobile Payment systems. Moreover, symmetric-key operations do not require high computational power nor do they require additional communication processing steps.

In this work, we designed and implemented a secure Payment protocol that allows the Merchant to send a message to the Acquirer through a Client (who will not be able to decrypt the message) for authentication purposes. The proposed protocol, called the Client Centric Model Payment protocol for VANETs (henceforth referred to as the CCMS-VAN Protocol), supports both credit-card and debit-card transactions, protects the real identity of the Client during the Payment and employs symmetric-key operations for all participants to reduce both, the setup cost for the Payment infrastructure and the transaction cost. Moreover, the CCMS-VAN protocol can be used by a portable device attached to an Application Unit (called AU Footnote 1).

A reason to have chosen mobile phone can be found in the following lines: A large percentage of vehicles on the road have to be equipped with a vehicle-to-vehicle or vehicle-to-roadside application before the application can be effective. Each year, only approximately 4–7% of the existing vehicles are replaced with new vehicles in the US. This means that it could take over 10 years to reach the critical mass when all new vehicles start to be equipped with the vehicle-to-roadside or vehicle-to-vehicle applications (a period longer than the time many people own or use a vehicle). Using mobile devices is an effective way to do vehicle-to-vehicle or vehicle-to-roadside since a large percentage of drivers are equipped with such types of devices.

The empirical performance of our proposed CCMS-VAN protocol is evaluated with actual mobile phones as the underlying implementation platform. By using these mobile phones, we demonstrate that our Client-side application can be installed on multiple heterogeneous Java™-enabled memory-constrained portable wireless handheld devices.

The rest of the paper is organized as follows. Section 2 presents related works relevant to this research. We present the contributions of this work in Sect. 3. In Sect. 4, we describe the design of the proposed Payment protocol for vehicle-to-roadside scenarios in VANETs. Section 5 presents the implementation of CCMS-VAN. We present performance evaluation results of our proposed Payment protocol in Sect. 6. Finally, we make some concluding remarks in Sect. 7. In Sect. 4, we describe the design of the proposed Payment protocol for vehicle-to-roadside scenarios in VANETs. Section 5 presents the implementation of CCMS-VAN. We present performance evaluation results of our proposed Payment protocol in Sect. 6. Finally, we make some concluding remarks in Sect. 7.

2 Related work

Several studies [8, 13, 14, 29, 30, 48] have been conducted in recent years to improve the security of mobile Payment systems. Many of these efforts have also been dedicated to unify concepts and scenarios into frameworks that would be useful in the design of new electronic Payment systems. Moreover, these studies have considered the following methods to provide authentication in electronic Payment systems (including Mobile commerce (M-commerce): username/password, symmetric, asymmetric and elliptic curve cryptography, smart card, 2d bar code, and biometric methods. There are many authentication mechanisms and protocols based on these methods [3, 4, 11, 12, 15, 25, 26, 33, 35, 40, 47] but some of them do not offer enough security for M-commerce whilst symmetric and asymmetric signatures have been widely used for authentication purposes.

The taxonomy presented in [10] discussed many proposed M-commerce usage scenarios. The following models with communication restrictions have been identified:

  • Kiosk-Centric (as shown in Fig. 1), where the Merchant acts as a proxy to allow the communication between the Client and the Issuer due to the communications restriction that prevent the direct communication between both entities.

    Fig. 1
    figure 1

    Scenario with Merchant acting as a proxy: the Kiosk Centric model

    Full size image

  • Client-Centric (as shown in Fig. 2), where the Merchant cannot communicate directly with the Acquirer. The Client acts as a proxy to allow the communication among the above entities.

    Fig. 2
    figure 2

    Scenario with Client acting as proxy: Client Centric model

    Full size image

  • Server-Centric (as shown in Fig. 3), where the Payment Gateway acts as an intermediary between the Client and the Merchant due to the absence of direct communication between the Client and the Merchant.

    Fig. 3
    figure 3

    Scenario with Payment Gateway as the intermediate between the Client and the Merchant

    Full size image

These scenarios with communication restrictions create new security and privacy challenges but offer great business opportunities for Comfort applications used in VANET.

The Full Connectivity scenario (as shown in Fig. 4) (where all the entities are directly connected one to another [10]) has been used for most of the protocols proposed in recent years. Most of them use asymmetric-key operations [5, 13, 14, 29, 48] whereas the remaining scenarios use symmetric-key operations which are more suitable for wireless networks. Unfortunately, many of these past proposed protocols cannot be used for scenarios with communication restrictions (as in the case for the Client Centric Model [10]) because they assume full connectivity to one another. It is therefore necessary to develop payment systems based on restricted connectivity scenarios along with additional goals such as enforcement of security and high performance levels that can be achieved in the case of full connectivity.

Fig. 4
figure 4

Full connectivity scenario

Full size image

The above scenarios use the following entities:

  • Client: a user who wants to purchase goods or services from the Merchant.

  • Merchant: an entity that has products or services to offer or sell. This entity could be a computational one (such as a normal web server, a roadside computing station or an intelligent vending machine) or a physical one (such as a gas station that makes it possible to pay from within an AU) which the user can connect to using a short range link (using wireless technologies such as Wi-fi [46] or Bluetooth).

  • Acquirer: is the Merchant’s financial institution.

  • Issuer: is the Client’s financial institution.

  • Payment Gateway: an additional entity that acts as in intermediate entity between the Acquirer and the Issuer on the bank’s private network side and the Client/Merchant at the Internet side [27].

3 Contributions of this work

Recently, [41–44, 49] have proposed various secure Payment protocols suitable for those scenarios with communication restrictions. However, most of them have been theoretical proposals which did not capture practical performance issues we encounter with the deployment of actual Payment systems. For instance, in [43] we presented a theoretical proposal that makes use of a Digital signature with message recovery using self-certified public keys. One exception to these previous works is the Payment protocol presented in [44] which was actually implemented but for a scenario where direct interaction between the Client and the Issuer is not allowed because of the communication restriction imposed by the model (i.e. the Kiosk Centric model). The proposed protocol uses Symmetric cryptography and it was implemented in Java and using a Nokia™ N95 mobile device devices at the Client side.

In contrast to our previous proposals, in this work we present the design and implementation of our proposed secure Payment protocol (CCMS-VAN) based on Client Centric model [10] (as shown in Fig. 1) for VANET situations where the Merchant cannot communicate directly with the Acquirer. We evaluate the performance of the proposed protocol with an actual experimental testbed consisting of wireless connections and mobile devices. Moreover, since the Client is a mobile device that acts as a proxy, the implementation allows us to determine the additional computation cost when a Client is used as a proxy.

4 Proposed secure Payment protocol for vehicle-to-roadside scenarios in VANETs

4.1 Our proposed CCMS-VAN architecture

Taking into consideration the General Payment Model of Abad-Peiro et al. [1] which can be applied to many different Payment methods, we have designed a CCMS-VAN architecture (based on the Client Centric model) which uses the following entities: Client, Merchant, Acquirer, Issuer, and Payment Gateway (all of which were described earlier).

The parties of the Client Centric model communicate with each other when executing fund transfers using the following 3 primitive Payment transactions:

  • In Payment, the Client transfers the Payment amount to the Merchant.

  • In Value Subtraction, the Client requests that the Payment Gateway (on behalf of Issuer) deducts the money from the Client’s account.

  • In Value Claim, the Merchant requests that the Payment Gateway (on behalf of Acquirer) transfers money to the Merchant’s account.

The five entities in CCMS-VAN and their interactions are shown in Fig. 5. Note that the Client is a user entity equipped with an OBU and/or an AU. Moreover, this entity connects directly with the Payment Gateway (an entity which provides the necessary infrastructure to allow a Merchant to accept credit card and other forms of electronic Payment), allowing the Merchant to communicate with the Acquirer using this connection.

Fig. 5
figure 5

Proposed CCMS-VAN design architecture

Full size image

It is worth noting that, in our proposed architecture, there is no direct interaction between the Merchant and the Acquirer. Moreover, the connection between the Client and the Payment Gateway is set up through the Internet, using communication technologies (wireless, cellular) offered by a mobile phone operator (such as General Packet Radio Service (GPRS), Enhanced Data rates for Global System for Mobile Communications (GSM) of Evolution (EDGE), Evolution-Data Optimized (EvDO) and High Speed Downlink Packet Access (HSDPA)). Since the Issuer, the Acquirer, and the Payment Gateway all operate over the private networks of banks, the security of the messages exchanged among them is beyond of the scope of this paper.

However, before receiving Payment services, the Client must register with an Issuer. During the Client’s registration, the following steps are performed:

  1. 1.

    The Client shares his/her credit- and/or debit-card information (CDCI) with the Issuer (who will not reveal it to any Merchant).

  2. 2.

    The Issuer assigns several nicknames to the Client because of the trust relationship between both of them. These nicknames are known only to the Client and the Issuer and are used to prevent the Merchant from knowing the identity of the Client [16].

4.2 Notations

All the entities involved in our protocol are called parties and communicate through either wireless or wired networks or a combination of both. The symbols C, M, PG, I, and A are used to denote the names of the parties Client, Merchant, Payment Gateway, Issuer and Acquirer, respectively. Table 1 shows the symbols used to represent messages used in our proposed protocol.

Table 1 Symbols and messages used by our proposed payment protocol
Full size table

4.3 Session key generation technique

The CCMS-Van protocol employs two efficient key generation techniques to generate the sets of session keys used in transactions and increase the performance of the protocol by reducing the frequency of key updates.

The key set \(\mathit{KS}_{C-M_{i}}\) (with i={1,…,n}), is generated from the secret key KS C−M and stored in both the Client and the Merchant terminal. The set \(\mathit{KS}_{M-PG_{k}}\) (with k={1,…,n}), is generated from the secret key KS M−PG and stored both in the Merchant and the Payment Gateway terminals. The set \(\mathit{KS}_{C-I_{z}}\) (with z={1,…,n}), is generated from the secret key secret KS CI and is stored in the Clients device and the terminal of the Issuer. The set \(\mathit{KS}_{CPG_{j}}\) (with j={1,…,n}), is generated from the secret key KS CPG and is stored both in the Client and Payment Gateway terminals.

A more in-depth discussion of the two key generation techniques and the generation of the different sets of session keys are given in [44].

4.4 Our proposed Client Centric model Payment Protocol for VANETs (CCMS-VAN)

The CCMS-VAN Protocol is composed by two sub-protocols: the CCMS-VAN Merchant Registration Protocol (called MRP and it is executed between the Client C and the Merchant M) and the CCMS-VAN Payment Protocol (called PP and is executed among the Client C, the Merchant M and the Payment Gateway PG).

For the CCMS-VAN Merchant Registration Protocol, the Client has to register with the Merchant to send the master key KS CM . The protocol has to be executed every time the Client wants to perform transactions with a Merchant. The details of the protocol are shown as follows:

figure a

The master key KS CM is generated by the Client C and shared with the Merchant. To achieve that, C sends the master key with her/his nickname NID C , a nonce n for the challenge-response and MIDReq to M. After the Merchant M receives the message, she/he sends h(n,NID C ,ID M ,KS C−M ) and the Merchants identity (ID M ). Note that both messages (from the Client to the Merchant and vice-versa) are encrypted with the session key w. The various messages exchanged between the Client and the Merchant during the CCMS-VAN Merchant Registration Protocol are shown in Fig. 6.

Fig. 6
figure 6

Messages exchanged during the execution of the Merchant Registration Protocol

Full size image

Once C and M have exchanged the necessary information, they can generate a new set of \(\mathit{KS}_{C-M_{i}}\) using the same key generation technique. The Client may then start the CCMS-VAN Payment Protocol.

For the CCMS-VAN Payment Protocol, the Client purchases goods from the Merchant and pays for them using her/his credit-card or debit-card. This protocol is formalized as follows:

figure b
Step 1: :

The Client C and Merchant M exchange the information necessary to start the protocol by performing the following sub-steps.

1-1::

C sends his/her nickname (NID C ), the index i (that will be used to generate the session key between the Client and the Merchant) and the request for the transaction identity (TIDReq) to M.

1-2::

The Merchant receives the request and sends back its identity (ID M ) and TID to C, encrypted with \(\mathit{KS}_{C-M_{i}}\).

figure c
Step 2: :

Client C creates a Payment Request (referred to in the General Payment Model [1, 27]) using the following sub-steps.

2-1::

A Value-Subtraction Request (called VSRequest) is created and it includes \(\mathit{MAC}[(\mathit{Price}, h(\mathit{OI}), \mathit{TST}_{C}, \mathit{TC}, \mathit{IDM}),\mathit{KS}_{C-I_{z}}]\), TST C and TC.

2-2::

A new message is created which includes C′s nickname, I′s identity, Price, OI (used to inform M about the goods and prices requested), VSRequest and the timestamp TST C read from C′s clock.

2-3::

The message created in the previous sub-step (henceforth referred to as the Payment Request) is encrypted with the session key \(\mathit{KS}_{C-M_{i}}\).

2-4::

The Payment Request is sent to the Merchant.

figure d
Step 3: :

The Merchant M generates the Value-Claim Request (called VCRequest) by performing the following sub-steps.

3-1::

The message received from C is decrypted to extract OI, TST C and VSRequest.

3-2::

The timeliness of the Payment Request is verified. If the check is successful, the following sub-steps are performed.

3-3::

The VCRequest is prepared, and contains C′s nickname, h(OI), TST M , the VSRequest, order’s amount, identity of the transaction, ID M , I′s identity and \(\mathit{MAC}[(\mathit{VSRequest}, \mathit{TST}_{M}, h(\mathit{OI}),\mathit{TID}, \mathit{ID}_{M}, \mathit{Precio}, \mathit{NID}_{C}),\mathit{KS}_{M-\mathit{PG}_{k+1}}]\).

3-4::

The VCRequest and the M′s identity are encrypted with \(\mathit{KS}_{C-M_{i}}\).

3-5::

The encrypted message in sub-step 3-4 is then transmitted to the Client C with \(\mathit{MAC}[(\mathit{VCRequest}, \mathit{ID}_{M}), \mathit{KS}_{C-M_{i+1}}]\).

figure e
Step 4: :

The Client C performs the following sub-steps.

4-1::

The received message from M is decrypted to retrieve the VCRequest.

4-2::

A new message is created (that includes ID M , NID C , the received VCRequest, indices k y z and \(h(\mathit{KS}_{C-I_{z}})\) and is used to prevent the Payment Gateway from modifying the approval result in step 5-5) and is encrypted with \(\mathit{KS}_{C-PG_{j}}\).

4-3::

The last message encrypted in step 4-2 is sent to PG with the index j and \(\mathit{MAC}[(\mathit{VCRequest}, \mathit{IDM}, \mathit{NID}_{C}, k, z,h(\mathit{KS}_{C-E_{z}})),\mathit{KS}_{C-PG_{j+1}}]\).

figure f
Step 5: :

Using the private network of the banking institution, the Payment Gateway (PG) performs the following sub-steps to verify and approve the Payment.

5-1::

The VCRequest is decrypted to retrieve VSRequest and the others fields, such as ID M , NID C .

5-2::

The timeliness of VCRequest is verified. If the check is successful, the following steps are executed.

5-3::

The VSRequest and other important, such as: h(OI), TID, ID M , Price, z and h(KS C−Iz ) are forwarded to the Issuer (I) where it is decided whether to approve or reject the transaction.

5-4::

ID M and the requested price Price are sent to confirm to the Acquirer A that the Merchant is the party to whom the requested amount Price will be transferred to.

5-5::

The approved result (Stt) and Value-subtraction Response (called VSResponse and encrypted with \(\mathit{KS}_{C-I_{z}}\)) are received from the Issuer I. It is worthwhile noting that the VSResponse is prepared by the Issuer after (a) checking the timeliness of VSRequest and the validity of the Clients account, and (b) after transferring the total amount of OI to the Merchants account.

figure g
Step 6: :

The Payment Gateway PG generates the Payment Response (called PResponse) in the following sub-steps.

6-1::

The VCResponse is created (including Stt and h(Stt,h(OI))) and encrypted with \(\mathit{KS}_{M-PG_{k+1}}\).

6-2::

The Payment Response (called PResponse and encrypted with \(\mathit{KS}_{C-PG_{j+1}}\)) is created and sent to the Client. PResponse includes the VSResponse and the VCResponse (which will be forwarded to the Merchant M).

figure h
Step 7: :

The Client C performs the following sub-steps.

7-1::

The PResponse is decrypted to retrieve the VSResponse and VCResponse primitives.

7-2::

The Clients own OI is compared with the received h(OI). If they do not match, then the Client performs Sub-step 7-3a, otherwise the Client performs Sub-step 7-3b.

7-3a::

A message is sent to the Payment Gateway to notify it of the response failure. The Payment Gateway then starts a recovery procedure or resends the message.

7-3b::

The VCResponse is sent to M who in turn proceeds to deliver the goods to the Client.

After a transaction is completed, \(\mathit{KS}_{C-M_{i}}\), \(\mathit{KS}_{C-I_{z}}\), \(\mathit{KS}_{M-PG_{k}}\) y \(\mathit{KS}_{C-PG_{j}}\) are put in the revocations list of every entity of the system to prevent their replay between the Client and the Merchant. Figure 7 shows the transmitted messages among the parties of the system during the execution of our proposed CCM-VAN Payment Protocol.

Fig. 7
figure 7

Message exchange during the execution of the CCMS-VAN Payment Protocol

Full size image

4.5 Security analysis

In this section, we performed a detailed security analysis of our proposed secure Payment protocol. The anonymity of the Client in the CCMS-VAN protocol is achieved by using a nickname NID C (a temporary identity known only to the Client and the Issuer) instead of his/her real identity. As a result, neither the Merchant nor the Payment Gateway can map the nickname to the true identity of the Client. Note that this anonymity protects relevant information from third parties but not unrestrained anonymity because it only implies the protection of relevant information from unintended parties [2].

The Confidentiality of messages transmitted in each transaction while in transit in the proposed protocol, is protected by employing symmetric cryptography which uses a secret shared key between the two parties (called sender and receiver) that wish to communicate safely without revealing the content of the message. Moreover, the encryption key also allows the receiver and the sender to authenticate each other. In addition, the proposed protocol uses the Message Authentication Code (MAC) to maintain the Integrity of important messages.

Although, generally, in any transaction a party should not trust others unless they can provide a proof of trustworthiness [27], the proposed protocol assumes that the trust relationship between the Client and the Issuer exists because the Client has a credit- and/or debit-card issued by the Issuer who will not reveal it to any other party.

The Non-repudiation of a transaction is ensured in the proposed protocol by \(\mathit{KS}_{C-I_{Z}}\), since it could be generated only by the Client or Issuer but not by the Merchant. Thus, the Merchant can provide a non-repudiable evidence to prove to other parties that the Client has sent a message or requested the Merchant to perform a transaction.

Our proposed protocol is also secure against replay attacks because the timestamp included in the transmitted message ensures the freshness of the message and prevents an intruder E from impersonating a legal user by replaying the users transmitting contents. Moreover, it is difficult for any intruder E to get information related to the secret key through an analysis of intercepted data because the authentication key is dynamic (i.e., exploiting, on each transaction, different session keys from one master secret) which makes the proposed protocol secure against key guessing attacks.

5 Design and implementation of CCMS-VAN Protocol

5.1 Experimental testbed platform

As mentioned before, the CCMS-VAN implementation is composed of 5 applications (Client, Merchant, Payment Gateway and Issuer) which have been implemented in Java Platform 2, Standard Edition (J2SE) [23], except for the Client that was implemented in Java Platform, Micro Edition (JavaME) [22] for mobile devices. Since the JaveME Mobile Information Device Profile (MIDP) version 2.0 does not have the necessary security support, we have used security APIs from [7], a light-weight API suitable for mobile computing applications and resource-constrained devices. Thus, all the five applications implemented use the same security APIs.

The wireless communication between the client and merchant is established using TCP/IP over the 802.11b channel with a maximum transfer rate of 11 Mbit/s and Wired Equivalent Privacy (WEP) encryption with a 64 bits key.

The hardware configuration of the devices used to execute and evaluate all the components of our proposed payment protocol are shown in Table 2.

Table 2 Hardware specifications of the systems used in our performance evaluation tests of the proposed protocol
Full size table

5.2 Cryptographic operations

Two important design aspects that should be considered when choosing encryption algorithms and hash functions are their security features and their computational requirements. Taking into consideration these requirements and the results discussed in [44] (about the comparison of different cryptographic algorithms), Table 3 shows the cryptographic algorithms used by the implementation of CCMS-VAN protocol.

Table 3 Cryptographic operations used by CCMS-VAN protocol
Full size table

The cryptographic algorithms shown in Table 3 are contained in the Java class named cCryptography of the Client application and implemented in the following methods:

  • generateAESKey(): This method creates an AES key to be used with the cryptography algorithms implemented in the wallet application. We have used the implementation described in [24].

  • AESEnc(): Method used to encrypt messages with the Advanced Encryption Standard algorithm.

  • AESDec(): Method used to decrypt messages encrypted with AESEnc().

  • HMAC-MD5(): This method is used to calculate a Message Authentication Code (MAC) involving a cryptographic hash function in combination with a secret key. Thus, the result can be used to simultaneously verify both the data integrity and the authenticity of a message.

  • generateItemofSet(): Method that allows to create a session key (using the Session Key Generation Technique presented in Sect. 4.3) from a master key.

5.3 The CCMS-VAN software at the Client side

With the CCMS-Van Payment protocol, a software (henceforth referred to as the CCMS-VAN Wallet) is required at the Client’s side for purchase transactions. The CCMS-VAN Wallet can be obtained by connecting to the Issuers web site and downloading it or sending a request to the Issuer to receive it by mail. Once the Client has downloaded or received the CCMS-VAN wallet, she/he should install it on her/his mobile device. To prevent unauthorized users from: (a) opening the application, (b) authorizing Payment transactions, or (c) accessing Clients information and key files, the Client is required to set up her/his own password (henceforth referred to as KWP password) during the installation process. Figure 8 illustrates snapshots of the main screen, the login screen, and the main menu of CCMS-VAN wallet on a Nokia™ N95 device. The left screen shows the main screen of CCMS-VAN wallet, the middle screen shows the login screen and the right screen shows the main menu.

Fig. 8
figure 8

Snapshots of main screen, the login screen and the main menu of the CCMS-VAN wallet on the Nokia™ N95 device

Full size image

The CCMS-VAN wallet provides the following functionalities:

  • Personal Details: To prevent the Client from being prompted for her/his information during both the Merchant Registration and Payment phases, the CCMS-VAN wallet allows the Client to store in a file (protected by the CCMS Wallet Password (KWP)) his/her personal information (such as name, contact information, Issuer ID and credit-and/or debit-card information) for other purposes. To achieve this, the CCMS-VAN wallet prompts the user to enter the above information and store it at the Clients mobile device. Figure 9 illustrates the CCMS-VAN wallet prompting the Client to enter her/his details on Nokia™ N95 device.

    Fig. 9
    figure 9

    Snapshots of CCMS wallet Personal Details form on Nokia™ N95 device

    Full size image

  • Key Generation: To generate a new session key from the master key, the CCMS-VAN wallet calls generateItemofSet() with two values: a master key and a random number j. Upon receipt of the master key, its Big IntegerFootnote 2 representation is created and depending on the value of j, the required number of zeros is added to the right of the master key. The MD5 function is then applied to the result obtained to produce a new 128-bit session key.

    The aforementioned key generation technique can be directly applied to generate the sets of session keys KS CI and \(\mathit{KS}_{MPG_{k}}\) from the keys KS CM and KS MPG , respectively. Moreover, to generate the set of session keys KS CI , the Credit- and/or Debit-Card Information (CDCI) is treated as the Big Integer and is added to the value of KS C−I before doing performing a left shift operation. An example of the proposed session key generation technique is shown in Fig. 10.

    Fig. 10
    figure 10

    An example of the key generation technique used by the CCMS wallet

    Full size image

  • Merchant Registration: The Client should execute the Merchant Registration Protocol to register with the Merchant to share the master key KS CM before making Payments to a Merchant. First, the Client is prompted to enter the KWP password to retrieve her/his personal information (such as name, address, contact number and email address) stored on the Clients device. Then, the CCMS-VAN wallet generates the secret key KS CM and the session key by using the generateAESKey().Once the keys have been generated, the CCMS-VAN wallet encrypts using the session key w by calling the AESEnc(), the Client’s personal information, the secret KS CM , a nonce, and a request for the Merchants identity before being sent to the Merchant to register the Client. The format of the Client registration message is shown in Table 4.

    Table 4 Client registration message format
    Full size table

    Upon receipt of the Client registration message, the Merchant decrypts it using AESDec() to retrieve the Clients information including the secret key KS CM . The Merchant then encrypts her/his identity and h(n,NID C ,ID M ,KS CM ) with the session key w using AESEnc(). The encrypted message is sent to the Client to confirm the registration.

    At the Client side, the Client retrieves the confirmation of her/his registration by decrypting the message using AESDec(). Then, the CCMS-VAN wallet stores the secret key KS CM in a key file protected with the KWP password. Once the registration is done, the Merchant stores on its device the Client’s information together with the secret key KS CM .

    Figure 11 illustrates the CCMS-VAN wallet during the Merchant Registration phase on the Nokia™ N95 device. The left screen shows the CCMS wallet displaying the Client’s details whereas the right screen shows the successful registration.

    Fig. 11
    figure 11

    Snapshots of CCMS-VAN wallet during the execution of the Merchant Registration Protocol phase on Nokia™ N95 device

    Full size image

  • Payment Execution: To make a payment to the Merchant, the Client is first prompted to enter the following information: Order Description, the Product ID, the Price and the Type of Card to use (Debit or Credit). After providing the information, the CCMS-VAN wallet application generates the keys \(\mathit{KS}_{C-M_{i}}\) and \(\mathit{KS}_{C-I_{z}}\) based on the random numbers i and z, respectively. The Client then sends his/her nickname, the i, and the Transaction ID Request (TIDReq). Upon receipt of the message, the Merchant generates the key \(\mathit{KS}_{C-M_{i}}\) (based on the i value) and sends his/her identity ID M ) and the transaction ID (TID) to the Client, encrypted with the session key \(\mathit{KS}_{CM_{i}}\) (using AESEnc()). The Client then creates the Value-Subtraction Request (VSRequest) that is sent to the Issuer. An authenticated hash of this message is computed using the HMAC-MD5 algorithm with the \(\mathit{KS}_{CI_{z}}\) key by using HMACMD5(). It is worth pointing out that the Merchant will not able to decrypt or create the request since the Merchant does not have the key KS C−I which is known only the Client and the Issuer. Once the VSRequest has been created, the Client prepares the Payment Ordering request (called PRequest) and encrypts it with the key \(\mathit{KS}_{CM_{i}}\) using AESEnc() to ensures its confidentiality. The PRequest is sent to the Merchant and includes the VSRequest, the Order Information (OI), Price, Client Nickname (NID C ), timestamp TST C and the Issuer identity (ID I ). Upon receipt of the request from the Client, the Merchant (who has the key KS CM ) decrypts the message using AESDec(). Then, the Merchant combines the VSRequest received from the Client and the amount payable by the Client with the necessary information to create the VCRequest. This message is encrypted with the key \(\mathit{KS}_{CM_{i}}\) before being sent to the Client. Note that the Merchant needs to send the message through the Client due to the connectivity restriction that prevents direct communication between the Merchant and the Acquirer.

    The message received from the Merchant is decrypted using AESDec() to recover the VCRequest. The Client then creates a message which includes the received VCRequest and other necessary information (such as ID M , NID C , k, z and \(h(\mathit{KS}_{CI_{z}})\)). This message is encrypted with the key \(\mathit{KS}_{CPG_{j}}\) using AESDec() before being sent to the Payment Gateway (PG). PG decrypts the message received from the Client using AESDec() and then sends the VSRequest to the Issuer. Upon receipt of the approval response, the PG prepares the PResponse (which includes VCResponse and VSResponse (encrypted with \(\mathit{KS}_{MPG_{k+1}}\))) and encrypts it with the key \(\mathit{KS}_{CPG_{j+1}}\) using AESEnc(). PG then sends the Payment Ordering Response (PResponse) to the Client which in turn transmits the VCResponse (recovered from the message received from PG, using AESDec() to decrypt the message). Note that although the flow information between the Payment Gateway, the Issuer, and the Acquirer (step 5 of CCMS-VAN protocol shown in Fig. 7) exists within a private banking network (beyond the scope of CCMS-VAN Protocol), still, we have implemented the Issuer and Acquirer to have a better idea of the performance of the entire Payment system even if it could be assumed that all transactions relevant to Acquirer and Issuer are successful within a limited time as provided by the private banking network.

    Once the Merchant receives the message from the Client, it retrieves the VCResponse using AESDec() to decrypt the message. The format of PRequest, VSRequest, VSResponse, VCRequest and VCResponse primitives are shown in Table 5.

    Table 5 Format of Payment primitive transactions PRequest, VSRequest, VCRequest, VCResponse and VSResponse
    Full size table

    Figure 12 illustrates the CCMS-VAN wallet during the Payment phase on Nokia™ N95 device. The left screenshot shows the CCMS-VAN wallet displaying the Order description whereas the right screen shows the successful Payment transaction.

    Fig. 12
    figure 12

    Screenshots of the Payment phase on the Nokia™ N95 Device

    Full size image

6 Performance evaluation

6.1 Discussions of empirical results

In this section, we present an empirical performance analysis of our proposed CCMS-VAN protocol using performance metrics such as execution time for the various execution phases (such as merchant registration protocol, payment protocol) of the protocol and the size of application code which is an important factor for resource-constrained devices (e.g. those with limited memory).

6.1.1 Execution time of Merchant Registration Protocol

The empirical results obtained for our implementation of the CCMS-VAN protocol are reported in this section, where we focus on the time taken to perform various parts of the CCMS-VAN protocol and the overall time taken to complete a Payment transaction. The results were collected by performing 10 executions with different sets of data and the time measurements were done using the getTime method in the Date class of J2SE.

The average times required by the Client and the Merchant to perform the Merchant Registration Protocol are shown in Tables 6 and 7, respectively. Note that the time taken by the Client to input the data has not been included into the time taken by the application to perform the Merchant Registration Protocol. Moreover, when we tested our implementation by entering the maximum number of characters allowed into each individual field, we found that the maximum times taken by the Client (1196 milliseconds for Nokia™ N95) to perform the Merchant Registration Protocol are not much different from the average times calculated in Table 6 and Table 7.

Table 6 Time taken (in milliseconds) at Client to execute the Merchant Registration Protocol (TCRP)
Full size table
Table 7 Time taken (milliseconds) at Merchant to execute the Merchant Registration Protocol (TMRP)
Full size table

6.1.2 Execution time of Payment Protocol

The average total time that the Client has spent on performing the first transaction with the Merchant (both the Merchant Registration Protocol and the Payment Protocol) was 9.46 seconds (1.12 of TRCP + 8.34 of TPP = 9.46 seconds) using the Nokia™ N95 device. For subsequent payment transactions, the total average time to complete each transaction will reduce to only 8.34 seconds on Nokia™ N95 device because the Client does not have to execute the Merchant Registration Protocol. This minimal amount of time to complete a transaction reveals the potential of CCMS-VAN protocol to execute Payment transactions in wireless environments with minimal delays.

Table 8 shows the average time in milliseconds needed to execute the Payment Protocol by the Client, the Merchant, and the Payment Gateway, respectively.

Table 8 Time taken (in milliseconds) at Client (Nokia™ N95), Merchant, Payment Gateway, and Issuer on performing Payment Protocol (TPP)
Full size table

6.1.3 Application size

Due to the limited memory space available on mobile devices, application code size is an important issue which should be considered when developing applications for such devices. As the Client is the only party in our proposed Payment protocol that uses a mobile device to interact with the system, in this section we focus on the Clients side for the performance evaluation measurements.

The CCMS-VAN wallet software has an acceptable file size of 68 Kilobytes for the Nokia™ N95 mobile phone which is about 0.042% of the memory availableFootnote 3 on the above mobile device.

7 Conclusions and further work

A lightweight protocol for secure on-line Payments in a vehicle-to-roadside Restricted Scenario in VANETs (where the Merchant cannot directly communicate with the Acquirer) was proposed in this research. Our protocol employs symmetric cryptographic techniques which has low computation requirements for all engaging parties (since no public-key operation is required). Moreover, the Client takes an active role in the Payment process and acts as a proxy to allow the communication between the Merchant and the Acquirer.

Our empirical performance evaluation results on the implementation have proven that Payment transactions over a wireless network can be conducted by our proposed CCMS-VAN protocol. The selected lightweight, secure cryptographic exploited by our proposed payment protocol. Deploying such algorithms in CCMS-VAN results in the reduction of messages exchanged and computation costs at the Client’s mobile device. As we have seen from the implementation, a Payment transaction by CCMS-VAN can be completed within average of 8.34 second using a Nokia™ N95 device.

The Client acts as a proxy during the Payment process (which requires more computation resources and message exchanges) and despite the limited resources on the mobile device, our performance results demonstrate that we can still complete a Payment transaction within a reasonable amount of time (compared with other payment protocols reported in the literature [28, 44, 50] which have similar end-to-end latency but less message exchanges).

The Clients CCMS-VAN wallet software bytecode requires only 68 Kilobytes to be stored on a Nokia™ N95 mobile device. This small code size of the application makes it very suitable for memory-constrained mobile devices.