An anonymous e-rental protocol based on ID-based cryptography and NFC

Abstract

Most e-rental services require customers to register sensitive information, which gives malicious service providers a good opportunity to launch social engineering attacks, or to use data mining techniques collecting and analyzing customers’ information or rental preferences. Therefore, we propose an anonymous e-rental protocol based on ID-based cryptography and near field communication technology, with particular focus on vehicle rentals. Our contributions include: (1) Anonymity. Users’ real identity is hidden from the rental service providers. (2) Unlinkability. Rental service providers cannot find the relation between two rental records. (3) Traceability. As full anonymity is not always desirable, traceability allows disclosure of a malicious user’s identity, whereas other users’ privacy remains unviolated. Rental service providers can request TTP to reveal users’ identity with a legal warrant. (4) Flexibility. Users choose their preferred service providers and vehicles. (5) Anonymous payment. Rental service providers cannot associate users’ identity with the financial transactions.

1 Introduction

More and more subscription and rental services have gone online in recent years, such as Apple’s iTunes video and magazine services, Amazon’s Kindle Lending Library, even car rental services, etc. Most of the time these service providers require customers to register their personal information. For example, in current e-car rental systems [1, 2], customers have to provide ID certificates, telephone numbers, residential address, and driving license. Unfortunately, if a malicious provider collects customers’ rental records or personal information, e.g. hobbies, lifestyles, credit numbers and frequent locations, customers’ privacy may be compromised. Moreover, if the cars are equipped with GPS devices, users’ travel routes can be completely tracked.

As this has attracted more and more privacy concerns, people are getting aware of the importance of renting a car without disclosing their own identity. They hope that a secured anonymous rental system must achieve anonymity, unlinkability, and traceability [3]. To guarantee anonymity, users provide their personal info to a trusted third party (TTP) instead of to a rental service provider. As for unlinkability, it means a rental service provider cannot find the relation between a user’s rental records and his identity. But full anonymity is not always desirable [3]; traceability allows disclosure of a malicious user’s identity, whereas other users’ privacy remains unviolated. A rental service provider can even request a TTP to reveal users’ identity if there are consumer disputes or accidents.

More and more studies in this area have been published to protect users’ privacy [3–5]. Wang et al. proposed an e-cash system with anonymity revocation [4]. In Wang et al.’s protocol, users have to acquire an anonymous certificate from a TTP for their withdrawal and payment. When double spending occurs, banks will request the TTP to reveal a user’s identity. But during Wang et al.’s withdrawal stage, banks can only verify whether users have the secrets of a certificate. They cannot confirm if the certificate is issued by the TTP. A malicious user can take such an opportunity to generate a random certificate to the banks. Because the user knows the certificate’s content, he can certainly pass the bank’s verification. In such a case, banks may issue e-cash to adversaries. When banks find this e-cash is double spent, even the TTP cannot track the attackers through the randomly generated certificate.

Several online subscription systems have been proposed in recent years. In 2008 Blanton [6] proposed a method that allows an anonymous user to have unlimited times of access to the subscription service during each time interval, and no links can be established between a user’s identity and his rental records. In 2010 Chen et al. [5] proposed a new e-cash system with anonymity revocation and mutual authentication. They improved Wang et al.’s scheme by enhancing its certificate validation and by performing mutual authentication, but their scheme does not guarantee forward secrecy. If an attacker knows the secret key of a TTP, a bank or an agency, he may eavesdrop on their communications. The attacker can compute their session key, decrypt their messages, and use counterfeit e-cash for payment. In 2010, Slamanig and Rass [3] proposed an e-service system that allows anonymous transactions. They use tamper-resistant smart cards to store anonymous certificates. Despite high portability of smart cards, their convenience is restricted because they cannot work without a card reader. Their scheme is able to identify malicious users behind transactions, but it cannot provide a fine-grained access control of the resources in their subscription service. In 2012 Vasco et al. [7] proposed an anonymous subscription scheme to protect user’s anonymity and to provide fraud detection. It allows a set of users to buy access to a limited set of services, but cannot disclose a fraudster’s identity. In 2013, Lee et al. [8] proposed an anonymous subscription system. The scheme is based on a single-login platform and does not require users to provide their real identity for registration, so as to protect their privacy.

Because ID-based encryption takes users’ personal information such as names, phone numbers, ID numbers, or emails to generate public keys, some schemes are based on bilinear pairing ID-based encryption [9, 10]. The key-generation center (KGC) uses public keys to generate private keys with RSA algorithms [11]. In 1985, both Koblitz and Miller [12, 13] proposed new encryption schemes based on elliptic curves. In 2001, Boneh and Franklin [14] proposed a bilinear pairing ID-based encryption scheme. Compared with RSA, their method requires shorter keys but has better efficiency in computation.

In this paper, we propose an anonymous e-rental protocol based on ID-based cryptography and NFC technology, with particular focus on vehicle rentals. Our protocol uses an NFC-enabled phone for authentication and the vehicle’s access control. In our mechanism, even though a malicious user can compromise a mobile phone, e.g. modifying the rental applications, he cannot clone the secrets inside because they are stored in the secure element.

Near field communication is based on radio frequency identification (RFID) standards and complies with ISO/IEC 18092 [15], ISO/IEC 21481, ECMA 340, and ETSI TS 102 190. It is also compatible with existing contactless smart card standards ISO/IEC 14443. NFC operates at 13.56 MHz, and its transmission is limited to 10–12 cm at the rate of 106, 212, or 424 kbps. As illustrated in Fig. 1, NFC-enabled phones consist of three NFC components: NFC controller, secure element (SE), and RF antenna.

