Hi Jun,
Not sure if this approach is doable since it seems mbedTLS’s X.509 has tight coupling on parsing and signing/verifying.
>> Incase it helps…
Mbed TLS project plans to make changes for X.509 and TLS to use PSA Crypto for all crypto operations. Today only certain operations use PSA Crypto APIs when MBEDTLS_USE_PSA_CRYPTO is enabled.
The work would ultimately help TLS and X.509 in NS to make use of PSA Crypto APIs in TF-M on secure side.
The phase1 work intended to start from next quarter -
https://github.com/orgs/ARMmbed/projects/18#column-15836318
Here is the strategy document about the work -
https://github.com/ARMmbed/mbedtls/blob/ad7d4231f356254ec96d851ba5bbec975d2b50ea/docs/architecture/psa-migration/strategy.md
Regards,
Shebu
From: TF-M <tf-m-bounces@lists.trustedfirmware.org>
On Behalf Of Li, Jun R via TF-M
Sent: Wednesday, December 15, 2021 6:48 AM
To: Kevin Townsend (kevin.townsend@linaro.org) <kevin.townsend@linaro.org>
Cc: tf-m@lists.trustedfirmware.org
Subject: Re: [TF-M] Any existing efforts on enabling X.509 certificate support inside TF-M
Hi Kevin,
Thanks for the reference! Actually, that is the example we are referring to. However, our custom SP manages a biometric sensor module which sends the X.509 certificate to the SP and the certificate needs to be verified by SP only. The
related keypairs inside SP are generated inside and the key handles can’t be used by NS even though we can use opaque key way to do signing/verification on NS. I’m thinking a possible approach is to separate the X.509 parser and hashing algorithm from signing
and signature verification. So, the parsing and hashing can be done by NS and the signature can be verified inside TF-M if we can’t enable X.509 parser inside TF-M, though there will be several forward and backward round trips between NS and TF-M. Not sure
if this approach is doable since it seems mbedTLS’s X.509 has tight coupling on parsing and signing/verifying.
I agree moving the X.509 support into TF-M would increase TF-M’s image size very much. However, if it is not avoidable to enable X.509, it will add the size increment onto either NS or TF-M.
Regards,
Jun
On 12/14/21, 22:27, "Kevin Townsend" <kevin.townsend@linaro.org> wrote:
Hi Jun,
There was some discussion of this a year or more back, but the decision was that this can be done safely on the NS side using the PSA Crypto API as is, and placing it on the secure side would increase the code size of the secure binary
more than necessary (pulling in required encoding functions from MbedTLS, etc.). Here is an example of how we generate a CSR on the NS side in Zephyr, generating the private key through the PSA Crypto API so that it is never exposed to the NS environment:
https://github.com/zephyrproject-rtos/zephyr/blob/main/samples/tfm_integration/psa_crypto/src/psa_crypto.c#L329
If you require all of this to exist in a secure partition, you'll have to make the appropriate config changes to MbedTLS yourself, but hopefully this code serves as a useful starting point.
Sample output:
[00:00:07.495,000] <inf> app: Adding subject name to CSR
[00:00:07.496,000] <inf> app: Adding subject name to CSR completed
[00:00:07.497,000] <inf> app: Adding EC key to PK container
[00:00:07.499,000] <inf> app: Adding EC key to PK container completed
[00:00:07.500,000] <inf> app: Create device Certificate Signing Request
[00:00:08.692,000] <inf> app: Create device Certificate Signing Request completed
[00:00:08.693,000] <inf> app: Certificate Signing Request: