When Things Know What They Are: IoT in the Age of Self-Sovereign Identity
With approximately 15 billion connected Things either consuming or providing digital services every second of every day, every Chief Information Security Officer (CISO) and their teams hope; they hope that yet again their intricate security countermeasures will swat away another distributed denial of service (DDOS) attack from thousands of hacked IoT devices, or that none of their own devices are compromised and distributing malware throughout their company’s network.
To that end, companies spend hundreds of billions of USD annually to avoid the average of USD$22M in costs for each cyber attack. These expenses would be substantially reduced if the primary driver for successful cyber attacks could be addressed — that is to say, if the targeted device or entity could be imbued with a trusted identity. A trusted identity can be proven by the device to which it belongs and verified by anyone for every single digital interaction without relying on a third party. Such an identity, also known as ‘self-sovereign identity’, is a foundational element of a Zero Trust framework, which is starting to be mandated by nation-states as THE required cybersecurity framework.
The term ‘self-sovereign identity’, or SSI, is quickly emerging as a new paradigm in discussions surrounding the data privacy and autonomy of humans engaging in digital transactions around the globe. Here we explore how SSI can be useful in the context of the Internet of Things (IoT).
The physical analogy of the use of SSI by people is the wallet in our pocket. This wallet often contains cash, a driver’s license, club membership cards, credit cards, notes, receipts, etc. A digital version of the individual’s physical wallet — a digital wallet — also contains digital certificates that prove memberships and authority to do things like drive a car or use a credit card. The digital wallet may also contain digital assets such as cryptocurrency and documents capturing important information to be presented on request (e.g., proof of vaccination). Most of these items are issued by third-party authorities (e.g., national identity by the government, driving license by the transport authority, club membership by the golf club, etc.), and can be presented electronically by the human owner of the digital wallet.
IoT devices — things that connect to the cloud, including smart sensors, smartphones, etc. — can also benefit from having a digital wallet to prove on request things such as who manufactured them, where and when they were manufactured, which software they are running, what rights to access cloud services they have, when they were serviced and by whom, their carbon footprint, their energy consumption, etc. Now that IoT devices are proliferating everywhere with tens, and eventually hundreds, of billions accessing cloud-based services an untold number of times during their lifetimes, they will need secure ways of presenting trustworthy information about themselves in order to function effectively and securely in the new era of Zero Trust.
Let’s take a very basic and highly relevant example to illustrate this point. When a surveillance camera connects to a network in order to stream to a cloud server/service, to capture video for analysis and storage, it is essential to make sure that the camera is bona fide and is connecting to the right server/service.
What does bona fide mean in this context? A bona fide device can verifiably answer questions such as: Has it been manufactured by a trustworthy manufacturer in a trusted country? Are all its hardware and software components sourced from trusted and identifiable companies? Can it prove that it is still in control of its identity? Can it prove it has not been hacked? These are increasingly important questions that must be answered by each surveillance camera, not once but multiple times every day during its lifetime.
What does it mean to be hacked? Is the camera running the correct firmware version without known zero-day bugs? Is access to the camera protected properly (think of the damage done by a simple hack such as Mirai)? Are its context and situation correct (e.g., does its reported location make sense, and is it operating in the way one would expect)?
What does it mean to control one’s own identity? Can the device cryptographically prove that it still controls the means to prove its identity to anyone, at any time?
What does it mean to connect to the right server/service? Perhaps the camera is streaming to the wrong server/service because of a lack of updated ownership information or because of a hack by a malicious actor.
If you are asking, in the context of this example, how these issues are managed today, the answer would be a combination of ‘not really being managed properly’ and ‘within very constrained ecosystems hindered by rigid management capabilities that either lack the ability to scale or are themselves vulnerable to cyber attacks.’ And this problem is only getting worse. Surveillance cameras are just one easily recognized combination of hardware and software. There are literally tens of thousands of other examples of IoT devices that may include hardware but always include software.
Now let’s understand how SSI can be used to cope with these challenges in IoT. The ITN (Integrated Trust Network)¹ provides two functions in this regard: (1) a DID (Decentralized Identifier) registry and (2) SSDTs™ (Self-Sovereign Digital Twins™). We are going to focus the remainder of this blog on the latter.
The SSDT™ is the same as the digital wallet we discussed earlier. Both are instances of self-contained software comprising key management capabilities, a data vault, and operating ‘services’. However, whereas we typically think of digital wallets as being used only by people, SSDTs™ are also used by organizations and things.
Let’s understand how a surveillance camera would use an SSDT™ to address the issues we raised earlier as an example to better understand how SSDTs™ would be used generally in the world of IoT.
The manufacturer of the camera would create and host the SSDT™ on behalf of the camera at the time it is manufactured. It would issue the camera’s SSDT™ digital certificates proving where it was manufactured, when, with which hardware components, firmware version, etc. The keys to the SSDT™ would be held on the SSDT™ and the ownership certificate by the manufacturer until the camera is sold to the retailer. At that time, the manufacturer would revoke its ownership certificate of the camera and issue an ownership transfer certificate to the retailer with information such as when the sale took place, the details of the retailer known to the manufacturer, etc. Now, the camera has information in its SSDT™ not only about its origin but also its current owner.
When the retailer sells the camera to, say, a transit authority, for installation on a bus, again the retailer revokes its ownership certificate and issues an ownership certificate to the SSDT™ showing when the sale took place and the information known to the retailer about the transit authority. The transit authority then issues a digital certificate to the camera to be held in its SSDT™ stating in which bus the camera was installed, with what firmware version, to which server/service it is allowed to connect over the network, etc.
Now every time the camera connects to the network, it can prove from its SSDT™ that it is bona fide, has not been hacked, and to which server/service it expects to connect, all based on information issued to its SSDT™ from trusted authorities like the manufacturer, the retailer and the transit authority, and the cryptographic keys that allow the SSDT™ to verifiably sign all claims that it makes to ensure anyone can verify that the claims are made by the subject of the credentials and not by some other, potentially malicious, entity.
Note that wherever the SSDT™ is located in the cloud, only one entity controls it through the ownership certificate it was given by the previous owner and the registration of the owner’s keys in the DID document of the camera as the camera’s controller. All the information presented by the SSDT™ based on the digital certificates it holds is considered verifiable, immutable, and cannot be repudiated — i.e., trustworthy.
In our next blog, we will look at the significance of this example in the context of DIDs, or unique global identifiers.
> Read “The Digital Business Trilemma, Zero Trust, and the ITN.”
[1] The Integrated Trust Network (ITN) is the first Web3 infrastructure for trusted, self-sovereign identities for businesses. The ITN is backed by industry consortia and global companies representing over $450bn in annual revenue, spanning across industries representing over 18% of global GDP. The ITN was specifically created to address the threats to highly decentralized digital business transactions. As the first federated Certificate Authority (CA) for IoT, eCommerce, and business automation, the ITN acts as a global trust anchor for digital business. Using the ITN, businesses will be able to create very secure digital services that are locally highly performant while also decentralized in their use, a fundamental paradigm shift from the current leading identity providers for businesses worldwide such as Google, Amazon, Gemalto, Okta, and Microsoft.
