Let’s chat about blockchain technology, shall we? If you know almost nothing about blockchains, then it’s probably easy to conflate it with so-called cryptocurrencies like Bitcoin and Ethereum. Those are systems where someone magically created a store of money – well, a store of some sort of artifact that becomes money only when someone decides it’s a good idea to pay for them with officially recognized money (which some refer to as fiat currency, literally meaning, “Let there be money” – which pretty well describes cryptocurrency as well). Those systems happen to rely on blockchain technology for robustness and decentralization.

Robustness and decentralization are good things if you’ve got something of value whose integrity you want to protect. And money isn’t the only thing that fits into that category, which is why blockchain may be involved in many things other than cryptocurrency.

I was one of those folks minimally aware of blockchains (not that I’m an expert now…). So when I saw blockchain being bandied about for security, I wondered whether this was a natural fit or just some marketing effort to apply blockchain to everything. To help clear that up, I had a conversation with Gemalto, who includes blockchain in their security arsenal, to see if I could better understand how blockchain fits into the security picture.

Simply a Ledger

Blockchain’s relevance becomes clearer when you think of it as a ledger, which it is. That’s why it’s good for cryptocurrencies: all transactions ever are recorded on a ledger. Anything else that could use a ledger of some sort could also leverage blockchain. Including IoT data transactions. That said, it’s not always the best solution.

The idea is that multiple parties who don’t know each other share data. Because they’re not necessarily trusted (although they’re also not distrusted), the multiple parties to a transaction may want a way to confirm that the data is valid.

But that can be a misleading notion. “Invalid data” could mean that an originating IoT device malfunctioned and created bad data. Blockchain can’t help with that. When someone confirms a transaction, they’re not doing an end-to-end validation of the history of that data. So what does a confirmed transaction mean?

The issue here is one of data integrity – that is, that the originally reported data (whether or not from a correctly functioning device) was faithfully transmitted and recorded. In the simplest case, the data is stored in a database owned by the IoT device or service provider. And, in simple two-party transactions, that may be sufficient and efficient.

But when transactions involve multiple parties – more common, perhaps, in industrial settings – then you likely have multiple copies. Or you have one copy that multiple parties can access. If you have one or just a few copies, then it becomes, well, not easy, but viable to hack in and alter the data, since there’s only one (or at most a few) places where the data resides. It’s the single point of failure problem.

This becomes particularly important if that data is the basis for an important decision on action to take – especially if that action will be automatically taken without a human intervening. If the data is wrong, the action might also be the wrong thing to do. So ensuring integrity becomes mission-critical.

With blockchain technology, networks are created with multiple nodes, each of which hosts a copy of the ledger. Those nodes communicate with each other, so that changes to one need to be validated by the others. This makes it really hard to monkey with the data: if you hit only one node, it’s likely to be rejected as invalid. If you try to hit all the nodes (really hard), you have to do it really, really quickly before the other nodes figure it out and before new transactions are added to the ledger.

Cryptography and Consensus

There are two characteristics of these networks and of blockchains that make this robustness possible. The first is the structure of the ledger itself. It has cryptographic elements built in that make it really hard to mess with. First, each transaction includes a hash signature that will show whether the transaction itself has been altered (assuming the hash hasn’t also been changed).

But, yeah, someone changing the transaction could conceivably try to change the hash so that no one notices. Instead, the hash includes not only the transaction, but also the hash from the prior transaction (i.e., it’s a link that forms the chain). In other words, the hash of a new transaction reflects the entire prior history of the ledger. If someone wants to go in and change an old transaction, they have to change not only the hash of the changed transaction, but also the hashes of each subsequent transaction. That’s really hard to do quickly in a way that won’t be noticed by the other nodes.

Which brings up the other characteristic of a blockchain network: consensus. In one way or another, transactions – or changes – have to be approved by someone or some group. With Bitcoin, transactions are validated by so-called miners who have to solve some hard cryptographic problem to prove that they did the validation (and they get a cracker – er – some Bitcoin for their efforts).

Gemalto pointed to a newer network called Cosmos, and this is much more about consensus than Bitcoin. The idea is to protect against any kind of data failure – whether due to a faulty machine or to maleficent interlopers. There is a group of voters (100 for now, increasing to 300 over time) who have a stake in the network, and they validate each transaction before it can be added to the official register.

This brings up the whole idea of a state machine: there are a series of states that a transaction must go through before it attains the sought-after committed state. With Cosmos, each voter checks the cryptographic integrity of the new transaction, and, if two thirds of the voters agree, then the transaction is committed. This allows for up to one third of the machines to have a problematic version of the transaction without the transaction being rejected as invalid.

Once committed, the transaction becomes part of the ledger. Because all of the transactions are linked together cryptographically, and because the ledgers are replicated across the nodes, you can’t change an old transaction: the ledger is considered immutable. What if you find a mistake in a transaction and you need to fix it? Just as with good accounting principles, rather than change the original transaction, you need to create a new transaction that has the correction.

A Variety of Networks

Different blockchain implementations use different validation algorithms and have different rules, so the specifics of the validation and the organization may vary. Networks like Bitcoin are public, and anyone can download the software and become a miner. For IoT, it’s more likely that the networks will be private. Private networks are also more likely to be permissioned – that is, not just anyone can participate.

Part of the blockchain ethos involves lack of central authority and control. Requiring permission inherently means that someone has to be authorized to give permission, and that starts to build some hierarchy into the network. So it’s something of a tradeoff: if you know that everyone in the network has been vetted, then you may have more confidence in the security of the system. But that works only if you trust the people, organization, and rules that govern how the vetting happens. It’s a delicate balance.

So, in summary then, IoT devices churn out data. That data is assumed to be correct as generated for our purposes. That data is then replicated across the network in a cryptographic manner. The voters at the various nodes generate a cryptographic vote on each transaction, and, if 2/3 of the votes agree, the transaction is locked into the ledger. (At least, using the example of the Cosmos network. Others may work differently.)

Validation is relatively quick: newer algorithms promise to be fast (unlike the intentionally hard Bitcoin ones), allowing quick turn on a large number of validations. For any given validation (which has to take its place along with other validations, and which has to achieve consensus), a couple of seconds is typical (Gemalto said definitely faster than 30 seconds).

There’s some inherent complexity to all of this, which is why, if the data is used only between two parties, or if it doesn’t drive automated decisions and action, then it may not be the best solution. Will blockchain pervade the IoT for those applications that could use it? It remains to be seen. Gemalto is clearly placing their bet on that happening.

More info:

Gemalto’s blockchain security offering

Cosmos network

Sourcing credit:

Gorav Arora, Director, CTO Office, Gemalto

Joe Pindar, Director, CTO Office, Gemalto