Creating Device Identity using Hyperledger Indy

Introduction

Identity is the genesis of any operation of an IoT device. Without the device identification, the management and interoperability of IoT devices is not possible. In addition, the distributed nature of IoT makes centralized IoT solutions irrelevant. DLT architecture is a perfect fit for creating identity for IoT devices which are self governed. This gives devices and users of the system a complete control over their identities, at the same time enabled secure interaction between any two entities. Hyperledger Indy provides a self sovereign identity ecosystem based on DLT technology enabling secure and verifiable trust. 

Motivation

• Identity is the first step for a lot of other IoT operations like access control, remote operation, etc. Currently most of the access control systems are either centralized or do not scale well.
• With the identity of a device known, the vision of autonomous IoT device functioning becomes much more realizable. 
• The tracking of the device status during the supply chain provides critical management insights to the organization. 

Goal

To create an identity system for IoT devices and involved actors, thereby, laying the foundation for application to various IoT use cases. Further extending the system to enable device-to-device interaction enabling autonomous service exposure and consumption.

Assumption

GSMA’s DLT vision document outlines identity of IoT devices and access control as the foundation use case for IoT. We assume that the POC resulting from the present work will act as a foundation work for the rest of their use cases like those related to supply chain, data sharing and integrity.

Design Details

The initial design of the device identity creation would have the interaction of Hyperledger Indy, Hyperledger Fabric and Hyperledger Burrows. Hyperledger Indy is based on Plenum, but we will be using Fabric to reduce the changes to existing systems looking to adopt the identity solution. The general architecture of the solution will be as follows:

Initially, a smart contract is deployed on Fabric which will be responsible for onboarding and creating trust anchor roles for any new actor. The fabric will be composed of the organizations responsible for taking decision on the actor’s identity creation. These can be members of the board. For our POC we will create a network with dummy organizations. Once the initial roles are created, with each step of the supply chain, creation of series of identities will occur. Consider the following steps:

1. Device Creation: Once the device is created, the corresponding identity of the device will be created. This will contain the device id (uuid), manufacturing company, status. The claim issuer in this case would be the manufacturing company, the holder will be the device, and the verifier would be the users. We will maintain status as a separate identity as the status will be changing across the process and thus, will require revocation and recreation will be frequent.
2. QA Testing: Once the QA testing is done and the result is available, corresponding identity will be created on the Indy. The claim issuer will be the QA team, the holder will be the device, and the verifier will be the users interested in the status. The QA test result will be the value which will be held in the identity. The previous status will be revoked and a new status will be created.
3. Supplier: Once the device is with supplier, again the status will be revoked and recreated. Other details like supplier details will form another identity. The claim issuer will be the supplier, the holder will be the device, and the verifier will be the users interested in the status.
4. User: The identity other than the status will be the user registration details which will be created. The user will be the issuer, the device will be the holder, and the users will be the verifiers.
5. Recycle: The status and the date will be recorded as a separate identity. The issuer will be the user of the device, the holder will be the device and the verifier will be the user interested in the status.

Network: The sample fabric network will be designed with 4 organizations with 2 peers (though it can be scaled to include more organizations and peers) and will form a consensus among themselves. The smart contract will control the transactions being accepted into the network. The initial setup of the Indy requiring the creation of steward will be done via the contract. The Steward will then create other roles and once setup, the normal operation will resume. The smart contract will be the gateway to the network.

Smart Contract: The smart contract is a replacement for a trusted entity since the code will be shared with the participating entities and will be deployed by consensus. The contract is responsible for creation of Steward role. Usually, Stewards are important members of a governing body. Steward is then responsible of creating other actors like manufacturer (production line), manufacturer (QA), wholesaler, distributor (mobile operator) and end customer at various stages. For all the actors, the Steward will onboarding actors mentioned above and then grant verinym and a trust anchor role.