PKI based identity on a blockchain

August 15th, 2017 Company News Development Notes


Device and applications explosion in the IoT world turns every related security issue to critical due to its huge scale. There are numerous IoT manufacturers and application development companies, and thousands of already deployed IoT devices that potentially can be used by the attackers, as it recently happened several times.

In this post I will target the device identity. I will show how to use the most popular conceptual approach today – a blockchain, put on it the proven technology of the Internet – the PKI, and with that limit access to the devices to mutually authenticated sessions, where both identities: of the requestor and the device are cryptographically verifiable.

As usual, some technical background in form of general definitions first and then the magical part.

The technology used in this blogpost was developed in

Register for our webinar organized by GlobalSign and


There is a bunch of technologies used in this post. It will be much easier to understand certain things, if the reader has basic understanding of how hashing and digital signatures work, but I did an effort to make it readable for any 🙂


Blockchain is a linked (chained) list of records, intended to serve particular purpose. As of today main application of such model was cryptocurrency (Bitcoin), with slight movement towards more generic use (Ethereum). Records in blockchain contain data relevant to the host application.

In more common words: blockchain is the way to store application specific data, when the data by design can be split to discrete meaningful chunks. Relationship between consequent records shall be such, that removing an element would not pass undetected. The storage shall be decentralized in a way, that all elements of the system carry some version of the blockchain.

To ensure data integrity, system policy shall take care that all system elements have the very same blockchain version at some moment in time after each change.

The Ledger

Another word that can describe blockchain structure is the ledger. To make a logic connection, records in the blockchain would be called events, each event carries some event related data, that allow event (and whole ledger) validation.

Keep in mind, that every event should be signed by a valid signer.


Public Key Infrastructure – ecosystem that allows creation and management of digital certificates (X.509). Globally maintained by CAs (certificate authorities), that provide tools to keep the PKI up and running.

PKI + Blockchain = Identity

Let’s start from building a real life example: a house, with couple of computers and mobiles, an electronic door lock and a couple of security webcams (each device is intended to be set eventually with its own certificate):

The arrangement is not random – devices are put on layers. Topmost layer L0, displayed as main home PC, next one below – some laptop, main mobile phone L2.1 (also used to authorize identities of cameras and the lock that then appear on Layer 3), L3.4 – will be some guest mobile authorized by L2.2 (e.g. her mom came to visit on holidays).

Arrows show, how upper layer devices are used to authorize lower level devices (e.g. L2.2->L3.4). That structure will later allow us to replace separate identities, without need to replace all identities in the system (e.g. compromise response with limited damage).

To start analyzing the trust in such network, let’s define two logic components (remember that we are talking about PKI on blockchain?):

Certificate Chain

As it sounds – certificate chain is a logic chain built up of certificates. X.509 can support more than one unique name, and we will use that fact to chain up the certificates.

CN (common name) field, the domain name, will be the actual device identity (like a username). Using this analogy, private key used in appropriate way will be the password, with major difference that it never leaves the device and only used to prove the possession.

SAN (alternate name) will hold slightly changed CN of the entity that approved, or authorized the new identity creation (issuance of new X.509).

Built in such fashion, certificates will form a tree, where leaf nodes are the certs and relationships are created by their content (CN and SAN fields). Tree root will be the uppermost node (L0, or home PC in our example).

The picture below, shows our house in schematic view with devices displayed as certificates with some data, to show the bonds between them (L3.3->L2.2->L1->L0):

Consider a connection request from L3.4 to L3.3 (her mom is trying to open the electronic lock): in order to find common root, L3.3 (the lock) will have to walk up the tree, using SAN fields of L3.4 and L2.2, as well as its own, and the search will be: L3.4->L2.2->L1<-L2.1<-L3.3

This means, that L3.3 is a relative with L3.4 through the L1, and with trust criteria correctly set the connection can be securely allowed.

However, there is a catch: how can we be sure, that the certificate of L3.4 is indeed signed by the correct key? Or in other words – if some bad CA signed a certificate with the same CN and SAN fields, how can we tell them apart?

