Identity Management in Internet of Vehicles based on Distributed Ledger Technology

Author: Jan Lauinger
Edited by: Mohammad Hamad, Sebastian Steinhorst

1. Introduction

With the rise of technology in the automotive industry, vehicles are more and more connected to the cloud and roadside infrastructure, thus, defining the term "Internet of Vehicles" (IoV). In addition to that, environment sensing, enabled by advanced sensor technology, drives the development of Advanced Driver-Assistance Systems (ADAS) towards applications such as fully autonomous driving. However, Connected Autonomous Vehicles (CAVs) face critical challenges, especially in the domain of security. Vehicle security is of crucial importance due to the latest attacks that remotely take over vehicle control [1]. Such attacks not only affect driver and passenger safety, they demand active research to apply the latest Internet security solutions in the domain of connected vehicles.

The European Union (EU) funded project, called "novel adaptive cybersecurity framework for the Internet of Vehicles" (nIoVe), approaches this challenge with a holistic multi-layer security framework. This blog post introduces the latest developments of the nIoVe secure communication layer which builds on top of the lowest infrastructure layer. While establishing trust between infrastructure components, the secure communication layer must deal with the dynamics of vehicle/device positioning. Hence, providing a secure communication layer at the EU scale requires the consideration of the latest research trends that go beyond traditional certification infrastructure such as Public Key Infrastructures (PKIs). The green lock on the left side of our browser's address bar indicates a trusted certificate powered by PKI, which illustrates the power of PKIs as the backbone of today's trusted Internet. Nevertheless, and besides the creation of digital money, Distributed Ledger Technology (DLT) evolves as a potential candidate for solving certification management at scale in a privacy-enhanced way.

2. Self-sovereign Identity Management and Anonymous Credentials 

During our research activities in nIoVe, we identified the project Hyperledger Indy [2] as a promising solution to the requirement of scalable certificate management independent of problems introduced by location dynamicity. Hyperledger Indy implements a concept called "Selfsovereign Identity Management" (SSIM) [3]. With SSIM, credential holders (vehicles) manage and maintain their credentials individually without relying on central servers or third-party services for federated identity management. At the same time, credential holders have the ability to selectively disclose certain attributes of their credentials. Disclosing values associated with credential attributes can be even proven using Zero-Knowledge Proofs (ZKPs), where nothing except the validity of a statement is revealed to a verifier [4]. This gives maximum privacy to the credential holder when participating in a verification scheme. Aside from privacy benefits, credential holders generate proofs locally at any location.

Figure 1: DLT-based Credential Management Lifecycle (Issuing, Authentication, Verification, Revocation (not discussed)) between Government (Schema Creator), Registration Authority (Credential Definition Creator and Credential Issuer), Vehicle (Credential Holder), and Gas/Charging Station (Credential Verifier)

The implementation of Hyperledger Indy uses two main schemes to cover the full cycle (issuing, authentication, revocation) around anonymous credential management: (1) the group signature scheme introduced by Camenisch and Lysyanskaya [5] and (2) revocation management based on cryptographic accumulators [6]. We mention these concepts for readers that want to dig deeper into the topic. This post, however, provides a high level description of how DLT-based decentralized identity management in the IoV could look like in the next section.

3. Certification in the IoV powered by Permissioned Distributed Ledger Technology

To communicate the topic of credential management for trusted and secure communication, we consider the use case of a vehicle which authorizes itself at a gas/charging station before the establishment of the communication channel. Figure 1 visualizes the scenario. To achieve trusted communication, a government authority starts by registering a Credential Schema (CS) at the ledger. The CS defines attributes of the certificate that will be issued to a holder. In the context of the IoV, possible attributes that certify vehicles could be license numbers, ownership details, insurance numbers, and proofs of value-added tax, conformity, roadworthiness, etc: : : [7]. The ledger which processes the CS transaction is permissioned. This means that authorized nodes participate in the blockchain network and maintain a copy of the ledger. This assumption does not require the computing-intensive Proof of Work (PoW) consensus protocol. Instead, the plenum consensus protocol [8] in Hyperledger Indy is a deviation of the Practical Byzantine Fault Tolerant (PBFT) consensus protocol [9] which relies on a more efficient three-phase commit protocol to verify transactions. Changing the blockchain type to public would require a redesign of stakeholder contracting and is out of scope of this article.
With the CS registered at the ledger, a vehicle registration authority can register a Creden
tial Definition (CD) at the ledger. The CD contains public cryptographic metadata and references the CS of the government. Crypto data of the CD supports group signature creation, verification as well as the credential revocation protocol. In order to allow other registration authorities to issue credentials that are linked to the government CS, CD information is decoupled from CS data and can be registered individually.

