How Bitcoin might help fix the Internet of Things
There’s a flaw in the heart of the Internet of Things (IoT). Not many people are talking about the flaw because we’ve all been struck by how cool it is to put actual live real things on the internet since the first coffee pot was put on the internet in 1993. The IoT is flawed not for technical reasons but because of economics: the incentives for the people who make things and for the people who buy them and put them on the internet are misaligned.
In the last couple of years there have been a sequence of high-profile flaws in fundamental internet software (Heartbleed, POODLE, Shellshock etc.). Pretty much all the IoT stuff we’re currently putting into our homes is riddled with security vulnerabilities. Some of the most sensitive IoT devices — CCTV cameras — contain some of the most shocking vulnerabilities. In the light of this it’s particularly awful to see users advised to access their cameras by putting them directly on the open internet with port forwarding, bypassing NAT and firewall protections. Once hackers can break into a system through an IoT device then it’s possible to do all kinds of things over the internal networks. And these networks don’t even have to be IP-based LANs: simple serial buses can be used to control actuators to move real world objects, like the locks on automobile doors.
The problem with the IoT is that today OEMs make their profits by selling things that customers then connect to the internet. Once the thing is sold most OEMs have little incentive to provide further things free-of-charge to the customer. For small OEMs the effort to maintain existing firmware would be a large part of the development resource. So even when the security vulnerabilities are known, OEMs of IoT devices are commonly slow to provide security patches to firmware (if at all). Worse still, users are slow to apply them (if they even know about them). This is the flaw at the heart of the IoT.
OEMs make things, they don’t run things
Another problem that OEMs face is that they commonly aren’t very good at running services on the internet. Anyone who has tried to download software or find a user guide will know just how few OEMs can run a simple web site. It’s a huge step to go from a web site to an ultra-reliable service provided to millions of IoT devices. And even if they try to do that it’s common to see it done very badly. To be sure, there is always the possibility of outsourcing to a service provider (indeed, I founded a company called LiveDevices in the late ‘90s to provide what we now call cloud services to what we now call IoT things). But this has issues of its own, not least that the service provider themselves are vulnerable to attack (a DDoS attack on GitHub is inconvenient; an attack on a service provider that’s a vital part of heating controls, home security systems, etc. is at a whole different level of inconvenience).
How can Bitcoin help?
Fundamentally the incentives of customers and OEMs must be aligned in order to deal with security. This essentially means that OEMs must get paid to provide new firmware to customers. Right now this is impractical: no-one is going to give a credit card over to an unknown OEM to have small sums billed to it in return for firmware at random times. And no OEM (certainly not a small one) wants the hassle of billing small sums to millions of credit cards and they certainly don’t want to build up the cloud-hosted infrastructure to check the billing and distribute the firmware. But I think this is one thing Bitcoin is almost perfectly designed for.
I wrote back in 2013 about how even machines will be able to use Bitcoin and gave an example of how the blockchain could be used to record entitlements that the machines could respect (I talked about blockchain-based DRM for video players to know what content was bought and who owns what). I think this approach can be used to manage the firmware of an IoT thing.
Buying firmware with Bitcoin
I think there are two goals for firmware management for IoT things:
- Be able to take payments from customers before loading new firmware
- Not to require the OEM to operate any infrastructure (nor to require any specialist IoT service provider to do so either)
The first goal is important. Once there is a revenue from customers to an OEM there is both resource and incentive to keep the firmware of an IoT thing up-to-date (and not just security patches but improvements in functionality). Given the razor-thin margins in some product areas this revenue could actually provide the largest source of profit. In any case, getting direct customer revenue is far better than the customer-damaging practices used by some OEMs today to get revenue to make up for thin margins (from the installation of dangerous crapware on PCs to the insecure capture and of sensitive private data). At least Apple has been training us to get used to paying $1 for a small bit of software that improves our products (even if our value judgements are sometimes a bit skewed).
The second goal above is particularly important. Building reliable internet infrastructure is hard when you’re small (it’s hard enough when you’re big). When I was the CTO of Vidiactive, an internet TV startup, our first set-top box prototype could play videos straight from a web page but had no back-end internet infrastructure. We just gave each box its own email account on a regular IMAP mail server and users simply emailed web links to the email address. The device software just read its e-mail and listed the videos in the UI. We could have hired someone else to run a cloud-hosted service with a database and a web API but the history of the internet is littered with companies that provided services then stopped. Any IoT thing that needs to operate for years must be guaranteed access to a service that has longevity. When even Google will shutter a well-used service with little notice, it’s vital that only services that are highly likely to stick around are relied upon. This is where Bitcoin comes in.
Imagine an IoT thing with a bootloader that had a TCP/IP stack and a Bitcoin SPV (Simple Payment Verification) client. Each device is also given at manufacturing time a Bitcoin address (but it doesn’t have the private key, which is retained by the OEM). The owner of the IoT thing pays bitcoins to that address to cover the cost of firmware. The OEM regularly sweeps up all the bitcoins in its device accounts, sending them to the OEM’s main bank account. The bootloader uses the SPV client to verify when its address last received payment from someone and if it was paid enough sufficiently recently then it will download and install any new OEM firmware. The firmware is digitally-signed by the OEM with a public key so that only legitimate firmware can be installed and because of this the firmware is tamper-proof and doesn’t need to be held on a secure server operated by the OEM: anywhere on the internet will do (such as on Dropbox). The bootloader just needs to know where to look. It’s not a good idea to hardwire a URL for this into the bootloader: cloud-hosted storage services can be here today and gone tomorrow. Instead, the blockchain itself can record where to look for the latest firmware. The blockchain has been used to store all kinds of weird things, from pictures to prayers and even illegal prime numbers. The simplest of these ways to embed a URL in the blockchain is for the OEM to have a known Bitcoin address and to send trivial sums from this to one or more addresses and so encode the URL. The bootloader can use its Bitcoin SPV client to look for the most recent transaction from the OEM to find these addressses and extract the URL.
Once the bootloader has the most recent URL it can download the firmware and then apply it, ready for a reboot. Today firmware updating is frequently implemented so badly that interrupting a device half-way through programming typically ‘bricks’ the device, but it’s possible to do it atomically such that only if the new firmware is properly applied will the device switch over to using it. This is an important property of IoT firmware updates: the user may need to decide precisely when the device can be restarted with new firmware.
The only thing an OEM needs to run the firmware updating scheme outlined here are a bunch of tools and development code:
- Embedded software libraries for the bootloader (containing the SPV etc.)
- A tool to create and sign the firmware with the OEM’s private key and upload the firmware to somewhere on the internet
- A tool to put the location of the firmware into the blockchain
- A tool to create a Bitcoin address for each device and to regularly sweep the money from those addresses into the OEM’s main bank account
Managing the firmware of an IoT thing is only the first step. But it’s a vital step that aligns economic incentives for OEM and customer and ensures that even small OEMs can operate in the market. Once this is in place it’s possible to see how other services (such as blockchain DRM for video content) can use the blockchain as a medium for storage and exchange.
I’m grateful to @polemitis for comments on an earlier draft. If you liked this article then my tip jar is at 1rV3mvdBdRBrAQMasEYti941WuNee5tKN