Why Blockchain May Not Reach Beyond the IP Gateway in IoT Security
Is it time to walk away from the centralized architecture we’ve used for more than two decades?
By Guillaume Crinon, Global IoT Strategy Manager, Avnet
Editor’s note: This article originally appeared in Embedded Systems Engineering.
Blockchain is a technology initially deployed at the heart of crypto-currency systems such as Bitcoin or Ethereum where the basic idea is to get rid of centralized banking systems ruling monetary transactions. Instead, every transaction is signed by its emitter (private key) and broadcast to everyone along with the corresponding public key. Then, everyone is able to check the validity of the transaction, going back in history to check that the spender has the money, and registers it in the form of a “block” mathematically “chained” to the previous block into a shared and massively duplicated public ledger keeping track of all transactions to date. A public set of rules ensures that duplicated ledgers are consistent with one another. Public cryptography tools make sure that no one can corrupt past transactions in ledgers. Distributed among participants mostly playing by the same official public rules, trust is decentralized, no longer concentrated among a few banks.
To incentivize participants faced with the tedious job of checking others’ transactions and contributing to the ledger, crypto currencies have also engineered rewarding mechanisms yielding a very controlled monetary creation, often referred to as “mining.”
IoT Security Basics
Securing communication between two devices within a network relies on three ideas:
- Mutual authentication: each device should be able to prove its true identity to the other.
- Message integrity: each message sent to the other side should be signed in a way that prevents any interferer from secretly changing its content.
- Message confidentiality: optionally each message may be encrypted so that only the authorized parties understand the content.
Figure 1: The Diffie-Hellman key contract established in 1975 is the most important use of asymmetric cryptography.
A very efficient way to implement these concepts in the real world of low-power battery-operated sensors and gateways is to rely on symmetric cryptography, which uses the same key on both sides to encrypt/sign and decrypt/verify. For example, mutual authentication and message integrity are commonly achieved by appending each message sent with a 32-byte hash code (SHA256 function for instance) taking as inputs: the message to be sent; a means to defeat replay-attacks by a third party; and a pre-shared 128/256-bit key. Message confidentiality is usually implemented with an AES cypher taking as inputs: the message to be sent and a pre-shared 128/256-bit key.
Whereas these implementations are widely deployed in most communication protocols such as Bluetooth, 802.15.4, 802.11, etc., only the IP-compliant ones can take advantage of an efficient symmetric key distribution scheme called Transport Layer Security, or TLS, formerly SSL. The other implementations rely on more or less manual pairing, factory pre-setting of keys, or even distribution of keys in the clear!
Figure 2: Exchanging public keys to compute the same AES/SHA key on both sides
Efficient and Secure
It turns out that the mechanisms at work within TLS can be easily ported over non-IP communication protocols yielding efficient and secure systems all the same.
Figure 3: End-to-end device-to-server security
In short, TLS relies on asymmetric cryptography and a transaction invented by Diffie and Hellman in 1975, allowing TLS to compute the same shared secret between two entities, which are exchanging only public information. Asymmetric cryptography works with mathematically-correlated key pairs: One key is defined as private and should neither be shared nor exposed, while its counterpart is public and can be distributed to peers. When one is used to encrypt/sign, only the other one can decrypt/verify.
Applying the Diffie-Hellman key contract to any communication session solves the problem of securely distributing and renewing symmetric keys in the field, which is also how TLS over HTTP (making it HTTPS) works.
Certificates and Trusted Third Parties: A Centralized Model
Swapping public keys between devices, machines or servers allows opening a secure channel end-to-end between them and implementing state-of-the-art mutual authentication, integrity and confidentiality. However, as Figures 3 and 4 show, the robot and the server willing to open an end-to-end secure channel are often distant and their communication has to go through many intermediaries and networking layers, such as a Local Area Network (LAN) gateway bridging to a Wide Area Network (WAN), and several telecom operators.
Simply swapping public keys between robot and server requires trusting that all the intermediaries will pass the public key to the next level. However, they could also keep it for themselves and pass on their own, breaking the end-to-end tunnel into two tunnels and eavesdropping and stepping into the conversation unnoticed, thus successfully performing a well-known “man-in-the-middle” attack.
In order to solve this famous problem, the Internet has been relying on certificates delivered by a certification authority. Certification authorities are entities trusted by everyone whose role is to bind a public key to its owner’s identity into a document they sign in turn: the certificate.
Anyone willing to share a public key will therefore have it converted into a certificate first. The other party receiving the certificate will then trust that the public key belongs to the sender because the certification authority guarantees the bond between the public key and the sender’s identity.
We now have a full solution working and relying on a centralized trust architecture built around a few certification authorities able to bind in a well-protected database the unique identity of objects and their public keys.
As long as everyone trusts these certification authorities and their capability to keep their databases highly secured, the architecture holds perfectly well.
Figure 4: Man-in-the-middle attack
Blockchain: The Promise of Decentralization
But the word is out that blockchain will disrupt this scheme very soon, allowing peer-to-peer secure communication between sensors and devices not needing Certification authorities anymore.
How trust could be decentralized with a blockchain architecture raises many questions:
- Should all the sensors, devices, machines, servers able to communicate globally or within an application or a vertical participate?
- If the idea is to get rid of certification authorities, would it mean that every device could sign certificates for others or that certificates themselves would not be needed anymore?
- Distributing the trust would also imply distributing a trust database in the form of a ledger. What should it contain? Bonds between IDs and public keys or more?
- Would every participating device be required to check the ID of others transacting messages and registering them into a shared ledger?
- How would the devices described in point 4 be incentivized?
- By which mechanism would they be capable of synchronizing their copy of the public ledger with peers so as to maintain a consistent ledger overall?
- How would they efficiently store a valid copy of the duplicated ledger locally?
With a current average of 250k monetary transactions every day, the Bitcoin ledger has grown to 130GB since inception in 2009 and is expected to carry on growing at a rate greater than 50GB per year.
The process of “mining” new blocks, once affordable by a personal computer, has become so demanding in computational resources and energy because of the monetary creation regulation mechanism that only a small number of computer pools (less than 10 in the world, mostly in China) now own 50% of the capacity, hence the trust of the Bitcoin currency.
As a reminder, IoT hardware can be classified into two categories:
- Mains-powered: servers, gateways, high-end sensors and actuators in addition to rechargeable devices to some extent
- Battery-powered: low-cost sensors, actuators, tiny gateways and rechargeable devices
Anything battery-powered and low-cost will certainly not have the processing capability nor the energy to participate actively in a public or private blockchain infrastructure as previously described. So much for secure peer-to-peer communications between battery-powered devices.
As a consequence, a blockchain architecture for trust and security is likely to stop at the network edge, no further than the gateway, provided that the gateway has processing power, network bandwidth and a sufficiently large amount of memory to participate in the community job.
The cost of trust
A distributed trust architecture will not come at no cost. Some mechanism and business-model will be needed to finance the extra hardware, the extra cellular bandwidth, the extra energy and earlier wearing-out of those devices and machines which will support the computing and storage of trust processing.
Looking at the industry, I am not sure we are ready yet to discard the centralized trust architecture the world has been relying on since the Internet went live more than 20 years ago. More probably, trust entities will structure themselves with a blockchain architecture and offer compelling business models for their customers to collaborate in the overall maintenance and redundancy of their trust business.
Further, Industrial IoT or Industrial 4.0 use certification authorities will be massively vertical and self-contained to start with, more like Intranet of Things deployments. Therefore, it’s possible that major players that everyone trusts will offer centralized trust architectures and business models 10 years from now.
The future will tell.
