How to properly authenticate IoT device identity -

How to properly authenticate IoT device identity

How do you establish that an IoT device can be trusted? This article takes a look at the process authenticating the device’s identity.

Hello ­– is that you? Being able to ask this question and trust the answer is vital to establishing meaningful communications, be it between humans or between machines. Humans can check faces, voices, or mannerisms to decide whether people are who they say they are.

Machines, on the other hand, must have unique identities and be able to prove that they own them. There also needs to be a way to check the legitimacy of those identities with an external reference, through a chain of trusting relationships that is anchored in some absolute reality – a so-called root of trust.

I’ll say more on techniques for establishing roots of trust later. First, though, we should set some context by reminding ourselves how standard clients and servers establish secure, authenticated communications channels. Later we’ll look at how things have to be done differently for internet of things (IoT) ecosystems.

Typically, clients and servers establish secure, authenticated communications using a cryptographic handshake, such as the TLS 1.3 protocol. This ensures that a connection is authenticated, so that the communicating parties know who they are speaking to, and encrypted, so that their data is private. The exchange in such protocols goes as follows:

  1. The client makes a connection to a server.
  2. The server presents its identity to the client and cryptographically verifies that it owns the identity. The client confirms that it trusts the server’s identity.
  3. The client sends its own identity and cryptographic verification back to the server. The server confirms that it trusts the client’s identity.
  4. An encrypted channel is established so the client and the server can communicate privately.
Crypto Quantique authentication figure 1 - authentication in TLS handshake
Figure 1: Authentication in TLS handshake.

Building trust

A moment’s reflection points out a key shortcoming of this process as described: steps 2 and 3 have enabled the client and server to establish each other’s unique identity but have not shown that those identities are legitimate. It’s like when a passport is presented: we can see that the traveller looks like the photo, but we have to trust that the passport’s issuer has done a good job of confirming their identity.

In TLS connections over the internet, this identity check is usually handled by a certificate authority (CA), whose role is to confirm a machine’s identity and provide it with a certificate stating that it has done so. In step 2 of the TLS protocol, therefore, the server can show the client its certificate to prove its identity. If the client trusts that the CA has done its job properly, then it will see the CA’s signature on the server’s certificate as validating its identity. Similarly, the client can use a CA certificate to validate its identity with the server. However, the apparent extra layer of security that this CA step provides does rely on the CA having done its job properly in the first place, as well as maintaining its own security for the long term. If the CA itself gets compromised, as has happened, then all bets are off.

Crypto Quantique authentication - figure 2 - requesting certificates from a CAcertificate authority CA
Figure 2: Requesting certificates from a certificate authority (CA).
Crypto Quantique - figure 3 - server authentication using a CA certificate
Figure 3: Server authentication using a CA certificate.

Authentication for the IoT

The TLS protocol and CAs may be less suitable for authenticating the identity of IoT devices. For example, an IoT device may operate on a private network and so be unable to access an internet-based CA. The fix for this is to give each IoT device (and each server in its IoT ecosystem) a unique identity and a way to prove it is legitimate without having to reference an external authority.

For servers, the answer is to program their firmware with an endpoint to which IoT devices will connect and a public certificate for either the server itself or an appropriate CA. The IoT devices are then programmed to trust this server certificate. When the server presents its identity, the IoT device knows to trust it, and only needs the server to prove its ownership of the identity to finalize the authentication. The process for an IoT device is a little more complex and relies on establishing something unique about each device while it is being made or its firmware programmed ­– a process known as provisioning. There are two ways to do this: either extract some material from it or inject some material into it.

Crypto Quantique - figure 4 - IoT devices are programmed to trust the server certificate
Figure 4: IoT devices are programmed to trust the server certificate.

The issues around extracting and injecting identities

If vendors choose to establish unique identities by extracting material from each device, they can then load the server with a database of these identities. This approach simplifies step 3 of the authentication flow. The client IoT device simply sends its identity, and cryptographic verification of that identity, to the server, which confirms the identity is listed in its database and that the verification is correct. The server has then established trust in the device without having to handle certificates.

