Internet of things Security

Network and IoT security in a zero-trust security model

Network and IoT security in a zero-trust security model
Written by ga_dahmani
Network and IoT security in a zero-trust security model

You can never be too careful when it comes to network and IoT security. With an increasing number of disparate devices connecting to corporate and industrial infrastructures, better safe than sorry.

IoT network security

For network administrators, it’s no longer just about protecting laptops and PCs, but about managing a network made up of a colorful palette of connected hardware, including low-cost and mobile IoT devices. But how can you keep your network secure when each device is governed by its own rules? The answer is (relatively) simple: TRUST NO ONE!

This is where the concept of a “zero trust architecture” comes in, which is a security concept based on not trusting a device by default simply because it is part of your network. Instead, each device needs to authenticate itself for each connection it wants to establish. Since any possible connection involves at least two parties, the authentication required here is called mutual authentication.

There are different communication protocols that make use of mutual authentication, such as SSH Y TLS. But what these protocols have in common is that authentication is based on unique device certificates. Without such a certificate, a device cannot authenticate itself.

How does a device obtain a certificate?

It all starts with the device having its own unique public-private key pair. To generate a certificate, the first step is to share the public key of this pair with a Certificate Authority (CA). The CA will verify that the public key belongs to this device by sending it a challenge. Only the device that possesses the corresponding private key will be able to successfully respond to this challenge. The CA now knows that the public key belongs to the device and will create a certificate for it.

Once created, the certificate can be sent to the device, which can now use it in future authentication protocols on networks that consider the specific CA that created the certificate to be a trusted source. This is something that makes the term “zero trust” a bit misleading. Even when you don’t trust the devices, there is something you have to trust. In this case, trust is based on the certificates and the authority that grants them.

But there is another aspect that is important to take into account: the private key. The private key is the foundation on which all security is built. It is what binds the certificate to the device because anyone who wants to check the authenticity of the certificate can do so by questioning the private key. And because this private key is so important, it should always be stored securely within the device.

An attacker should never be able to read, alter, or copy this private key, as this compromises the security of the entire network to which the device is connected. Keeping the private key private should be the top priority of any device. And the network needs to trust (that word again…) the device in order to do so.

How is the private key securely stored on the device?

There are a few ways to do this, starting with the traditional use of secure hardware, such as a secure element or a Trusted Platform Module. Both are secure chips that need to be added to the device and are responsible for securely creating and storing keys. This is an acceptable solution for expensive devices like phones and laptops, but it usually doesn’t solve all security problems, as limited parties have access to it. However, for low-cost IoT devices, adding a secure chip to the BOM adds too much cost.

A more affordable solution is to store the key pair in the memory of one of the chips that the device already needs, such as a microcontroller. In this case, the key pair can be externally provisioned during manufacturing or generated internally (if the chip has an internal random number generator). The main disadvantage of this option is that the chips for IoT devices are not designed to securely store keys. This means that there is a serious risk that the private key could be compromised by a determined attacker with access to the device. In addition to this, when keys are injected from the outside, the party injecting those keys is another entity that must be trusted to keep the secrets secret.

There is another alternative to these traditional methods of generating and storing secret keys, and it is based on Unclonable Physical Functions (PUF).

PUFs use deep submicron variations in the chip manufacturing process to create unique device identifiers. This means that PUFs can generate cryptographic keys (like the key pair we require) from the silicon of the chips. These keys are unique to each chip and never have to be stored in memory; they are simply (re)generated whenever they are needed. This eliminates the need to provision keys externally, as well as the use of dedicated hardware to protect stored keys.

This is why PUF implementation is rapidly gaining traction, especially for low-cost IoT devices. Using PUFs to create and protect the keys needed to generate device certificates provides the kind of trust that a zero-trust architecture requires.


Now that we’ve seen all the different building blocks that are required to securely connect devices on a network, we can take a step back and see what we’ve learned.

It all starts at the device level, where the foundation for a zero-trust architecture is established by choosing the right way to provision the device with the keys that are the basis of its unique certificate. The method of choice will vary depending on the hardware of individual devices.

Different approaches provide different levels of security, but one thing they all have in common is that they need to instill the right level of trust that they will keep the private key private. When a device is equipped with a pair of public and private keys, a CA can provide the next piece of the puzzle by generating a certificate for the device. Once a device has this unique certificate, it is ready for the mutual authentication required to securely enter a network built on a zero-trust architecture.

Combining the security provided by the way cryptographic keys are stored with the trust that must be placed in the CA, it is safe to say that, at least in this case, there is no “zero trust” without trust.

About the author


Leave a Comment