Hi,
As part of some of our work on TF-M, specifically around attestation, device provisioning and firmware management, we've been reviewing some of what various companies are currently doing or requiring during the provisioning process (whether provisioning at the manufacturing phase, or provisioning devices into cloud or similar services post manufacturing).
The common thread in almost all of these scenarios is the use of X.509 certification chains when working with the public key(s) held on the end device.
At Linaro, we've been thinking through some of the benefits and tradeoffs of migrating from the current approach of exposing unsigned public keys for things like initial attestation and signing firmware, and what would be required to allow the signing of the attestation/firmware keys on devices, and generating new keys such as provisioning a device onto an Amazon/Google/Microsoft cloud service which would require creating a new private key held in secure storage, and storing the signed certificate chain associated with that new private key for on-demand retrieval.
- Some of the initial thinking and imagined benefits of migrating to X.509 certificate chains are described here: https://github.com/microbuilder/certificate_chains/blob/master/rfc_tfm.md
- Some general notes on X.509 certificates are available here: https://github.com/microbuilder/certificate_chains/blob/master/README.md
- And here are two scripts showing how to create 2 and 3 level certificate chains, just as a proof of concept to better understand how this might work with something like TF-M: - https://github.com/microbuilder/certificate_chains/blob/master/2lev_cert_cre... - https://github.com/microbuilder/certificate_chains/blob/master/3lev_cert_cre...
Specifically, they key missing aspects to enable the use of standard X.509 certificates are:
- Update mcuboot to understand a certificate chain -- rather than the raw public key -- when verifying firmware images - Generating PKSC#10 (RFC2986) certificate signing requests on the secure side, using a securely held private key during the request generation process - Generate new private keys and store them in secure storage for non-attestation uses like cloud services, and retrieve the associated and signed cert chains for that key on demand
A proposal of how this might work in the real world is shown here, with the TF-M secure code requrements in the 'opt' box of the sequence diagram: https://github.com/microbuilder/certificate_chains/blob/master/rfc_tfm.md#ce...
We don't have a full TF-M proof of concept ready yet, but wanted to put the idea on the table of migrating to X.509 certificate chains while we work on a proof of concept, and continue analysis of how provision at manufacturing and in the field (to cloud services, etc.) can be improved.
Any feedback/concerns is welcome here or perhaps in the Github repo above until a specific change request can be prepared for TF-M.
Best regards, Kevin Townsend