Blockchain-based Lightweight Authentication Mechanism for Vehicular Fog Infrastructure

Blockchain-based Lightweight Authentication Mechanism for Vehicular Fog Infrastructure

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 with reduced computational and communicational overheads. Further, its extensive evaluation on the widely applicable Automated Validation of Internet Security Protocols and Applications (AVISPA) tool guarantee its safeness against different attack vectors.

Authentication protocol, Blockchain, Elliptic curve cryptography, Key exchange, and Vehicular fog computing

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.

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).

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.

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.

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.

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.

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.

Fig. 1: A typical vehicular fog computing scenario [19].

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 with the public parameters and . Here, the parameters refer to the base point of and a large prime number, respectively.

Step 2: The AD deduces its public and private key as ( & ), where and . Here, the operation (.) denotes the ECC multiplicative operation.

Step 3: Finally, the AD declares the collision-resistant one-way hash functions ( and ) to be used during the authentication and key exchange mechanism. With this, the parameters 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 ( and ) are never relayed in clear text as illustrated in Fig. 2.

OBU AD
-Selects
-Generates time stamp
-Computes
-Computes
-Decrypts
-Extracts and from
-Validates
-Check the availability of in
its blockchain
-Allocate unique Id to OBU
-Generates a random secret key ()
-Computes its public key using
-Computes
-Stores
       
-Saves
Fig. 2: Phase II: Registration Phase.

Step 1: The OBU selects an identity for itself and simultaneously generates a time stamp . 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 , followed by its encryption using the AD’s public key . The computed token value is then relayed to AD.

Step 3: Upon receiving, , the AD then decrypts the message to extract the values of and . Following this, AD validates the time-stamp of the generated token. If falls within the permissible time window, then AD proceeds, else the connection is terminated. In the next phase, the AD validates the availability of in its blockchain. If a match is found, the 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 () for the OBU and transmits the same over the secured channel. Additionally, the AD also computes, transmits, and stores the value of in its distributed ledger.

Step 4: The OBU then stores the values of and 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.

OBU SM
-Select a random number
-Generate time stamp
-Compute
-Compute
-Compute
-Compute
-Validate time stamp
-Fetch for the
-Compute
-Check
-If same, OBU is marked authentic; else tear down the connection
-Select a random number
-Compute
-Compute
-Generate time stamp
-Compute
-Compute
-Validate time stamp
-
-Check
-If same, SM is marked authentic; else connection terminated
-Compute
Fig. 3: Phase III: Mutual Authentication and Key Exchange Phase.

Step 1: The OBU initially generates a random number and time stamp . Following this, it performs two ECC multiplicative operations over to compute and .

Step 2: Next, the OBU computes the values of the token ; which involves a , concatenation and XOR operations. Using this token, the value of OBU’s authentication token is estimated as follows: . Finally, the values of are relayed to the SM via its RSU for further analysis.

Step 3: Upon receiving these values, the first step performed by is validation of the time-stamp . Upon successful validation, the SM fetches the value of from the registered list of OBU’s blockchain. Using this value, SM calculates an authentication token to validate the truthfulness of as follows: . If the values of and match, then SM successfully establishes the authenticity of the OBU, else the connection is terminated.

Step 4: Next, generates a random number, a time stamp (), and an authentication token () in the same manner as . Additionally, it computes a session key, using key derivation function (kdf), to be used for further communication between the two parties as: . Finally, the values of are transmitted to the OBU for further processing.

Step 5: On receiving the values of , 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: . The successful validation of and establishes the authenticity of the SM; this implies that both parties have successfully validated each other and are ready for further data transmission.

Step 7: Finally, computes the session key .

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 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 rounds of consensus for saving the time involved in speaker selection. Here, the speaker is selected using the following evaluation: where refers to the current block’s height.

Step 2: Post successful authentication and key exchange (as detailed in previous phase), the 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 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 . Here, the variable denotes speaker’s request others to vote.

Step 5: Post receiving the request, the WP share its vote using wherein denotes 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 OBU sends an encrypted token where . Once the new SM, , receives the request via the new RSU, then it decrypts the token to deduce , 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 is not found then it is established that the 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.