• Secure element (SE): A secure element is a tamper-resistant device that contains a secure memory area that stores confidential and cryptographic data, and a micro-controller that runs securely hosting applications.

• NFC controller: It serves as a bridge for host controller (the mobile phone OS), SE, and RF antenna. NFC controller has three operation modes: card emulation, P2P mode, and reader/writer mode.

• RF antenna: It is responsible for transmission and reception of radio signals.

Our protocol uses NFC phones as user’s mobile devices, because NFC phones can serve as a smart card and a card reader. Besides, the secure element (SE) in an NFC phone is tamper proofed and stores user’s private data. The cryptosystem in this paper is based on bilinear pairing identity-based certificateless signature schemes.

Fig. 1

Components of an NFC-enabled phone [16]

The steps of our car-rental protocol are as follows: (1) Users provide their personal information to a TTP, such as ID number, driving license, credit card number, and traffic offense records. The TTP is responsible for identity authentication and payment. (2) Users take their NFC phones to request a temporary anonymous license from the TTP. They can browse the web to choose a car to rent. They have to send the temporary license and the car’s info to the company. After the company confirms that the license has been generated by the TTP, it issues a ticket for a specific vehicle and sends it to users’ NFC phones. (3) Users receive the ticket and go to the pickup place. They hold their NFC phones near the car’s onboard unit (OBU) for authentication. If the ticket is verified, users can drive the car. (4) When the car is returned, the company collects its payments through the TTP. (5) If there are consumer disputes or accidents, the rental service provider can request the TTP to reveal the driver’s identity.

The main contributions of our scheme include: (1) high security and convenience of a car-rental system that combines NFC phones with ID-based cryptography; (2) a privacy-based rental system that allows anonymous car hiring without sacrificing the rental service providers’ interests; (3) free choice of rental service providers; (4) anonymous payment.

The next section reviews the related studies in this area. The third section provides the preliminaries and detailed steps of our protocol. The fourth section deals with the security analysis of our method. In the fifth section, we use GNY proof to prove that our protocol is a viable scheme. A conclusion is drawn in Sect. 6.

2 Related work

Section 2.1 deals with bilinear pairing and its application. Section 2.2 analyzes related studies.

2.1 ID-based encryption from bilinear pairings

Shamir [10] proposes an ID-based encryption scheme taking users’ identity as public keys for better key management and distribution. Boneh and Franklin [14] propose an ID-based encryption from bilinear pairings. It achieves efficient computation of keys. Since then, many encryption schemes of this kind have been proposed [17].

In bilinear pairing ID-based encryption, the key generation center (KGC) is responsible for parameter setting and key distribution. It generates $\left\{ {G_1 ,G_2 ,P,q,e} \right\}$ as system parameters, where $G_{1}$ denotes a cyclic additive group of order $q$, and $P$ a generator of this group; $G_{2}$ denotes a cyclic multiplicative group of the same order $q$ in a finite field; $e$ denotes a mapping function, i.e., $e:G_1 \times G_1 \rightarrow G_2$. It also defines a map-to-point hash function $H_1:\left\{ {0,1}\right\} ^*\rightarrow G_1$to compute public keys and to map users’ identity to a point over an elliptic curve. Meanwhile, KGC generates a random number $s\in Z_q ^*$ as a private key and then uses it to compute its public key $P_{pub} =sP$. When a user sends his/her identity to KGC, it uses it to generate a key pair and return a public key $Q_{ID} =H_1 ( {ID})$ and a private key $S_{ID} =sQ_{ID}$.

The following paragraph introduces the application of bilinear pairing ID-based encryption.

• En/decryption in Boneh and Franklin’s [14] scheme:

  • Encryption: If Alice wants to send a message $M\in \left\{ {0,1} \right\} ^n$ to Bob, Alice has to use Bob’s public key $Q_{B}$ to encrypt M. The steps are: (1) Alice computes Bob’s public key $Q_B =H_1({ID_B})$; (2) generates a random number $\sigma \in \left\{ {0,1} \right\} ^n$; (3) computes $r=H_{3}(\sigma ,M)$; (4) encrypts the message as C= {rP, $\sigma \oplus$ H$_{2}$(e(Q$_{B}$,P$_{pub})^{r}$),$M\oplus$ H$_{4}(\sigma )$} = $\{U,V,W\}$, and sends the encrypted message to Bob.

  • Decryption: After Bob receives the message $C$ = $\{U, V, W\}$, he uses his private key S$_{B}$ to decrypt $C$. The steps are: (1) Bob computes $V\oplus H_{2}(e(S_{B}$,U)) = $\sigma$; (2)$W\oplus H_{4}(\sigma )=M$; (3)$r=H_{3}(\sigma$,M), and verifies rP ?= U; (4) if it is verified, Bob confirms the reception of message M.

• Key agreement protocol (KAP): Zhang et al. [18] propose a secured and efficient session key agreement protocol. (1) Both Alice and Bob generate a random value $a$, $b \in Z_{q}^{*}$, compute $T_{A}$ = aP and $T_{B}$ = bP respectively, and then send $T_{A}$ and $T_{B}$ to each other. (2) Alice and Bob compute their shared keys: $K_{AB}=e$(aP $_{pub}+S_{A}$, $T_{B}+Q_{B}) \quad e(S_{A}$, $Q_{B})$ and $K_{BA}=e(T_{A}+Q_{A}$, bP $_{pub}+S_{B}) \quad e(Q_{A}$, $S_{B})$, where $K_{AB}=K_{BA}=e(P$, $P)^{abs} \quad e(P$, $Q_{B})^{as} \quad e(Q_{A}$, $P)^{bs} \quad e(Q_{A}$, $Q_{B})^{2s}$. And their shared session key is SK $_{AB}=H(A$, $B$, $h$, $K_{AB})$, where $H()$ denotes a one-way hash function, and $h$ = aT $_{B}$ = bT $_{A}$.

