IoT Encryption: The challenge of missing entropy

One of the least-resolved problems with the Internet of Things is around setting up the ‘thing’ in the first place.

It arrives in the consumers hands, unconfigured. Most consumer-y things need to connect to Wi-Fi, Bluetooth, to a mobile app or to a web service.

Those connections are hopefully encrypted: WPA, SSL / TLS etc.

But there’s no random number generator

In order to set up those connections, there will doubtless be a service offered where the keys can be entered. It may be a web server running on the ‘thing’ where one enters a Wi-Fi PSK, or a different exchange between mobile and device, perhaps over Bluetooth. That connection will be insecure. Try doing SSL when you have no effective random number generator on the ‘thing’…

We have tested numerous devices that exhibit serious security flaws in unconfigured mode, or that can be exploited during the configuration process. It’s all very well doing encryption once configured, but it’s not much use if the keys can be compromised during configuration.

Entropy can be created by loading per-device key material or unique seeds to random number generators. This can be done at the factory, but it can be VERY expensive to do so. Per-device firmware can add a significant marginal cost per device, particularly for lower cost consumer things.

Many are tempted to generate keys on the device without sufficient entropy, relying on local algorithms, partly because it’s a cheap way of doing it. These are very vulnerable to reverse engineering attacks. We’re currently looking at the Anki Cozmo smart toy; this has a per-device Wi-Fi PSK. It appears to be random, though we’ll need to dismantle this $150 toy to prove or disprove this. Maybe after Xmas!

Private keys can be loaded onto the device in the factory. This either requires per-device firmware, or powering up the device in a commissioning mode. Both of these will add significant complexity and cost to the device, which can have a big impact on the already thin margins in low cost IoT devices.

There is also the chance that someone can obtain the keys from the device before it ends up in your hands. Sounds ridiculous, but supply chain issues and tampering are starting to become a big worry for many manufacturers.

Entropy can be generated on the device. However, the standard sources for entropy in a Linux system rely on differences in the device (e.g. MAC address), input timings from the keyboard (no keyboard!), disk seek times (often no disks!), and interrupt timing. IoT devices using a standard Linux build do not have an adequate source of entropy.

Userspace solutions such as HAVEGED exist, relying on precise timing variations on the CPU. However, even then implementation specifics can mean the difference between secure and insecure random number generations. These are the Debian specific notes: http://bazaar.launchpad.net/~ubuntu-branches/debian/experimental/haveged/experimental/revision/12?start_revid=12#debian/README.Debian.

Entropy can be generated by dedicated hardware random number generators. A number of microprocessors already offer this functionality, using tiny inconsistencies at the chip level and environmental influences such as temperature and electrical noise to generate entropy. Again, this adds cost and complexity – as well as the developers knowing the hardware exists!

 Even with hardware in place, attacks have been developed to bias the random numbers generated e.g. this frequency injection attack: https://www.cl.cam.ac.uk/~atm26/papers/markettos-ches2009-inject-trng.pdf.

Another route to resolve the problem is to download keys to the device when the user configures it for the first time. It is critical therefore that the provisioning process is secure and resistant to man in the middle or related attacks that could be used to compromise those keys in transit:

A direct connection between the IoT device and users phone is a good mechanism to transmit keys. The integrity of the connection from mobile app to web service can be broadly assured (cert pinning etc) to download keys from the service. However, without entropy sources on the ‘thing’, the connection from phone to ‘thing’ is very vulnerable to interception. Having a physical method to put the thing in to a pairing or setup mode would be wise. The problem here is that someone in RF range could intercept the key material in transit. Hence, proving physical proximity of the phone to the ‘thing’ whilst a physical interaction takes place (a button?) would be ideal.

Having a physical UI on the ‘thing’ would be ideal, ready for the user to enter a PIN or key of sufficient complexity to protect a provisioning process. However, a physical UI is a costly overhead.

We’re also looking at the new BB-8 robot toy complete with ‘Force Band’ – this is a wrist-worn device with an accelerometer that allows one to control the droid with hand gestures. Very cool!

However, the connection is over BLE. There is no UI on the droid, so pairing has to be initiated on the band, requiring it to be brought very close to the droid. This is achieved through dropping the BLE RF signal strength when in pairing mode, so the band can be certain that the droid is pairing with it and only it.

Here’s the problem – it’s possible to amplify RF, so we’re working on attaching a high gain antenna to the Bluetooth aerial in the band (in red below)  to see if we can takeover BB-8 from a distance and turn him to the Dark Side once again.

Get this process right and you’ll have a secure device that reinforces and protects your reputation. Get it wrong and you could have a nasty customer data breach, or perhaps worse.