Scheme [19] Proposed
Supports Mutual Authentication
Supports Anonymity
Resists Replay
Resists Impersonation
Supports Forward Secrecy
Supports Confidentiality
Supports Integrity
Supports Non-interactivity
Supports Non-repudiation
Supports Key Exchange
TABLE I: Comparison of the security features provided by proposed scheme against the existing state-of-the-art [19].

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.

% OFMC % Version of 2006/02/13 SUMMARY SAFE DETAILS BOUNDED_NUMBER _OF_SESSIONS PROTOCOL /home/span/BlockECC.if GOAL as_specified BACKEND OFMC COMMENTS STATISTICS parseTime: 0.00s searchTime: 0.23s visitedNodes: 27 nodes depth: 4 plies SUMMARY SAFE DETAILS BOUNDED_NUMBER hspace*2mm_OF_SESSIONS TYPED_MODEL PROTOCOL /home/span/BlockECC.if GOAL As Specified BACKEND CL-AtSe STATISTICS Analysed : 0 states Reachable : 0 states Translation: 0.13 seconds Computation: 0.00 seconds
Fig. 4: Evaluation of mutual authentication and key exchange mechanism on AVISPA

C. Computational and Communicational Overhead Analysis

(a) Computational overhead Vs number of vehicles.
(b) Computational overhead Vs number of SMs.
(c) Communicational overhead Vs number of vehicles.
(d) Communicational overhead Vs number of SMs.
Fig. 5: An illustration of 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 () and ECC-based multiplicative operation () 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 (in the proposed scheme) and (in the existing scheme). On the basis of this observation, Fig. 4(a) and 4(b) summarize the results with respect of variable number of vehicles and SMs. It is evident from Fig. 4(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. 4(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. 4(c) and 4(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 were communicated between the two parties which results to a total of 7 tokens. Meanwhile, a total of 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.

References

  1. S. Garg and G. S. Aujla, “Accessing risk priority of SSL SYN attack using game theoretic attack defense tree model for VANETs,” in 3rd International Conference on Computing for Sustainable Global Development (INDIACom), New Delhi, India.   IEEE, March 2016.
  2. S. Garg, A. Singh, S. Batra, N. Kumar, and L. T. Yang, “UAV-Empowered Edge Computing Environment for Cyber-Threat Detection in Smart Vehicles,” IEEE Network, vol. 32, no. 3, pp. 42–51, 2018.
  3. K. Kaur, S. Garg, G. S. Aujla, N. Kumar, J. J. P. C. Rodrigues, and M. Guizani, “Edge Computing in the Industrial Internet of Things Environment: Software-Defined-Networks-Based Edge-Cloud Interplay,” IEEE Communications Magazine, vol. 56, no. 2, pp. 44–51, 2018.
  4. X. Hou, Y. Li, M. Chen, D. Wu, D. Jin, and S. Chen, “Vehicular Fog Computing: A Viewpoint of Vehicles as the Infrastructures,” IEEE Transactions on Vehicular Technology, vol. 65, no. 6, pp. 3860–3873, 2016.
  5. C. Zhu, G. Pastor, Y. Xiao, and A. Ylajaaski, “Vehicular Fog Computing for Video Crowdsourcing: Applications, Feasibility, and Challenges,” IEEE Communications Magazine, vol. 56, no. 10, pp. 58–63, 2018.
  6. C. Huang, R. Lu, and K.-K. R. Choo, “Vehicular fog computing: architecture, use case, and security and forensic challenges,” IEEE Communications Magazine, vol. 55, no. 11, pp. 105–111, 2017.
  7. S. Garg, K. Kaur, N. Kumar, and J. J. P. C. Rodrigues, “Hybrid Deep-Learning-Based Anomaly Detection Scheme for Suspicious Flow Detection in SDN: A Social Multimedia Perspective,” IEEE Transactions on Multimedia, vol. 21, no. 3, pp. 566–578, 2019.
  8. J. Kang, R. Yu, X. Huang, and Y. Zhang, “Privacy-preserved pseudonym scheme for fog computing supported internet of vehicles,” IEEE Transactions on Intelligent Transportation Systems, vol. 19, no. 8, pp. 2627–2637, 2018.
  9. Y. Yao, X. Chang, J. MiÅ¡ić, and V. MiÅ¡ić, “Reliable and Secure Vehicular Fog Service Provision,” IEEE Internet of Things Journal, vol. 6, no. 1, pp. 734–743, 2019.
  10. J. Wei, X. Wang, N. Li, G. Yang, and Y. Mu, “A Privacy-Preserving Fog Computing Framework for Vehicular Crowdsensing Networks,” IEEE Access, vol. 6, pp. 43 776–43 784, 2018.
  11. S. Basudan, X. Lin, and K. Sankaranarayanan, “A privacy-preserving vehicular crowdsensing-based road surface condition monitoring system using fog computing,” IEEE Internet of Things Journal, vol. 4, no. 3, pp. 772–782, 2017.
  12. B. Wang, Z. Chang, Z. Zhou, and T. Ristaniemi, “Reliable and privacy-preserving task recomposition for crowdsensing in vehicular fog computing,” in 87th Vehicular Technology Conference (VTC Spring), Porto, Portugal.   IEEE, June 2018.
  13. Q. Kong, R. Lu, M. Ma, and H. Bao, “A Privacy-Preserving and Verifiable Querying Scheme in Vehicular Fog Data Dissemination,” IEEE Transactions on Vehicular Technology, vol. 68, no. 2, pp. 1877–1887, 2019.
  14. M. Li, L. Zhu, Z. Zhang, X. Du, and M. Guizani, “PROS: A Privacy-Preserving Route-Sharing Service via Vehicular Fog Computing,” IEEE Access, vol. 6, pp. 66 188–66 197, 2018.
  15. N. Kumar, K. Kaur, S. C. Misra, and R. Iqbal, “An intelligent RFID-enabled authentication scheme for healthcare applications in vehicular mobile cloud,” Peer-to-Peer Networking and Applications, vol. 9, no. 5, pp. 824–840, 2016.
  16. A. Lei, H. Cruickshank, Y. Cao, P. Asuquo, C. P. A. Ogah, and Z. Sun, “Blockchain-based dynamic key management for heterogeneous intelligent transportation systems,” IEEE Internet of Things Journal, vol. 4, no. 6, pp. 1832–1843, 2017.
  17. J. Kang, R. Yu, X. Huang, M. Wu, S. Maharjan, S. Xie, and Y. Zhang, “Blockchain for Secure and Efficient Data Sharing in Vehicular Edge Computing and Networks,” IEEE Internet of Things Journal, 2018, DOI: 10.1109/JIOT.2018.2875542.
  18. M. Li, L. Zhu, and X. Lin, “Efficient and Privacy-preserving Carpooling using Blockchain-assisted Vehicular Fog Computing,” IEEE Internet of Things Journal, 2018, DOI: 10.1109/JIOT.2018.2868076.
  19. Y. Yao, X. Chang, J. Mišć, V. B. Mišć, and L. Li, “BLA:Blockchain-Assisted Lightweight Anonymous Authentication for Distributed Vehicular Fog Services,” IEEE Internet of Things Journal, 2019, DOI: 10.1109/JIOT.2019.2892009.
Comments 0
Request Comment
You are adding the first comment!
How to quickly get a good reply:
  • Give credit where it’s due by listing out the positive aspects of a paper before getting into which changes should be made.
  • Be specific in your critique, and provide supporting evidence with appropriate references to substantiate general statements.
  • Your comment should inspire ideas to flow and help the author improves the paper.

The better we are at sharing our knowledge with each other, the faster we move forward.
""
The feedback must be of minimum 40 characters and the title a minimum of 5 characters
   
Add comment
Cancel
Loading ...
349777
This is a comment super asjknd jkasnjk adsnkj
Upvote
Downvote
""
The feedback must be of minumum 40 characters
The feedback must be of minumum 40 characters
Submit
Cancel

You are asking your first question!
How to quickly get a good answer:
  • Keep your question short and to the point
  • Check for grammar or spelling errors.
  • Phrase it like a question
Test
Test description