DE · Topics ·

Designing Over-the-Air, Secure Devices

The fundamentals of IoT device security are hard to build in late in the development process, and the details do matter.
Andrew Howard Andrew Howard

Building a commercial product is difficult. Those lucky enough to build something that consumers or businesses want will endure a long journey. For those wishing to secure these products, it adds even more time and complexity. We are usually brought into hardware security evaluations near the end of the release cycle. Although not popular, my reaction to the many Internet of Things (IoT) products I review with product managers is that it would be cheaper to start over. The fundamentals of IoT device security are hard to build in late in the development process, and the details do matter.

Typically, we are brought in by the enterprise security team. They are usually under pressure from the board of directors or regulators to provide information on their company’s internet-connected products. The Mirai Botnet and the recent action by the FTC against D-Link are often the spark for these conversations. From there, the first conversation with the product manager usually goes the same way: “We are secure. The product has been tested by a red team. They followed secure coding principals, and they are utilizing patched, commodity operating systems.” We applaud their commitment to a secure development lifecycle. Then we tell them the bad news: This is not good enough to keep a product secure in the field, and unfortunately, they do not know it.

No device will have perfect security. Given this fact, and the number of device security issues I have witnessed, a secure, over-the-air (OTA) update mechanism is the most important security feature all devices must implement and is where I point most product managers first. It is more important than nearly any other security mechanism, short of the basic security hygiene issues. Sure, you can build a very secure product, but seeing that most of these devices are in the field for years, it is impossible to know what security challenges are coming, and having no mitigation option when a new vulnerability is discovered is not an enviable position.

Translating a Foreign Concept

Yet, the concept of secure OTA firmware updates and patch validation are often foreign to product managers. And, if a company has implemented OTA updates, they typically do so in an unsecure manner. Yes, the device can be updated by the manufacturer, but also by everyone else. OTA updates must be encrypted, authenticated, validated and securely transferred. Manufacturers fail to understand that a strong OTA update strategy can often mitigate against a full recall when security or safety issues are discovered in the future. An OTA update is always cheaper than a recall.

OTA updates typically rely on a strong public key infrastructure (PKI). If this is weak, the OTA process is at risk. How secret key information is provisioned, rotated, used and revoked is important. The details of key sizes, key seeding techniques and key storage methods matter greatly. A seemingly tiny mistake, like leaving a secret key in the device’s memory, can have devastating results. For example, we often see the same secret key material used across a family of devices and never rotated. This leads to scenarios where if an attacker can extract the secret key from one device, they can use it to push a malicious patch to the rest of the devices in the field. Ideally, each device would get its own secret key or keys and they would rotate often.

Part of the Design Process

The apparatus around the secure OTA update capability is equally important. It includes methods to validate and monitor updates, protect the validation routes and manage inevitable update challenges. Device manufacturers should be able to answer questions such as the following:

• Which devices in the field are running the latest application code? Which are not?

• For those devices not running the latest application code, why not?

• How does rollback work if a code deployment fails?

Designing a product that is secure the day it is released is difficult. Designing a product that’s secure for its entire lifecycle—with no updates—is almost impossible. Ensure your devices support a secure OTA update process that is encrypted at rest and in transit, authenticated, validated and built on a solid PKI. This will increase the lifespan of devices and protect your reputation.

Andrew Howard is chief technology officer for Kudelski Security

(, which bills itself as a trusted cybersecurity innovator for the world’s most security-conscious organizations. Contact him via [email protected]

Share This Article

Subscribe to our FREE magazine, FREE email newsletters or both!

Join over 90,000 engineering professionals who get fresh engineering news as soon as it is published.