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. 

...

To create an identity system for IoT devices and involved actors, thereby, laying the foundation for application to various IoT use cases. In particular, we focus on the identity access, identity association with id, monitor the supply chain. Further extending the system potentially in the future to enable device-to-device interaction enabling autonomous service exposure and consumption.

...

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

...

general architecture of the solution will be as follows:

Image Removed

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  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:

Image Added

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 peersFrom the use case:

Device status is a particularly important attribute of the device because this is very difficult to trust at present especially when buying from less official channels. Device status can contain multiple attributes and permissions to add/ update attributes may differ according to the user role e.g.

○ only a manufacturer can allocate a serial number,

○ only the manufacturer QA team can mark a device as having passed QA,

○ only the manufacturer can change the ownership of the device to a

distributor,

○ only a distributor can only a Mobile Network Operator can allocate an MSISDN;

Detail Steps:

1. Schema Creation, Credential Definition Creation. 
   1. Distributor (Mobile Network Operator)  with create schema (Telecom Schema) as standard in the entire supply chain. Both Producer (Manufacturer, called pineapple in our demo) and QA team ( is the QA team of the Manufacturer) will together create Credential Definition.
   2. To simplify the reality, in the use case, the Manufacturer is a different entity compare to MNO (although could be the same some times). Also usually you have several distributors in this case GSMA, assumed only one to make it easier.
2. Device Creation
   1. Once the device is created, the corresponding identity (DID Documents) of the device will be created. The device will be treated as an independent thing and receive the credential from Producer. The device shall  shall be assigned the series number from manufacturer.
3. QA Testing
   1. The device will be passed through QA testing. In the demo, assume passing the QA.
   2. After QA pass, manufacturer will offer a Credential Offer for the device. The device shall receive the Credential from manufacturer. (currently, our credential including: manufacturer, sequence_id, bandwidth, QA_status, history = null)
4. Passing device through Distributor
   1. After receiving Credential from Producer and QA Team, the Distributor (Mobile Network Operator) will assigned and MSISDN in DID Documents of device. After that, the device can connect to the internet.

We simply use the DID to mark the ownership and access control. The KYC process and recycling process are not taken into consideration currently. The changing of ownership from manufacturer to operator, and from operator to end user is use the revoke of DID and claim new DID.

Network: The network will be designed with 3 organizations (Distributor, Producer, QA Team) with 3 peers (User, device A, device B) and will form a consensus among themselves. The smart contract DID documents and Verkeys 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  

DID and Verkey: DIDs work as the role of trust anchor to the ledger, as we create Steward’s DID. The actions (including owner’s action and manufacturer's action) is written on the ledger, generate new DID/Verkey pairs. After that, Prover uses Credential Offer to create Credential Request. Trust Anchor then uses Prover's Credential Request to issue a Credential. Steward is then responsible of creating other actors like manufacturer (production line), manufacturer ( QA ), wholesalerteam, 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. 

Implementation

https://github.com/quantumcatwang/Telecom-IoT-device-SSI