Function 1:

$$\begin{aligned} K_{AB}&= e( {aP_{pub} +S_A ,T_B +Q_B })e( {S_A ,Q_B }) \\&= e( {aP_{pub} ,bP+Q_B })e( {S_A ,bP+Q_B })e( {S_A ,Q_B }) \\&= e( {aP_{pub} ,bP})e( {aP_{pub} ,Q_B })e( {S_A ,bP})e( {S_A ,Q_B })e( {S_A,Q_B }) \\&= e( {P,P})^{abs}e( {P,Q_B })^{as}e( {Q_A ,P})^{bs}e( {Q_A ,Q_B })^{2s} \end{aligned}$$

Function 2:

$$\begin{aligned} K_{BA}&= e( {T_A +Q_A ,bP_{pub} +S_B })e( {Q_A ,S_B }) \\&= e( {aP,bP_{pub} +S_B })e( {Q_A ,bP_{pub} +S_B })e( {Q_A ,S_B }) \\&= e( {aP,bP_{pub} })e( {aP,S_B })e( {Q_A ,bP_{pub} })e( {Q_A ,S_B })e( {Q_A,S_B }) \\&= e( {P,P})^{abs}e( {P,Q_B })^{as}e( {Q_A ,P})^{bs}e( {Q_A ,Q_B})^{2s}=K_{AB} \end{aligned}$$

2.2 Privacy protection and related studies

In 2008, Wang et al. [4] proposed an e-cash system that can revoke anonymity. In 2010, Chen et al. proposed a new one. Both of their schemes are based on bilinear pairing ID-based cryptography. They work with a TTP to issue an anonymous certificate for the user and store it on a server. This certificate will be used in e-cash withdrawal and payment. If double spending occurs, the banks can request the TTP to reveal the users’ identity.

In Wang et al.’s scheme, when users try to withdraw e-cash, they have to prove that they know the secret value $x$ of $X$, where $X$ = xP and is one of users’ certificates; $P \in G_{1}$; and $x \in Z_{q}^{*}$. The users send $X$ to the bank and the bank responds with a random number $w \in$ $Z_{q}^{*}$. The users use their private keys to sign $w$: pick a random number $k \in Z_{q}^{*}$; compute $c=H_{1}(w$, $P$, xP, kP), $s=k-$ cx; and return {$c$, $s$} to the bank. The bank verifies the signature by computing $c'=H_{1}(w$, $P$, $X, sP- cxP) ?= c$. However, the bank is unable to verify whether $X$ comes from the TTP or not. It means malicious users can take $X'\in$ $Z_{q}^{*}$ to compute $X'=x'P$. They can prove to the bank that they know the secret value $x'$, and then use a fake certificate $X'$ to pass the bank’s authentication. At last, they withdraw the e-cash.

In Chen et al.’s protocol, users need to ask the TTP for a license License = {LST, LVT} in the license-issuing stage. Next, they compute a session key shared with the bank $K_{CB}=H_{2}(e(S_{C}$, kQ $_{B}))$; encrypt the authentication message Auth $_{CB}$ = {ID $_{C}$, ID $_{B}$, $k$, $b^{2}H_{3}$(CNO), $b^{-1}$LST, LVT, $T_{S}$}; and return EK $_{CB}$(Auth $_{CB})$ and kQ $_{C}$ to the bank. After receiving the message, the bank decrypts it with the shared session key $K_{BC}$ = $H_{2}(e(S_{B}$, kQ $_{C}))$. It then verifies $e(V$, $P)=e(W$, $P_{pub})e(H_{3}(b^{-1}$LST, $W)Q_{T}$, $P_{pub})$. If it is verified that the license is issued by the TTP, the bank performs a blind signature on the e-cash and returns it to the users. The users receive and unblind it and sends the anonymous e-cash e-cash = {CNO, LST, ($R$, $S)$} to a merchant. The merchant has to verify the e-cash by examining its bank-issued signature and sends it to the bank to claim payment. If the bank finds double spending in the deal, it can send a request to the TTP to trace the user’s real identity. Unfortunately, we have found that the session keys’ forward secrecy is not guaranteed in each session of the scheme. We take the withdrawal stage as an example. If malicious users know the bank’s secret key $S_{B}$, they may eavesdrop on {EK $_{CB}$(Auth $_{CB})$, BkQ $_{C}$}. Then they are able to compute the user-bank shared session key $K_{CB}$ = $H_{2}(e(S_{C}$, kQ $_{B}))$ = $H_{2}(e(S_{B}$, kQ $_{C}))$ = $K_{BC}$. If they have $S_{B}$ and kQ $_{C}$, they can act as a counterfeit bank to compute the session key $K_{CB}= K_{BC}=K_{attack}=H_{2}(e(S_{B}$, kQ $_{C}))$; and to decrypt EK $_{CB}$(Auth $_{CB})$.

3 An anonymous e-rental protocol based on ID-based cryptography and NFC

As shown in Fig. 2, our anonymous e-rental protocol consists of five elements: TTP, rental service provider, user (NFC phone), vehicle (OBU), and bank. It includes four stages: anonymous license issuing, vehicle ticket issuing, vehicle ticket verification, and vehicle control.