Here when it is time to put it all onto the Ledger, and tie with authorization proofs.

Authorization Proof Chain

First of all several basic claims and definitions:

Here we can form a definition for authorization proof:

Real life example would be – teacher and parent signatures on homework diary.

Looking at our example: L0 (the PC) authorizes issuance of X.509 to L1 (the laptop) and alongside that, creates a record (event) with signed name (CN) and public key (generated by the L1).

Given that:

  1. L0 is already equipped with X.509 based identity
  2. All devices equipped with SW tools allowing communication and required cryptographic operations (beame-gatekeeper, beame-insta-ssl, beame-authenticator)

This flow will be:

  1. L1 generates RSA key pair and sends request to L0 for identity creation
  2. L0 generates valid CN (FQDN) for a new identity
  3. L0 creates authorization token, containing authorization proof (signed L1 public key and the new L1 CN)
  4. L0 creates a record for issuing a registration token
  5. L0 sends the token, containing the record from 4), back to L1
  6. L1 stores the record from the token
  7. L1 generates certificate request (using own private key and the token) and sends it to CA
  8. CA verifies signature of L0 and the request
  9. CA signs the new cert and sends it back to L1
  10. L1 gets a certificate and creates a record, following the record of its authorization proof

Now this procedure will be repeated for every lower level device (mobiles and webcams). Keep in mind, that L3 devices would be authorized by L2 identity. So by the end of the process, we will have that all devices own a valid certificate, connected by its content to its ancestors up to L0, and also holding the proof of its creation, signed by the authorizing entity. Lets call these records “creation events” and draw on a simplified diagram how they are related:

Looking at the diagram, it is easy to spot, that walking up the “create” events, we can get from any device, to the corresponding “create” of L0. So it looks just as walking up the certificates. With some significant differences:

That’s that. The diagram we just saw is the Event Ledger and finally, considering all the functionality, and it is our Blockchain.

Small problem: each device seems to have different version of the Ledger. How do we deal with this? Correct – mining. We need some external highly available entity to do a synchronization of our blockchain. Availability level – is a function of how fast the system changes, so for our system it can be rather low (may be even performed on-demand).

For the purpose of this limited use-case, we’ll set that responsibility to L0, our main home PC. For that, any device creating an event, will send its full Ledger to the Miner and the latter will merge it and send it back. So now there will be N+1 verifiable versions of the Ledger in the system (N = number of devices).

Now any device, receiving a request and, for example, not finding suitable authorization proof in local ledger, can request the Miner to perform required merge, by sending to it its own Ledger along with the requestors one. All what will be left to do, is to verify (e.g. by L3.3), that merged version is correct, by walking through it and finding corresponding event.

So let’s look back at the scenario, where L3.4 (her mom) was trying to access L3.3 (open the door lock). We were able to verify on L3.3 the identity of L3.4 by finding the certificate of L0 in their common certificate tree. Now, L3.3 will be able to verify, that the X.509 certificate, that L3.4 owns, contains the right public key, by manipulating the events in the Ledger. Fin.


The PKI based identity on a blockchain is the new security technology developed by

In this blogpost, we’ve seen a smart-home, where home appliances and computers identities are members of global PKI, and their common history being kept on limited functionality event ledger – the blockchain.


Is it scalable? – Of course. Define system functionality. Add event types (there are a lot). Use suitable amount of miners.


What happens if my certificate is lost/device broken? – That one is left to the same operations: verifying the cert, finding corresponding events in the Ledger and making decisions (subject for separate blogpost)


What if my certificate was compromised? – Compromise response is yet another blogpost. Still, using flexible logic and correct event structure it is possible to get to very limited damage in certain compromise scenarios.


Can I use same identity to connect to my cloud IoT services? – Yes. Want to know more? – Register for webinar organized by Globalsign and

Recent Posts

Private cloud is easy

Insta-SSL as a simple way to use RDP / VNC / SSH into LANs

VMs, Docker and vs NSA

x.509 based identity, OS level or dedicated application?

SSO and custom Identity Providers