Innovating IoT Security with Self-Sovereign Identity

The number of devices connected to the Internet, known as the Internet of Things (IoT), is growing rapidly. By 2030, there could be around 29 billion IoT devices. However, many of these devices have weak security, making them targets for attackers. To protect these devices, it is essential to give them secure identities. This can help prevent unauthorized access and attacks on critical systems.

In large IoT systems, it is essential to manage device identities efficiently. Current methods often rely on a centralized system called Public Key Infrastructure (PKI) using X.509 certificates. This approach can be slow and costly due to the need for human involvement in managing certificates. When a device's identity changes, its certificate must be revoked, and a new one must be issued, which can take time and resources. Additionally, relying on a single authority for certificates can create vulnerabilities if that authority is compromised.

#Self-Sovereign Identity

A promising alternative is Self-Sovereign Identity (SSI). This approach gives devices control over their own identity data without relying on a central authority. In an SSI system, each device creates its own identity and can store its public key on a distributed ledger. This ledger is a secure place where other devices can find the device's public key.

In an SSI model, a device uses a Decentralized Identifier (DID) to represent its identity on the ledger. When a device's information is stored on a ledger, it can generate a digital credential called a Verifiable Credential (VC). This credential holds additional information about the device's identity.

The benefits of SSI include:

1. A device can change its identity without needing to update its credentials immediately.
2. If a device's keys are compromised, it can revoke its DID and invalidate its VC right away.
3. Devices can manage identity changes without needing human intervention.
4. The system can support a large number of devices.

#Challenges in Implementing SSI

While SSI has great potential, using it in IoT systems poses challenges. Many discussions about SSI have focused on using it at the application layer of the Internet, which can be problematic. The first issue is a lack of established protocols that work well with IoT. The second issue is that using two different technologies simultaneously (X.509 certificates on the server side and VCs on the client side) can complicate the process of mutual authentication.

To address these issues, the goal is to implement authentication directly in the Transport Layer Security (TLS) protocol, which is responsible for creating secure communication channels over the Internet. By adding support for VCs into the TLS handshake, we can take advantage of SSI while avoiding the drawbacks of PKI and X.509 certificates.

#The TLS Handshake

The TLS protocol works by establishing a secure communication channel between a client and a server. During the handshake, which is the initial phase of creating this secure connection, the client and server exchange messages to agree on cryptographic parameters and authenticate each other.

In traditional TLS Handshakes, the server usually sends its certificate, which confirms its identity. The client verifies this certificate before establishing a secure connection. However, to include VCs in the handshake, we need to extend the protocol to support this new certificate type.

#Extending the TLS Handshake for VCs

The new handshake protocol aims to achieve three main goals:

1. Allow servers (and optionally clients) to authenticate using VCs.
2. Maintain compatibility with existing X.509 certificates, enabling hybrid handshakes.
3. Retain all security features of the original TLS 1.3 handshake.

To do this, we introduce two extensions to the protocol: one for the VC certificate type and another to indicate which DID methods a device supports. Devices will include these extensions during the handshake process, enabling them to use VCs for authentication while still supporting X.509 certificates if needed.

#Advantages of the New Handshake Design

The proposed TLS handshake does not add new messages or remove existing ones but focuses on integrating VCs while keeping the core handshake intact. By using this approach, companies implementing the new handshake will find it easier to adopt. The design reduces the complexity associated with managing certificates and allows for a smoother transition to SSI in IoT.

#Implementation of the New Handshake in OpenSSL

To evaluate the new handshake, we implemented it in OpenSSL, an open-source cryptographic library. The aim was to minimize changes to the OpenSSL codebase and make the integration seamless. Most of the new functionality was added to an external provider, allowing the main OpenSSL library to remain unchanged.

The implementation involved adding support for the VC certificate type and the DID methods extension. This way, the handshake can handle VCs during authentication, ensuring that devices can securely communicate without relying on traditional PKI methods.

#Performance Analysis

To test the performance of the new handshake protocol, we set up an experimental environment using Raspberry Pi devices. We assessed various connection configurations and measured handshake sizes and latencies.

#Experimental Setup

We connected two Raspberry Pi 4 devices in a client-server configuration. These devices communicated with a Distributed Ledger Technology (DLT) node to resolve DIDs. We tested the new handshake under different configurations:

1. HTTP over TCP
2. HTTP over TCP with IPSec
3. HTTPS with a TLS channel established during the handshake

#Results of the Performance Tests

The results showed that the original TLS handshake was generally faster than handshakes using VCs, mainly due to the time taken to resolve DIDs during the verification process. However, the differences were not significant enough to dismiss the potential benefits of using VCs.

For unilaterally authenticated handshakes, the new VC protocol experienced some overhead due to additional DID resolution steps. However, using IPSec provided better performance in terms of reducing latency, making it an attractive option for securing IoT communications.

In mutually authenticated handshakes, both devices authenticated each other using VCs, which slightly increased latency. Yet, similar optimizations with local storage of DIDs can improve performance.

#Conclusion and Future Directions

In conclusion, the new TLS handshake design offers a viable method for incorporating Self-Sovereign Identity into large-scale IoT systems. By keeping the protocol compliant with existing standards and minimizing changes to the OpenSSL library, we ease adoption for companies looking to improve their IoT security.

The experimental results demonstrate that our approach is feasible and can offer comparable performance to traditional PKI methods. Moving forward, optimizing the implementation further will be essential to enhance performance, allowing for a robust and efficient identity management process in IoT systems.