While bludgeoning two buzzwords at the peak of the hype cycle is often an illconceived attempt to proactively incubate s ynergy, we feel there is a strong exception in the case of Internet of Thing (IoT) devices and Distributed Ledger Technology (DLT).
One common (and very valid) criticism of a move to fill our world with IoTenabled consumer devices comes from a concern around security and device management. If a device owned by a consumer is able to be hacked or otherwise compromised by an outside attacker, this can become not only an inconvenience but may be an actual physical danger to consumers as thermostats, locks, and more become controlled by such devices.
One potential solution to this is to equip these devices with the ability to generate unique, unforgeable cryptographic identities (public/private key pairs) and enforce at the hardware level that the device cannot operate or be activated without being provided with a cryptographically signed authorization from someone who is allowed to do so.
This still leaves unanswered the question of how the device knows which identities are authorized at any given time, the key distribution problem faced by any cryptographic system.
Fortunately, DLT provides a very powerful answer to the inherently thorny question of key distribution. If the IoT devices not only have the ability to perform the raw cryptographic verifications but can also verify a list of authorized users as maintained by a Distributed Ledger (DL), then very strong assurances can be made that such devices are only physically able to be controlled and activated by those who own them or those the owners have authorized in turn.
Device Identity
While potentially problematic to get right in adversarial conditions, we can (somewhat) trivially embed secure computing environments in devices that allow us to generate private/public key pairs where the private key can never be copied or extracted, but can securely sign messages on the chip itself on demand.
This allows us to guarantee that if we get a signed message from a known public key, we can be assured that it was generated by a known device and is not the result of a leaked or stolen private key.
We can then use this to bootstrap strong access controls around the networkenabled capabilities of the device itself, only acting on commands generated by individuals or devices which are properly authorized to make a particular request.
DLT as Identity Management
Once we have a mechanism for generating secure devices that are married to a particular device, we still need a method of assigning meaning to that identity and validating that meaning on the devices themselves.
We address this problem by using a DL to hold the metadata regarding device ownership and allowed access. This acts, conceptually at least, much like the CA system for generating and authenticating SSL certificates for the internet.
This allows manufacturers to onboard devices into the system at the time of manufacture and individual identity issuers to onboard individuals into the system to claim ownership of their devices and allow others temporary or permanent authorizations when desired.
The cryptographic proofs generated by the DL can be validated on the device itself using similar technology to that which we are using to generate device identity in the first place.
A set of libraries that allows device manufacturers to safely and securely validate these authorizations can then allow manufacturers to draw from a standardized set of tools rather than rolling their own, making the endtoend implementation process faster, more costeffective, and secure.
Next Steps & Desired Outcome
In order to move toward a set of tools that can enable IoT devices to take advantage of this, a platform for managing device identity and authentication will need to be built and maintained.
Eventually, a set of standards for how to generate, onboard, and utilize identity proofs will need to be adopted by those building both the hardware and the software side of IoTenabled products, but this should be driven by learnings derived from the first useful use cases rather than being dictated by committee before we have had a chance to see how this technology is used in the real world.
A good way of moving toward the end outcome is then to choose some immediately useful use cases as a starting point, proving out the potential value in a realworld environment, then taking first steps at distilling those learnings into standards as a basis for building the secondversion use cases that follow in their footsteps.
