Content uploaded by Suchetana Chakraborty
Author content
All content in this area was uploaded by Suchetana Chakraborty on Mar 25, 2021
Content may be subject to copyright.
BlockAPP: Using Blockchain for Authentication
and Privacy Preservation in IoV
Rohit Sharma
Department of Research and Development,
Tejas Networks Ltd.,
Bangalore, Karnataka, India
Email: rohitsha@india.tejasnetworks.com
Suchetana Chakraborty
Department of Computer Science and Engineering,
Indian Institute of Information Technology Guwahati,
Guwahati, Assam, India
Email:suchetana@iiitg.ernet.in
Abstract—Recent proliferation in disruptive technologies has
opened up a new horizon for Internet of Vehicles (IoV). The
success of IoV highly depends on the robustness of vehicular
information system as a dispute among the service providers
on data rights or any kind of security violation could disrupt
the transport services altogether. In this work we propose a
blockchain based novel architecture for vehicle authentication
and privacy preservation with seamless access control for IoV.
Proposed architecture is decentralized, robust and scalable.
Along with privacy preserving authentication and conflict-free
access-log maintenance, the proposed BlockAPP protocol also
supports an optional traceability feature. Performance evaluation
using smart contact over Ethereum Blockchain validates the
effectiveness of the proposed architecture.
I. INTRODUCTION
Rapid urbanization and revolutionary technological ad-
vancements in the field of cyber-physical systems have con-
ceived a connected world, called Internet of Things. Internet of
Vehicles (IoV) is a special case of IoT where vehicles, capable
of sensing and communicating, along with mobile devices
carried by on-board humans are connected to Internet to serve
quality transport services. IoV architecture supports both V2V
(vehicle-to-vehicle) and V2I (vehicle-to-infrastructure) com-
munication to enable inter-vehicular interaction and thus cre-
ates a large dynamic network of vehicles spanning over a city,
or even a country sometimes. These connected vehicles share a
strong spatio-temporal correlation. A coordinated interaction
among these vehicles integrated with the IoT system would
help in building up a massive scale vehicular information
system (VIS). Different ITS applications operate on the basis
of this VIS to offer services towards road safety [4], traffic
management [3], and infotainment [19].
Quality of all transport services depends on the robustness
and availability of the VIS. Although the availability of data
can be assured with the exponentially increasing number of
vehicles, ensuring robustness would be challenging due to
the following characteristics of IoV. Firstly, unlike IoT, the
mobility of vehicles is restricted by the road distribution,
which restricts the contact time between two communicating
vehicles. Second, the information flow is two-way: vehicles
send sensory data packets to the server and also receive
packets defining services subscribed to. In between the servers
and vehicles there exist multiple access points like RSUs,
cloud servers or cell towers along the information flow. Third,
vehicles can subscribe to multiple services at the same time
and opt out certain service at any point of time. However,
critical services related to road traffic and safety are assumed
to be non-optional and subscribed by all vehicles. Finally, there
exists a huge scope of dispute among the service providers
with respect to access control and data rights, which also may
threaten the privacy policy.
The problem of enforcing robust data management in
IoV is multifold [18]. In this work, we mainly focused on
two major aspects of robustness: authentication and privacy
preservation. As vehicles communicate through open wireless
media and information passes through multiple intermediate
access points, there is a possibility of malicious vehicles to
create an unnecessary disturbance on road by broadcasting
fake traffic jam or accident information. It is important to
authenticate both the communicating parties, service providers
and vehicles. Authentication procedure requires vehicle identi-
fication to be disclosed, which actually imposes privacy threats
to the concerned vehicle. Vehicle identification along with
location profiling and misuse of private data by the service
providers or malicious users violate the privacy policy and
could cause personal or large-scale societal loss. However,
privacy preservation for ensuring non-traceability gives an
opportunity to the malicious vehicles to hide their identity
conveniently. Therefore, the challenge lies in designing a
robust data management platform to ensure authentication and
privacy preservation with the support of restricted vehicle
traceability.
II. RE LATE D WOR K
The problem of vehicle authentication in VANET envi-
ronment has been explored for quite a long time. While
some of the works solely focused on authentication [13], [1],
others considered privacy-preservation along with authentica-
tion [22], [11], [8], [20]. Privacy preservation approaches are
broadly classified into pseudonym based approaches and group
based approaches.
In most of the pseudonym based approaches [15], [24], [22],
a central authority is needed to keep track of the certificates
and verify them at the time of dispute. The privacy of vehicle
is always at stake in these protocols as authority can access
978-1-5386-4920-6/18/$31.00 ©2018 IEEE
Authorized licensed use limited to: Indian Institute of Technology - Jodhpur. Downloaded on March 25,2021 at 10:06:03 UTC from IEEE Xplore. Restrictions apply.
a device’s identity when ever they require it. Also, each time
the verification has to be done from a pool of certificates,
which adds an extra overhead with increased computation as
proposed by [15].
In group-based protocols [11], [8], [20], group is assigned
to the passing vehicles by either On-Board Units (OBUs) or
Road-Side Units (RSUs) and all the communication is done by
vehicle using group id or by using group signature instead of
their original id. The receiver can validate the message against
group signature or id, which in turn preserves the vehicle
privacy. In ECPP protocol [11], RSUs assign group to passing
vehicles. An improvement to this protocol is later proposed by
Jung et al. [8] to guarantee unlinkability and traceability even
when multiple RSUs get compromised. Since verifying group
signature is also computationally expensive work, Hao et
al. [5] have proposed a distributed key management technique
to improve efficiency where authorities are responsible for
key generation and road-units are responsible for allocation
of keys.
Although group based protocols reduce computational ef-
fort as compared to pseudonym based protocols, they open
up many challenges including limited privacy and higher
cost towards group maintenance. Among other types, vehicle
authentication is mostly done using a trusted third party
controller. Peplow et al. [14] proposed a trusted third party
who is in charge of issuing an authenticator, corresponding
certificates, long-term public/private key pairs and a permu-
tation table for every authorized vehicle. With the help of
these long term key pair, users create a short term key pair
for every broadcast message. A two servers (for registration
and validation) mechanism for authenticating vehicles’ random
ids during communication is proposed by Wei Jiang et al. [6]
that also preserves privacy. In case of any dispute the servers
conduct a tracing protocol to figure out the real identity of a
malicious user.
With the emergence of Blockchain technology over last
few years, few works have experimented with its powerful
usage on different contexts of vehicular networking systems.
In [23], authors have proposed a blockchain based layered
ITS framework and identified the key research issues for
such a decentralized system. They have also provided a case
study for real-time ride sharing application. Block-VN [16]
is a blockchain based distributed architecture that allows the
network of vehicles to discover and share their resources.
Blockchain has been used as a secure robust and transparent
platform to serve variety of ITS applications such as the collec-
tive validation of the occurrence of a road incident [7], reward
based intelligent vehicle communication [17], or anonymous
reputation system for distributed trust management in vehic-
ular communication [12]. A blockchain based decentralized
VIS architecture to ensure the privacy of users and thereby
increasing the security of vehicular ecosystem can be seen as
the basis of next generation ITS serving many applications
like remote software update, insurance and tax or resource
sharing [2], [10].
In this paper, we propose an efficient authentication scheme
Fig. 1: Blockchain for proposed architecture
with privacy preservation for vehicular information sys-
tem by exploiting the advantages of blockchain technology.
Blockchain provides a decentralized, robust and scalable plat-
form to manage seamless access control and vehicle authen-
tication so that to promise conflict resolution for all service
providers. An efficient variant of pseudonym based privacy
preservation strategy along with optional tracebility support
have also been discussed in this paper. The detailed description
of the proposed BlockAPP protocol for IoV environment along
with the implementation results have been provided in the
following sections.
III. BLO CK APP PROTOC OL OV ERV IE W
A blockchain can be explained as a distributed database
that keeps track of the growing list of blocks that are linked
to each other as shown in Figure 1. Each block contains a set
of transactions that are by principle immutable and secure. For
multiple parties with conflicting interests, blockchain provides
a decentralized platform of logging the transactions among
the involved parties in a transparent manner. By exploiting
these advantages of blockchain, the proposed architecture
provides a robust architecture for authentication and privacy
preservation of vehicles in efficient manner as well as enforces
seamless access control. A valid transaction added to the
blockchain reflects the authenticity of the authorized access.
A decentralized architecture for maintaining access logs in a
transparent manner could resolve the conflict among multiple
service providers in a massive-scale IoV system. Figure 1 gives
a schematic diagram of a blockchain for the proposed system.
A. System Model and Architecture
The proposed system consists of four major entities namely
a registration server, the service providers, a blockchain and
the vehicles. Registration server is mainly responsible for
managing and validating vehicle id, which are verified by
the service providers for vehicle authentication later on. There
exist multiple service providers, each offering many services
that a vehicle can subscribe to. Vehicles can avail multiple
services from different service providers at the same time,
if authorized. Each service provider and registration server
must have to register with a trusted central authority to access
Authorized licensed use limited to: Indian Institute of Technology - Jodhpur. Downloaded on March 25,2021 at 10:06:03 UTC from IEEE Xplore. Restrictions apply.
Fig. 2: An overview of three-phase system architecture
blockchain. Service providers will have the permission to
read and write to the blockchain, while registration server
can only write to the blockchain. The resolution of conflicts
among multiple service providers with respect to data rights is
guaranteed by the blockchain. The proposed system works in
three phases: first, registration phase, where vehicles exchange
messages with the registration server to get registered with
pseudo id. Second, authentication phase where the service
providers would try to authenticate vehicles against their
pseudo ids stored in the blockchain. Finally, authorization
phase where the vehicles send service request messages to a
service provider and the access request details with permission
status are added to the blockchain as a set of transactions by
a service provider. An overview of this three-phase system
architecture has been shown in Figure 2. RSUs, vehicles, and
cloud servers act as the intermediate access points to the
registration server during registration phase and to the service
providers during authentication and authorization phase. There
exist two types of blocks: one will be added by the registration
server to maintain the log of registered vehicles while the other
type will be added by the service providers to maintain the
access log. Other block properties remain the same as we
can add an extra field in the block called ‘type’ as shown
in Figure 1. There exist three types of transactions as well,
namely registration transaction, authentication transaction, and
authorization transaction. The transaction format for all three
types of transaction is shown in Figure 3. Transaction val-
idation has to be done by all the members of blockchain
consortium as discussed in subsection III-G. If a transaction is
found to be valid then only it is added to the block, otherwise
it is discarded.
B. Registration Phase
During registration phase vehicles get registered to the reg-
istration server using their original ids and are assigned with
the pseudo ids and session keys for further communication
with service providers. Vehicles use these pseudo ids, which
are valid for a session only, during future communication to
Fig. 3: Transaction format for all three phases
avoid identity spoofing as well as preserve its privacy. For
registration, a vehicle sends a request message containing
it’s original id (usually the vehicle registration number or
the driver’s license, encrypted using server’s public key) to
the registration server. This original id is assumed to be
authenticated by a trusted authority, the detailed description
of which is beyond the scope of this paper.
Fig. 4: Registration phase
The series of message exchange between the registration
server and vehicles has been shown in Figure 4. Prv denotes
the public key (key allocated at one time setup) of registration
server. The keys are exchanged using ECDH Key Exchange
protocol as described in section III-E. After the successful
key exchange, registration server sends the pseudo id to a
vehicle and wait for the acknowledgment. The pseudo ids
for vehicle are generated by encrypting original ids with the
session’s public key of registration server (public key selected
by registration server during ECDH key exchange and since it
dumps all the session details, original ids can not be retrieved
by decrypting the pseudo ids). Pvand P0
vdenote the public
and private keys of a vehicle generated during key exchange,
respectively. On receiving an acknowledgment message, the
registration server adds a transaction to the blockchain, if
it is valid. The transaction validation process is discussed
in subsection III-G. The registration transaction, as shown
in Figure 3, contains transaction type, vehicle pseudo id,
shared secret information (necessary information to decrypt a
message encrypted using vehicle’s private key), session details,
and vehicle’s public key. Once the transaction gets added to
the blockchain, registration server dumps all the shared details
Authorized licensed use limited to: Indian Institute of Technology - Jodhpur. Downloaded on March 25,2021 at 10:06:03 UTC from IEEE Xplore. Restrictions apply.
Fig. 5: Authentication phase
gathered from vehicles during the registration phase. The only
information it keeps are a list of registered original ids, session
details encrypted using public key of vehicle and mapped to
the corresponding pseudo ids (this will help in Traceability).
C. Authentication phase
Once the registration is over and the registered vehicle de-
tails are added to the blockchain, vehicles try to communicate
to the service providers to avail the needed services. The vehi-
cle sends a message containing it’s pseudo id and service ac-
cessing request along with session parameters, acquired from
the registration phase. Pseudo id is sent as a plain-text, while
the request and the session parameters are encrypted using
the vehicle’s private key. When the registration server sends a
transaction for validation purpose each service provider stores
a local copy and waits for it to be added to the blockchain. If
the transaction is added to the blockchain the service provider
marks it as a valid transaction. If there is no entry for the
transaction in the blockchain for the session duration interval,
is is marked as invalid. The invalid transactions are deleted
from the local cache. Once the session for a pseudo id is over
the service provider will discard that transaction details from
it’s local storage. A matching pseudo id along with session
information in a valid transaction with that in a service request
sent by the vehicles authenticates its identity. Local cache entry
also helps in reducing the access time for authentication as the
validation can be done even before the request from a vehicle
arrives. The authentication phase is complete when the service
provider receives an acknowledgement from the vehicle. The
service provider then adds an access log transaction to the
blockchain. The transaction format, as shown in Figure 3,
contains transaction type, pseudo id, timestamp, permission,
and block-id. Once the transaction gets validated, the service
provider starts mining the transaction. The transaction is added
to the blockchain even if the access permission gets denied.
The message flow between a vehicle and a service provider
during the authentication phase is shown in Figure 5, where
Pvand P0
vdenote the public and private keys of a vehicle
generated during key exchange.
Fig. 6: Authorization phase
D. Authorization phase
Every service provider maintains a public-private key pair
for each service it provides so that when a vehicle gets
subscribed to a service it receives the public key for that
service. This key-pair for services helps the service provider
to differentiate between different services and also to ensure
the authorization and authentication of a vehicle to access a
service. In this phase, the vehicle sends a request message
for a service along with a digital signature of service. The
message sent by the vehicle will be encrypted using its private
key or shared secret used as a key (as in ECDH). The
service provider checks the digital signature and service id.
If the digital signature belongs to the services provided by the
service provider, the vehicle is given access to read or write
related to the service that would be helpful for other vehicles
or the service provider.
The message flow between vehicle and service provider is
shown in Figure 6. Pvand P0
vdenote the public and private
keys of a vehicle generated during key exchange, respectively.
Psdenotes the public key of a service. The communication
will be terminated with a termination message from the service
provider followed by an acknowledgment from the vehicle.
Once digital signature is verified, the service provider adds
an authorization transaction that will log the authorization
permission of vehicle to blockchain. The transaction format
is shown in Figure 3 and contains transaction type, pseudo
id, access type(read/write), permission, service-id. Once the
transaction gets validated, the service provider start mining the
transaction. The transaction is added to the blockchain even if
permission gets denied.
E. Key Exchange Protocol
The method of exchanging keys between two parties in-
volved in communication to allow the use of a cryptographic
algorithm is known as key exchange. If the sender and receiver
wish to exchange encrypted messages, each must be equipped
to encrypt messages to be sent and decrypt messages received.
Here we have considered asymmetric key cipher with the
Authorized licensed use limited to: Indian Institute of Technology - Jodhpur. Downloaded on March 25,2021 at 10:06:03 UTC from IEEE Xplore. Restrictions apply.
public/private key, where both the parties need the other’s
public key. Most common ones are RSA, DSA and Elliptic
Curve Cryptography (ECC). ECC digital signature algorithm
for ensuring authenticity of messages in VANET has already
been used in literature [13]. Elliptic Curve Diffie Hellman
(ECDH) is an anonymous key exchange protocol that allows
two parties to exchange key between them with the help of
shared secret and a generator point on the curve as per elliptic-
curve cryptography(ECC). It is a Diffie Hellman variant of
ECC that uses smaller key size and less time to provide
the same level of security provided by RSA or other similar
protocols [9].
F. Miner’s Security Enforcement
These are the three stepped security measurements that
need to be adopted in order to enforce access control using
blockchain technology.
AEncryption Firstly, each miner (e.g. service provider or
registration server) generates its private and public key. The
blockchain maintains the public keys of all miners in the
network and helps in establishing the communication be-
tween any two service providers. A miner adds a transaction
into the blockchain by signing it with its public key so that
to ensure the confidentiality.
BDigital Signature Secondly, each miner digitally signs
(encrypts with its private key) the transaction to ensure
the integrity and non-repudiation of the transaction. With
digitally signed message, receiver can easily find that the
message is not tampered, and the sender of the transaction
is a valid entity in the network.
CVerification Lastly, the receiver, after receiving messages,
identifies the sender by verifying the digitally signed mes-
sage. After verification, the receiver decrypts the message.
G. Transaction Validation
The validity of a transaction to be added into the blockchain
is ensured using consensus protocol. The miner’s network
that we are using in our model is a private network. The
validation happens by majority voting in the Miner’s network.
The transactions are signed by the private key of the senders
and the other members of the network have the sender’s public
key to decrypt it. There exist three types of transaction, each
belongs to a specific phase and they get validated in different
ways. Registration transaction are validated against the sig-
nature of the registration server along with session duration.
Authentication transactions are checked against the id of the
miners (in this case service providers) and pseudo id of the
vehicles as each service provider maintains a list of all valid
pseudo ids present in the network for a session. When a service
provider receives an authentication transaction it checks the list
for the corresponding pseudo id of the vehicle and validates
the transaction. Similarly, an authorization transaction gets
validated against the pseudo id of the vehicle and id of the
miner node.
H. Traceability
In case of malicious activities, the identity of the vehicle
needs to be traced so that the law enforcement authority can
take necessary actions against the offender. Traceability of
original id of the vehicle while preserving the privacy seems
to be a challenging task. However, traceability should always
be maintained for the proposed architecture to be free from
malicious activities. The blockchain used in this scheme is a
private one where the miners have been set up by a trusted
central authority as a one-time job. Hence the central authority
can query both the registration server and the blockchain for
tracing the original id. The proposed design does not allow
the registration server to read from blockchain in order to
refrain it from tracing the original id and further service
providers are also not allowed to query the registration server
for tracing original id. In case any malicious activity is noticed,
the concerned authority can detect the vehicle’s pseudo id
and time-stamp (only central authority can look in details
of transactions to get time-stamp) from the authorization
transaction log, which can lead to authentication transaction by
matching pseudo id in near time-stamp and from there to the
registration transaction by using block-id and pseudo id. The
registration server maintains a map of original ids encrypted
using the public key of vehicle for that session against the
pseudo ids provided. To decrypt this information, private keys
of vehicle for that session can be generated using public key
and shared secret of that session, and hence, the original id of
the vehicle can easily be traced following this back-tracking
approach.
IV. ANA LYSI S
We implemented the interaction with blockchain during
authentication phase to authenticate vehicle pseudo id and
addition of transaction during different phases as a smart
contract on Ethereum blockchain. A smart contract is a
protocol for digital facilitation towards enforcing a conflict-
free agreement among multiple parties without the need of
third-party coordinator. Ethereum uses smart contract on top
of blockchain so that the developers can write programs on
blockchain. We have used Remix platform to implement the
smart contract in Solidity language. The miner nodes include
an authority node, and the service providers along with a
registration server.
A. Transaction Management
The set of transactions as described in Figure 3, are stored
in blocks of a blockchain as tuples. The complexity of this
part of architecture depends upon the blockchain transaction
rate as most of the current blockchain architecture including
Ethereum has very high transaction period of almost few
seconds [21]. Usually all data-rich applications heavily suffer
from bad performance due to this low transaction rate. How-
ever, in our proposed architecture this part would not affect
the communication with vehicle. As addition of a transaction
to the blockchain is a background process for all the service
providers and since all of them maintain a list of valid pseudo
Authorized licensed use limited to: Indian Institute of Technology - Jodhpur. Downloaded on March 25,2021 at 10:06:03 UTC from IEEE Xplore. Restrictions apply.
ids locally, they don’t need to interact with the blockchain
frequently for authentication once the pseudo ids get validated.
Once a registration transaction gets added to the blockchain
and the service provider validates the saved pseudo ids locally,
authentication can take place locally at a service provider.
B. Vehicle’s Authentication
The service providers interact with blockchain following the
receipt of registration transaction in order to validate vehicle’s
pseudo id. If no record against a requested pseudo id is found,
an empty transaction is returned signifying the invalidity of
the queried pseudo id. Only the registered entities will be
able to perform transactions on the blockchain as it’s a private
blockchain and even the registration server is not allowed to
read the blockchain due to potential privacy threat.
V. CONCLUSION
In this paper we proposed a novel architecture for vehicular
information system using Blockchain technology to maintain
consensus among distributed service providers so that to en-
sure data integrity, vehicle authentication, privacy preservation
and seamless access control. This decentralized blockchain
framework is particularly suitable to manage massive scale
IoV data. The limitation of longer transaction time can be
avoided by adopting the proposed local caching strategy. The
scope of on-demand traceability is another interesting feature
supported by BlockAPP protocol that might be very useful in
highly dynamic IoV environment.
VI. ACK NOWLEDGMENT
This work has been partially supported by Science and
Engineering Research Board (SERB), Department of Science
and Technology, Government of India through Early Career
Research Award bearing project no. ECR/2017/000813 and
Tejas Networks Ltd..
REFERENCES
[1] P. Caballero-Gil, C. Caballero-Gil, J. Molina-Gil, and C. Hernndez-
Goya, “Flexible authentication in vehicular ad hoc networks,” in 15th
Asia-Pacific Conference on Communications, 2009, pp. 576–879.
[2] A. Dorri, M. Steger, S. S. Kanhere, and R. Jurdak, “Blockchain: A
distributed solution to automotive security and privacy,” IEEE Commu-
nications Magazine, vol. 55, no. 12, pp. 119–125, 2017.
[3] A. E and S. R, “An intelligent secure traffic management system based
on vanet,” vol. 9, pp. 15–27, 01 2014.
[4] M. Gerla and M. Gruteser, Vehicular Networks: Applications, Protocols,
and Testbeds. Cambridge University Press, 2011, p. 201241.
[5] Y. Hao, Y. Cheng, C. Zhou, and W. Song, “A distributed key man-
agement framework with cooperative message authentication in vanets,”
IEEE Journal on Selected Areas in Communications, vol. 29, no. 3, pp.
616–629, 2011.
[6] W. Jiang, F. Li, D. Lin, and E. Bertino, “No one can track you:
Randomized authentication in vehicular ad-hoc networks,” in IEEE
International Conference on Pervasive Computing and Communications
(PerCom), 2017, pp. 197–206.
[7] J. Joy, “Vehicular blocktrees,” in Vehicular Networking Conference
(VNC), 2017 IEEE. IEEE, 2017, pp. 147–150.
[8] C. D. Jung, C. Sur, Y. Park, and K.-H. Rhee, A Robust Conditional
Privacy-Preserving Authentication Protocol in VANET, 2009, p. 35.
[9] V. Kapoor, V. S. Abraham, and R. Singh, “Elliptic curve cryptography,”
Ubiquity, vol. 2008, no. May, pp. 7:1–7:8, 2008.
[10] B. Leiding, P. Memarmoshrefi, and D. Hogrefe, “Self-managed and
blockchain-based vehicular ad-hoc networks,” in Proceedings of the
2016 ACM International Joint Conference on Pervasive and Ubiquitous
Computing: Adjunct. ACM, 2016, pp. 137–140.
[11] R. Lu, X. Lin, H. Zhu, P.-H. Ho, and X. Shen, “ECPP: Efficient
conditional privacy preservation protocol for secure vehicular commu-
nications,” IEEE INFOCOM 2008 - The 27th Conference on Computer
Communications, 2008.
[12] Z. Lu, Q. Wang, G. Qu, and Z. Liu, “Bars: a blockchain-based
anonymous reputation system for trust management in vanets,” in 2018
17th IEEE International Conference On Trust, Security And Privacy In
Computing And Communications/12th IEEE International Conference
On Big Data Science And Engineering (TrustCom/BigDataSE). IEEE,
2018, pp. 98–103.
[13] S. S. Manvi, M. S. Kakkasageri, and D. G. Adiga, “Message au-
thentication in vehicular ad hoc networks: ECDSA based approach,”
in International Conference on Future Computer and Communication,
2009, pp. 16–20.
[14] R. Peplow, D. S. Dawoud, and J. van der Merwe, “Ensuring privacy
in vehicular communication,” in 1st International Conference on Wire-
less Communication, Vehicular Technology, Information Theory and
Aerospace Electronic Systems Technology, 2009, pp. 610–614.
[15] M. Raya and J.-P. Hubaux, “Securing vehicular ad hoc networks,” J.
Comput. Secur., vol. 15, no. 1, pp. 39–68, 2007.
[16] P. K. Sharma, S. Y. Moon, and J. H. Park, “Block-vn: A distributed
blockchain based vehicular network architecture in smart city,” Journal
of Information Processing Systems, vol. 13, no. 1, p. 84, 2017.
[17] M. Singh and S. Kim, “Intelligent vehicle-trust point: Reward based
intelligent vehicle communication using blockchain,” arXiv preprint
arXiv:1707.07442, 2017.
[18] Y. Sun, L. Wu, S. Wu, S. Li, T. Zhang, L. Zhang, J. Xu, and Y. Xiong,
“Security and privacy in the internet of vehicles,” in International
Conference on Identification, Information, and Knowledge in the Internet
of Things (IIKI), 2015.
[19] W. Viriyasitavat, F. Bai, and O. K. Tonguz, “Toward end-to-end control
in VANETs,” in IEEE Vehicular Networking Conference (VNC), 2011,
pp. 78–85.
[20] Y. Wang, H. Zhong, Y. Xu, and J. Cui, “ECPB: Efficient conditional
privacy-preserving authentication scheme supporting batch verification
for VANETs,” I. J. Network Security, vol. 18, pp. 374–382, 2016.
[21] G. Wood, “Ethereum: A secure decentralised generalised transaction
ledger,” Ethereum project yellow paper, vol. 151, pp. 1–32, 2014.
[22] L. Wu, J. Fan, Y. Xie, J. Wang, and Q. Liu, “Efficient location-based
conditional privacy-preserving authentication scheme for vehicle ad
hoc networks,” International Journal of Distributed Sensor Networks,
vol. 13, no. 3, 2017.
[23] Y. Yuan and F.-Y. Wang, “Towards blockchain-based intelligent trans-
portation systems,” in Intelligent Transportation Systems (ITSC), 2016
IEEE 19th International Conference on. IEEE, 2016, pp. 2663–2668.
[24] C. Zhang, R. Lu, X. Lin, P.-H. Ho, and X. Shen, “An efficient identity-
based batch verification scheme for vehicular sensor networks,” in
INFOCOM 2008. The 27th Conference on Computer Communications.
IEEE. IEEE, 2008, pp. 246–250.
Authorized licensed use limited to: Indian Institute of Technology - Jodhpur. Downloaded on March 25,2021 at 10:06:03 UTC from IEEE Xplore. Restrictions apply.