Fig. 2

Infrastructure of our anonymous e-rental protocol

The elements are described as follows:

• TTP: It performs mutual authentication with users and is responsible for issuing anonymous licenses. A rental service provider should verify an anonymous license with TTP and claim for payments.

• User (NFC phone): The user should use an NFC-enabled mobile phone that contains a broker application. To launch the application, the user’s PIN number [19] is required to access the secure element (SE) of the NFC. The broker application helps users browse vehicle information on the Internet, such as car type, location, price, and its rental service provider. The secure element is mainly responsible for the encryption/decryption of the communications and storage keys.

• Rental service provider: A rental service provider owns the vehicles waiting for rent. The provider should verify users’ anonymous licenses with TTP. If a license is valid, the provider issues a vehicle ticket for a specific vehicle to the users. After the vehicle is returned, the provider collects user’ payments through the TTP.

• Vehicle (OBU): Each vehicle is equipped with an OBU with an NFC reader. The OBU checks the validity of users’ vehicle tickets. If the tickets are verified, users are authorized to control the vehicle.

• Bank: The bank has to cooperate with the TTP and is responsible for the payments.

Details of the four stages are as follows:

• 1. Anonymous license issuing: Users perform mutual authentication with the TTP. If users’ identity is confirmed, the TTP issues a temporary anonymous license to them. Users can use the license for car hiring within its validity period.

• 2. Vehicle ticket issuing: After the APP helps users choose their preferred vehicle, it sends the anonymous license and the chosen vehicle’s information to the company to which the vehicle belongs. If the license is verified, the company issues a ticket to the users.

• 3. Vehicle ticket verification: Users hold their NFC phones close to the OBU to perform ticket verification. After the OBU confirms its own provider issues the ticket, and the ticket is still valid, it authorizes the users to control the vehicle.

• 4. Vehicle control: During car hiring, users are allowed to use their NFC phones to give commands to the car such as door open, door close, ignition, and return.

3.1 Notations

The notations we use in our car-rental system are listed in Table 1.

Table 1 Notations

3.2 Preliminaries

In our preliminaries, we explain in detail how we initialize our car-rental system and clarify each role’s function in our system, i.e. TTP, rental service provider, rental APP, SE, and OBU.

3.2.1 Initialization of our system

The system generates $G_{1}$, $G_{2}$, $P$, and $e$: $G_{1 }\times \quad G_{1 }\rightarrow$ $G_{2}$; and it defines the following functions:

$$\begin{aligned} \begin{array}{l} H_1 :\left\{ {0,1} \right\} ^*\rightarrow G_1 ; \\ H_2 :G_2 \rightarrow \left\{ {0,1} \right\} ^n; \\ H_3 :\left\{ {0,1} \right\} ^n\times \left\{ {0,1} \right\} ^n\rightarrow Z_q ^*; \\ H_4 :\left\{ {0,1} \right\} ^*\rightarrow \left\{ {0,1} \right\} ^n; \\ f( x):x=x+ 1. \\ \end{array} \end{aligned}$$

In elliptic curve cryptography [20–22], a 160-bit key can achieve RSA’s 1,024-bit security. To make a trade-off between the security baseline and low computational loads for mobile devices, here we take 160 bits as the default value of our key length. Keys longer than 160 bits can of course have even higher security strength.

The detailed functions of these hashes are as follows:

$H_{1}$ :

is a map-to-point hash function, which converts an arbitrary string {0,1}* to a point on an elliptic curve $G_{1}$, e.g., the MapToPoint function in Boneh and Franklin’s [14] identity-based scheme.

$H_{2}$ :

is a hash function that maps a point on an elliptic curve $G_{2}$ to a fixed-length string.

$H_{3}$ :

is a one-way hash function that converts two fixed-length string $\{0,1\}^{n}$ to an integer in the $Z_{q}^{*}$ domain.

$H_{4}$ :

is a traditional hash function that maps an arbitrary string $\{0,1\}^{*}$ to a fixed-length string $\{0,1\}^{n}$ The system generates a random number $s$ as its private key and computes $P_{pub}$ = sP as its public key. It also makes its system parameters public, i.e., Params = {$G_{1}$, $G_{2}$, $q$, $P$, $P_{pub}$, $e$, $n$, $H_{1}$, $H_{2}$, $H_{3}$, $H_{4}$,$f(x)$}.

During initialization, each role in our protocol has a unique identifier: ID $_{T}$ for TTP, ID $_{SEi}$ for SE, ID $_{Sj}$ for rental service provider, and ID $_{Ck}$ for OBU, respectively. According to each role’s identifier, the system computes a public key for each of them, i.e., $Q_{ID}$ = $H_{1}$(ID), and generates their corresponding private key $S_{ID}$ = sQ $_{ID}$. Each role receives a pair of keys from the system at the initial stage. For an NFC phone, it has a key pair {$Q_{SEi}$, $S_{SEi}$} stored in the SE; for a TTP, it is {$Q_{T}$, $S_{T}$}; for a rental service provider, {$Q_{Sj}$, $S_{Sj}$}; for an OBU, {$Q_{Ck}$, $S_{Ck}$}, respectively.

As shown in Table 2, TTP’s AuthList includes: user’s identifier ID $_{SEi}$; user’s temporary identifier TID $_{i}$; the expiry date, ExpTime $_{i}$, of an anonymous license; a session key, SK $_{i,T}$, between a TTP and its user; and a key $K_{LICi}$ for TTP to encrypt an anonymous license. Initially, AuthList is an empty set, i.e. AuthList = $\phi$.

