CONFIG_NORDIC_SECURITY_BACKEND causes psa_crypto failures

[BHeise]

Hi, we encountered a problem with nRF_Connect SDK v2.2.0 that is not a problem with SDK v2.1.0.

We have a project running on the nRF5340 that requires using shared secrets as in the sample project v2.2.0/nrf/samples/crypto/ecdh, however, we are using the function psa_import_key() to import 32-byte (256-bit) keys in binary format. 

Our project also requires X.509 certificates signed by a 384-bit key.  We are using mbedtls_x509_crt_parse_der_nocopy() to parse the certificates and mbedtls_ecdsa_read_signature() verify the certificate signature.  A sample certificate of the signing key is below. 

It seems that CONFIG_NORDIC_SECURITY_BACKEND=y and CONFIG_MBEDTLS_ECP_DP_SECP384R1_ENABLED=y are required to get 384-bit signature verification working on X.509 certificates.  However, CONFIG_NORDIC_SECURITY_BACKEND=y causes psa_import_key() to return a status of -135.  This issue is easily replicated by adding CONFIG_NORDIC_SECURITY_BACKEND=y to the v2.2.0/nrf/samples/crypto/ecdh sample project.  It results in the psa_crypto functions returning errors.  Is there a way to get both 384-bit signature verification of X.509 certificates and the psa_crypto functions working with nRF_Connect SDK v2.2.0?

Thanks,

-Bob

 

 

Certificate:

    Data:

        Version: 3 (0x2)

        Serial Number:

            3e:39:ce:5f:ae:50:26:23:91:1a:9c:b8:82:cd:23:9c:42:f0:3c:f9

        Signature Algorithm: ecdsa-with-SHA384

        Issuer: C = CA, ST = Alberta, L = Calgary, O = RMED, OU = Engineering, CN = Kornelius.com, emailAddress = [email protected]

        Validity

            Not Before: Oct 13 17:57:03 2022 GMT

            Not After : Oct 13 17:57:03 2032 GMT

        Subject: C = CA, ST = Alberta, L = Calgary, O = RMED, OU = Engineering, CN = Kornelius.com, emailAddress = [email protected]

        Subject Public Key Info:

            Public Key Algorithm: id-ecPublicKey

                Public-Key: (384 bit)

                pub:

                    04:86:a2:3b:4e:1d:e3:d8:a0:59:c4:cd:46:9e:3c:

                    dc:b7:92:c4:d5:9a:59:b2:b9:28:0e:e2:2b:c4:b7:

                    7b:90:c4:3a:2f:97:93:48:38:2c:87:d9:29:14:7c:

                    a6:8f:9f:61:bc:a4:e8:6e:2b:f0:33:16:f6:6b:83:

                    98:6b:da:45:d3:1e:6c:15:8d:6c:70:ac:2f:09:14:

                    fc:27:ef:8b:b6:26:54:38:48:31:27:b7:1a:33:a7:

                    2d:99:de:18:cd:84:02

                ASN1 OID: secp384r1

                NIST CURVE: P-384

        X509v3 extensions:

            X509v3 Subject Key Identifier:

                11:3D:68:5A:7A:1B:EA:A3:C3:E4:5B:68:F0:D4:6B:82:A7:D3:B5:1D

            X509v3 Authority Key Identifier:

                keyid:11:3D:68:5A:7A:1B:EA:A3:C3:E4:5B:68:F0:D4:6B:82:A7:D3:B5:1D

 

            X509v3 Basic Constraints: critical

                CA:TRUE

    Signature Algorithm: ecdsa-with-SHA384

         30:65:02:31:00:aa:4b:5c:be:f9:9b:af:b3:e2:de:5a:70:19:

         5d:96:68:61:6d:6b:04:80:1d:c9:b8:1d:a5:da:cf:3c:dc:84:

         2c:06:5c:7a:b9:40:64:e6:f5:91:f0:d3:1f:74:ae:d7:68:02:

         30:5a:37:db:a1:4d:0a:b2:fb:0f:73:f3:95:41:e4:7c:83:0b:

         0b:3e:7c:73:c7:00:67:f3:fd:0b:7d:44:ee:b4:75:0a:69:9f:

         99:24:d5:41:ce:cb:9c:78:41:87:ed:cf:0d

[Vidar Berg]

Hello,

I forwarded your question to our developers as I could not find any relevant changes between v2.1.0 and v2.2.0 to explain this. I will update the ticket as soon as I know more.

Best regards,

Vidar

[Vidar Berg]

