Chain of trust - adding another company to the chain
55 views
Skip to first unread message
Peter Oberauer
Aug 12, 2025, 10:08:50 AMAug 12
to swupdate
Hi. We are looking for SWUpdate best practices in the following scenario:
Company A manufactures devices, and builds the Yocto Linux SDK (toolchain).
Company A manufactures devices, and builds the Yocto Linux SDK (toolchain).
Company B (and others) buy the devices, use the SDK to create application(s) and sell the devices with their software application on it.
Initially the devices only trust Company A (at secure boot).
The question, is: somehow the device must be told that it must now also trust Company B (at least SWUpdate updates from Company B).
What are the best practices around adding that additional trust, in a secure way?
What are the best practices around adding that additional trust, in a secure way?
To provide more context:
The device uses NXP i.MX 8X, U-Boot, Yocto Linux, SWUpdate.
Everything we have found online so far (from NXP, SWUpdate etc) covers the simpler case, where there are only keys from one company to manage.
Which terminology/keywords should we be using for our scenario?
After the initial reprogramming at company B, the device will need to
accept additional updates in the field, from a USB stick, without
internet connectivity.
Rightly or wrongly, current plans are:
Company A signs the boot container, Linux rootfs (read-only, dm-verity).
Company A fuses their four SRKs and closes the device for signed secure boot.
Company B creates the SWUpdate - using the boot container and rootfs (built and signed by A) and their own app partition. And signs the SWUpdate themselves.
Company B creates the SWUpdate - using the boot container and rootfs (built and signed by A) and their own app partition. And signs the SWUpdate themselves.
Therefore the device needs to go from trusting A (on secure boot), to also trusting B (on SWUpdate).
Thank you
Peter
Stefano Babic
Aug 12, 2025, 10:25:18 AMAug 12
to Peter Oberauer, swupdate
Hi Peter,
On 8/12/25 16:07, Peter Oberauer wrote:
> Hi. We are looking for SWUpdate best practices in the following scenario:
>
> Company A manufactures devices, and builds the Yocto Linux SDK (toolchain).
> Company B (and others) buy the devices, use the SDK to create
> application(s) and sell the devices with their software application on it.
This is the well known "OEM" use case.
>
> Initially the devices only trust Company A (at secure boot).
> The question, is: somehow the device must be told that it must now also
> trust Company B (at least SWUpdate updates from Company B).
> What are the best practices around adding that additional trust, in a
> secure way?
You have to implement a full PKI. Company A becomes the CA (Certificate
Authotity) and creates certificates for itself (to deliver Yocto /
rootfs) and for Company B (to deploy applications). Certificates are
signe by CA. On the device, CA public certificate is installed. Device
can verify packages signed by A and signed by B, each of them with own
certificate.
>
> To provide more context:
>
> The device uses NXP i.MX 8X, U-Boot, Yocto Linux, SWUpdate.
Common case...
>
> Everything we have found online so far (from NXP, SWUpdate etc) covers
> the simpler case, where there are only keys from one company to manage.
Well, do you expect that vendor will fully provide support for your
project ? Take into account that there are several parts that are very
specific to a project. And to the Hardware.
NXP is not telling vyou about the great idea they had to move the SCU FW
into the bootloader. If the API between SCU and Kernel changes (and this
happened a lot of times..), system is broken and you need to upgrade
both U-Boot and Kernel at once. That creates a dependency, and you must
update U-Boot for changes in kernel (and viceversa). The only suitable
way I found with this SOC is to create an A/B schema also for U-Boot,
and synchronize updates of U-Boot (together with ATF, hdmi fw, etc.) and
the kernel.
> Which terminology/keywords should we be using for our scenario?
> After the initial reprogramming at company B, the device will need to
> accept additional updates in the field, from a USB stick, without
> internet connectivity.
See above.
>
> Rightly or wrongly, current plans are:
> Company A signs the boot container, Linux rootfs (read-only, dm-verity).
> Company A fuses their four SRKs and closes the device for signed secure
> boot.
Company B won't be able to replace the kernel - probably this is ok for you.
> Company B creates the SWUpdate - using the boot container and rootfs
> (built and signed by A) and their own app partition. And signs the
> SWUpdate themselves.
> Therefore the device needs to go from trusting A (on secure boot), to
> also trusting B (on SWUpdate).
Company B could also provide a full blown update, including U-Boot and
Kernel), if it gets the artifacts as they are from company A, that has
already signed them.
Best regards,
Stefano Babic
On 8/12/25 16:07, Peter Oberauer wrote:
> Hi. We are looking for SWUpdate best practices in the following scenario:
>
> Company A manufactures devices, and builds the Yocto Linux SDK (toolchain).
> Company B (and others) buy the devices, use the SDK to create
> application(s) and sell the devices with their software application on it.
>
> Initially the devices only trust Company A (at secure boot).
> The question, is: somehow the device must be told that it must now also
> trust Company B (at least SWUpdate updates from Company B).
> What are the best practices around adding that additional trust, in a
> secure way?
Authotity) and creates certificates for itself (to deliver Yocto /
rootfs) and for Company B (to deploy applications). Certificates are
signe by CA. On the device, CA public certificate is installed. Device
can verify packages signed by A and signed by B, each of them with own
certificate.
>
> To provide more context:
>
> The device uses NXP i.MX 8X, U-Boot, Yocto Linux, SWUpdate.
>
> Everything we have found online so far (from NXP, SWUpdate etc) covers
> the simpler case, where there are only keys from one company to manage.
project ? Take into account that there are several parts that are very
specific to a project. And to the Hardware.
NXP is not telling vyou about the great idea they had to move the SCU FW
into the bootloader. If the API between SCU and Kernel changes (and this
happened a lot of times..), system is broken and you need to upgrade
both U-Boot and Kernel at once. That creates a dependency, and you must
update U-Boot for changes in kernel (and viceversa). The only suitable
way I found with this SOC is to create an A/B schema also for U-Boot,
and synchronize updates of U-Boot (together with ATF, hdmi fw, etc.) and
the kernel.
> Which terminology/keywords should we be using for our scenario?
> After the initial reprogramming at company B, the device will need to
> accept additional updates in the field, from a USB stick, without
> internet connectivity.
>
> Rightly or wrongly, current plans are:
> Company A signs the boot container, Linux rootfs (read-only, dm-verity).
> Company A fuses their four SRKs and closes the device for signed secure
> boot.
> Company B creates the SWUpdate - using the boot container and rootfs
> (built and signed by A) and their own app partition. And signs the
> SWUpdate themselves.
> Therefore the device needs to go from trusting A (on secure boot), to
> also trusting B (on SWUpdate).
Kernel), if it gets the artifacts as they are from company A, that has
already signed them.
Best regards,
Stefano Babic
Peter Oberauer
Aug 12, 2025, 11:48:07 AMAug 12
to swupdate
Hi Stefano
Thank you!
> Company A becomes the CA... On the device, CA public certificate is installed...
If Company A signs different certificates for Company B and Company C:
SWUpdate from B or C will be accepted?
SWUpdate from B or C will be accepted?
What if B wants the device to ultimately accept updates from B, but not from C?
Is that also a common case?
Is that also a common case?
What is a good way to handle that?
e.g. once B has updated the device, it becomes theirs. A and B are trusted, but not C.
Searching for SWUpdate and PKI, I've found this paragraph:
https://sbabic.github.io/swupdate/signed_images.html#using-pki-issued-certificates
https://sbabic.github.io/swupdate/signed_images.html#using-pki-issued-certificates
Is there anything that goes into more detail on SWUpdate and PKI use cases please?
Thank you
Peter
Stefano Babic
Aug 12, 2025, 12:48:23 PMAug 12
to Peter Oberauer, swupdate
Hi Peter,
On 8/12/25 17:48, Peter Oberauer wrote:
> Hi Stefano
>
> Thank you!
>
> > Company A becomes the CA... On the device, CA public certificate is
> installed...
>
> If Company A signs different certificates for Company B and Company C:
> SWUpdate from B or C will be accepted?
Yes, if SWUpdate uses the CA public certificate.
>
> What if B wants the device to ultimately accept updates from B, but not
> from C?
You need then to introduce an intermediate certificate, different for B
and C, and this generates certificate for A and B. And a different
intermediate certificate will create certificates for A and C.
Nevertheless, on the device you need the intermediate public certificate
to verify the update.
> Is that also a common case?
No.
> What is a good way to handle that?
>
> e.g. once B has updated the device, it becomes theirs. A and B are
> trusted, but not C.
It depends also if B then overtake the other artifacts from A. Then it
could be simpler, and B signs just with own certificates. Only B updates
are accepted then.
>
> Searching for SWUpdate and PKI, I've found this paragraph:
> https://sbabic.github.io/swupdate/signed_images.html#using-pki-issued-
> certificates
>
> Is there anything that goes into more detail on SWUpdate and PKI use
> cases please?
No.
Best regards,
Stefano Babic
On 8/12/25 17:48, Peter Oberauer wrote:
> Hi Stefano
>
> Thank you!
>
> > Company A becomes the CA... On the device, CA public certificate is
> installed...
>
> If Company A signs different certificates for Company B and Company C:
> SWUpdate from B or C will be accepted?
>
> What if B wants the device to ultimately accept updates from B, but not
> from C?
and C, and this generates certificate for A and B. And a different
intermediate certificate will create certificates for A and C.
Nevertheless, on the device you need the intermediate public certificate
to verify the update.
> Is that also a common case?
> What is a good way to handle that?
>
> e.g. once B has updated the device, it becomes theirs. A and B are
> trusted, but not C.
could be simpler, and B signs just with own certificates. Only B updates
are accepted then.
>
> Searching for SWUpdate and PKI, I've found this paragraph:
> https://sbabic.github.io/swupdate/signed_images.html#using-pki-issued-
> certificates
>
> Is there anything that goes into more detail on SWUpdate and PKI use
> cases please?
Best regards,
Stefano Babic
Reply all
Reply to author
Forward
0 new messages