Table 2 Content of TTP’s AuthList

Table 3 depicts the content of TTP’s RentList: TID $_{i}$; the expiry date, RentTime $_{i}$, of a ticket; and a rental service provider’s identifier ID $_{Sj}$. Initially, RentList = $\phi$.

Table 3 Content of TTP’s RentList

Table 4 shows the content of a rental service provider’s CarList: TID $_{i}$; RentTime $_{i}$; SK $_{i,j}$; OBU’s identifier ID $_{Ck}$; and a flag ReturnConfirm, which is used to confirm vehicle return.

Table 4 Content of rental service provider’s CarList

After initialization, each role’s public and private information is listed in Table 5.

Table 5 List of public and private information

3.2.2 Function

This subsection clarifies the functions of each role; see Table 6.

Table 6 List of each role’s functions

• Encrypt() uses a key $K$ to encrypt message.    Input: $K$, message    Output: $C$    $C = E_{K}$(message)    return $C$

• Decrypt() uses $K$ to decrypt ciphertext $E_{K}$(message).    Input: $K$, $E_{K}$(message)    Output: message

• IBE_Encrypt() uses an ID-based cryptosystem [14] to encrypt message $M$ with the public key $Q_{ID}$ and returns $C$    Input: $M$, ID    Output: $C$    $\sigma \quad =$ {0,1}$^{n}$    $r=H_{3}(\sigma$, $M)$    $C$ = {rP, $\sigma \oplus H_{2}(e(Q_{\textit{ID}}$, $P_{pub})^{r})$, $M\oplus H_{4}(\sigma )$} = {$U$, $V$, $W$}    return $C$

• IBE_Decrypt() uses an ID-based cryptosystem to decrypt the ciphertext $C$ with the private key $S_{\textit{ID}}$. Then it verifies the user’s identity $U$ and returns $M$ or Reject.    Input: $C$, $S_{\textit{ID}}$    Output: $M$ or Reject    $V\oplus H_{2}(e(S_{\textit{ID}}$, $U))$ = $\sigma$    $W\oplus H_{4}(\sigma )=M$    Set $r=H_{3}(\sigma$, $M)$    if $U$ = rP    return $M$    else    return Reject

• ComputeSK() uses ID $_{A}$’s private key $S_{A}$ and {ID $_{B}$, $T_{B}$} to compute a session key SK $_{AB}$, whose key agreement is based on Zhang et al.’s [18] scheme. $k$ denotes a random number generated by ID $_{A}$.    Input: $k$, $S_{A}$, ID $_{B}$, $T_{B}$    Output: SK $_{AB}$    $Q_{B}=H_{1}$(ID $_{B})$    $K_{A}=e(T_{B}+Q_{B}$, kP $_{pub}+S_{A}) \quad e(Q_{B}$, $S_{A})$    SK $_{AB}=H_{4}$(ID $_{A} \, \vert \vert$ ID $_{B} \,\vert \vert \, K_{A}$ $\vert \vert$ kT $_{B})$    return SK $_{AB}$.

Fig. 3

Anonymous license issuing protocol

3.3 Proposed anonymous e-rental protocol

Our anonymous e-rental system consists of four parts: (1) issuing of anonymous license; (2) issuing of ticket; (3) verification of ticket; (4) vehicle control.

3.3.1 Anonymous license issuing protocol

The steps of our license issuing protocol are demonstrated in Fig. 3.

• Step 1 User’s car-rental APP requests a random number $T_{SEi}$ from SE.

• Step 2 SE generates a random number $a \in Z_{q}^{*}$, computes $T_{SEi}$ = aP, and returns the random value to the APP.

• Step 3 The APP generates a nonce Nonce $_{SEi} \in$ {0,1}$^{n}$; uses TTP’s public key $Q_{T}$ to encrypt {ID $_{SEi} \vert \vert T_{SEi} \vert \vert$ Nonce $_{SEi}$} as ciphertext $C$ and sends {ID $_{SEi}$,$C$} to TTP.