With the CS and CD stored at the ledger, the vehicle registration authority can issue a credential to a vehicle. To do so, the vehicle commits values to the attributes defined in the CS of the government. Using the CL group signature scheme, the registration authority signs the credential request and issues the credential to the vehicle. With that, the vehicle as the credential holder can prove attributes of the credential to a verifier. This is possible because the vehicle can sign data as a member of the group signature scheme. Disclosing the initial value commitments that are associated with credential attributes is left to the vehicle.

Equipped with the credential, a vehicle can approach any road side unit or IoV device. To, e.g., set up a trusted and secure communication channel to a gas/charging station, the charging station first requests a credential proof of the vehicle as it only accepts registered vehicles. By generating a proof based on a credential, the vehicle can answer the request of the charging station with a proof presentation. Afterwards, the charging station can verify all signatures and cryptographic proofs of the proof presentation with the help of publicly accessible ledger data found in the CS and CD. Upon successful verification, a secure communication channel between the vehicle and the charging station is established. 

4. Summary

This post gives a high-level introduction into anonymous credential management in combination with DLT. The IoV scenario indicates how trust chains for secure communication can be established between network participants. In this case, the vehicle acts as a self-sovereign entity regarding credential management. This concept is the basis of the secure communication layer in nIoVe. Current standardization activities by the World Wide Web Consortium (W3C) adopt the anonymous credential concept in their standard of verifiable credentials [10]. Another important read is the topic of Decentralized Identifiers (DIDs) [11] as the underlying decentralized key management which we did not cover in this post. Before ending this article, we like to link our publication at the International Conference of Blockchain and Cryptocurrency (ICBC 2021), where our work [12] proposes an anonymous protocol for CS access control. Lastly, we would like to thank all nIoVe project partners for making this work possible.


[1] Charlie Miller. Lessons learned from hacking a car. IEEE Design & Test, 36(6):7–9, 2019.

[2] Linux-Foundation projects: Hyperledger. Hyperledger Indy. [Online; accessed 29-April-2021].

[3] Andrew Tobin and Drummond Reed. The inevitable rise of self-sovereign identity. The Sovrin Foundation, 29(2016), 2016.

[4] Oded Goldreich and Yair Oren. Definitions and properties of zero-knowledge proof systems. Journal of Cryptology, 7(1):1–32, 1994.

[5] Jan Camenisch and Anna Lysyanskaya. Signature schemes and anonymous credentials from bilinear maps. In Annual international cryptology conference, pages 56–72. Springer, 2004.

[6] Jan Camenisch, Markulf Kohlweiss, and Claudio Soriente. An accumulator based on bilinear maps and efficient revocation for anonymous credentials. In International workshop on public key cryptography, pages 481–500. Springer, 2009.

[7] European Union. Car registration documents and formalities. youreurope/citizens/vehicles/registration/formalities/index\_en.htm. [Online; accessed 29-April-2021].

[8] Hyperledger Indy. Plenum Byzantine Fault Tolerant Protocol. hyperledger/indy-plenum/wiki. [Online; accessed 29-April-2021].

[9] Pierre-Louis Aublin, Sonia Ben Mokhtar, and Vivien Quema. Rbft: Redundant byzantine fault tolerance. In 2013 IEEE 33rd International Conference on Distributed Computing Systems, pages 297–306. IEEE, 2013.

[10] Manu Sporny, D Longley, and David Chadwick. Verifiable credentials data model 1.0. W3C, W3C Candidate Recommendation, March, 2019.

[11] Drummond Reed, Manu Sporny, Dave Longley, Christopher Allen, Ryan Grant, Markus Sabadello, and Jonathan Holt. Decentralized identifiers (dids) v1. 0. Draft Community Group Report, 2020.

[12] Jan Lauinger, Jens Ernstberger, Emanuel Regnath, Mohammad Hamad, and Sebastian Steinhorst. A-poa: Anonymous proof of authorization for decentralized identity management. In Proceedings of the Conference on Blockchain and Cryptocurrency (ICBC 2021), page 8, 2 in press.

By accepting you will be accessing a service provided by a third-party external to