In recent years, cyberattacks on IoT devices have hit the billions – yes, billions with a B. During the early IoT years, companies were so enamored with capitalizing on the technology and pumping out millions of connected devices, few stopped to think about how we should secure them. Today we’ve come full circle and it’s painfully evident we MUST secure IoT devices, and the question has become ‘How?’
Security is fluid. Someone discovers a security vulnerability, someone else updates the vulnerability and the problem is solved. Until the next vulnerability is discovered. But how do you fix future unpredictable security holes on a device that may be sitting in the middle of an ocean or strapped to someone’s wrist? You could send out a field service person to manually update every device or simply replace every hacked or outdated device, but that is a costly and time-consuming endeavor. The alternative? OTA updates.
OTA updates (over-the-air updates) are a way for manufacturers to deploy a wireless update to firmware on connected devices once they are in the field. “Over-the-air” means communication with devices that are connected to the Internet or other networks to install new software or firmware updates. A secure OTA system allows manufacturers to update security features, fix bugs, improve software, test/deploy additional features, and more once a device has left the factory.
OTA: Secure Communication is Key
In order to perform secure OTA updates, the OTA update mechanism needs to be a core part of a device’s architecture where the remote device is responsible for identifying and applying updates to itself, and the OTA server is responsible for securely distributing updates to its connected devices.
But first, you establish communication between the system and the device. Because there is no way for the server to know where the device is or how to get behind any firewalls securing it, this connection must almost always be initiated by the device itself. So, the device is designed to “call back” to the OTA system to establish communication with the OTA server.
Each device should also be uniquely identifiable, which is generally already a requirement for IoT products. This identification assignation most often occurs during the manufacturing process. Because of the delay between the time firmware is released to the factory and when a product ships, most factories already have a system in place for updating firmware before shipment. The product is manufactured using the originally submitted firmware and before it leaves the factory it powers up and looks for any available updates. This is an opportunity to add a unique identifier to each device which provides a great deal of flexibility for your OTA updates.
If your devices are uniquely identified, you can roll out firmware updates to test devices and update by geography, time zone, product version, etc. Unique device IDs also allow you track which devices have been updated, which haven’t updated properly, when devices aren’t being used or when they may be broken. These analytics can help you identify and fix potential problems with your product. You may notice a device is broken before the user does and have the opportunity to reach out to the user proactively or replace the device, earning a reputation for delivering excellent customer service.
Securing the OTA Process
Once a device is uniquely identifiable and a communication channel can be established between the device and the OTA system, you want to make sure you can secure the OTA update process. One tool you can use is authentication, which may include authentication of the server, the device and the firmware package.
It’s important to authenticate your server and the firmware package so your device knows the update they are receiving is, in fact, from you and not a man-in-the-middle server trying to take over the device. Securing the device is a bigger challenge.
You should have your server authenticate your device to prevent malicious access. But devices are out in the world and can be physically captured – someone could walk away with your remote heart rate monitor – and eventually a thief may be able to crack the device. This means you must limit the server access you give to a device. If the heart monitor thief cracks the device and is able to connect to the hospital server, you don’t want it to have privileges that will allow the thief to change server settings or access other devices on the server. Device authentication and limiting functionality of a device connecting to your server are the best ways to manage security on the device side.
How do you authenticate? Signatures. Signing is a way to authenticate that data can only come from a verified source. The signer has a private key and the reader has the public key which verifies the private key but isn’t capable of generating a signature of its own. An important part of a signature is the time. If the message is received after the time stamp has expired, the signature is not authenticated and the message is not verified. Even if you can prevent a hacker from posing as a verified source and generating new messages, they could capture the entire packet and send it again at a later time or even multiple times. In most cases that might not be a big deal, but if you are sending instructions to an airplane to “decrease altitude by 10,000 feet”, the hacker would only need to send that message a few times to crash your plane. Including a time stamp in a signature prevents replay attacks.
Encryption is another layer of security you can add to your OTA updates. Encrypting is obfuscating the data in a way that no one else can decipher – it’s like turning your data into a secret code. When you encrypt your data along the wire, no one can read it if they are able to intercept it.
One of the challenges inherent in OTA updates on some IoT devices is that the limited size of the processor restricts the encryption and hashing you can do. So, it’s important to consider the type of data you are dealing with when you are choosing the processor for your device (this goes back to baking OTA in from the start). For instance, if you are handling Personally Identifiable Information (PII) you must select a processor that can provide both authentication and encryption of the data being exchanged.
Failsafe OTA Updates
You’ve uniquely identified your device, you’ve secured the communication between the device and the server, and now you’re ready to send an update. How can you ensure your updates don’t “break” your device? Using an A/B partition method will provide a failsafe for your update process. With the A/B partition method, you run two partitions with the system running on just one side. The device booter will boot on A and when it receives a new update it will write it to the B partition. It then reboots to bring up B and run the new software.
Outside of this process is a watchdog that is receiving periodic check-ins from the firmware. If the watchdog doesn’t hear from system within a designated time frame, it will reboot whole system. If partition B with the new firmware doesn’t boot properly, it will boot back to partition A and the old firmware. Then A alerts server that new firmware was downloaded but not running. A watchdog prevents your device from getting stuck halfway through an update and becoming nonresponsive.
Not If but How?
It’s no longer a question of if you should add secure OTA update capabilities to your connected device. Companies are embracing the ability to future-proof their products with the quick security updates, easy new feature deployments, valuable device data and more that OTA firmware management provides. To be successful, companies must assess whether they have the time, money and resources required to build a platform from scratch or if outsourcing to an established platform would be more efficient.