EASPSC: Efficient authentication of SignRecryption protocol using shareable clouds in VANET groups

Abstract

Vehicular ad hoc networks (VANET) is one of the most awaited and ambitious projects of Intelligent Transport System (ITS), where vehicles are permitted to talk with each other. The ultimate goal of the network is to develop a connected network of automobiles, and eventually to reduce traffic and accidents. However, VANET is an ad hoc network without any infrastructure. Apart from architectural issues, there are plenty of security and performance issues, which makes it difficult to be implemented. Therefore, we are using fully authenticated Signcryption technique along with re-cryptography and shareable cloud to make the network safe, reliable and robust. Signcryption combines signature and encryption in a single step, hence decreasing the number of computations. Re-cryptography allows alternative authorities to take charge of the primary authority while maintaining communication transparency. Group signature facilitates secure communication within the group. Security has been verified using Burrows-Abadi-Needham (BAN) logic and Automated Validation of Internet Security Protocols and Applications (AVISPA).

Appendices

Appendix A: BAN Logic Rules and Assumptions for EASPSC

BAN logic rules are directly imported from [14] in our protocol to derive new logical derivations as below:

• 1. $P|\equiv (P \overset {\text {K}}{\leftrightarrow }Q) \wedge P\triangleleft (X)_{K}$: K is the secret shared between P and Q only, and P sees X is encrypted with K, So, P believes that Q once believed and said X.

  P ≡ (Q|≡ X)

• 2. P|≡ (Q|⇒ X) ∧ P|≡ (Q|≡ X): P believes Q has jurisdiction over X and it can be trusted for the truth of X, and P believes that Q believes X, so, P also believes that X is true.

  P|≡ X

• 3. $P|\equiv (Q| \sim X) \wedge P|\equiv Q|\equiv \#X$ P believes that Q once said X, and P believes that Q believes X is fresh, hence P believes in truthiness and freshness of X.

  P|≡ #X

Following assumptions are taken into consideration in our protocol:

