On the scale of “none at all” to “X.509 certificates“, there is a wide range of security implementations possible. In this article, we discuss how a Pre-Shared Key (PSK) scheme is “secure enough” to get your prototype off the ground and why your first prototype on Golioth will be “secure by default”.

This article isn’t about production-level security

Getting devices connected to the internet is non-trivial. Security protocols and methods exist to keep unwanted devices off of networks, and put processes in place that require devices to verify that they are allowed onto a network. In bootstrapping a device to securely connect to the internet, many people choose plaintext connections instead of taking the time and headache of utilizing good security practices.

At the other end of the spectrum, we have strict security practices and the engineers charged with maintaining networks. Devices that seek to join those networks must implement the layers of encryption required to certify that a device is on a network. Security professionals stake their careers on solid methods and highly complex processes.

We are taking a middle ground.

Enter: the password

First, let’s define what a Pre-Shared Key (PSK) system looks like. With PSK, your device and your backend will share the same secret. If you ever used passwords, you are likely familiar with the concept. You can think of PSK as passwords not for human users, but for devices. Imagine you are a user of a service, to which you log in with a password and a username. When you signed up for your account, you told the service (pre-shared) the username and password you want to use for future log-ins. PSK is essentially the same if you substitute a user for a device. Each device is assigned (pre-shared) a key (“password”) and a PSK-ID (“username”) by the backend, which it then can use to authenticate itself to the backend.

What about the security of PSK usage at scale? To draw a security analogy, let’s start with considering how WiFi PSK works, and how much you trust it. In a PSK WiFi network, you configure a “password” on the WiFi access point, and then give the same password to anyone who you want to let connect to that network. Most home WiFi networks use PSK authentication, even though you might not call it PSK, but a “WiFi password”. Many corporate visitor networks work the same. TLS PSK in IoT is more robust. For authorization purposes, giving the same password (“PSK key”) wouldn’t help much. It would merely tell the device is authorized to use the service, but it would not prove anything about its identity. That’s why when using TLS PSK in IoT, you shouldn’t give the same password to multiple devices. Every device should have its own “password” (and “username” – a PSK identity).

By assigning a unique PSK to each device, compromising the password of one device will not compromise other devices. In this aspect, TLS PSK is more secure than your average WiFi connection. In many smart home deployments, the same WiFi password is shared by all devices, mostly because of its convenience. However, that also means that if any of those devices get compromised, your WiFi network is no longer secure. Anyone with that WiFi password can connect new devices to it.

PSK is good enough for prototypes

PSK has its use case, and it’s convenience motivated. You likely don’t want to be bothered with procuring a Hardware Security Module (HSM) and setting up a secure process to generate and distribute certificates. You likely need to get some level of security as quickly as possible. That’s the “good enough”. Certificates are going to give you great security, but are going to make everything way more complex. This is where PSK is a great candidate.

Adding a layer: PSK key rotation

To make it more difficult for a potential attacker to compromise your device, it is worth changing (rotating) your device’s keys once in a while. The process doesn’t have to be complicated, but it could be if you don’t design for it.

Start by building your device with two sets of keys. One main key (that is actively being used), and one backup key (only used under special conditions). That way, if you need to update your key, you can keep your existing main key in place and only update the backup key. After the update, if you have experienced a successful authentication for that device, all you need to do is swap the roles of the keys, and you’re good to go. On an unsuccessful start, just keep things as they are and try the key update process again.

When you head towards production

So if PSK is so great, why don’t we just drop certificates and use PSK instead? From the single-device perspective, it might seem like a good idea. But once you start thinking about hundreds, thousands, or millions of devices, things become more complicated and more expensive.

If you are preparing to manufacture millions of devices securely, you are likely considering many aspects of not only technical / hardware / software security, but also physical security of your operations. Who can build authentic devices for me? Who do I trust to build authentic devices?

With PSK, the naive approach could be just setting up a manufacturing station that generates random keys and upon producing a device with a specific key, it also registers the key “in the cloud”. This will make your production depend on internet availability, and availability of the servers that register the keys. Outage of any of these will bring your production to halt.

You might work around this problem by having a local database of keys on the manufacturing station, but that leaves you with a synchronization challenge, and you’d have to rely on a local storage of the manufacturing station to persist the information. Going down this path, it’s likely you’ll find more new problems than solutions.

Ultimately, PSK is not a great solution for manufacturing at scale. It might work well for small batches in your PoC, but make sure to consider how it will impact your product at scale.

“Secure by default” with Golioth

At Golioth, we want to make sure your devices can seamlessly go through all phases of an IoT project – from a concept, through a prototype, to production at scale. We want to set you and your project up for success from day one.

That’s why we decided to make TLS PSK authentication required for all devices connecting to Golioth. Using PSK during development requires very little overhead, and meets convenience requirements for fast iteration, fast onboarding, and simple debugging. Your prototype will have security that is based on battle-proven Internet standards and meets compliance and certification requirements of most IoT use-cases. You can assign multiple keys to any one device to try out PSK key rotation. Your team and end customers won’t need to worry about the prototype being safe. It will also pave the way for easy migration to more advanced security once you are ready to produce devices at scale.

Check out the video below to see PSK assignment in action and to hear more about PSK use at Golioth.