Blockchain-based Lightweight Authentication Mechanism for Vehicular Fog Infrastructure

TL;DR

This paper proposes a lightweight, blockchain-based authentication scheme utilizing elliptic curve cryptography for secure, scalable vehicular fog computing networks, addressing latency, mobility, and trust issues in vehicle-to-infrastructure communication.

Contribution

It introduces a novel decentralized authentication and key-exchange scheme combining blockchain and ECC tailored for vehicular fog computing environments.

Findings

Enhanced security features demonstrated in performance evaluations

Scheme is lightweight and scalable for vehicular fog networks

Outperforms existing authentication methods in security and efficiency

Abstract

With the increasing development of advanced communication technologies, vehicles are becoming smarter and more connected. Due to the tremendous growth of various vehicular applications, a huge amount of data is generated through advanced on-board devices and is deemed critical to improve driving safety and enhance vehicular services. However, cloud based models often fall short in applications where latency and mobility are critical. In order to fully realize the potential of vehicular networks, the challenges of efficient communication and computation need to be addressed. In this direction, vehicular fog computing (VFC) has emerged which extends the concept of fog computing to conventional vehicular networks. It is a geographically distributed paradigm that has the potential to conduct time-critical and data-intensive tasks by pushing intelligence (i.e. computing resources, storage, and application services) in the vicinity of end vehicles. However secure and reliable transmission are of significant importance in highly-mobile vehicular networks in order to ensure the optimal Quality of Service (QoS). In this direction, several authentication mechanisms have been proposed in the literature but most of them are found unfit due to absence of decentralization, anonymity, and trust characteristics. Thus, an effective cross-datacenter authentication and key-exchange scheme based on blockchain and elliptic curve cryptography (ECC) is proposed in this paper. Here, the distributed ledger of blockchain is used for maintaining the network information while the highly secure ECC is employed for mutual authentication between vehicles and road side units (RSUs). Additionally, the proposed scheme is lightweight and scalable for the considered VFC setup. The performance evaluation results against the existing state-of-the-art reveal that the proposed scheme accomplishes enhanced security features.

Figures

Tables

Table 1. TABLE I : Comparison of the security features provided by proposed scheme against the existing state-of-the-art [ 19 ] .

Scheme	[19]	Proposed
Supports Mutual Authentication	$\times$	$✓$
Supports Anonymity	$✓$	$✓$
Resists Replay	$\times$	$✓$
Resists Impersonation	$✓$	$✓$
Supports Forward Secrecy	$\times$	$✓$
Supports Confidentiality	$✓$	$✓$
Supports Integrity	$✓$	$✓$
Supports Non-interactivity	$✓$	$✓$
Supports Non-repudiation	$✓$	$✓$
Supports Key Exchange	$\times$	$✓$

Full text

I Introduction

With the emergence of information and communication technology, vehicles have become smarter than ever before. The integration of sensing, communication, and networking abilities in vehicles have enabled them to smartly interact with each other and with road-side units (RSU) in order to share information on a real-time basis. This information exchange capability of vehicles has led to the emergence of Vehicular adhoc Networks (VANETs), a key part of the intelligent transportation systems (ITS). These urban vehicular networks ensure a wide range of vehicle-based services for their intended users like road safety applications, smart traffic control, entertainment services, etc [1]. Nevertheless, with the penetration of millions of smart vehicles in the global market, a gigantic bunch of vehicular on-board facilities have been furnished which collect and exchange huge amounts of data, resulting in significant growth of the network traffic [2]. Although the conventional cloud computing architecture is known for providing a diverse range of services to vehicular networks, the long network distance between mobile devices and remote data centers hinders its performance while resulting in a high delay sensitivity [3]. Thus, the concept of vehicular fog computing (VFC) has evolved, in which computation, storage, and networking are hosted in close proximity to vehicles [4, 5]. The extension of the fog computing paradigm to conventional vehicular networks brings multiple opportunities to collect, process, organize, and store traffic data in real time. Locating the services close to end devices achieves better communication efficiency, seamless data processing, location awareness, and real-time response while minimizing latency along with other constraints. However, in order to ensure the desirable quality of service (QoS), an optimal balance between performance, security, and privacy requirements has become prominent [6, 7].

