Created date

March 14, 2018

Content type (localized)



Decentralized Certificate Hierarchies for IoT Devices Using Blockchain Technology

Public Key Infrastructure (PKI) is used to establish trust among entities on the internet. This is accomplished by issuing cryptographic certificates to service providers as well as end-user devices that use these certificates to establish secure communication channels with the help of protocols such as the Transport Layer Security (TLS). This solution requires all certificates to be issued by the same Certificate Authority (CA), i.e. all certificates pointing to the same root certificate. Alternatively, servers and client devices must store a large number of root certificates issued by multiple CAs in order to create trust across otherwise disconnected trust ecosystems. Therefore, a typical browser or a cell phone holds hundreds of root certificates from issuers that most users never heard of.

The IoT world will have many ecosystems that will include a diverse set of devices coming from different manufacturers from around the world. They will eventually all want to talk to each other to some extent. It is unlikely, and certainly undesirable, that we will have a single IoT CA creating a monopoly governing a single source of trust.

The other extreme is for each device to have a self-signed certificate, which is certainly useful for creating encrypted communication channels between devices, but does not help with verification of authenticity, trustworthiness or compliance with standards or regulations.

We need to find a middle ground: decentralized, immutable, distributed source of trust. 

Several standards organizations are working on a mechanism to publish trusted information about device compliance, security level, resistance to vulnerabilities and general device description (aka “food label”) based on the blockchain technology. This solution creates a secure, machine-readable distributed database of device model information where manufacturers may publish device model information, certification labs or standards organizations may publish compliance and interoperability with specifications, and regulatory bodies may check compliance with regulations, without a central authority governing it all.

Furthermore, as information about a device model gets published, certified by a compliance lab, and updated with security and software updates, such an unmodifiable sequence of transactions builds trust in a device over time. The opposite is also true since lack of information or compliance or updates decreases trust in a device.

There is no single source of trust, but rather a gradual building of trust by multiple entities attesting for each other. For instance, a standards organization approving multiple certification or compliance labs makes the labs more trustworthy. Or a test lab conducting tests of device interoperability and conformance to specification helps manufacturers build their reputation of having multiple compliant device models that are maintained with security patches over a long period of time.

Such information may be used by end users before they decide to purchase a device. It can also be used by other devices, such as home gateways when they discover a new device on the network, which wants to connect to the home domain, in order to verify its capabilities, compliance with standards and regulations, etc. Individual ecosystems may set up policies or requirements for which devices may join the ecosystem. For instance, a level of security that may be good enough for a backyard lighting system may not be sufficient for a commercial building security system.

The distributed nature of this mechanism may be even more important considering the large number of IoT standards, different government or international regulations, and the fact that many devices will likely interoperate with more than one standard and may fall under multiple regulatory policies. Again, such a diverse environment cannot be governed by a single private organization or governmental agency.  

Without reliance on a central CA, a manufacturer may decide to create its own self-signed root certificate (e.g. X.509) and its corresponding key pair, which signs device model certificates, which in turn sign individual device certificates. Since any legitimate or illegitimate manufacturer can do this, it is certainly not good enough, at least initially, to establish sufficient level of trust in the device.

However, when a manufacturer is added to the blockchain by a trusted standards organization as a legitimate member company, the trust in such a self-signed certificate may increase. Once a device made by such a company is certified by a reputable test lab, the device model certificate trust increases. After enough information about all these entities is published on the blockchain, their PKI certificates will gain trust without a centralized CA and may increase that trust as software updates are published and incremental compliance tests are passed.

Example use case: A home gateway detects a connection request from a new device on the home network. The request is accompanied by information about its model number, signed by the device private key and the certificate chain including the model certificate and manufacturer certificate attached. As the gateway has no relationship with the device manufacturer, it does not hold the device root CA certificate. The gateway connects to the blockchain, looks up the device model, checks its certificate (or a corresponding hash), verifies device compliance and interoperability, further looks up the manufacturer record and the root certificate also included in the blockchain. If certificate information matches and compliance policies are satisfied, the gateway accepts the connection request and creates a secure TLS channel (or equivalent) with the device. Furthermore, if the manufacturer certificate has been endorsed by a standards body or the device model certificate is included in the compliance record, the gateway’s trust in the authenticity of the device increases. 

Standards organizations, industry alliances, compliance and certification labs, and regulatory bodies may include their certificates in the blockchain registration record as well. The more legitimate transactions they issue on the blockchain or are issued by others about them, the more their reputation increases and the more trustworthy their certificates are.

When a manufacturer is no longer a member of a standards organization, or a specific device model fails certification, or a particular version of software (such as Linux) or communication protocol (such as TLS) is vulnerable to a newly found attack, such entries may be added to the blockchain as well. They decrease the trustworthiness in such a device until software updates are made available.

A typical device manufacturer certificate hierarchy:

It may be even simpler by removing the business unit (BU) intermediate certificate or even each device model may represent its own certificate hierarchy.

Alternatively, the manufacturer may decide to use a public certificate authority in which case the manufacturer certificate would be a sub-CA certificate signed by the public CA. In other words, each manufacturer is free to decide how to manage its own certificates or whether to use a third party to issue certificates.

The described system may be even more open. One could start a new organization or a consortium by adding it to the blockchain. Similarly, a device manufacturer or a service provider may add a record about itself to the blockchain. When that manufacturer joins the consortium, the consortium may create a transaction on the blockchain announcing that the manufacturer is an official member. The manufacturer may also add a transaction verifying that the compliance organization is a valid entity. As more and more manufacturers join the consortium, its reputation increases. Similarly, a manufacturer’s reputation increases if it is a member of multiple standards or consortia. Additionally, two or more standards organizations may create a liaison relationship and record it on the blockchain.  

This mesh-like arrangement allows for revocation of certificates associated with the manufacturer or in general any entity on the blockchain. For instance, when a manufacturer produces noncompliant devices or it fails to provide a mandatory security software update, etc., it will be known via the blockchain. This may not represent a complete revocation of the certificate, but it certainly lowers the trust associated with the manufacturer’s devices. When multiple organizations do that, it may result in de-facto revocation.  

Each entity participating in these relationships may have its own certificate. Transactions that reference another entity not only by its identifier but also by its certificate (or at least its hash) may be more valuable. For instance, when a standards organization approves a test lab, it may include its certificate or hash in that transaction. In turn, when a test lab issues a compliance transaction about a specific device model, it may sign it using its private key. This mechanism makes it more difficult to issue fraudulent transactions. 

The mechanism described above attempts to help IoT ecosystems to determine a level of trust in order to decide whether to add an otherwise unknown device to its network. One extreme is to handpick and pre-integrate a small number of devices up front; another one is to admit everybody. The former is expensive, does not scale and makes users unhappy by limiting choice; the latter results in unreliable, non-secure networks also resulting in unhappy users. Thus, the proposed solution creates a meaningful balance between scalability, security and usability, while leaving policy setting to each ecosystem. 

This article builds on earlier posts where we describe a compliance ledger: “Protecting Revenue Streams with Compliance and Market Segmentation Tracking” and another that summarizes the difference between centralized and decentralized trust: “Verimatrix Labs: Rethinking Rights Management for IoT.”

We have also published a more detailed technology description of the “IOT Compliance Ledger.”

We’d love to hear about any developments that you are involved in to make blockchain a viable option for IoT security, compliance or certificate management.