The Importance of Authentication

Remote authentication is one of the most crucial and omnipresent aspects of security in the embedded world. Without well-managed authentication, no one would know which device they’re talking to: does your smart bird need refilling, or are you being deceived by some particularly web-savvy wildlife? Digital signatures represent a cryptographic method for managing authentication. Each device has a unique identity that, when prompted, the device can attest to securely by producing a signature that proves that it “owns” the identity. Whilst this is a powerful technique, it is not the end of the story. After all, how do you know which identities you can trust? If a device can prove to you that it is “Tom’s SmartWatch”, you probably want to be sure that you are the right Tom. This is where the idea of a Root-of-Trust comes into play; somewhere along the line, someone needs to have provided the device with some initial piece of information verifying where exactly it came from. Naturally, this problem cuts both ways, as the device needs some way of knowing that you are also the right Tom. In this blog, I will explain a handful of methods for establishing a Root-of-Trust between devices and servers, and how a little effort at the provisioning stage makes for easily secured connections down the line.

What is an authenticated connection?

Before we get to device provisioning, let’s take a quick step back and look at how clients and servers establish secure, authenticated, connections. Typically, this is done using a cryptographic handshake such as the TLS 1.3 handshake, more-or-less the gold standard of secure connections. The TLS handshake ensures that a connection is encrypted so that onlookers can not intercept any traffic, and authenticated so that the communicating parties can be sure who they are speaking to. The TLS and other cryptographic handshakes expend a good deal of effort supporting encryption, but we can understand the authentication process as follows:

1.  The client initiates a connection to a server.
2.  The server presents its identity to the client and cryptographically verifies ownership of this identity. The client confirms that this identity is one it trusts.
3.  The client returns its identity and own cryptographic verification to the server. The server confirms that it trusts this identity as well.
4.  A secure channel is established and the parties are ready to communicate safely.

Building trust

Since digital signatures easily handle the verification of identities, the magic in steps 2 and 3 is contained in the trust in identity. When someone presents an identity to you, you need to have some method of confirming that the identity itself is legitimate, not just that they own it. Consider an analogy to the real world, when someone presents a passport to prove their identity: the fact that they resemble the passport photos confirms they are the holder of the passport, and we trust the passport issuer checked their identity properly. In TLS connections over the internet, this is usually done using certificates and certificate authorities. A certificate authority (CA) is an entity whose job is to confirm people’s identities and give them a certificate stating that the CA has verified their identity. Now, to present its identity in step 2, the server shows the client its certificate from the CA. Since the client trusts the CA has done its job, the CA signature on the certificate lets the client know that the identity of this server is valid; once the server verifies ownership of the identity using its signature, the client has full trust in the server. Similarly, the client has a certificate from a CA which the server can validate. Of course, this process relies on a CA who is diligently confirming everyone’s identities, which is deemed as an acceptable price to pay to secure connections over the internet.

The importance of authentication for IoT

Whilst the TLS protocol and Certificate Authorities are well-suited to the needs of the internet, the IoT space requires some extra time setup. To request a certificate from a CA, one needs to be able to connect to the authority in the first place – and many embedded devices won’t be able to successfully navigate the internet to find a CA, either because they lack the resources or because they exist inside a closed network. Instead, we must provide the device with some Root-of-Trust whilst setting up, so that the server knows its identity is legitimate. Conversely, the device needs to be given some information about the identity of the server it is connecting to, otherwise, a rogue party may be able to masquerade as the server and hijack the devices communications.

So the question is, what sort of material can we provide the device and server to establish trust in each other’s identities?  For server verification, there is a relatively simple answer: at some point in time, the device must be programmed with the owner’s, also referred to as the Original Equipment Manufacturer (OEM), firmware. Inside this firmware, the OEM typically includes the endpoint the device is going to connect to – as part of this firmware package, it is easy to include a public certificate for either the server itself or an appropriate CA, with the device programmed to trust this certificate. When the server presents its identity, the device’s code tells the device that it knows that this identity can be trusted, and server authentication is complete once it proves ownership of the identity.

