Chris Conlon: Device Security 101

We all wring our hands over the security (or lack thereof!) of our myriad smart devices. If you haven’t had your home network hacked through your toaster, or baby cam, you’re missing out on the zeitgeist. But it doesn’t have to be this way — smart devices can be designed with security in mind, and [Chris Conlon] came to Pasadena to give us a talk on the basics.

He starts off the talk with three broad conceptual realms of data security: data in transit, data at rest on the device, and the firmware and how it’s updated. A common thread underlying all of this is cryptography, and he devotes the last section of his  talk to getting that right. So if you’d like a whirlwind tour of device security, watch on!

Data in Transit

Your smart device probably uses the Internet for some service or another. Your data, as it moves through the network, is vulnerable. You might want to keep it private and unmodified along the way, and also be sure that it travels to the right destination. Here, you’ve got basically two choices: either implement TLS/SSL at the session layer, or secure your connections deeper down at the network layer with IPSec.

You’ve probably heard of TLS/SSL. It’s what keeps your web surfing safe when you type https:// into your browser. TLS (transport layer security) is actually made up of four components. One takes care of the initial connection — the Handshake — and the client and server agree on what encryption algorithm they’re going to use for the connection. This is the place where authentication happens: your client is sure that the server is who you think it is, and this depends on the X.509 certificate chain. Once the encryption is set up, that keeps your data private and unmodified. This all seems to work nearly effortlessly in the browser on your laptop.

But from an embedded device perspective, TLS is difficult. It involves cryptographic algorithms which can tax your microprocessor’s CPU, demand too much memory, and generally bog your device down. To help, you can choose a crypto algorithm that uses less RAM or ROM, depending on what you’re short of. You can buy devices with built-in hardware crypto peripherals to offload the CPU work. If you’re thinking of running an RTOS, look for TLS support before you get too deeply into your project.

Data at Rest

Data stored on the device itself is also vulnerable. If it has sensitive information on it, it should be at least encrypted, and if it’s possible to not store the information at all, that avoids the problem entirely. Presuming your firmware uses encryption, keeping the encryption keys secret is an important issue. Generating the keys locally on the device prevents them from being snooped in transit. [Chris] additionally suggests not re-using keys for different purposes, and changing them often.

But how does the device store the keys? Ideally your chip has a secure storage element: a TPM or HSM where the keys can be stored. If you don’t have any secure storage, you can always require the user to take some action to decrypt the keys, or zero them out in case tampering is detected.

Firmware Upgrades

If you’ve ever read our coverage of device hacking, you already know that the firmware upgrade procedure is rife with opportunities for mischief. Your device needs to be able to be remotely updated, but it also needs to be able to trust the source of the firmware, it needs to be encrypted in transit, and it needs to be sure that the new firmware arrived intact.

[Chris]’s method leans heavily on public-key encryption to get the job done. As long as the device is TLS-capable, it can use any transport mechanism in the middle. [Chris] suggests that it would be possible to use MQTT, secured by TLS, to handle the distribution of the firmware.

Cryptography

If you’ve been paying attention, you’ve noticed that all of the above relies heavily on keeping things secret, and that means thinking hard about the underlying cryptography. And crypto depends heavily on random numbers, which isn’t very easy on small, deterministic hardware devices.

Things you might think are random, but aren’t, include clocks and serial numbers. What you really want is a true random number generator — something that gets its randomness from the environment. If your device doesn’t have enough entropy coming in, you can seed a pseudorandom number generator periodically with whatever entropy you’ve got, and hope that’s good enough. Many devices these days have hardware random number generators in the silicon, which takes care of that.

Next, you need to make sure that you’re using a long enough key for the encryption, and this depends on both the algorithm you’re using and the actual number of bits in the key. The choice of algorithm is influenced its speed and memory requirements and your microcontroller’s resources. If the chip you’re using has a dedicated SHA-2 hardware peripheral, for instance, you’re probably going to want to use that, and then you can pick the appropriate key length accordingly. Then you know how much entropy you need, and can figure out how to get it.

Summary

[Chris] points out that this talk is a big overview. If you’re actually tasked with designing a secure hardware system, you’re going to need to dig in to each and every one of these points in real detail. Nonetheless, he’s got a summary slide packed with good advice, and it’ll give you a good footing to start your own learning process.

Filed under: cons, Hackaday Columns, security hacks