In this direction, several authentication protocols have been proposed for vehicular fog infrastructures. For example, Kang et al. [8] proposed a privacy-preserved pseudonym scheme to address the location privacy issues in VFC. Likewise, Yao et al. [9] presented a three-layered framework to ensure the reliability and security of VFC while preserving its performance. Considering the importance of vehicular crowdsensing in transportation, Wei et al. [10] proposed a fog-based privacy-preserving scheme for conditional road surface monitoring. In a similar direction, Basudan et al. [11] also devised a privacy-preserving protocol to enhance the security of the vehicular crowdsensing network. To provide secure data transmission in VFC, Wang et al. [12] proposed a reliable and privacy-preserving task recomposition based on Paillier encryption. In [13], Kong et al. also used homomorphic Paillier cryptosystem to design a secure querying scheme for data dissemination in VFC. Likewise, a new privacy-preserving route-sharing scheme for VFC was devised in [14] to protect user and group privacy. Although several authentication schemes exists in the literature, most of them fail to provide data auditability, in case the central server crashes. Moreover, the existing approaches also incurs high computational cost and communication overhead due to large number of interactions among users and data centers [15].

In order to provide information confidentiality, mutual authenticity, privacy, and anonymity, records should be kept in a distributed manner. Thus, blockchain has emerged as a feasible solution to achieve such goals. A blockchain is a decentralized and distributed ledger in which a digital record of transactions is maintained across blocks without requiring a central authority. All the blocks in the blockchain are linked in a chronological order to form a chain and secured using cryptography. Since, central managers are not involved in the blockchain structure, it is more robust against single point failure issues. Due to its wide range of benefits, blockchain-based applications, ranging from financial services to Internet of Things (IoT), are constantly expanding. Motivated by these facts, several approaches were developed in the literature in order to provide authentication in vehicular networks. For example, Lei et al. [16] put forward a novel network topology based on a decentralized blockchain structure; wherein a blockchain was employed to simplify the distributed key management in vehicular communication systems. Kang et al. [17] adopted the concept of consortium blockchain to achieve secure data storage and sharing in vehicular edge networks. To support conditional privacy, one-to-many matching, destination matching, and data auditability in VFC, Li et al. [18] proposed an efficient and privacy preserving car-pooling scheme using blockchain. Accordingly, Yao et al. [19] presented a lightweight anonymous authentication mechanism for distributed vehicular fog services using blockchain. Their primary focus was on cross-data center authentication using blockchain and cryptographic functions. However, the designed scheme did not support mutual authentication between vehicles and service managers (SMs), which is a prerequisite for any secure authentication protocol.

I-A Contributions

It is evident from the above discussion that a number of approaches have been proposed for VFC infrastructures but limited works have been carried out with respect to cross-data center authentication for accessing VFS, which is deemed important for providing any service in VFC scenarios. Keeping in view the necessity of accessing the VFS with reduced latency and overhead while maintaining an adequate level of security, it is essential to design a cross-datacenter authentication and key-exchange mechanism that is not only secure but also lightweight. Additionally, the literature also suggest that the existing approaches are primarily focused on centralized architectures which fall short in maintaining the network information across a distributed setup such as vehicular fogs in a profitable manner. Thus, the major contributions of the proposed work can be summarized as follows:

• •

We present an effective cross-datacenter authentication and key-exchange scheme using blockchain and Elliptic curve cryptography (ECC). Here, the distributed ledger of blockchain is used for maintaining the network information while the highly secure ECC is employed for mutual authentication between vehicles and RSUs.

• •

The proposed scheme has been purposefully designed to be lightweight while provisioning the facility of re-authentication to participating vehicles.

• •

The design goals of the proposed lightweight mechanism include cross-data center authentication, user anonymity, mutual authentication, user privacy and confidentiality.

• •

Lastly, the proposed scheme has been extensively evaluated with the existing state-of-the-art in terms of security features and computational and communicational overheads. Additionally, the safeness of the designed authentication and key-exchange mechanism has been validated using the well-known AVISPA tool.

I-B Organization

The rest of this paper is organized as follows: Section II illustrates the system model of the proposed work followed by the proposed authentication mechanism in Section III. Moreover, detailed analysis of the security features and performance analysis are illustrated in Section IV. Finally, the conclusions are summarized in Section V.

II System Model

