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.

handshakeYou’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

image17Data 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.

keysizesThings 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.

10 thoughts on “Chris Conlon: Device Security 101

  1. Design guideline paradoxes form with low-end products.

    *Optimize cost, battery life, and cpu resource use…
    but also require performance sapping cryptography.

    *Make the connection secure, secret, and robust…
    but federal legal requirements have already compromised the certificate systems.
    SSL as a truly secret end-to-end network protocol is gone, but it is still secure if configured correctly.
    Note certificate spoofing is common on corporate network IDS systems to MiM SSL, so it can’t be considered secure due to user behaviour.

    *Maybe trust some hardware features to handle the cryptography…
    Even most of Intel doesn’t know what the management silicon does on their own chip…

    *Maybe add a new layer of bureaucracy to make people feel safer…
    Every time the DHS grabs my balls at the airport… I’m reminded of how “important” people stand in a different line than regular people.

    “Madness is rare in individuals – but in groups, parties, nations and ages it is the rule.” (Nietzsche)

    1. I don’t trust whatever government agencies are watching my data to have my best interests at heart, but I do trust them not to explode my washing machine by disabling load stabilisation, simply because I can’t imagine what they would have to gain by doing so. There are a subset of things which it makes sense to secure against individuals or groups, but not against nations.

  2. One aspect is that humans usually are the weakest link. Example: someone may try to guess the wifi password written on the poster and the unlock code for that guy’s phone (1:39)

    ESSID: Dlab?
    pass: endm04? endmill?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s