This post has been republished via RSS; it originally appeared at: New blog articles in Microsoft Community Hub.
Summary
Azure Sphere is updating keys used in image signing, following best practises for security. The only impact on production devices is that they will experience two reboots instead of one during the 22.11 release cycle (or when they next connect to the Internet if they are offline). For certain manufacturing, development, or field servicing scenarios where the Azure Sphere OS is not up to date, you may need to take extra steps to ensure that newly signed images are trusted by the device; read on to learn more.
What is an image signing key used for, and why update it?
Azure Sphere devices only trust signed images, and the signature is verified every time software is loaded. Every production software image on the device – including the bootloader, the Linux kernel, the OS, and customer applications, as well as any capability file used to unlock development on or field servicing of devices – is signed by the Azure Sphere Security Service (AS3), based on image signing keys held by Microsoft.
As for any modern public/private key system, the keys are rotated periodically. The image signing keys have a 2-year validity. Note that once an image is signed, it generally remains trusted by the device. There is a separate mechanism based on one-time programmable fuses to revoke older OS software with known vulnerabilities such as DirtyPipe and prevent rollback attacks – we used this most recently in the 22.09 OS release.
When is this happening?
The next update to the image signing certificate will occur at the same time as 22.11 OS is broadly released in early December. When that happens, all uses of AS3 to generate new production-signed application images or capabilities will result in images signed using the new key.
Ahead of that, we will update the trusted key-store (TKS) of Azure Sphere devices, so that the TKS incorporates all existing keys and the new keys. This update will be automatically applied to every connected device over-the-air. Note that device TKS updates happen ahead of any pending updates to OS or application images. In other words, if a device comes online that is due to receive a new-key-signed application or OS, it will first update the TKS so that it trusts that application or OS.
We will update the TKS at the same time as our 22.11 retail-evaluation release, which is targeted at 10 November. The next time that each Azure Sphere device checks for updates (or up to 24 hours later if using the update deferral feature), the device will apply the TKS update and reboot. The TKS update is independent of an OS update, and it will apply to devices using both the retail and retail-eval feeds.
Do I need to take any action?
No action is required for production-deployed devices. There are three non-production scenarios where you may need to take extra steps to ensure that newly signed images are trusted by the device.
The first is for manufacturing. If you update and re-sign the application image you use in manufacturing, but you are using an old OS image with an old TKS, then that OS will not trust the application. Follow these instructions to sideload the new TKS as part of manufacturing.
The second is during development. If you have a dev board that you are sideloading either a production-signed image or a capability to, and it has an old TKS, then it will not trust that capability or image. This may make the “enable-development” command fail with an error such as “The device did not accept the device capability configuration.” This can be remedied by connecting the device to a network and checking that the device is up-to-date. Another method is to recover the device – the recovery images always include the latest TKS.
The third is for field servicing. During field servicing you need to apply a capability to the device as it has been locked down after manufacturing using the DeviceComplete state. However, if that capability is signed using the new image signing key and the device has been offline - so it has not updated its TKS - then the OS will not trust the capability. Follow these instructions to sideload the new TKS before applying the field servicing capability.
Thanks for reading this blog post. I hope it has been informative in how Azure Sphere uses signed images and best practises such as key rotation to keep devices secured through their lifetime.