A high level diagram considered in the proposed work is depicted in Fig. 1 and is inspired from the work carried out in [19, 9]. As shown in the figure, the considered vehicular fog computing environment primarily consists of the following entities which actively participate in provisioning the designed authentication and key exchange solution in the considered VFC setup based on blockchain and ECC.

$\bullet$ Region: The considered VFC setup can be segregated into different regions comprised of different vehicular fog data-centers (VFDs) responsible of provisioning VFS to the intended users. Further each region may encapsulate one or many RSUs and a single service manager (SM) and witness peer (WP).

$\bullet$ Road Side Unit: In VANETs, RSUs are the communicating nodes which provide different safety and entertainment services to vehicles and further relay the required information amongst each other. In the considered VFC scenario, a RSU manages a VFD and provides VFSs to the legitimate users.

$\bullet$ **On-board Unit (OBU): **These are mounted on the vehicles and help them to interact with each other (V2V) and with RSUs (V2I). They are powered with communicational, computational, and storage facilities. In the current context, OBUs are referred to VFS end-users which are required to be registered with the audit department (AD) to access the intended services.

$\bullet$ Audit Department: Here, the AD is a central trusted authority which is responsible of publishing the public parameters to employed cryptographic functions. Additionally, it is also a place of registration for the vehicles/OBUs and the SMs.

$\bullet$ Service Manager: The SM is essentially responsible for managing the blockchain network of a particular region. It is an authorized entity registered with the AD, which helps OBUs to authenticate and establish trust with the VFC infrastructure.

$\bullet$ Witness Peer: Every SM is associated with a witness peer (WP) that helps writing the authentication results to the public ledger. WP together with SM forms a consortium blockchain network and rely on Practical Byzantine Fault Tolerance (PBFT) for consensus establishment.

III Cross Data Center Authentication in VFC

The overall process of key exchange and authentication in the considered VFC environment can be segregated into the following five phases: 1) System Initialization Phase, 2) Registration Phase, 3) Mutual Authentication and Key Exchange Phase, 4) Consensus Phase, and 5) Service-Delivery Phase. The detailed description of these phases is presented below:

A. Phase I: System Initialization Phase

During this phase, the AD prepares the VFC environment for the upcoming phases of the proposed scheme. The detailed elaboration of this phase is as follows:

Step 1: The AD picks an elliptic curve $E$ with the public parameters $P$ and $n$. Here, the parameters refer to the base point of $E$ and a large prime number, respectively.

Step 2: The AD deduces its public and private key as ($\mathbb{SK}_{AD}$ & $\mathbb{PK}_{AD}$), where $\mathbb{SK}_{AD}\in Z_{p}^{*}$ and $\mathbb{PK}_{AD}=\mathbb{SK}_{AD}.P$. Here, the operation (.) denotes the ECC multiplicative operation.

Step 3: Finally, the AD declares the collision-resistant one-way hash functions ($H_{1}()$ and $H_{2}()$) to be used during the authentication and key exchange mechanism. With this, the parameters $<E,p,n,H_{1}(),H_{2}(),\mathbb{PK}_{AD}>$ are made public, i.e., are published.

B. Phase II: Registration Phase

During this phase, the OBUs and SMs register themselves with the AD over a secure channel. In order to maintain the OBUs’ and SMs’ anonymity, their respective identities ($\mathfrak{TD}_{OBU_{i}}$ and $\mathfrak{TD}_{SM_{j}}$) are never relayed in clear text as illustrated in Fig. 2.

Step 1: The OBU $i$ selects an identity $\mathfrak{TD}_{OBU_{i}}$ for itself and simultaneously generates a time stamp $T_{OBU_{i}}$. This time stamp helps in validating the relayed message and ensures that the messages are not relayed in the near future.

Step 2: The OBU then computes an intermediate token $\mathbb{TK}_{0}=\{\mathfrak{TD}_{OBU_{i}}||T_{OBU_{i}}\}$, followed by its encryption using the AD’s public key $\mathbb{PK}_{AD}$. The computed token $\mathbb{TK}_{0}$ value is then relayed to AD.

