Oscar Lage, Santiago de Diego, and Michael Shea
The world of the Internet of Things (IoT) has the same challenge as the rest of the internet with the lack of verifiable identity of what is being connected to whom. This creates significant security and privacy risks for both the operators of IoT devices and the public at large. Although the number of IoT devices continues to multiply, the value they bring to business and society will be seriously compromised unless security and privacy issues related to the identity of these devices are addressed. This chapter outlines how the application of the self-sovereign identity (SSI) paradigm in the IoT space can close some of these security gaps and provide a resilient identity layer for IoT. Our guides include three active contributors to SSI and IoT infrastructure: Oscar Lage, global head of cybersecurity at Tecnalia; Santiago de Diego, cybersecurity researcher at Tecnalia Research; and Michael Shea, managing director, The Dingle Group.
19.1 IoT: Connecting everything safely
The IoT landscape is one of immense diversity. Loosely, the IoT includes any device that can connect to a network (over any transport), stream data, and receive commands from afar. IoT covers industrial systems, building automation, home automation, healthcare, agriculture, mining, mobility, and wearables, just to name a few segments. Very few areas of our modern life are not touched by the IoT.
In structure, an IoT system consists of a hub (or controller) and devices. Devices can be sensors (e.g., temperature, CCTV) or actuators (e.g., lights, door locks). A typical IoT network may contain multiple hubs (or controllers) and hundreds (or thousands) of devices. Hubs/controllers, in most cases, are hosted in a cloud environment (e.g., Amazon Web Services, Microsoft’s Azure); however, they can be on-premises as well.
From a security and privacy viewpoint, in our highly connected world, it is best to assume that all networks are constantly under attack. IoT systems, especially, with their poor security reputation, have become entry points for targeting critical infrastructure. In 2019, cyberattacks on IoT devices increased by 300%. In the first half of 2019, the number of attacks surpassed the billion mark for the first time, reaching 2.9 billion attacks, a 3.5× increase compared to the second half of 2018 [1].
In June 2020, the JSOF research lab announced that it had discovered a number of zero-day vulnerabilities in a widely used low-level TCP/IP software library developed by Treck, Inc. [2]. The 19 vulnerabilities, given the name Ripple20, affect millions of IoT devices and include multiple remote-code-execution vulnerabilities. The vulnerable software library was integrated into IoT devices for Caterpillar, Cisco, HP (Hewlett-Packard), HPE (Hewlett-Packard Enterprise), Intel, Rockwell, Schneider Electric, Digi, and more. All these companies’ devices are potentially vulnerable to remote hacks by cybercriminals.
NOTE A zero-day vulnerability is a computer-software vulnerability that is unknown to, or unaddressed by, those who should be interested in mitigating the vulnerability (including the vendor of the target software) and that is being actively exploited in the wild.
When the number of devices in a network is numbered in the hundreds or thousands—and every device on the network is a potential attack vector—keeping all devices identified and up to date is an enormous task. For network administrators to have any chance of keeping up with the attackers, automation is critical for provisioning, key rotation, and revocation of rights to devices to keep networks safe, as explained in chapter 10.
The research company IDC estimated in 2019 that the global spend on IoT-related devices and services was $745 billion and forecasted a 17.8% compound annual growth rate (CAGR) over the next five years [3]. While this information is very positive for those participating in the IoT sector, the report also mentions that the industry has failed to reach the forecasted growth rates for the past several years. IDC believes there are two main reasons for this repeated underachievement:
We believe that SSI could become one of the driving forces to catapult the IoT industry to reach its full potential.
19.2 How does SSI help IoT?
SSI cannot solve all of the security and privacy challenges within the IoT sector. However, the integration of SSI into the IoT ecosystem can address the following:
The first significant contributions from SSI are decentralized identifiers (DIDs) and DID documents (chapter 8). These can provide the following:
-
Identifiers and identity verification mechanisms needed to establish trusted connections with IoT devices
-
A verifiable list of the services offered by the device in a standardized way
-
Secure, private connections over which to exchange digitally signed information between devices and controllers (or other peer devices)
The second key contribution is from verifiable credentials (VCs, chapter 7). These provide:
-
A standard authorization mechanism by which any device can assert the provenance of data from sensors or processing of commands to actuators
-
A much richer data model for handling and disclosing attributes
-
The ability to do selective disclosure through zero-knowledge proofs or semantic schemas for data model extensibility, neither of which are available with traditional X.509 certificates [4]
The combination of DIDs and VCs can bring high-assurance identity—the missing element of IoT. With high assurance identity,
-
Data streaming from IoT sensors can be traced back to a verifiable source, enabling organizations to prove provenance and maintain reliable data supply chains.
-
Remote devices will know with confidence where their commands are coming from.
-
Firmware updates can be easily validated for their source and trustworthiness.
19.3 The business perspective for SSI and IoT
SSI is an important new development in technology; however, it is frequently sold on its technological merits without connecting it to the business problems it solves. (See chapter 18 for more guidance on how to explain SSI to businesses.) For adoption of SSI in IoT, we should stress these business benefits:
-
SSI allows owners and users of IoT devices to become their own root of trust, eliminating dependencies, vulnerabilities, and costs associated with third parties.
-
The cost to identify devices or rotate keys can drop to fractions of a cent, and devices can be added or removed with very low risk.
-
SSI high-assurance identity means fewer concerns, interruptions, or delays caused by security issues within an IoT network.
-
Secure DID-to-DID connections and verifiable credential exchange mean assured provenance of data, which means better results from machine learning algorithms processing that data.
As SSI gains traction in the IoT market, we expect to see hard data backing up these promises.
19.4 An SSI-based IoT architecture
To help you visualize what this might mean, we have created a basic SSI reference architecture for IoT. It begins with the actors and their digital agents involved in an SSI-based IoT ecosystem:
-
Certification Body: The entity that issues a VC to a Manufacturer
-
Verifiable Data Registry: A trusted Layer 1 registry accessible to everyone (see chapter 2)
The first step, initialization, is where the IoT device connects with both the Manufacturer and the Certification Body. All communications during these steps use secure channels (Transport Layer Security [TLS], DTLS [Datagram Transport Layer Security], DIDComm). This is shown in figure 19.1:
-
The device generates its key pair, DID, and DID document. Note that the device needs a secure element or trust execution environment (TEE) to protect its own keys.
-
A one-time token is issued by the Manufacturer and incorporated into the device in the manufacturing process to enable the device to authenticate with the Manufacturer.
-
The device forms a connection and shares its self-generated DID with the Manufacturer using the one-time token for security. Once the initialization has been completed, the Manufacturer knows the IoT device DID, and the two have a permanent connection.
Figure 19.1 The initialization process in which an IoT device generates a key pair, DID, and DID document and securely registers them with the Manufacturer
-
The Manufacturer creates its own DID and DID document and registers them in a verifiable data registry (VDR): a Layer 1 blockchain, distributed ledger technology (DLT), or other database.
In this first stage, the Certification Body is not yet involved.
Figure 19.2 shows the second stage, during which VCs are issued:
-
The Manufacturer connects to the Certification Body, which performs due diligence and then issues VC credential C to the Manufacturer as the holder. The Manufacturer’s agent stores credential C in its wallet.
-
The Manufacturer generates a unique credential C2 linked to credential C and issues credential C2 to each of its IoT devices. The Manufacturer is now both an issuer and holder.
-
The manufacturer writes the DID and DID document of each device to the VDR.
Figure 19.2 The Certification Body issues a quality credential.
If the Certification Body needs to revoke a certification credential in the future, it will update the revocation registry in the VDR (see chapter 7). The revocation registry allows a verifier to easily and quickly check the credential status without having to go back to the issuer.
Now let’s expand the scenario by adding another actor: the Verifier. A verifier can be a human actor, another IoT device, or an organization. Figure 19.3 shows the scenario where the Verifier is the controller for an IoT network on which the Manufacturer wants to register a device:
-
The device requests to register on the IoT network, so the IoT network controller asks the IoT device for proof of a certified identity credential.
-
The IoT device responds with a verifiable presentation that includes a list of claims from the credential C2 and signed by the IoT device.
-
The IoT network controller first verifies the digital signatures by checking the VDR for the public keys associated with the DIDs of the Certification Body, the Manufacturer, and the device. The IoT network controller next checks the revocation status of credential C2 against the VDR. Finally, the IoT network controller validates the claims from the C2 credential.
Figure 19.3 Verification process between the different parties
It is worth noting that neither the Certification Body nor the Manufacturer is needed for the actual verification process—only for the issuance of the original credentials. The IoT device can cryptographically prove its identity to the IoT network controller, and the VDR is the only service the IoT network controller needs to consult during verification.
Now let’s look at an example to understand how this could be applied in real life.
19.5 Tragic story: Bob’s car hacked
Imagine this not-so-fictional scenario:
Bob has just picked up his brand-new car. To celebrate, he and his partner Carol are going out for dinner. Bob parks his car in an unattended parking lot. While Bob and Carol are enjoying dinner, Evan breaks into Bob’s new car and substitutes the integrated global positioning system (GPS) for an identical one, which reports back to Evan the current location of Bob’s car. Now, Evan can know where Bob is at any time. After following Bob for a few months, Evan knows where he lives, which routes he drives, and where Carol lives. Evan is ready to execute his evil plan against Bob.
Now let’s apply the SSI IoT reference model to this scenario. This time, let’s assume Bob’s car’s operating system includes SSI identity verification to ensure every component or subsystem in the car comes from a trusted source. When a new component is installed in the car, the initialization process requires the operating system (OS) to request proof of an identity credential from the component.
The component must reply with an acceptable proof. The OS checks the proof’s cryptographic integrity and then uses an over-the-air (OTA) process to look up the manufacturer’s DID in a VDR to get the public key required to verify the proof. If both of these verifications pass and the component’s identity is confirmed, the OS then exchanges a peer DID with the component so subsequent communications can use a secure private channel known only to the two of them.
In this new version of the story, the rigged GPS component would fail at multiple layers. First, it would not have the original GPS’s peer DID to re-establish the secure communication channel with the OS. Second, when the rigged GPS received the credential initialization request, it would have neither a DID nor the necessary credential from an approved manufacturer. Therefore the OS would not accept the rigged GPS—and it would warn Bob that someone was tampering with his car.
19.6 The Austrian Power Grid
While Bob’s car might be a fanciful scenario, there is nothing fanciful about managing a power grid. It is a complex and serious business. The electric grid is made up of power producers, transmission operators, distribution operators, and consumers (residential and industrial). For example, the operator of the electric grid in Austria, the Austrian Power Grid (APG), is responsible for ensuring the reliable delivery of energy across all stakeholders. This means real-time management of power entering and leaving the grid while maintaining a stable frequency across the grid.
In early 2020, the APG and the Energy Web Foundation announced a proof of concept to enable the participation of small-scale distributed energy resources (DERs) in the APG [5]. Support for small-scale energy production (e.g., home-based solar energy) is part of a strategic goal to place Austria at the forefront of modern grid digitalization, increasing grid resilience and moving APG toward the goal of 100% renewable electricity by 2030.
Historically, the DER identification process would be conducted at every level of the grid, increasing financial costs to the DERs and grid operators and adding significant delays into the onboarding process. Thus there are strong incentives to create a high-assurance identity credential for a DER that can be trusted and shared across all stakeholders, eliminating a key barrier to grid decentralization.
Utilizing SSI, each DER can present its identity VC when interacting with the grid. When joining the grid, the VC for the DER can be cryptographically verified. The grid operator can then either accept or reject the DER with a much higher confidence level.
Once this SSI identity model has been set up, further improvements can be made, such as implementing reward models that give incentives to DERs to participate in the network. This reward system can also be implemented using blockchain technologies using the same SSI identity management scheme, using DIDs to identify the actors in the network and peer DID connections as secure private channels for transferring and redeeming rewards.
19.7 SSI Scorecard for IoT
Most people focus on the value of SSI for people and the organizations they deal with. However, the benefits of SSI apply equally to the entire IoT industry. In this chapter, we presented a story about how a replacement component could hijack a car’s GPS system and how this could be prevented if manufacturers used an SSI high-assurance identity model for components. We then presented a generalized proposal for SSI-based IoT architecture and showed how it applies to real-world examples such as the Austrian Power Grid. In addition to much stronger security and privacy, we also believe SSI can also bring innovative new reward models for IoT actors and networks, helping grow their usage and the value they deliver.
For IoT, we evaluate that SSI will be transformative for business efficiencies and regulatory compliance, but it will also have clear positive effects for the bottom line and relationship management (table 19.1). The SSI Scorecard is color-coded as follows:
References
1. Doffman, Zak. 2019. “Cyberattacks On IOT Devices Surge 300% In 2019, ‘Measured In Billions’, Report Claims.” Forbes. https://www.forbes.com/sites/zakdoffman/2019/09/14/dangerous -cyberattacks-on-iot-devices-up-300-in-2019-now-rampant-report-claims/#461686625892.
2. JSOF. 2019. “Ripple20: 19 Zero-Day Vulnerabilities Amplified by the Supply Chain.” https://www.jsof-tech.com/ripple20.
3. i-SCOOP. n.d. “IoT 2019: Spending, Trends and Hindrances Across Industries.” https://www .i-scoop.eu/internet-of-things-guide/iot-2019-spending-trends.
4. Fedrecheski, Geovane. 2020. “Self-Sovereign Identity for IoT Environments: A Perspective.” https://arxiv.org/abs/2003.05106.
5. T&DWorld. 2020. “Austrian Power Grid, Energy Web Foundation Launch Proof of Concept to Use DERs for Frequency Regulation.” https://www.tdworld.com/distributed-energy-resources/article/21122056/austrian-power-grid-energy-web-foundation-launch-proof-of-concept-to-use
-ders-for-frequency-regulation.