On the IoT Exchange - DID integration

One of the challenges of introducing Decentralized Identifiers (DID) into Internet of Things (IoT) is the proprietary nature of the IoT ecosystem. Most IoT devices use proprietary technology. The ideal way of integrating DIDs is to put the keys and some cryptographic operations directly into the device. The assumption here is (1.) the manufacturer themselves can either generate and embed the keys from a secure or "offline" environment or (2.) manufacturer can embed cryptographic logic into the device and the device would generate the keys themselves, given that the device has enough power to execute the operations. If we are going create a service from DIDs and we do not have any access to the device manufacturing process, we may need to generate and maintain the keys elsewhere, but we need to make sure the pathway from that "elsewhere" to the device is _secure_, and how that secured pathway is implemented is *out* of the scope of this post.

That "elsewhere" is what we call the IoT Exchange. It maintains one DID for every device. It also maintains a cryptographic key pair per DID. IoT Exchange has its own digital identity wallet using an HSM plus key management service. It can also have its own device activation service but can also integrate into big cloud based IoT services such as Azure IoT Hub and AWS IoT Core using a fast private network. In fact, it can also use cloud services for data storage and analysis using that private network.

IoT Exchange also acts as a gateway of the devices to a potentially insecure network. Here we can demonstrate the power of DIDs. Consider this scenario. I have a service called Telebroadcaster that broadcasts device telemetry using a pub-sub mechanism. Incoming data from the service comes from different sources. Data can be from IoT Exchange, or from any other IoT Hub. Now as a consumer of the Telebroadcaster service, I need to trust both Telebroadcaster and IoT Exchange that the messages I am receiving are not malicious messages. Now if another party wants to me to share them the messages, That party needs to trust not only me but also both Telebroadcaster and IoT Exchange. This forms a complex trust chaining that is hard to maintain and to implement. But if message is to be signed by the owner of a DID, which is the device itself (technically IoT Exchange signs the message on behalf of the device), anybody in the solar system, perhaps even in the whole galaxy, can cryptographically verify the ownership of the message.

How would one verify the ownership if a message using the owner's DID? It is very simple. A DID (eg. did:ion:test:EiDPJSVutRWWQYDsTNYG1bhO_wgtrm_wzVSo2BKa_eXM9Q) is associated with a public key generated from a public-private key pair. The owner keeps the private key hidden to anyone except to himself/herself, while the public key is stored in a DID Document, a document persisted in a globally distributed ledger accessible to anyone. Whenever an owner communicates, it signs its message using its private key and send to the network along with its DID. Any party receiving the message validates the message by using the owner's DID to resolve the DID document and verifying the signature of the message by using the public key fetched from the DID document.

The fundamental thing of using DIDs in communication is we *always* sign messages before transmitting into the network. In practice today, device messages are not signed. When a TLS connection is terminated, the messages sent from that connection become just normal messages and not cryptographically verifiable. If a message is signed, we can still prove, even outside a secure environment that this message is totally from a specific person, organization, or a thing.

Comments

Post a Comment

Popular posts from this blog

The Sidetree Protocol

Blockchain scalability is a non-trivial problem, but there is now a promising strategy for scaling blockchain-based systems known as ‘Layer 2’ protocols, or L2s, for short (example: Bitcoin’s Lightning Network). L2s achieve scalability through deterministic processing and transaction schemes that take place ‘above’ the blockchain, with zero or minimal consensus requirements beyond small points of interaction with the underlying chain. For decentralized identity to become a reality, it requires a system that operates at massive scale, while still delivering on important features, such as deterministic state resolution and differential persistence. Using blockchains for anchoring and tracking unique, non-transferable, digital entities is a useful primitive, but the current strategies for doing so suffer from severely limited transactional performance constraints. Sidetree Entities is a Layer 2 protocol for anchoring and tracking entities across blockchains. Sidetree Enities, and nod...
Read more

Smartkey Overview

Whenever we write applications, we need to keep our _secrets_ in a single central secure place. These secrets can be your password to your database, your api key, or your cryptographic keys used for signing messages. There are two major reasons why we want to do this. The first one is we want these secrets to be fetched by multiple instances of the application from a single place, instead of duplicating or hardcoding them in the application. This secure place may be a keystore stored in a directory in a file server, but making it reachable across different environments, specially when dealing with software development in the cloud, ultimately becomes a challenge. Nowadays, this is implemented as a service, where it expose endpoints easily accessible to applications for fetching the secrets themselves. Aside from key access, these type of services often offer key management solutions such as key rotation and key revocation. These solutions are sometimes referred as key management servi...
Read more