Update: one of the developers suggested that you add CONFIG_MBEDTLS_X509_LIBRARY=y and CONFIG_MBEDTLS_TLS_LIBRARY=y to your project as this should allow you to build without the CONFIG_NORDIC_SECURITY_BACKEND setting enabled. Hope this helps.

[BHeise]

Hi Sigurd,

To answer your question, I mean that the psa_crypto functions in the ecdh sample project return errors.  384-bit keys are required in our custom project, but I was hoping that you could observe the problem with a much simpler project such as the ecdh sample project with very few modifications.  When I add only one line to the ecdh sample project (That being CONFIG_NORDIC_SECURITY_BACKEND=y to prj.conf) I see the following in the log:

00> [00:00:00.448,333] <inf> ecdh: Starting ECDH example...
00> [00:00:00.448,364] <inf> ecdh: Creating ECDH key pair for Alice
00> [00:00:00.463,928] <inf> ecdh: ECDH keypair created successfully!
00> [00:00:00.463,958] <inf> ecdh: Creating ECDH key pair for Bob
00> [00:00:00.479,003] <inf> ecdh: ECDH keypair created successfully!
00> [00:00:00.479,034] <inf> ecdh: Export Alice's public key
00> [00:00:00.479,034] <inf> ecdh: psa_export_public_key failed! (Error: -135)
00> [00:00:00.479,064] <inf> ecdh: Example exited with error!

If you are not able to reproduce this error, then perhaps it has something to do with my PC.  I will plan to try this on another PC and let you know how that goes.

Regards, -Bob

[BHeise]

Hi Sigurd,

A colleague tested this issue with another PC and observed the same failure as me.

ecdh: psa_export_public_key failed! (Error: -135)

We are both running Windows 10. 

Regards, -Bob

[Sigurd Hellesvik]

Hi Bob,

I asked 2 colleguas to test this as well, and it works for all of us.
Just to make sure that we are on the same page:

I asked them to try the following:

Sample: crypto/ecdh

Board: nrf5340dk_nrf5340_cpuapp_ns

Add config to prj.conf: CONFIG_NORDIC_SECURITY_BACKEND=y

nRF Connect SDK: v2.2.0

Is this this correct?

Do you have debugging options enabled?

My colleagues both run Windows 10.

Regards,
Sigurd Hellesvik

[BHeise]

When I use nrf5340dk_nrf5340_cpuapp_ns the ecdh project with CONFIG_NORDIC_SECURITY_BACKEND=y works! 

I have never used nrf5340dk_nrf5340_cpuapp_ns before.  Up until now I have only ever used nrf5340dk_nrf5340_cpuapp because I thought that secure trumps non-secure.  Maybe not in this case?

00> [00:00:00.427,246] <inf> ecdh: Starting ECDH example...
00> [00:00:00.427,276] <inf> ecdh: Creating ECDH key pair for Alice
00> [00:00:00.502,655] <inf> ecdh: ECDH keypair created successfully!
00> [00:00:00.502,685] <inf> ecdh: Creating ECDH key pair for Bob
00> [00:00:00.517,425] <inf> ecdh: ECDH keypair created successfully!
00> [00:00:00.517,425] <inf> ecdh: Export Alice's public key
00> [00:00:00.531,951] <inf> ecdh: ECDH public key exported successfully!
00> [00:00:00.531,951] <inf> ecdh: Export Bob's public key
00> [00:00:00.546,325] <inf> ecdh: ECDH public key exported successfully!
00> [00:00:00.546,325] <inf> ecdh: Calculating the secret value for Alice
00> [00:00:00.573,577] <inf> ecdh: ECDH secret calculated successfully!
00> [00:00:00.573,577] <inf> ecdh: Calculating the secret value for Bob
00> [00:00:00.600,646] <inf> ecdh: ECDH secret calculated successfully!
00> [00:00:00.600,677] <inf> ecdh: Comparing the secret values of Alice and Bob
00> [00:00:00.600,677] <inf> ecdh: The secret values of Alice and Bob match!
00> [00:00:00.600,921] <inf> ecdh: Example finished successfully!

[Sigurd Hellesvik]

Hi Bob,

It is indeed the opposite way

Non-secure is more secure than secure.

This can be a bit confusing, and you are not the first one mixing this.
If you want to learn more about this, I recommend that you read  An Introduction to Trusted Firmware-M (TF-M)

Regards,
Sigurd Hellesvik

[BHeise]

Thank you.  I will switch to nrf5340dk_nrf5340_cpuapp_ns.

-Bob