4 best practices for wireless (OTA) updates

　　OTA Updates are critical for developers who connect devices . In today's article , We will explore how embedded developers are implementing their OTA Several best practices to keep in mind when implementing solutions . Although I will point out some specific to AWS Best practices , But most of them are generic .

　　 Best practices 1 – Encrypt your firmware updates

　　 Creating and testing is time consuming , And it will consume a large part of the development budget . Although software also drives most functions in the product , And can significantly change the product , The software is worth protecting through encryption .

　　 Encrypting firmware images has several benefits . First , It can convert your firmware binaries into seemingly random or meaningless forms . This is ideal , Because developers don't want their binary images to be easy to study 、 Investigation or reverse engineering . This makes it harder for someone to steal intellectual property , And it is more difficult for people who may be interested in attacking the system . secondly , Encrypting an image means that the sender must have some key or credential that matches the device that decrypts the image . You can look at a simple source to help validate the source , Although more should be done than just encryption to fully verify and verify integrity , For example, sign the image .

　　 Best practices 2 – Firmware rollback is not supported

　　 There are often disputes about whether the system should support firmware rollback . The argument for rollback is usually , If there is a problem with the firmware update , Then the user can roll back to the running old version . At first glance , That seems like a good idea , But it may be the source of vulnerabilities in the system . for example , hypothesis 1.7 There is an error in the version 2.0 system that allows remote attackers to access the system , New firmware version 1.8 Fixed this bug . Customers update their firmware to 1.8 edition , But attackers know that if they can force the system to recover to 1.7, They can have the system . Today we execute OTA In a new interconnected world , Firmware rollback is a vulnerability , So embedded developers can disable them to protect your users .

 

　　 Best practices 3 – Protect your boot loader

　　 Updating firmware wirelessly requires multiple components to ensure safe and successful completion . Usually , The focus is on sending the new image to the device and decrypting it . However , Just like in traditional firmware updates , The boot loader is still a key part of the update process , stay OTA Updating , Bootloader is not just your traditional style , And it must be safe .

　　 There are many ways to work with the onboard boot loader , But either way , Boot loaders must be secure . The secure boot loader needs to be able to verify the authenticity and integrity of the firmware before loading . Some systems will use the application code to validate the firmware and install it into the new application slot , Other systems rely entirely on the boot loader . In any case , The security boot loader needs to be able to verify the authenticity and integrity of the firmware before accepting the new firmware image .

　　 Embedded developers ensure that the boot loader is built into the trust chain , It is also a good idea not to modify or update easily . The secure boot loader is a key component of the trust chain necessary to ensure system security .

　　 Best practices 4 — Build a chain of trust

　　 A trust chain is a series of events that occur when a device is started , Ensures that every link in the chain is trusted software . for example , If the component is shipped with a hardware based trust root , To verify MCU From safe sources . Then the trust root (RoT) Transfer to developers , The developer programs the security boot loader and security policy onto the device . During the boot sequence ,RoT Verify the integrity and authenticity of the boot loader , Then verify the integrity and authenticity of any second stage boot loader or software , Then verify the authenticity and integrity of the application . The application then validates its data 、 secret key 、 Authenticity and integrity of operating parameters, etc .

　　 This sequence creates a chain of trust , The firmware OTA Update requires and uses the chain . When a new firmware request is issued , The application must decrypt the image and verify that the authenticity and integrity of the new firmware are intact . Only when the trust chain can successfully pass through each link in the chain , To use the new firmware . most important of all , Developers and end users know , When the system starts successfully , The new firmware is legal .

　　 Conclusion

　　OTA Update is a key infrastructure component of almost all embedded development devices . Of course , Some systems will never be updated once deployed , however , These may be just a small part of the system . OTA Update is the preferred mechanism for updating firmware in the field .