Although this flow is straightforward, there are challenges to obtaining the list of identities. Each device must have its cryptographically verifiable identity extracted during manufacture, which can be time-consuming and therefore costly. It can be difficult to manage the list of device identities, especially if the IoT ecosystem grows to include millions of devices. And the database needs to be stored and accessed securely, to stop it being edited to include fake device identities.

Nonetheless, if these issues are properly handled, storing a database of valid device identities is a practical solution to device authentication.

The second approach is to inject each device with authentication material. This is often done by installing a CA on a microchip production line. During manufacturing, each microchip defines its own identity and then securely requests a signed certificate for that identity from the production-line CA. This CA is also accessible by the customer’s IoT server, which can then use it to check the validity of a device certificate during step 3 of the authentication process.

The challenge here is trust. The certificate issued by the CA just tells the server that the microchip vendor built the device and checked its keys. It does not tell the server who bought the device. Customers buying devices made this way must trust the silicon vendor to protect its production-line CA from accidental or malicious misuse. Otherwise, it could allow other devices to which it had issued a certificate to be authenticated by the customer’s IoT server.

Ideally, the microchip maker should have a CA on its production line for each of its customers, but this more secure approach may be unacceptable in many IoT end markets on cost grounds.

A third way to establish a root of trust is to inject a secret authentication password into each device when its firmware is programmed, to supplement authentication in step 3.

However, there are risks with this approach.

The devices don’t each get a unique identity or secret because they are being programmed with the same firmware. If the firmware is leaked, all the devices are compromised, and anyone can enrol a device at the server. It’s possible to limit the effect of these issues by, for example, creating batches of 1000 devices with a common password, or to restrict for how long the password is valid. This approach can be helpful but tends to create multiple other issues as passwords proliferate, devices get cut off because their passwords are out of date, and so on.

If the devices are being programmed by a third party, as often happens, the customer must trust this party with its secret material or insist it uses cryptographic techniques to install the firmware without being able to inspect it. Both of these represent further logistical challenges, as well as potentially risking the intellectual property (IP) embedded in the firmware’s code.

The most secure, but costly, approach to establishing a unique identity for each IoT device is to send an engineer to be present while each one is programmed. This is estimated to take around 20 minutes of engineer time per device, which is usually regarded as being impractical at the scale of many IoT ecosystems. It does, however, demonstrate the benefits of anticipating your security management needs during the device design and provisioning planning stages.


Many companies are involved in the IoT, each with different capabilities, security concerns, and attitudes to risk. This means there is no common approach to provisioning devices to join IoT ecosystems. Some companies will handle the provisioning process themselves, making it straightforward to either inject or extract secret material for each device as they see fit. Others will not have the required infrastructure but will be concerned enough about security to pay a third party to provision their devices with great care and due respect for the value of the IP embedded in each device.

Both approaches will benefit from the effort these companies make to increase the security of their IoT ecosystems during device provisioning. Those who choose apparently lower-cost options, such as embedding passwords in firmware, may find that their upfront savings are later swamped by the costs of managing firmware secrecy and coping with possible security breaches.

In the end, effective authentication is vital to the successful implementation of IoT   ecosystems. It’s what allows us to ask “Hello, is that you?” and trust the answer we get.

Charlie Grover - Crypto Quantique

Charlie Grover is a cryptography researcher at Crypto Quantique, where he is driving performance improvements in securely extracting entropy, or randomness, from physical unclonable functions (PUFs) in CMOS semiconductors. His work is contributing to further development of secure root-of-trust technology for microcontrollers and application-specific integrated circuits (ASICs), where identities and cryptographic keys are developed inside these silicon devices on-demand, eliminating the need for key injection, key storage, or third-party involvement. Charlie holds a PhD in electrical and electronic engineering from Imperial College London, where he worked on lattice-based cryptography and other aspects of post-quantum cryptography. Before that, he was awarded a first-class undergraduate and master’s degree in mathematics at the University of Oxford. His research interests are cryptography in a post-quantum world and hardware security IP for semiconductors.

Related Content:

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.