Step 3: Upon receiving, $\mathbb{TK}_{0}$, the AD then decrypts the message to extract the values of $\mathfrak{TD}_{OBU_{i}}$ and $T_{OBU_{i}}$. Following this, AD validates the time-stamp of the generated token. If $T_{OBU_{i}}$ falls within the permissible time window, then AD proceeds, else the connection is terminated. In the next phase, the AD validates the availability of $\mathfrak{TD}_{OBU_{i}}$ in its blockchain. If a match is found, the $i^{th}$ OBU is directed to generate a new identity for itself and the above process is repeated. Afterwards, the AD generates the private-public key pairs ($\mathbb{PK}_{OBU_{i}},\mathbb{SK}_{OBU_{i}}$) for the OBU and transmits the same over the secured channel. Additionally, the AD also computes, transmits, and stores the value of $l=H_{1}(\mathbb{SK}_{OBU_{i}}||\mathfrak{TD}_{OBU_{i}})\oplus H_{2}(\mathbb{SK}_{AD}||\mathfrak{TD}_{OBU_{i}})$ in its distributed ledger.

Step 4: The $i^{th}$ OBU then stores the values of $l$ and $\mathbb{SK}_{OBU_{i}}$ in its repository.

C. Phase III: Mutual Authentication and Key Exchange Phase

During this phase, the OBUs mutually authenticate with the SMs via the deployed RSU and share a session key for further connection. The entire process is detailed in Fig. 3 and discussed as follows.

Step 1: The $i^{th}$ OBU initially generates a random number $r_{1}$ and time stamp $T_{OBU_{i}}$. Following this, it performs two ECC multiplicative operations over $r_{1}$ to compute $R_{1}$ and $R_{2}$.

Step 2: Next, the OBU computes the values of the token $\mathbb{TK}_{OBU_{i}}=H_{1}(\mathbb{SK}_{OBU_{i}}||\mathfrak{TD}_{OBU_{i}})\oplus m$; which involves a $H_{1}(.)$, concatenation and XOR operations. Using this token, the value of OBU’s authentication token is estimated as follows: $\mathbb{A}uth_{OBU_{i}}=H_{1}(R_{2}||\mathfrak{TD}_{OBU_{i}}||T_{OBU_{i}}||\mathbb{TK}_{OBU_{i}})$. Finally, the values of $<\mathbb{A}uth_{OBU_{i}},~{}r_{1},~{}T_{OBU_{i}},~{}\mathfrak{TD}_{OBU_{i}}>$ are relayed to the $j^{th}$ SM via its RSU for further analysis.

Step 3: Upon receiving these values, the first step performed by $SM_{j}$ is validation of the time-stamp $T_{OBU_{i}}$. Upon successful validation, the SM fetches the value of $l$ from the registered list of OBU’s blockchain. Using this value, SM calculates an authentication token to validate the truthfulness of $\mathbb{A}uth_{OBU_{i}}$ as follows: $\mathbb{A}uth_{OBU_{i}}^{*}=H_{1}(r_{1}.\mathbb{PK}_{OBU_{i}}||\mathfrak{TD}_{OBU_{i}}||T_{OBU_{i}}||l)$. If the values of $\mathbb{A}uth_{OBU_{i}}$ and $\mathbb{A}uth_{OBU_{i}}^{*}$ match, then SM successfully establishes the authenticity of the $i^{th}$ OBU, else the connection is terminated.

Step 4: Next, $SM_{j}$ generates a random number, a time stamp ($T_{SM_{j}}$), and an authentication token ($\mathbb{A}uth_{SM_{j}}^{*}=H_{1}(r_{2}.\mathbb{SK}_{SM_{j}}||T_{SM_{j}}||\mathbb{TK}_{OBU_{i}})$) in the same manner as $OBU_{i}$. Additionally, it computes a session key, using key derivation function (kdf), to be used for further communication between the two parties as: $SK_{ij}=kdf(\mathfrak{TD}_{OBU_{i}}||l||T_{OBU_{i}}||T_{SM_{j}})$. Finally, the values of $<T_{SM_{j}},~{}r_{2},~{}\mathbb{A}uth_{SM_{j}}>$ are transmitted to the $i^{th}$ OBU for further processing.

Step 5: On receiving the values of $<T_{SM_{j}},~{}r_{2},~{}\mathbb{A}uth_{SM_{j}}>$, the OBU proceeds further only if the received time-stamp is found valid.

