I am doing some research on the usage of secure boot images within the Torizon Cloud update system.
Our current setup is based on the Verdin AM62 modules running torizon O.S and a client application in Docker (with both O.S. and client application updateble via torizon cloud).
At the moment my understanding is that i can upload a secure created (boot or application) image (with 1 set of keys) to torizon cloud and use that to update a module, but how would this work if we have multiple module with all individual keys, do i need to create a separate image for all of these units, upload them to torizon cloud and start an individual update for each unit?
Or is the advised method to generate 1 set of keys and use that for all production units?
Disclaimer from the moderators: the content of this AI-generated message is wrong. Please be sure to check @jon.tx’s answer below.
Click here to check the original message
Thank you for reaching out with your question about managing secure updates for your Verdin AM62 modules using Torizon Cloud.
Hi, I’m the Toradex AI Assistant. The Toradex Support team will follow up with you shortly!
Did you like my answer?
Hello Richard,
When it comes to handling secure boot images and keys, you have a couple of options:
Individual Keys for Each Module: If each module has its own unique set of keys, you would need to create separate update packages for each device. This means each package must be signed with the corresponding device’s keys, ensuring that each module can verify the update’s authenticity. This approach maximizes security but requires more management effort.
Single Set of Keys for All Modules: Alternatively, you can use a single set of keys for all your production units. This simplifies the update process, as you only need to create and manage one update package for all devices. However, this reduces security granularity, as a compromise of the shared keys could potentially affect all devices.
For enhanced security, especially in production environments, it’s advisable to use offline signing keys. This means keeping your signing keys offline, which separates the authority for signing software from deploying updates, protecting your devices from unauthorized updates even if your Torizon Cloud account is compromised.
Ultimately, the choice between these strategies depends on your specific security needs and operational considerations. If security is paramount and you can manage the complexity, using individual keys is advisable. If ease of management is more critical and you can accept the associated risks, a single set of keys may suffice.
I hope this helps clarify your options. Feel free to reach out if you have more questions.
Best regards,
Toradex AI Assistant
Please, also check if these links can help you solve your problem:
No need for different keys for each update. You might be imagining that the update system encrypts the software updates separately for each module. That’s true, in the sense that each device has its own device certificate and private key, and we use that to create a mutual TLS connection for all interactions between the device and the update server. But you don’t have to do anything special to make that work: the device gets its TLS cert and private key at provisioning time, and generates and registers its unique subsystem-specific keys when the subsystem is registered. That’s all automated for you, though; if you have the device connected to Torizon Cloud you already have all of the device-specific keys configured and installed correctly.
But the keys that you use for signing the software update and ensuring the integrity of the delivered packages use asymmetric cryptography. That’s an additional layer of defense-in-depth, on top of the device-specific certs and keys. You sign software with a private key^†, and distribute the associated public key to all of the devices. That private key can be held in custody by Torizon Cloud (in which case we sign the software for you when you upload it), or rotated offline to provide even more security.
I’ll also note that one of the key benefits of Torizon Cloud is that you can have fearless and automatic key rotation, because it’s based on Uptane. That’s why you can start off using a signing key managed by Torizon Cloud, then rotate it later on, without having to change anything at all on your devices.
† Technically, there are multiple keys implicated in Uptane. You sign (metadata about) software packages with the Targets key, but the entire key structure, including revocation, freshness, and installation instruction signatures, is verified by the device on every update check.
I am doing some research on the usage of secure boot images within the Torizon Cloud update system.
Sorry, I believe I may have misinterpreted your question. If your question is about using secure boot images with Torizon Cloud, rather than the security of Torizon Cloud and the software update system itself, I think my answer above is a little off-topic.
You can certainly use Torizon Cloud to update a device with Secure Boot enabled. For the rest of your question, it’s perhaps useful to review how the secure boot chain of trust works.
First, the romcode of the SoC validates the signature of the bootloader against a key that is fused into the device using one-time-programmable fuses (the SMPK in the Verdin AM62 case). Second, the signed bootloader validates the signature of the kernel and the rest of the FIT image using a key contained in the bootloader image. Finally, (if enabled) the kernel validates the signature of the rootfs, using a key contained in the FIT image.
If any of these steps fail, the device will not boot.
All of the keys in the secure boot chain that are on the device are public keys, and should be the same for every device. If you’re flashing different signing keys on each device, you are using secure boot in a very strange and unintended way.
When you do an OS update, you are updating the rootfs (and potentially the kernel). So you’ll need to make sure that those elements are signed by the correct private key corresponding to the public key in the device’s bootloader (for the FIT image) or the FIT image (for the rootfs). As long as you’re always providing the yocto build with the same signing keys, that should always be the case. You pass the signing keys into your Yocto build with the variables in the documentation: TDX_K3_HSSE_KEY_DIR for the boot container signing keys, UBOOT_SIGN_KEYDIR/UBOOT_SIGN_KEYNAME/UBOOT_SIGN_IMG_KEYNAME for the FIT image signing keys, and CFS_SIGN_KEYDIR/ CFS_SIGN_KEYNAME for the composeFS (rootfs) signing keys.
Individual Keys for Each Module: If each module has its own unique set of keys, you would need to create separate update packages for each device. This means each package must be signed with the corresponding device’s keys, ensuring that each module can verify the update’s authenticity. This approach maximizes security but requires more management effort.
Bad bot.
The AI’s hallucination about it being somehow more secure to use individual keys for each module is just wrong (with some caveats that are so minor they aren’t even worth mentioning). Although it’s technically true that having individual keys for each module would minimize the damage if a single key leaked, it’s completely irrelevant. If you had a setup like that, you’d end up storing all the private signing keys for all the devices in one big key management system to feed into your build system; it’d no longer be feasible to do anything else. So a compromise that exposed one of the device keys would expose them all.
Thank you for your replies, i was in indeed thinkin about the secure boot implementation and not so much the secure connection for the torizon cloud environment, so your 2nd reply answered all my questions for now.
