Hi Jamie,
This aligns well with a key requirement we identified thinking about late binding devices that make use of TF-M, such as with cloud services or providers which tend to use X.509 certificate chains which will need to be signed, and a private key generated and held in secure storage as part of the binding and certification signing process.
Some initial thoughts are visible here in interim if it's useful to see a use case for this work: https://github.com/microbuilder/certificate_chains/blob/master/rfc_tfm.md
Best regards, Kevin
On Tue, 4 Feb 2020 at 14:32, Jamie Fox via TF-M < tf-m@lists.trustedfirmware.org> wrote:
Hi all,
I have pushed for review patches to enable persistent keys in the TF-M Crypto service. With these changes, persistent keys will be stored by Mbed Crypto using the ITS APIs exposed by TF-M.
The reviews are here:
https://review.trustedfirmware.org/c/trusted-firmware-m/+/3252 (implementation)
https://review.trustedfirmware.org/c/trusted-firmware-m/+/3253 (tests)
Currently, merging of these patches is blocked as they depend on Mbed Crypto 2.0 (or greater), which adds support for the latest ITS 1.0.0 APIs exposed by TF-M. Integrating Mbed Crypto 2.0 with TF-M is a work in progress.
If anyone wants to test these patches in the meantime, it is possible to cherry pick the patch in the Mbed Crypto repo that adds support for ITS 1.0.0. With the Mbed Crypto repo checked-out at the “mbedcrypto-1.1.0” tag, do a “git cherry-pick bda5a2111” to cherry pick the relevant patch.
Kind regards,
Jamie
-- TF-M mailing list TF-M@lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m