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:
 
-----BEGIN CERTIFICATE REQUEST-----
MIHrMIGQAgEAMC4xDzANBgNVBAoMBkxpbmFybzEbMBkGA1UEAwwSRGV2aWNlIENl
cnRpZmljYXRlMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAENLcv1exBcbEE2b4c
5933xMCx6WTLRR/jSpVSqHWyjE3xy0/CJiyQyQWy5Ewq6Z0R3zUbDobVnKEf/Prt
IZq1KKAAMAwGCCqGSM49BAMCBQADSAAwRQIgaAlTPmrIaRO7myM2Qr+LNk9sagdO
jPGUqbz4oUWhUsICIQCuHADW6F2l4czv78BO5Nf+FHZEpjbI1+fA2aLzglOaiA==
-----END CERTIFICATE REQUEST-----

 

Regards,

Kevin

 

On Wed, 15 Dec 2021 at 07:16, Li, Jun R via TF-M <tf-m@lists.trustedfirmware.org> wrote:

Hi everyone,

 

I’m wondering if there is any existing effort on enabling X.509 CSR generation and certificate verification inside TF-M? Our project has some custom secure partitions which need to generate the CSR and verify the issued certificates by themselves. The current TF-M implementation hasn’t added X.509’s support. So, I’m wondering if any open source project already does that which we can leverage?

 

Regards,

Jun Li

Intel Corporation, CA

 

--
TF-M mailing list
TF-M@lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/tf-m