Development Notes

PKI based identity on a blockchain

August 15th, 2017 Company News Development Notes

Introduction

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 Beame.io.

Register for our webinar organized by GlobalSign and Beame.io

Background

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

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.

PKI

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.

Summary

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

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 Beame.io

How to Create Multiple Credentials with beame-sdk

February 26th, 2017 Development Notes

Understanding the Beame.io Network’s Credential Hierarchy

How to Create Multiple Credentials with beame-sdk

Overview

The Beame.io credentialing system allows you to create an infinite number of cryptographic identities (publicly trusted TLS certificates), divide them into logical subgroups and delegate the authorization process downstream. These credentials can be used for building trust between different system components, such as servers, mobile devices, IoT devices, and end-users. These logical subdivisions allow the creation of an application-specific virtual private encrypted network, irrespective of how systems are connected. They grant the correct permissions to the appropriate user.

General Principles and Definitions

The network graph can grow infinitely both in depth and in width. Let’s consider the following diagram, (Figure 1: Understanding Credential Structure).Read more ⟶

Apple Delays ATS Compliance – Secure Your Apps Anyway with Crypto-ID SDK

December 27th, 2016 Development Notes

 

ats-twitter-1

Apple was set to begin enforcing App Transport Security in iOS applications and their servers on January 1st, 2017, but extended the deadline at the last minute. According to Apple’s Developer Portal,

“App Transport Security (ATS), introduced in iOS 9 and OS X v10.11, improves user security and privacy by requiring apps to use secure network connections over HTTPS. At WWDC 2016 we announced that apps submitted to the App Store will be required to support ATS at the end of the year. To give you additional time to prepare, this deadline has been extended and we will provide another update when a new deadline is confirmed.”

The company obviously ran the ATS adoption rates and exception rates of App Store programs and decided they simply cannot enforce it right now because too many apps would be non-compliant. Is this sort of what do you do when you learn that 75% of your employees failed a drug test?

Apple had two great ideas with ATS: an attempt to retire the usage of older versions of TLS and specific type of certificate signatures, and enforce the usage of HTTPS.  As a platform developer, it is important for Apple to protect application users and their devices.  So what went wrong?

Read more ⟶

First Look: Session Control with Mobile Device Authentication

November 19th, 2016 Company News Demo Development Notes

We’re excited to share this with our community! This is the first video of our technology allowing a user to authenticate to services and have full session control- all from their mobile device. Of course, it’s end-to-end encrypted. The mobile device holds crypto-credentials which allow it to be recognized and log in. Part of our beame-insta-server, this will be released soon in a closed beta. In the meantime, check out our open source tool, beame-insta-ssl to get free and secure tunneling with your very own free SSL certificate!

To get on the beta tester list for the beame-insta-server or to receive updates from us, please sign up on our website, https://www.beame.io

 

 

In Pictures: Install a Non-Terminating Tunnel to IIS with beame-insta-ssl

October 19th, 2016 Development Notes

Step 1: Install:  npm install beame-insta-ssl  -g
install-insta-1

Step 2: beame-insta-ssl is installed

2-installed

Step 3: Get your personal token by emailRead more ⟶

Your Beginner’s Guide to Using beame-insta-ssl

October 18th, 2016 Development Notes

screen-shot-2016-10-18-at-4-13-27-pm

beame-insta-ssl makes it easy for any web developer to make use of encryption – and get secure communications!

In addition to our Readme, this is a step by step guide with screenshots that will take you through getting started! Please email h@beame.io if you have any questions.

beame-insta-ssl will get you your very own fully-qualified domain name under the beame subdomain that looks something like this: https://ypxf72akb6onjvrq.ohkv8odznwh5jpwm.v1.p.beameio.net/insta-ssl and your very own free SSL certificate (GlobalSign root CA). This will allow you to tunnel securely over HTTP. You can choose to terminate or not to terminate the Transport-Layer Security (TLS), which will be explained below.

Step 1: Signing up on our SSL-secured website and check your email. Read more ⟶

What’s the difference between beame-insta-ssl and ngrok?

October 14th, 2016 Development Notes

 

Given the success that ngrok has enjoyed, it’s flattering for beame-insta-ssl to be compared to them. To clarify some of our users’ frequently asked questions, we will elaborate on the technical details of how we are different! Here’s the link to beame-insta-ssl’s readme. Let us know if you need more information. 

pablo

On a free plan, ngrok generates new random CN under ngrok.io each time you run it. You can connect to that tunneling ngrok domain by both HTTP & HTTPS, but the secure connection option uses a *.ngrok.io wildcard cert and is terminated by ngrok and not by the developer’s backend.

People say, “So what, I can bring my own free cert from Let’s Encrypt.” So  in order to  use Let’s Encrypt’s services, you need to bring your own domain name, plus you have to manage that certificate by yourself (there are 3rd party tools that you’ll be required to use).

Read more ⟶

How I set up secure file sharing from my computer straight to your web browser

August 14th, 2016 Demo Development Notes

Try it for yourself – it’s all open source!

Using our SDK to start a socket.io chat over TLS

August 4th, 2016 Demo Development Notes

Try it for yourself – it’s all open source!

Cutting out the middleman server for good (how I put my gov’t ID on a https:// address that I control)

August 3rd, 2016 Development Notes

Last weekend, LinkedIn* locked me out of my legitimate (since 2009) personal account. Here’s the response I got from them requesting my government-issued photo ID. What’s wrong with this picture?

No, to my knowledge it was not a phishing attempt. And I haven’t sent them my ID. I did something better:Read more ⟶