feature article
Subscribe Now

Blockchain in IoT Security?

It’s Not Just about Money

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

4 thoughts on “Blockchain in IoT Security?”

Leave a Reply

featured blogs
Oct 5, 2022
This year's Jasper User Group is coming up later this month on October 19th and 20th. Once again, we are back in person (I'll be there!) on the Cadence campus. There will also be a 3-hour webinar available before the event to provide an introduction to formal techni...
Oct 4, 2022
We share 6 key advantages of cloud-based IC hardware design tools, including enhanced scalability, security, and access to AI-enabled EDA tools. The post 6 Reasons to Leverage IC Hardware Development in the Cloud appeared first on From Silicon To Software....
Sep 30, 2022
When I wrote my book 'Bebop to the Boolean Boogie,' it was certainly not my intention to lead 6-year-old boys astray....

featured video

PCIe Gen5 x16 Running on the Achronix VectorPath Accelerator Card

Sponsored by Achronix

In this demo, Achronix engineers show the VectorPath Accelerator Card successfully linking up to a PCIe Gen5 x16 host and write data to and read data from GDDR6 memory. The VectorPath accelerator card featuring the Speedster7t FPGA is one of the first FPGAs that can natively support this interface within its PCIe subsystem. Speedster7t FPGAs offer a revolutionary new architecture that Achronix developed to address the highest performance data acceleration challenges.

Click here for more information about the VectorPath Accelerator Card

featured paper

Algorithm Verification with FPGAs and ASICs

Sponsored by MathWorks

Developing new FPGA and ASIC designs involves implementing new algorithms, which presents challenges for verification for algorithm developers, hardware designers, and verification engineers. This eBook explores different aspects of hardware design verification and how you can use MATLAB and Simulink to reduce development effort and improve the quality of end products.

Click here to read more

featured chalk talk

Current Sense Resistor - WFC & WFCP Series

Sponsored by Mouser Electronics and Vishay

If you are working on a telecom, consumer or industrial design, current sense resistors can give you a great way to detect and convert current to voltage. In this episode of Chalk Talk, Amelia Dalton chats with Clinton Stiffler from Vishay about the what, where and how of Vishay’s WFC and WFCP current sense resistors. They investigate how these current sense resistors are constructed, how the flip-chip design of these current sense resistors reduces TCR compared to other chip resistors, and how you can get started using a Vishay current sense resistor in your next design.

Click here for more information about Vishay / Dale WFC/WFCP Metal Foil Current Sense Resistors