How to update your IoT device software safely and secure?
Introduction
The success of the Internet of Things (IoT) has transformed industries, homes, and cities, creating a vast network of interconnected devices that communicate and interact seamlessly. As IoT devices continue to grow in number and complexity, the need for a reliable, efficient, and secure update process has become paramount.
This article explores the architecture, best practices, and considerations for designing an effective IoT update manager, focusing on flexibility, modularity, and security.
The Importance of an IoT Update Manager
IoT devices often operate in diverse and uncontrolled environments, necessitating regular updates to ensure optimal performance, security, and functionality. Without an effective update manager, IoT networks risk becoming vulnerable to security breaches, operational failures, or obsolescence.
When starting an IoT project, the challenges of designing a reliable update manager might not be obvious. But the legal framework is changing fast (GDPR, Cyber resilience act etc.), technologies advance at an ever-increasing pace and security problems are discovered even in major frameworks.
The solution for this can start with the flexible, tested and successfully implemented IoT update manager architecture from Concept Reply.
Initial design
A good initial design of the update manager is essential. You can easily do a system update later, but switching to a new version of update manager is a complex task: most of the time it means breaking backward compatibility, once update manager itself is updated there is no going back.
Depending on the available device memory, there are two main options for the initial design of the update process:
A. Using two image slots with an image swap mechanism.
B. Using one image slot with a direct image overwrite mechanism.
A. Two image slots
It is definitely the safer approach if the hardware platform has the luxury of extra storage space. Two complete system images, one active, on backup need to be stored at any time, although just one is actively used.
An image swap mechanism, usually in the bootloader, can set one partition or the other as active. This way, the new image is simply copied to the inactive slot before doing the swap.
Some CPUs can only boot up using the first image stored in the memory. In this case an image content swap mechanism is needed. Using an intermediate buffer (or scratch space) the new image is first copied in the secondary image slot and then the images are swapped, resulting in the new image being placed in the first slot and the backup image in the secondary slot.
B. Single image slot
For smaller or low-end hardware platforms where extra storage space is not an option, only one image slot can be present and active on the device.
To facilitate this, the bootloader needs to be capable of going to update mode, where it receives the new firmware image using different communication channels. Wireless channels (WiFi, BLE/Bluetooth, NFC) are more convenient but take up considerable storage space in the bootloader for the needed libraries, wired communication channels (UART, SPI, I2C) take up little space in the bootloader and are simpler to implement.
New firmware validation and rollback
It is a bonus for an update manager to have a rollback functionality in case a critical error occurs after the update is done. This way the system can be reverted to the previous, functional, state.
However, saving the system state before update starts requires lots of resources, which may not always be available. A system with two image slots can always store the previous firmware image in the secondary slot.
When resources are limited, and a single image slot is present, a good trade-off can be to prompt the user to do a full system back-up (on an external storage medium) before the update commences.
When using two image slots, it is important to have a “valid image” flag.
After updating, when running for the first time, the new image is responsible for setting this flag to true, but only once the system is up and fully functional.
Setting this flag too early in the boot process might result in a tight reset loop if a critical error appears after setting the flag.
Set it too late, and a user reset action might trigger an update rollback.
There is no rule set in stone as to when a new software should raise the image valid flag, but a timer or the idle task can be a good starting point.
The best way to do this is by having a system diagnostic routine at startup that will raise the flag once all the system diagnostic subroutines are successfully executed; so, it might pay off to invest time early in the project in the development of such a software component.
Modularity
Even the simplest IoT devices tend to have more than one software component to update: main image, bootloader, persistent data partition etc.
If it is guaranteed a system will not evolve, then it is easy, one can forget about modularity. In real life that is usually not the case.
At Concept Reply, we haven’t yet seen a single system to do so. All systems we developed evolved into having more than one updatable component: production data, calibration data, secondary image, persistent storage, binary image for slave device etc.
This is why having a modular architecture of an IoT update manager is a very good idea.
Update manager should be able to handle a list of components to update in a flexible way. The list can have as many components as needed; a component can be of any type.
Order of update
When having multiple components that can be updated at the same time, it is good to have a way to enforce the order in which this is done, rather than doing it randomly.
For maximum flexibility, it is best to store this information in the update packet itself.
In many IoT platforms there are, however, hard requirements that cannot be circumvented, these are better to be handled by the update manager in a coherent manner no matter which update package is used. (so, platform dependent rather than package dependent)
Persistent memory
One other important feature for an update manager is the ability to recover in case of a critical error / power loss.
To be able to do this, a system needs a persistent memory component where it can store the update status and detailed information about each step of the process.
This way, for example, Update Manager “remembers” after an unplanned power loss during the update that the first three components were already updated, and it needs to start with the fourth component again.
It is good to store all errors that may occur and the retry count, this way if a faulty update package always causes a reset, the system will eventually stop the update process in a predefined amount of time.
A way to persistently store update information is also important when one of the components requires a reboot before the update process can continue with the other components.
Security
Today more than ever, security is paramount in IoT, given the potential risks associated with vulnerabilities in connected devices. Ensuring that the update process is secure protects against unauthorised access and malicious updates.
Best practices for enhancing security include:
1. Update Package Integrity and Authenticity: Implement code signing to verify the authenticity and integrity of update packages. This involves digitally signing the updates with a private key and verifying the signature with a public key before installation.
Think about encrypting the entire package if it contains valuable intellectual property that an attacker may want to reverse engineer, even if high costs are involved.
2. Secure Boot and Firmware Validation: Employ secure boot mechanisms to ensure that only authenticated firmware can run on the device. Combine this with runtime firmware validation to detect and respond to any tampering attempts.
3. Access Controls and Authentication: Implement strict access controls and authentication mechanisms to prevent unauthorised access to the update manager. This includes using multifactorauthentication and role-based access controls.
4. Security Audits and Logging: Conduct regular security audits and vulnerability assessments to identify and mitigate potential threats. Staying proactive in security practices ensures ongoing protection against evolving cyber threats.
Maintain detailed logs of update activities and monitor for suspicious behaviour to detect and respond to potential security incidents promptly.
Update package signing strategies
Two of the most used signing strategies are Asymmetric Key Cryptography and Code Signing Certificates
A. Key Signing
The image is signed by the manufacturer using the root private key, and the device uses the public key to check the integrity and authenticity of the packet.
It is rather simple to implement, no complex infrastructure is needed, but the root private key is a critical point that needs to be secured against all possible attack scenarios. If compromised, then all the devices in the field are no longer secure.
The bootloader needs minimal security library support to implement this strategy.
B. Code Signing Certificates
The manufacturer needs to obtain a certificate from a trusted certification authority (CA) and signs the image using the private key associated with the certificate.
The image is transmitted together with the certificate, and the IoT device performs two actions:
- first checks the authenticity of the certificate (either online against a trusted CA or offline against a trusted root certificate pre-installed on the device).
- then validates the image signature (the public key embedded in the certificate is used to decrypt the signature, which is then compared to the self-generated image hash).
The biggest advantage is that there is no single point of failure compared to the other solution.
On the other side, the drawbacks of this solution are the following:
- this requires a complex IT infrastructure to generate, renew and keep track of all certificates.
- the bootloader needs more libraries to support the certificate validation.
Conclusion
Designing an IoT update manager with a focus on flexibility, modularity, and security is essential for maintaining the reliability and safety of IoT devices. The dynamic nature of IoT environments demands that update managers be adaptable and resilient, capable of evolving alongside technological advancements and emerging threats.
With all these challenges in mind it is not easy to implement an update manager, Concept Reply with its 10 years history as an IoT accelerator can be your trusted partner in achieving this in the best manner and time.