On the device side, things get a little more complicated. Essentially, the server needs to be pre-loaded with some way of confirming the identities of the devices it owns. Depending on the capabilities and conveniences of the OEM, there are several valid techniques for this, but we can lump them into two categories: either a) extract some material from each device or b) inject some material into each device. Either way, this needs to happen at some point during device provisioning – such as during the manufacture of the device or as part of its firmware installation. If a device is deployed in the field without some effort made to register its identity, it will not be possible to properly establish trust in its identity – and there’s no use cryptographically verifying that you own an identity that no one knows anything about!

If extracting and storing a list of device identities is impractical, instead devices can be injected with appropriate authentication material. A typical solution for this is to have a Certificate Authority installed in the manufacturing stage. As part of the manufacturing process for each device, the device defines its identity and securely requests a certificate for it, for which the CA provides it with a signed certificate. This CA is also registered with the server, which checks the validity of the device certificate during step 3 of the authentication process against this authority. Again, this leads to a smooth authentication protocol, reminiscent of authentication in a TLS handshake. The issue here is typically one of fragmentation of the IoT industry: the manufacture of devices is often performed by a specialist silicon vendor, distinct from the OEM who is licensing the devices themselves. For example, an OEM that manufactures smart cars will outsource the production of microchips, as their manufacturing premises are more geared towards assembling vehicles rather than layering silicon. So, the OEM needs to trust that the silicon vendor isn’t misusing the on-production CA, either maliciously or accidentally, since any device with a certificate from this CA could onboard at the OEM’s server. That is, the certificate issued by the CA just tells the server that the silicon vendor built the device and checked its keys. It does not tell the server who purchased the device, or who it was built for. For ideal security, the silicon vendor needs an on-production CA per OEM it builds devices for, which will most likely drive up the price tag; OEMs unwilling to pay this could settle for a generic on-production CA, but they must take on the corresponding risks.

So what happens if both options are unavailable? Let’s say an OEM has got a batch of devices whose identities they can’t extract and they can’t issue certificates for these devices during manufacture. At some stage, the devices must be programmed with their operational firmware. Here, at least, is the option to inject some secret material: a secret authentication password embedded in the device as part of its firmware could be used to supplement authentication in step 3. However, many risks require careful management here. Since the firmware package is generally the same for each device, the device has no unique identity or password to attest to. Thus, if the firmware is leaked, anyone can enrol arbitrary devices at the server, as the same password is valid for all devices! One can add some extra controls here, such as restricting each password to be used by only a thousand devices or to be valid for a set period, but it is hard to be confident that this will prevent a determined attacker. Additionally, if the OEM is outsourcing device programming to a third party, the OEM must trust this party with its secret material or install the firmware without inspecting it using some cryptographic techniques. For some OEMs, this solution is acceptable: sometimes, firmware is closely guarded Intellectual Property, and thus unlikely to be leaked as it is adequately protected. Alternatively, other OEMs may be less security conscious, with the relative cheapness of this solution matching up well with the level of security they require. However, it is by far the riskiest of the presented scenarios.

There is of course a final, manual option – an engineer can be physically present to facilitate onboarding of the device. However, this is estimated to take around 20 minutes of engineer time per device, not exactly a cheap option for deploying devices at scale! This exhibits the benefits of baking in your security management during provisioning, as otherwise, you have to put in a good deal of manual security work.

Conclusion

The IoT industry supports a wide variety of different OEMs, each with its capabilities, security awareness, and threat models. As a consequence, there is no one size fits all model to devise provisioning. Some OEMs will be doing parts of the provisioning process in-house and will find it easy to either inject or extract material themselves. Others will not have their means but will be security conscious enough that they are willing to pay someone else to carefully provision their devices. Either way, being willing to make some effort during provisioning goes a long way: otherwise, OEMs will be forced to try for a riskier solution like the passwords suggested above. Sure, it does not require much effort to set up, but in practice, the security risks and careful management of firmware secrecy will likely cause much more effort than they prevented! The importance of authentication can not be underestimated.