Identity in IoT

NOTE: This was originally posted on 19 Jun 2020 but I decided that a rewrite was in order, for clarity and better flow.

Identity is important in the Internet of Things

Device identity is one of the most important security challenges in IoT. If you get identity management wrong, you run a significant risk of anyone being able to access all of your devices.

Getting it right can marginally increase production cost of a device, but a weak approach to identity can trash your brand if consumers lose faith in your ability to do it securely.

Getting it wrong; an example

Several years ago, we reverse engineered the Tesla Model S. This used a VPN to connect back to the Tesla mothership (yes, that is what they call it).

Each car was issued a unique VPN key and certificate. Each VPN certificate was identified by the cars VIN – Vehicle Identification Number. It wasn’t possible to connect to the VPN as another vehicle as we didn’t have the key or certificate.

Once connected to the VPN, various clients would connect to web servers, sending and receiving data and firmware updates.

The intent was that the requests made by the web client used the same identifier as the VPN.

We quickly found that there was no link between the VPN identity and the one used by the web clients. We could change the VIN for those.

Although the VPN tunnel was established using a unique, cryptographically-assured identity, the web requests were not – they were just using a short alphanumeric string. A short alphanumeric string that is on the dashboard of many vehicles, and not treated as confidential in any way.

Image source: https://commons.wikimedia.org/wiki/File:93_94_HUD_Windshield.JPG

We changed our VIN to another Tesla VIN and could masquerade as another vehicle entirely.

There’s clear issues here: a non-confidential piece of information that can be easily cloned is being used as an identity.

(As an aside, the VPN tunnel has a strong identity, but that didn’t really matter to us – the web servers were unaware of this. When weak identity is wrapped in stronger identity, we call this “authentication decoupling”).

Other bad approaches to identity

Quite often a device will identify itself using a MAC address. It’s unique to the device. Hence it’s common that a device connecting over Wi-Fi or Bluetooth will use its MAC address to identify itself to a cloud platform.

Why? Because it’s cheap to do it this way. There’s already a unique piece of information on the device – no need to generate one in the factory. IoT developers are looking for something unique to the device to identify it from other devices. They don’t consider that there’s no means to check if the identity is authentic.

Identifying by MAC

In this example, the device makes a request along with its ID 15-6e-f3-79-a0-12, and says “Hi, I’m device 15-6e-f3-79-a0-12”, and the platform will say “Yeah, Hi, cool it’s you”.

The problem is that as an attacker we can just clone that identity. The MAC address is often just broadcast on the local network or printed on the device itself.

What if we don’t have access to the device or local network? Can we find valid identifiers by brute force?

A MAC is 6 octets, or 2^48. That’s a lot of permutations, surely? Well, it would be if we were using all 48 bits.

As you’ll know, the first three bytes of a MAC address are called the OUI. Organisationally Unique Identifier. This means that we already lost three bytes of randomness in that identifier. So it comes down to those last three bytes.

We’ve come down from 2^48, which is a big number, down to 2^24 or ~16.8 million IDs.

What we often find is that it’s only those last two bytes that are used, so now we’re down to 2^16 which is ~65,000 IDs. These are often used sequentially as well.

If I can find a way of working out which of those IDs are valid, we might be able to connect to the platform as those devices and do nefarious things.

Device enumeration

Differences between responses for valid and invalid devices on the platform allow one to determine which MAC addresses exist. For example, if we connect to the platform and say “Hi, I’m device 15-6e-f3-79-a0-12” and the platform replies “Hi device 15-6e-f3-79-a0-12” I know that the device is real.

If I say I’m device 15-6e-f3-79-bd-fa and the service replies “I’ve no idea who you are” then we know the device isn’t real and connected to the platform – an enumeration vulnerability.

This was possible with the Tesla. VINs are mostly known, with a very small part being sequential. We could easily find other valid vehicles on the platform.

Image source: https://en.wikipedia.org/wiki/Vehicle_identification_number

Improving identity

Ideally, we would like a device that doesn’t have an identity based on easily accessed, easily enumerated or easily deduced information such as a sequential serial or MAC. We’re are looking for a cryptographically assured identity. Something strong that we can challenge. We can say to the device “sign this bit of data with your private key, and then I’ll trust you”.

It never transmits that private key, but we’ve got the corresponding public key, so this message can be signed with those private keys and then validated.

It’s no longer possible to clone the identity from publicly visible information – so we’ve solved part of the problem.

Extracting Private Keys

This is where hardware security comes to the fore. The private key needs to be stored securely on the device, or it is exposed to compromise.

Often, the keys are just stored as files on the device. If we get a shell – through serial or network – we can read those keys out.

Sometimes we can’t get a shell, so we’ll fall back to using JTAG or chip-off memory extraction. Here’s an example of connecting using the JTAG port on a PCB:

Despite the identity being cryptographically assured, it can still be cloned with physical access.

How do we solve this? For some devices, this might not be an issue. An IP camera installed inside a house might not need to secure the key and certificate any further. A city-wide smart lighting system might place the nodes in the reach of an attacker.

Secure elements can be used to hold the keys inside a secure black box. This black box can encrypt and sign data with the key, but we can never extract the keys. Cloning identity has now been made very challenging.

We can still remove the secure element from the device and use it elsewhere though.

Key Distribution

How and when do you securely get the key material to your IoT device?

Do you send your keys to the factory in the far east? This increases cost, notably as the device probably has to be powered up on the line to load the keys

How do you assure the integrity of the keys in transit to the factory?

How do you assure the integrity of the keys when loaded to a system on the production line? Many IoT device manufacturers struggle with device security, let alone the security of their own IT systems that will be needed to receive and load keys.

How do you know that your manufacturer actually loads the keys correctly & doesn’t just flash the same key on to every device? We looked at one camera system where poor checks in a provisioning script could result in multiple cameras leaving with the same identity!

How do you know someone hasn’t copied your keys? An insider attack or otherwise?

Other options include having the user configure the device on first use, maybe using a smart phone as the route to deliver a key, but interception or tampering with that configuration process is a real issue.

Conclusion

Without a cryptographically sound source and store of identity, IoT devices are particularly exposed to compromise from their cloud platforms.

It’s often possible to discover other devices and connect to them without further authentication controls.

When that device is a camera, microphone or gathers other sensitive data, user trust in the device is likely to be significantly damaged.