They rigged a board to watch changes in indicator lights when the machine pushed out a can. And they hooked up the board to a computer with an internet connection so that anyone could also see the dispenser’s status. Even if they had to take a flight to put quarters in the machine.
There was little question of whether they were looking at the state of the right drinks dispenser: there was only one to choose from. And the likelihood of someone swapping the board out for a device that would fake the results was similarly low. Very few had direct access to the internet at that point. A decade later, in coining the term internet of things (IoT), Kevin Ashton, then a manager at consumer giant Procter & Gamble, envisaged a future where computers could track practically everything manufactured. “We would know when things needed replacing, repairing and whether they were fresh, or past their best,” he said.
It took a while for the industry to realise that it would at the same time need to find a way not just to identify each node but check that it is not just pretending or even if it should be there at all. Is that delivery drone really delivering a parcel or stalking? Who owns that camera that is sitting on the wall? Conversely, when someone tries to access an IoT device, how does that device know the request is legitimate?
Gradual improvements to embedded-systems security have coincidentally filled in many of the identification requirements. The ability to check provenance and validity now relies heavily on X.509 certificates. It is one of the key methods supported by Amazon Web Services, Bosch and others in their IoT hosting services. In principle, only legitimate users have the correctly signed digital documents, giving either end of the connection high confidence.
Now, as concerns grow over the ability of human users to identify themselves reliably online, IoT and embedded device makers are gaining some new options that may make dealing with them easier. At least once they are past the learning curve of handling a new set of cryptographic techniques.
Digital identity
When it started, eIDAS, the European Union’s proposal for a digital identity scheme for individuals followed the earlier standards developed by the IT industry. These revolve around centralised trust registries that service providers use to check the credentials provided by a user. Users of social media will recognise the logins supported by these OAuth-based systems while enterprises often embraced the XML-based Security Assertion Markup Language (SAML) to support single sign-on across different corporate servers and applications.
By mid-2022, the EU’s eIDAS team decided it needed to embrace the same kinds of decentralised approaches that have emerged from work on blockchains, the Web3 community and work by the Worldwide Web Consortium (W3C). Self-sovereign identity (SSI) makes it possible for individuals to manage their own identity and credentials independently of any central registry. Doing that involves three principal components. The first is a decentralised identifier (DID), which basically tells the receiver where to look for the details it needs to check an access request, including the two other components: what form of proof the user or object behind the DID aims to provide and what claims they are making, in the form of verifiable credentials (VCs).
The industry has settled on the W3C’s specification for DIDs. Proof methods are a lot more varied. They might be hosted on one of the major blockchains, such as Bitcoin or Ethereum, a centralised trust registry that delivers compatibility with more traditional identity systems or self-managed systems. VCs potentially provide a much greater level of flexibility than X.509 certificates. Operators can generate VC not just to cover all the services and data provided by the device or the tasks that a remote user might want to perform. Device managers can create VCs for each type of task or user. That, in principle, supports the principle of least privilege that governs the zero-trust approach to IT security. The recipient uses the named proof method to check that each VC is legitimate.
That combination makes it easier, in principle, to set up IoT ecosystems that involve multiple vendors and where access rights might change frequently. For example, operators of edge servers might allow certain software payloads only to be run by active subscribers. The server would check the VC’s claims against its own database rather than having to deal with the problem of updating and revoking X.509 certificates. That same edge server may also perform authentication services for the IoT devices it manages. Those devices could continue to rely on the X.509 infrastructure or simpler systems to reduce their computational overhead.
Above: ToIP’s concept of the identity and authentication stack with the trust-spanning VID protocol in the middle of the (light-grey) hourglass
The big problem
The big problem that faces the entire identity movement is the sheer variety of options organisations could use. Rather than try to force a common mechanism, developers are trying to fix some of the underlying plumbing. At the IoT Grand Slam conference in December, Scott Perry, principal for crypto and digital trust services at Schellman, explained, “We have holes in the internet architecture because we didn't realise we needed to bake in identity.”
This is where the Linux Foundation has stepped in, forming the Trust over IP Foundation (ToIP). The ToIP’s idea revolves around the idea that IP itself is a spanning protocol: it provides the glue for many upper-layer protocols to access various types of network, ranging from local wireless networks to long-distance ethernet.
Similarly, ToIP sees its work as building such a spanning protocol for systems that need to build trust in each other and verify they are what they say they are. With this approach, it should not matter if one organisation uses the Ethereum blockchain to manage DIDs and VCs while another opted for a decentralised filesystem and a particular type of zero-knowledge proof to vouch for the data. The trust-spanning protocols would map from one to the other. It also allows for the possibility of building chains of trust. A VC that vouches for a particular group could extend to all the current members of that group, with that second claim backed by another VC.
As with VCs and DIDs, the ToIP’s proposal relies on a cryptographic foundation. The core is the trust network’s version of an IP address: the verifiable identifier (VID). Unlike classic IP, VIDs are not linked to locations: much like DIDs they point to whoever or whatever holds the private key and other important pieces of data that underpin each identifier.
The rate at which developers take up these decentralised protocols over certificates in the embedded and IoT domains will naturally depend on changes in use-cases in parallel with attempts to reduce the memory and processing overhead of DIDs and VCs.
Though IoT launched with the promise of building systems of systems where each component has a different owner, cooperation often seems to happen more through cloud servers than directly between the edge devices. In other cases, some specific regulations have forced the hand of developers. The ICAO has developed a standard for identifying flying drones with codes managed through a central registry. But as governments move to digital identity with systems like eIDAS, it may make more sense to embrace the technologies and standards behind SSI.