• – MM₁ and MM₂ have agreed upon to share secret key SSK₁ and to create a re-encryption key using this.

  • MM₁ securely sends SSK₁ to MM₂$MM_{1}|\sim SSK_{1}$

  • MM₂ believes SSK₁ sent by MM₁ is fresh.

    $\frac {MM_{2} \triangleleft SSK_{1} \wedge MM_{2} |\equiv \#SSK_{1}} {MM_{2} |\equiv MM_{1} |\equiv SSK_{1}}$

  • MM₁ believes that this key has been known only to MM₂ and itself.

    MM₁|≡ $(MM_{1} \overset {\text {SSK1}}{\leftrightarrow } MM_{2})$

  • MM₂ believes that this key has been known only to MM₁ and itself.

    $MM_{2} |\equiv (MM_{2} \overset {\text {SSK1}}{\leftrightarrow } MM_{1})$

• 2. MM₂ and MM₁ have agreed upon to share secret key SSK₂ and to create a re-signature key using this.

  • MM₂ securely sends SSK₂ to MM₁$MM_{2}|\sim SSK_{2}$

  • MM₁ believes SSK₂ sent by MM₂ is fresh. $\frac {MM_{1} \triangleleft SSK_{2} \wedge MM_{1} |\equiv \#SSK_{2}} {MM_{1} |\equiv MM_{2} |\equiv SSK_{2}}$

  • MM₁ believes that this key has been known only to MM₂ and itself. MM₁|≡ $(MM_{1} \overset {\text {SSK2}}{\leftrightarrow } MM_{2})$

  • MM₂ believes that this key has been known only to MM₁ and itself. $MM_{2} |\equiv (MM_{2} \overset {\text {SSK2}}{\leftrightarrow } MM_{1})$

• 3. M₁ and proxy have agreed upon to share re-encryption key.

  • MM₁ securely sends re-encryption key to proxy. $MM_{1}| \sim rk_{12}$

  • Proxy believes that re-encryption key sent by MM₁ is fresh. $\frac {Proxy \triangleleft rk_{12} \wedge Proxy |\equiv \#rk_{12}} {Proxy |\equiv MM_{1} |\equiv rk_{12}}$

  • MM₁ believes that this key has been known only to proxy and itself. $MM_{1} |\equiv (MM_{1} \overset {\text {rk}_{12}}{\leftrightarrow } Proxy)$

  • Proxy believes that this key has been known only to MM₁ and itself. $Proxy |\equiv (Proxy \overset {\text {rk}_{12}}{\leftrightarrow } MM_{1})$

• 4. MM₂ and Proxy shares the re-signature key.

  • MM₂ securely sends re-signature key to proxy. MM₂|˜rs

  • Proxy believes that re-signature key sent by MM₂ is fresh. $\frac {Proxy \triangleleft rs_{21} \wedge Proxy |\equiv \#rs_{21}} {Proxy |\equiv MM_{2} |\equiv rs_{21}}$

  • MM₂ believes that this key has been known only to proxy and itself. $MM_{2} |\equiv (MM_{2} \overset {\text {rs}_{21}}{\leftrightarrow } Proxy)$

  • Proxy believes that this key has been known only to MM₂ and itself. $Proxy |\equiv (Proxy \overset {\text {rs}_{21}}{\leftrightarrow } MM_{2})$

• 5. All authorities and entities assume that the pre-shared information and the communication channels are safe. $MM_{2} |\equiv (\overset {{\upomega }}{\rightarrow } MM_{1}) \wedge A |\equiv (\overset {{\upomega }}{\rightarrow } MM_{1}) \wedge Proxy |\equiv \overset {{\upomega }}{\rightarrow } MM_{1} \wedge Cloud |\equiv \overset {{\upomega }}{\rightarrow } MM_{1}$$MM_{2} |\equiv (\overset {\text {PKc}}{\rightarrow } Cloud) \wedge A |\equiv (\overset {\text {PKc}}{\rightarrow } Cloud) \wedge MM_{1} |\equiv \overset {\text {PKc}}{\rightarrow } Cloud$$MM_{1} |\equiv (\overset {{\uppi }}{\rightarrow } MM_{2}) \wedge Proxy |\equiv \overset {{\uppi }}{\rightarrow } MM_{2} \wedge Cloud |\equiv \overset {{\uppi }}{\rightarrow } MM_{2}$$MM_{2} |\equiv (\overset {\text {PKp}}{\rightarrow } Proxy)\hspace {7.8mm} \wedge \hspace {1.5mm} MM_{1} |\equiv \overset {\text {PKp}}{\rightarrow } Proxy$$MM_{1} |\equiv (MM_{1} \overset {\text {W}}{\leftrightarrow } A)$ ∧ $A |\equiv (MM_{1} \overset {\text {W}}{\leftrightarrow } A)$$MM_{1} |\equiv (MM_{1} \overset {\text {X}}{\leftrightarrow } Proxy)$ ∧ $Proxy |\equiv (MM_{1} \overset {\text {X}}{\leftrightarrow } Proxy)$$MM_{1} |\equiv (MM_{1} \overset {\text {Y}}{\leftrightarrow } MM_{2})$ ∧ $MM_{2} |\equiv (MM_{1} \overset {\text {Y}}{\leftrightarrow } MM_{2})$$MM_{1} |\equiv (MM_{1} \overset {\text {Z}}{\leftrightarrow } Cloud)$ ∧ $Cloud |\equiv (MM_{1} \overset {\text {Z}}{\leftrightarrow } Cloud)$

• 6. All Public keys have their respective private keys, such as ω (public key of MM₁) has ω^− 1, π (public key of MM₂) has π^− 1 etc. But these private keys are unknown to any other entity. As, we know if the message is encrypted with private keys, it can be decrypted with corresponding public key. Hence, if any entity is able to decrypt any message with member’s public key, it assumes that the message is signed by that particular member. Here we denote it as $sign_{MM_{1}}$, $sign_{MM_{2}}$ and so on.

Role 1

Role MM₁

Role 2

Role Proxy

Appendix B: HLPSL code for roles of network entities

1.1 B.1 MM₁

M₁ must keep re-encryption keys secret from outsiders. Hence, we have protocol id as sec_P_M1,sec_A_M1 and sec_C_M1, which have been declared in goal section as well. The goal of this step is to keep re-encryption keys secret from other entities which are not involved. Rk12 is secret between M1 and Proxy, whereas Rkc is secret between M1 and cloud only. Since M2 is doing the task of registration, role of M1 ends here. wrequest and witness are the predicates to represent authentication goal, and secret represents the goal to protect secrecy of the data.

1.2 B.2 Proxy

Proxy receives the new nonce of re-encryption key from M1 which is encrypted with public key of proxy, P1. It receives Regreq encrypted with W1 (public key of M1) and sends Regreq encrypted with W2 (Public key of M2). Similarly, it receives re-signature key from MM2. Later, it fetches Regrep1 encrypted with MM2’s sign and sends Regrep1 encrypted with MM1’s sign in the network. The role of proxy ends here.

Role 3

Role V₁

Role 4

Role MM₂

1.3 B.3 Vehicle

Vehicle must keep Registration request secret from outsiders. Hence, we have protocol id as sec_A_M1 as a goal in this step. It sends registration request, routing request, and receives their replies. It also authenticates MAC₄ and MAC₂ after receiving from Regreq and RRep respectively.

1.4 B.4 MM₂

Role 5

Role V₂

Role 6

Role Cloud

M₂ must keep shared secret key, registration reply and re-signature key secret from outsiders. Rs21 is secret between M2 and Proxy, whereas SSK2 is secret between M1 and M2 only. RegRep is the secret between M2 and V1. Protecting these three is the secrecy goal of M2. Hence, we have protocol id as and sec_P_M2, sec_M2_M1,and sec_A_M2 respectively for each goal.

1.5 B.5 Cloud

Cloud receives Routing request from vehicle as MAC₃ and sends routing reply as MAC_2. These two are authenticated using authentication predicates wrequest and witness over MAC_3 and MAC_2 by the protocol id mac3_auth and mac2_auth, respectively.

1.6 B.6 Vehicle2

Second vehicle is just to show the presence of a random vehicle in the network. V₂ receives BSM sent by V₁, which is signed by group signature of V₁’s group.

1.7 B.7 Goal of Simulation

This section gives the secracy goals and authentication goals of various roles given above. AVISPA checks whether each goal is satisfied, if not, it outputs that the protocol is “not safe”.goal