Step 6: Next, the OBU validates the authenticity of the SM by performing the following computations: $\mathbb{A}uth_{SM_{j}}^{*}=H_{1}(r_{2}.\mathbb{SK}_{SM_{j}}||T_{SM_{j}}||\mathbb{TK}_{OBU_{i}})$. The successful validation of $\mathbb{A}uth_{SM_{j}}^{*}$ and $\mathbb{A}uth_{SM_{j}}$ establishes the authenticity of the $j^{th}$ SM; this implies that both parties have successfully validated each other and are ready for further data transmission.

Step 7: Finally, $OBU_{i}$ computes the session key $SK_{ij}=kdf(\mathfrak{TD}_{OBU_{i}}||\mathbb{TK}_{OBU_{i}}||T_{OBU_{i}}||T_{SM_{j}})$.

D. Phase IV: Consensus Phase

In the proposed scheme, we consider a PFBFT consensus algorithm for forming the public ledger. The authentication results are transferred to the blockchain using the following steps.

Step 1: In the considered setup, we assume $n$ WPs with the ability to write a block to the public ledger. During the process of consensus, one of the WPs is marked as the “Speaker”; while the rest act as “Congressmen”. The selected speaker is responsible for holding the consensus mechanism and cannot participate in the voting mechanism. However, the speaker is expected to conduct $m$ rounds of consensus for saving the time involved in speaker selection. Here, the speaker $x$ is selected using the following evaluation: $x=(h\ mod\ n)+1$ where $h$ refers to the current block’s height.

Step 2: Post successful authentication and key exchange (as detailed in previous phase), the $j^{th}$ SM broadcasts the authentication results to all the WPs.

Step 3: Upon receiving the broadcast authentication results, the WPs store the results in their respective memories; before they can be transferred to the public ledger.

Step 4: After $t$ intervals, the blockchain containing the authentication results is created, which in then followed by the voting process. In the initial run, the speaker broadcasts a request to the congressmen to vote using $<{P}_{req},h,WP_{x},block,Sig_{WP_{x}}(block)>$. Here, the variable ${P}_{req}$ denotes speaker’s request others to vote.

Step 5: Post receiving the request, the $k^{th}$ WP share its vote using $<{P}_{res},h,WP_{k},block,Sig_{WP_{k}}(block)>$ wherein ${P}_{res}$ denotes $k^{th}$ WP’s response.

Step 6: Upon receiving the response from the WPs, the speaker reaches a consensus to publish the block to the public ledger.

E. Phase V: Service Delivery Phase

This particular phase provides OBU the facility to avail the VFS seamlessly without the need to re-authenticate when moving to a new region. Under such a scenario, the $i^{th}$ OBU sends an encrypted token $E_{PK_{SM_{j^{*}}}}(l)$ where $l=H_{1}(\mathbb{SK}_{OBU_{i}}||\mathfrak{TD}_{OBU_{i}})\oplus H_{2}(\mathbb{SK}_{AD}||\mathfrak{TD}_{OBU_{i}})$. Once the new SM, $j^{*}$, receives the request via the new RSU, then it decrypts the token to deduce $l$, and validates the existence of this token in its local database. If not found, it cross-checks the same in the public ledger. A match denotes that the authentication has been carried out sometime in the past. SM then checks the revocation list, if $l$ is not found then it is established that the $i^{th}$ OBU is valid and shall be seamlessly provided VFS without the need for re-authentication.

IV Results and Discussion

This section presents the performance evaluation of the proposed scheme against the current state-of-the-art. For the detailed performance evaluation, the comparison has been performed in terms of (1) security features (2) formal security verification using AVISPA and (3) computational and communicational overheads analysis. The corresponding details are mentioned as follows:

A. Security feature evaluation

The design goals of the proposed scheme have been highlighted in Section I-A. In accordance with these features, the relative comparison with an existing scheme based on blockchain has been detailed in Table I. It is evident from the comparison that the proposed scheme provisions higher number of security features. For instance, the proposed scheme provides mutual authentication between OBUs and SMs, enables key exchange functionality, resists replay attacks, and supports forward secrecy.

B. Formal security verification

