Introduction
Praetorian has conducted hundreds of security assessments on Internet of Things (IoT) systems, and a common shortcoming is improperly authenticating IoT devices to backend servers. In this article, we will review some recurring IoT authentication pitfalls and address ways to fix these problems. We will also discuss ideal authentication solutions and why some companies are hesitant to implement them.
For IoT security, the authentication models depend heavily on the needs of the underlying system. The simplest authentication model involves a single IoT device that authenticates to backend services using a secret value over a secure TLS channel:
Suppose instead that the system has multiple IoT devices that all connect to backend services through a custom gateway. In this model, the needs of the system might be that the gateway is responsible for authentication to backend services:
In the first model, the authentication scheme relies on the strength of the secret value. An example of an insecure secret would be a value that is not unique per device, or a public/guessable value such as the serial number of the device.
In the second model, authentication is more complex. The peripheral devices authenticate to the gateway device, and the gateway device authenticates to the backend servers. The added complexity sometimes leads developers to take shortcuts for the sake of time and resources. One example would be the use of MAC addresses to authenticate a peripheral device to the local gateway. In this scenario, it is usually trivial for an attacker to spoof both a peripheral or gateway device since an attacker can change their MAC address to pass the authentication requirements. We’ll come back to this example later.
The most advanced and ideal IoT authentication scheme is the use of public key infrastructure (PKI). Using PKI, a server can use digital signatures to verify the identity of an IoT device. PKI can also be used to form certificate chains to address the gateway and peripheral device issues. PKI does have drawbacks; however, organizations requiring a high degree of security and cryptographic identity verification stand to benefit greatly from PKI.
Starting from the Basics: Shared Secrets
The goal of authentication is to prove an identity to a person or system, which allows that entity to trust who you say you are. For most web applications, authentication translates to typing in your username and password at a login screen. In IoT security, devices authenticate in a similar fashion but the password is usually just referred to as a secret. The secret is used to prove the identity of the device to a server or another system.
What type of secret should be used? A reasonable choice is to generate a secret token during the manufacturing process. The token would be unique per device, and the manufacturing process would include a step for securely storing the secret both on the device and in a backend key store.
One method Praetorian sometimes encounters is to encrypt a message with a stored symmetric encryption key. In this scenario, the device stores a securely-generated random secret it received during manufacturing. The backend server verifies the authenticity of the device by decrypting the message and checking for a known value. In this scenario, the strength of the authentication scheme depends greatly on how easy it is to gain access to the encryption key. If the encryption key is not unique per device, then any device in the system can be impersonated by reverse engineering a particular device’s firmware. This also applies to secrets derived from the device’s serial number (or an equivalent identifier), since an attacker can replicate the derivation process assuming the serial number is known.
Hardware and Design Improvements
When it comes to storing secrets in IoT devices, special care must be taken to ensure this data is not easily available to local attackers. For example, storing the secret in the device’s file system on a removable microSD card is not sufficient. Taking it a step further, storing it unencrypted in eMMC memory or a direct NAND flash chip is also not sufficient, since a physical attacker could attach serial lines to the chips and obtain the underlying data. A safer location would be in the device’s MCU internal storage, provided that debugging interfaces such as JTAG or SWD have been adequately secured. Ideally, secrets should be stored in trusted platform modules, or TPMs.
TPMs are special purpose integrated circuits that can store secret material such as encryption keys. It “seals” data in itself to prevent a physical attacker from extracting its contents. TPMs can also provide hardware authentication, since the “unsealing” operation requires the TPM to be in a specific state. That state can be configured in such a way that if certain hardware components are not present on the device, no data can be extracted. However, TPMs have their own drawbacks, namely cost and space on the PCB. Additionally, the data bus between the TPM and the MCU must be protected from passively sniffing data using an oscilloscope or logic analyzer.
If a TPM is not a viable option, design improvements can greatly reduce the risk associated with a compromised secret. Most importantly, IoT devices should have unique secrets to authenticate to the server. In the case of device secrets provisioned during manufacturing, there will need to be a separate process to ensure the correct key is flashed to a device. Managing keys during manufacturing is not simple and is beyond the scope of this blog post. Ideally, the device should generate its own public/private keypair and never disclose its private key.
Other Considerations
Authentication goes both ways. Just as the server authenticates the IoT device, the IoT device must also authenticate the server. This typically happens during the creation of the TLS channel. During the TLS handshake, the server provides its certificate to the client and the client verifies that the certificate is authentic. However, IoT devices sometimes do not properly verify the authenticity of the TLS certificate. This could allow an attacker to spoof the server’s identity by performing a man-in-the-middle attack. In order to properly verify a TLS certificate, an IoT device needs to store the root CA certificate to verify the server certificate’s chain of trust. Additionally, the IoT device needs to verify that the name of the peer matches the subject alternative name (SAN) field shown in the certificate. Praetorian has sometimes found bugs in the name verification step, such as checking if a certain string exists in the SAN, which can easily be bypassed with an attacker-provided certificate. For example, if the device checks for the substring “acme”, an attacker could generate a certificate for “acme.attacker.com” that is signed by a trusted CA.
In IoT security, authorization controls are just as important as authentication controls. One of the reasons to use unique credentials per device (as opposed to sharing credentials) is that it makes authorization controls possible. After validating the identity of a device, the server can ensure that the device is authorized to perform the requested action. In the case of pub/sub protocols, devices should also verify that requests are coming from an authorized server, rather than other devices.
Moving to PKI
When it comes to shared secrets, some authentication schemes are better than others. But shared secrets can only go so far in a complex system requiring a high level of security. In cases like this, public key infrastructure (PKI) can be a good option. PKI is a general term to describe issuing, distributing, storing, using, verifying, revoking, managing, and interacting with certificates and public/private keys. Instead of an IoT device storing a shared secret, it now stores a public/private keypair. This is useful because the server only has to know the device’s public key. The server does not need (and should not have) a copy of the device’s private key. Additionally, the server can revoke the device’s certificate if it is known to be compromised.
Let’s apply PKI to our original two authentication models: a single IoT device and a gateway with peripheral devices. In the first model, the device now has a public/private keypair and stores the private key in a TPM. The public key is shared with the server during manufacturing. Every time the device communicates with the server, the device digitally signs a hash of the message. The server then verifies this signature using the device’s public key and compares it to the message’s hash value.
In the model with multiple devices and a gateway, there are a few more steps. Every gateway and peripheral device has a public/private keypair, and the server is aware of all public keys. Let’s assume the system requirements prevent peripheral devices from knowing the gateway’s public key in advance, so the peripheral device only has a known-authentic copy of the server’s public key.
When a peripheral device starts a connection with a gateway, the peripheral device sends a signed message. Next, the gateway connects to the backend server, authenticates with its signature, and asks the server if the message it received from the peripheral device is authentic. If it is authentic, the gateway can now authenticate the peripheral device. However, now the peripheral device must authenticate the gateway. Since the server can verify the authenticity of the gateway’s signature, the server sends back a copy of the gateway’s public key signed with the server’s private key. After the peripheral device receives this signed public key, the peripheral device can verify the identity of the gateway using the backend server’s public key. Now, both devices are authenticated to one another. The flexibility of PKI means there are several ways to accomplish this.
While PKI is based on simple ideas, the centralized infrastructure tends to become complex and difficult to administer. This is especially true given the availability needs of the system (particularly relating to certificate revocation). Recognizing these challenges, the major public cloud providers all offer IoT-specific services that include some level of streamlined PKI support. More specialized IoT PaaS providers also have PKI-related service offerings.
In some unique cases, developers could be justified in building their own PKI systems. Cases like this should be rare, and should only be done after exhausting other options.
Conclusion
Authentication matters for all IoT systems, and it is important to implement properly. If you already have thousands of units out in the field, there are steps you can take to improve the authentication design to reduce the risk of further compromise. When creating new devices, consider storing secret material in a dedicated TPM. This will prevent attackers from being able to trivially extract the data from regular storage devices. Additionally, ensure the stored secret is unique for every device. Finally, consider migrating your authentication process to dedicated PKI. This will allow you to be flexible in how devices authenticate not only to a backend server, but to other peer devices. PKI can be costly and complex, but for a system with the right security needs, the benefits outweigh the drawbacks.
References
‍Industrial Internet Of Things Volume G4: Security Framework. Industrial Internet Consortium, 2016, pp. 67-71, https://www.iiconsortium.org/pdf/IIC_PUB_G4_V1.00_PB-3.pdf.
