Hi, I haven't dug into the details here but just wanted to point out that there is an x509 library in Mbed TLS.
Thanks, Ronald.
-----Original Message----- From: TF-M tf-m-bounces@lists.trustedfirmware.org On Behalf Of Abhishek Pandit via TF-M Sent: 28 September 2020 11:42 To: Soby Mathew Soby.Mathew@arm.com; David Brown david.brown@linaro.org; tf-m@lists.trustedfirmware.org Subject: Re: [TF-M] X.509 Certificate Chain Support in TF-M
Adding TF-M mailing list, in case anyone is interested in the topic.
-----Original Message----- From: Soby Mathew Soby.Mathew@arm.com Sent: 24 September 2020 15:02 To: David Brown david.brown@linaro.org Cc: Abhishek Pandit Abhishek.Pandit@arm.com; Kevin Townsend kevin.townsend@linaro.org; Anton Komlev Anton.Komlev@arm.com; David Wang David.Wang@arm.com; Tamas Ban Tamas.Ban@arm.com; Shebu Varghese Kuriakose Shebu.VargheseKuriakose@arm.com; Adrian Shaw Adrian.Shaw@arm.com Subject: RE: X.509 Certificate Chain Support in TF-M
[+Adrian]
Hi David
To me, what might make some sense would be to have some kind of restrictions on what can be done with the private key stored on the secure side. If all operations are done through an extended API, those would be the only operations permissible, whereas a generic private key storage could allow rogue non-secure code to make use of signing of other things, including signing non-resident data (one device using another for attestation. At least the risks and costs of this should be considered.
Thanks for the clarification. This would mean that given the current PSA Crypto design, the only way to achieve this would be to implement a custom RoT service in SPE. Hence the NSPE cannot make use of the key for arbitrary signing operation.
My primary concern with this solution at this point, is that we haven't consider securing the protocol necessary to associate a certificate/key pair with a particular device. Maybe we should be looking into SDO?
Yes, that does seem like a good candidate. From my reading, several aspects of provisioning seem to be outside TF-M realm.
Having roots of trust instead of public keys (or certs) for direct signing keys would give OEMs and other parties involved in the firmware upgrade process more flexibility.
I see, thanks. We use certificate chains when firmware images need from different vendors need to be deployed in different privilege levels or multiple boot stages are present in A-profile. The Platform boot guide document https://developer.arm.com/documentation/den0072/0101/ mentions this as well. Possibly this is an enhancement to MCUBoot (Boot loader for TF-M).
After talking with Adrian, I think there is consensus that certificate chain is a useful feature to have. So from my point of view, if there is some collaborative effort to develop such a service as TF-M specific extension, I think it would be very useful to the community.
Best Regards Soby Mathew
-----Original Message----- From: David Brown david.brown@linaro.org Sent: 23 September 2020 19:12 To: Soby Mathew Soby.Mathew@arm.com Cc: Abhishek Pandit Abhishek.Pandit@arm.com; Kevin Townsend kevin.townsend@linaro.org; Anton Komlev Anton.Komlev@arm.com; David Wang David.Wang@arm.com; Tamas Ban Tamas.Ban@arm.com; Shebu Varghese Kuriakose Shebu.VargheseKuriakose@arm.com Subject: Re: X.509 Certificate Chain Support in TF-M
On Wed, Sep 23, 2020 at 04:52:13PM +0000, Soby Mathew wrote:
I had a review and thanks for the excellent proposal, and it does make sense to me to add this support but some questions from my side:
- Do you envisage the new CSR API and ability to store certificate blobs in secure world as an extension to PSA Attestation API ?
- I know it is desirable to add this functionality to secure world, but to clear my mind, Is it possible to provide the same functionality from Non Secure side but making use of PSA crypto APIs ? For example the
PSA
Crypto
could export the public key and sign necessary data to createthe CSR
from
NS side. Similarly new keys can be imported to Crypto by NSworld while
the
certificate chains are maintained in NS world for non IAT services. I may have missed some key point.I agree that there is little reason to store the certificates themselves on the secure side. If they were modified or tampered with, there would no longer be a private key to make use of them.
My primary concern with this solution at this point, is that we haven't consider securing the protocol necessary to associate a certificate/key pair with a particular device. Maybe we should be looking into SDO?
- I understood how we can make use of certificate chains for
attestation,
but
it is less clear how this can be made use of while booting firmware images. Could you elaborate more ?Only in the sense of allowing a signed firmware image to have a certificate chain with it. Having roots of trust instead of public keys (or certs) for direct signing keys would give OEMs and other parties involved in the firmware upgrade process more flexibility.
David
-- TF-M mailing list TF-M@lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m