In addition to the above validation, the execution of the proposed scheme was also formally verified using a well known tool-AVISPA. It is an open source suite of applications that is supportive in analyzing and verifying security protocols. In order to validate any designed security protocol, AVISPA needs the input in high level protocol specification language (HLPSL). The structure of HLPSL helps to describe the security protocol with intended security features and goals. The HLPSL defines the protocol in terms of different functions such as roles, transitions, composed role, and a top-level role named environment. Further, AVISPA relies on the support of four different back-ends to validate any designed security protocol. These backends are namely-on the fly model checker (OFMC), CL-based attack searcher (CL-AtSe), SAT-based model checker (SATMC), and tree automata-based protocol analyzer (TA4SP). The back-ends help validate the safeness of the proposed mechanism against the targeted security goals and provide the user with a detailed trace in case of violation.

In order to validate the proposed scheme, Phase III of the scheme has been coded in HLPSL and subjected to AVISPA to verify its safeness against different security attacks. The related results, depicted in Fig. 4, clearly show that the proposed authentication mechanism is safe on OFMC and CL-AtSe back-ends.

C. Computational and Communicational Overhead Analysis

In this section, the detailed analysis of the proposed scheme relative to an existing scheme [19] has been carried out in terms of computational and communicational overheads analysis. These results have been validated typically for Phase III since the majority of the computational and communicational overhead differences have been observed for this phase. In order to assess their performance, the experimental results derived by Yao et al. in [19] have been employed. The authors summarized the computational time required in executing the cryptographic hash function ($T_{h}$) and ECC-based multiplicative operation ($T_{ECC}$) in their work as 0.596 msec and 1.473 msec, respectively. The computational time with respect to XOR and concatenation is assumed to be negligible. Further, the time for executing kdf operations has not been evaluated since it is used for session key generation that is performed only in the proposed scheme.

In total, the proposed scheme executes a total of 5 hash functions and 6 ECC-based multiplicative operations, against a total of 5 and (k+3) operations respectively by the existing scheme. Thus, the total computational overhead associated with single pass of Phase III is $5\times T_{h}+6\times T_{ECC}$ (in the proposed scheme) and $5\times T_{h}+(k+3)\times T_{ECC}$ (in the existing scheme). On the basis of this observation, Fig. 5(a) and 5(b) summarize the results with respect of variable number of vehicles and SMs. It is evident from Fig. 5(a) that the computational overhead increases when increasing the number of vehicles which can be attributed to the increasing number of authentication requests. However, the results clearly showcase that the proposed scheme depicts superior results compared to the existing scheme. Additionally, the results obtained in Fig. 5(b) clearly show that the proposed scheme is scalable and is not affected by the increase in the number of SMs. On the other hand, the computational overhead of the existing scheme rises significantly when increasing the number of SMs.

Apart from the above comparison, Figs. 5(c) and 5(d) highlight the communicational overhead associated with the two schemes for a variable number of vehicles and SMs respectively. The comparison is based upon the number of token transmitted between the OBUs and SMs during the authentication process. For the proposed scheme, the following tokens $<\mathbb{A}uth_{OBU_{i}},~{}r_{1},~{}T_{OBU_{i}},~{}\mathfrak{TD}_{OBU_{i}},T_{SM_{j}},~{}r_{2},~{}\mathbb{A}uth_{SM_{j}}>$ were communicated between the two parties which results to a total of 7 tokens. Meanwhile, a total of $k+2$ tokens were sent in the existing scheme. It is evident from the results that, for the scenarios, the existing scheme experiences constant increase in the communicational overhead compared to the proposed scheme. It is worth noticing that the proposed scheme is unaffected by the number of SMs and and experiences less overhead even with increase in number of vehicles. Thus, it can be concluded that the proposed scheme is lightweight compared to the existing scheme.

V Conclusion

VFC has emerged as a promising candidate for the provisioning of different services including safety and infotainment in modern ITS. However, its growing popularity is accompanied with a gigantic array of security attacks. Thus, it is essential to safeguard these networks against different attack vectors. In this direction, provably secure authentication and key exchange policies are essential. Therefore, in this paper, a lightweight authentication and key exchange mechanism for VFC infrastructures has been proposed. The designed mechanism is based on ECC and blockchain; which helps vehicles to seamlessly access VFS with the following features: cross-data center authentication, user anonymity, mutual authentication, lightweight, user privacy and confidentiality. The extensive performance assessment of the proposed mechanism established its superiority in terms of reduced communicational and computational overheads with enhanced security features relative to an existing scheme.