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 a rapidly growing number of disparate devices being connected to corporate and industrial infrastructures, it’s better to be safe than sorry.

For network administrators it is no longer only about protecting laptops and PCs, but rather about managing a network comprised of a colorful palette of connected hardware including mobile and low-cost IoT devices. But how can you possibly keep your network secure when every device plays 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, every device needs to authenticate itself for every connection it wants to establish. Given that any possible connection involves at least two parties, the authentication that is required here is called mutual authentication.

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

How does a device get a certificate?

It all starts with the device having its own unique public-private keypair. To generate a certificate, the first step is sharing the public key from 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. Now the CA knows that the public key belongs to the device, and it will create a certificate for it.

Once created, the certificate can be sent to the device, which is now able to use it in future authentication protocols on networks that consider the specific CA that has created the certificate 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 that you need to trust. In this case, the trust is based on the certificates and on the authority that provides them.

But there is another aspect that is important to consider: the private key. The private key is the foundation on which all the security is built. It’s what ties the certificate to the device because anyone who wants to check the authenticity of the certificate can do this by challenging the private key. And because this private key is so important, it should always be stored securely inside the device.

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

How is the private key stored securely on the device?

There are a few ways to do this, starting with the traditional use of secure hardware, like a Secure Element or a Trusted Platform Module. These are both secure chips that need to be added to the device and that take care of creating and securely storing keys. This is an acceptable solution for expensive devices such as phones and laptops but does not usually solve all security issues since limited parties have access to it. However, for low-cost IoT devices adding a secure chip to the bill of materials adds too much cost.

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

There is yet another an alternative to these traditional methods for generating and storing secret keys, and it’s based on physical unclonable functions (PUFs).

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

This is why the deployment of PUFs is gaining traction rapidly, 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.

Conclusion

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

It all starts on the device level, where the foundation of a zero-trust architecture is established by selecting the right way to provision the device with the keys that are the basis for 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 that they all have in common is that they need to instill the appropriate level of trust that they will keep the private key private. When a device is equipped with a public-private key pair, 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 that is required to be allowed entrance in a secure way to a network built on a zero-trust architecture.

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