• Step 4 TTP perform the following actions:

  • (a) TTP uses his own private key $S_{T}$ to decrypt $C$ to derive {ID $_{SEi} \vert \vert T_{SEi} \vert \vert$ Nonce $_{SEi}$} and verifies whether the message is sent by ID $_{SEi}$.

  • (b) TTP generates a random number $b \in Z_{q}^{*}$ and a nonce Nonce $_{T} \in$ {0,1}$^{n}$. It also requires that $T_{T}$ = bP and Nonce $_{SEi}'=f$(Nonce $_{SEi})$.

  • (c) TTP uses user’s public key $Q_{SEi}$ to encrypt {ID $_{T} \vert \vert T_{T} \vert \vert$ Nonce $_{T} \vert \vert$ Nonce $_{SEi}'$} as ciphertext $C'$ and then returns {ID $_{T}$, $C'$} to the user.

• Step 5 APP forwards the message to SE, and SE’s actions include:

  • (a) SE uses $S_{SEi}$ to decrypt $C'$, obtains {ID $_{T} \vert \vert T_{T} \vert \vert$ Nonce $_{T} \vert \vert$ Nonce $_{SEi}'$}, and verifies whether the message is sent by TTP.

  • (b) SE uses {$a$, $S_{SEi}$, ID $_{T}$, $T_{T}$} to compute the session key SK $_{i,T}$, shared with TTP.

  • (c) SE requires that Nonce $_{T}'=f$(Nonce $_{T})$; uses SK $_{i,T}$ to encrypt Nonce $_{T}'$ as Auth $_{SEi}$ and returns {Auth $_{SEi}$, Nonce $_{SEi}'$} to TTP.

• Step 6 After APP verifies Nonce $_{SEi}'$, it sends Auth $_{SEi}$ to TTP.

• Step 7 TTP’s actions include:

  • (a) TTP uses {$b$, $S_{T}$, ID $_{SEi}$, $T_{SEi}$} to compute the session key SK $_{i,T}$ using to decrypt Auth $_{SEi}$. Then it verifies Nonce $_{T}'$.

  • (b) TTP issues a temporary anonymous license:

    • (i) It computes the expiry date of the license ExpTime $_{i}$ = systemTime + validity.

    • (ii) It generates an anonymous identifier TID $_{i}\in$ {0,1}$^{n}$; a key $K_{LICi} \in$ {0,1}$^{n}$; and a session key SK $_{i,j} \in$ {0,1}$^{n}$ for the user and company.

    • (iii) It uses $K_{LICi}$ to encrypt {TID $_{i} \vert \vert$ ExpTime $_{i} \vert \vert$ SK $_{i,j}$} as an anonymous license License $_{i}$; also, it uses SK $_{i,T}$ to encrypt {TID $_{i} \vert \vert$ ExpTime $_{i} \vert \vert$ SK $_{i,j}$} as Auth $_{T}$.

  • (c) TTP stores {ID $_{SEi}$, TID $_{i}$, ExpTime $_{i}$, SK $_{i,T}$, $K_{LICi}$} into the list AuthList and returns {Auth $_{T}$, License $_{i}$} to the user.

• Step 8 APP forwards Auth $_{T}$ to SE. SE uses SK $_{i,T}$ to decrypt the message, obtains {TID $_{i} \vert \vert$ ExpTime $_{i} \vert \vert$ SK $_{i,j}$}, stores SK $_{i,j}$, and returns {TID $_{i}$, ExpTime $_{i}$} to APP.

• Step 9 APP stores {TID $_{i}$, ExpTime $_{i}$, License $_{i}$}.

3.3.2 Ticket issuing protocol

The steps of the ticket issuing protocol are illustrated in Fig. 4.

• Step 1 Users use the car-rental APP to search for available vehicles near their location. Users select their preferred vehicle and choose their planned rental period. The APP forwards the selected vehicle’s information {TID $_{i}$, RentTime $_{i}$, ID $_{Sj}$, ID $_{Ck}$, Price $_{Ck}$} to SE for encryption.

• Step 2 SE uses SK $_{i,T}$ to encrypt the vehicle information and then returns the ciphertext Auth $_{SEi}$ to APP.

• Step 3 APP sends {TID $_{i}$, ExpTime $_{i}'$, License $_{i}$, Auth $_{SEi}$} to the rental service provider.

• Step 4 The rental service provider sends {ID $_{Sj}$, TID $_{i}$, ExpTime $_{i}'$, Auth $_{SEi}$} to TTP.

• Step 5 TTP’s actions include:

  • (a) TTP verifies whether the license has expired by comparing ExpTime $_{i}'$ with ExpTime $_{i}$; checks the validity of TID $_{i}$; and checks if the license has been used somewhere. Any failure in the verification or checking will abort the session.

  • (b) TTP uses SK $_{i,T}$ to decrypt Auth $_{SEi}$; obtains {TID $_{i} \vert \vert$ RentTime $_{i} \vert \vert$ ID $_{Sj} \vert \vert$ ID $_{Ck} \vert \vert$ Price $_{Ck}$}; and verifies {TID $_{i}$, ID $_{Sj}$} so as to confirm the user’s reservation with the service provider. This prevents malicious rental service providers’ abuse of users’ personal data in fake deals.

  • (c) TTP returns {$K_{LICi}$, RentTime $_{i}$, ID $_{Ck}$, Price $_{Ck}$} to the rental service provider.

• Step 6 The rental service provider’s actions include the following:

  • (a) The service provider uses $K_{LICi}$ to decrypt License $_{i}$; obtains {TID $_{i} \vert \vert$ ExpTime $_{i} \vert \vert$ SK $_{i,j}$}; and verifies {TID $_{i}$, ExpTime $_{i}$, Price $_{Ck}$}.

  • (b) The service provider issues a temporary ticket for a specific vehicle.

    • (i) It generates a session key SK $_{i,k} \in$ {0,1}$^{n}$ for OBU and the user.

    • (ii) It uses $K_{SC}$ to encrypt {ID $_{Ck} \vert \vert$ TID $_{i} \vert \vert$ RentTime $_{i} \vert \vert$ SK $_{i,k}$} as Ticket $_{i}$ and uses SK $_{i,j}$ to encrypt the same message as Auth $_{Sj}$.

  • (c) The service provider stores {TID $_{i}$, RentTime $_{i}$, SK $_{i,k}$, ID $_{Ck}$, $\phi$} into CarList and runs following steps:

    • (i) It returns a confirmation message to TTP and the TTP stores {TID $_{i}$, RentTime $_{i}$, ID $_{Sj}$, Price $_{Ck}$} into RentList.

    • (ii) It returns {Ticket $_{i}$, Auth $_{Sj}$} to the user.

• Step 7 The APP forwards Auth $_{Sj}$ to SE. SE decrypts it with SK $_{i,j}$; obtains {ID $_{Ck} \vert \vert$ TID $_{i} \vert \vert$ RentTime $_{i} \vert \vert$ SK $_{i,k}$}; stores SK $_{i,k}$; and returns {ID $_{Ck}$, TID $_{i}$, RentTime $_{i}$} to APP.

• Step 8 After APP verifies {ID $_{Ck}$, TID $_{i}$, RentTime $_{i}$}, it stores {ID $_{Ck}$, TID $_{i}$, RentTime $_{i}$, Ticket $_{i}$}.

Fig. 4

Protocol of ticket issuing

3.3.3 Vehicle ticket verification protocol

Figure 5 shows the detailed steps of our ticket verification.

• Step 1 The user sends {ID $_{Ck}$, TID $_{i}$, RentTime $_{i}$} to SE through APP.

• Step 2 SE uses SK $_{i,T}$ to encrypt the vehicle info and then returns the ciphertext Auth $_{SEi}$ to APP.

• Step 3 APP forwards {Auth $_{SEi}$, Ticket $_{i}$} to OBU.

• Step 4 OBU’s actions include the following:

  • (a) OBU uses $K_{SC}$ to decrypt Ticket $_{i}$; obtains {ID $_{Ck} \vert \vert$ TID $_{i} \vert \vert$ RentTime $_{i} \vert \vert$ SK $_{i,k}$}; and uses SK $_{i,k}$ to decrypt Auth $_{SEi}$. Then it obtains {ID $_{Ck} \vert \vert$ TID $_{i} \vert \vert$ RentTime $_{i}$} and verifies it. If the verification fails, OBU ends the session.

  • (b) OBU stores {TID $_{i}$, RentTime $_{i}$, SK $_{i,k}$} and authorizes the user to control the vehicle.

Fig. 5

Protocol of ticket verification

3.3.4 Vehicle control protocol

Fig. 6

Protocol of vehicle control and return

Figure 6 shows the detailed steps of vehicle control.

• Step 1 APP sends user’s command to SE.

• Step 2 SE generates a nonce Nonce $\in$ {0,1}$^{n}$, uses SK $_{i,k}$ to encrypt {Command $\vert \vert$ Nonce} as CMD and returns CMD to APP.

• Step 3 APP forwards CMD to OBU.

• Step 4 OBU’s actions include the following:

  • (a) OBU checks users’ rental period. If the period is reached, OBU rejects user’s command.

  • (b) OBU uses SK $_{i,k}$ to decrypt CMD and then executes Command.

  • (c) If the command is Return, OBU sends TID $_{i}$ and returnTime $_{i}$ to its rental service provider.

• Step 5 The rental service provider stores current system time as the return time and sends returnTime $_{i}$ to TTP.

• Step 6 TTP clears its AuthList and RentList, and the user’s rental session is finalized.

4 Performance evaluation and security analysis

4.1 Performance evaluation and comparison

This section evaluates the performance of our proposed protocol. Detailed analysis of our computational loads are described as follows. We use $E$ to denote a symmetric key cryptographic function; $H$ a hash operation; nGx $n$ multi-exponentiations in group Gx; $R$a pseudo random number. The computational loads are listed in Table 7. As the table shows, most of the computational loads are required for our license issuing stage and the rest stages only run symmetric encryption and generate random numbers.

Table 7 Operation costs

On the NFC interface, the significant increase of computational loads occurs at the ticket verification stage, in which both Auth $_{SEi}$ and Ticket $_{i}$ are transmitted over the air. OBU uses $K_{SC}$ to decrypt Ticket $_{i}$; Ticket $_{i}$ contains encrypted {ID $_{Ck} \vert \vert$ TID $_{i} \vert \vert$ RentTime $_{i} \vert \vert$ SK $_{i,k}$}; and Auth $_{SEi}$ contains encrypted {ID $_{Ck} \vert \vert$ TID $_{i} \vert \vert$ RentTime $_{i}$}. If we assume the session key is 128 bits and others are all 32-bit integers, the payload in air transmission is 40 bytes plus packet headers.

Table 8 Comparison with other e-rental schemes

Tables 8 compares the functionality of our paper and related schemes. As shown in the table, all the protocols meet the requirement of anonymity, flexibility, and mutual authentication. As for unlinkability, Slamanig and Rass’s protocol [3] allows a service provider to issue multiple tokens to a user. Despite their user’s anonymity, the service provider can still find the relation between the user’s tokens. As for traceability, only Slamanig and Rass’s [3], Chen et al.’s [5] and our methods allow TTP to disclose users’ identity. The TTP in Vasco et al.’s [7] protocol can only store partial information of a user’s identity. Consequently, their service provider cannot request a user’s real identity from the TTP. As for anonymous payment, Slamanig and Rass’s [3], Blanton’s [6], and Lee et al.’s [8] methods do not implement this function.

The main difference between our e-rental car services and other online rental services lies in the legal issues and the value of the hired products. As driving requires a license and a car is a real object which is much more expensive than most things for rent online, an anonymous e-rental protocol has to take traffic regulations and rental agents’ risk evaluation into consideration. Although we guarantee a customer’s anonymity, we still have to allow the rental service providers to trace the identity of their renters under some special circumstances.

4.2 Security analysis

Anonymity

• At the stage of anonymous license issuing, only the TTP knows users’ real identity $\textit{ID}_{SEi}$.

• At the stage of vehicle ticket issuing, if users want to rent vehicles, they only need to send the anonymous license with a specific vehicle information to a rental service provider. The service provider does not know the user’s real identity.

• At the stage of vehicle ticket verification, the OBU in the vehicle does not know the user’s identity because the content of the ticket does not include the users’ real identity.

• Throughout the rental process, only TTP has the user’s real identity and anonymity is guaranteed in our protocol.

Confidentiality

Messages among user, TTP, rental service provider, and OBU are all protected by session keys SK $_{SETi}$, SK $_{SESi}$, SK $_{SECi}$, respectively. Consequently, adversaries cannot decrypt the ciphertexts to access the information.

Replay attack

At the stage of anonymous license issuing, the messages between user and TTP are encrypted with nonces such as {$T_{SEi}$, Nonce $_{SEi}$} and {$T_{T}$, Nonce $_{T}$}. Particularly, SE needs $T_{SEi}$ and $T_{T}$ to generate session key $SK_{i,T}$ Therefore if attackers replay earlier messages, they cannot pass our verification.

Considering if an attacker replays an expired anonymous license at the stage of issuing a vehicle ticket, because the rental service provider will verify the license with TTP, TTP will find that the license does not exist in its AuthList. If a license is replayed to a rental service provider within its rental period, TTP will find TID $_{i}$ is already stored in the RentList.

At the stage of ticket verification, if an attacker replays a vehicle ticket to an OBU within its rental period, the OBU will decline the request.

Man-in-the-Middle (MITM) attack

At the stage of anonymous license issuing, APP uses TTP’s public key $Q_{T}$ for encryption and then sends {ID $_{SEi}$, $C$} to TTP. Even though adversaries intercept the message, they do not have TTP’s private key to decrypt the ciphertext $C$. Thus, they cannot acquire {ID $_{SEi}$, $T_{SEi}$, Nonce $_{SEi}$}, and they cannot compute Nonce $_{SEi}'$ and the session key SK $_{i,T}$. In other words, since adversaries do not have users’ private key either, they are unable to decrypt $C$’, sent from TTP to users. Again, they cannot compute Nonce $_{T}'$ and SK $_{i,T}$. So, here adversaries are unable to launch MITM attacks by playing a user or a TTP.

At the stage of issuing a vehicle ticket, users’ rental info is encrypted with SK $_{i,T}$. Because attackers do not have this key, they cannot decrypt the message and find out the service provider information and the vehicle information. Therefore, they cannot act as a middle man and launch an MITM attack.

At the stage of vehicle ticket verification, because {ID $_{Ck} \vert \vert$ TID $_{i} \vert \vert$ RentTime $_{i}$} is encrypted with SK $_{i,k}$, attackers are unable to find which vehicle has been rented by the user without this key. They cannot launch an MITM attack under such a condition.

Backward secrecy

Our protocol guarantees backward secrecy.

At the stage of anonymous license issuing, even though we assume an attacker has $S_{SEi}$, $S_{T}$ and $s$, he cannot compute $a$ and $b \,\,$by using $T_{SEi}$ = aP and $T_{T}$ = bP. Therefore, he cannot compute the session key $K_{SEi}$ = $e(T_{T}+Q_{T}$, aP $_{pub}+S_{SEi}) \quad e(Q_{T}$, $S_{SEi})=e(T_{SEi}$ + $Q_{SEi}$, bP $_{pub}+S_{T}) \quad e(Q_{SEi}$, $S_{T})=K_{T}$, where $K_{SEi}$ = $K_{T}=e(P$, $P)^{abs} \quad e(P$, $Q_{T})^{as} \quad e(Q_{SEi}$, $P)^{bs} \quad e(Q_{SEi}$, $Q_{T})^{2s}$. Even though attackers may eavesdrop on $T_{SEi}$ = aP and $T_{T}$ = bP, it is still nearly impossible to compute abP from aP and bP. Even if an attacker gets the key SK $_{i,T}$, he cannot deduce the session keys of previous sessions.

At the stages of ticket issuing and ticket verification, the session keys SK $_{i,j}$ and SK $_{i,k}$ are randomly generated by a TTP and a rental service provider, respectively. Even though attackers can obtain each role’s private keys, they cannot break current session keys or decrypt messages of previous sessions.

Forward secrecy

Our protocol guarantees forward secrecy.

At the stage of anonymous license issuing, if an attacker obtains $S_{SEi}$, $S_{T}$ and $s$, he cannot predict the random numbers $a$ and $b$ to compute the following user TTP session keys.

At the stages of vehicle ticket verification, an attacker cannot deduce future session keys from current ones and each role’s private key, because SK $_{i,j}$ and SK $_{i,k}$ are randomly generated by a TTP and a rental service provider, respectively.

5 Proof

We use GNY proof [23] to examine the security of our protocol. Our security proof consists of four parts: (1) notations used in the proof; (2) initial assumptions; (3) goals at each stage; (4) detailed steps of our security proof. Table 9 details each step of our proof.

Table 9 GNY proof of our protocol

6 Conclusion

In this paper, we propose an anonymous e-rental protocol that features ID-based cryptography and NFC phone technology. A user can go through all the rental procedure on his NFC phone, and only TTP knows his real identity. Even his rental service provider and attackers cannot breach his privacy, abuse his personal data, or analyze his rental habits. But if there are consumer disputes or traffic accidents, the service provider is allowed to take a legal warrant to request the TTP to reveal the user’s real identity.

With the integration of bilinear pairing ID-based cryptography, our protocol is secure and efficient in the mobile environment. All the secrets and users’ sensitive information are stored in NFC phones’ secure elements. Compared with related schemes, our protocol can prevent attacks such as replay attacks and MITM attacks, and guarantees anonymity, confidentiality and forward/backward secrecy.