psa_cipher_encrypt returns -135 INVALID_ARGUMENT when running with TF-M

[Anthony Ambuehl]

Hi I am working on a security focused project.  I have written some functions that perform AES-128 cipher encryption using PSA_ALG_CBC_NO_PADDING and a key with a persistent lifetime PSA_KEY_LIFETIME_PERSISTENT.  I developed and tested the functions initially without TF-M and they worked as expected.  Now I am switching to using the TF-M environment with PSA_CRYPT in a secure partition.

The issue that I'm having is that I get an PSA_ERROR_INVALID_ARGUMENT (-135) when I call psa_cipher_encrypt.

I was able to trace the code down through submitting the IPC call and also after it has reached tfm_crypto_sfn.

I was also able to confirm it reached  nrfxlib/nrf_security/src/psa_crypto_drivers_wrapper  psa_driver_wrapper_cipher_encrypt(...) but from there I was unable to trace it any further.  While debugging it appeared to reach line 897 where it would call cc3xx_cipher_encrypt but VS Code cannot find the source for this function.

I should note, I am calling the psa_cipher_encrypt from a secure partition, though I suspect the problem would be same if I call from the non-secure partition as well.

I have attached the zephyr/.config file (as example.config)

example.config

I suspect there is a mis-configuration that is selecting the OBERON driver instead of the nrf_cc3xx driver, but I'm not sure how/why that is occurring.

Any recommendations on how to track down the issue?

Why does VSCode get lost when it tries to enter cc3xx_cipher_encrypt?

[Sigurd Hellesvik]

Hi,

Which version of the nRF Connect SDK do you use?

If you are not using v2.4.0, I can recommend this.
As you can read in v2.4.0 release notes, we changed the crypto drivers for TF-M to Oberon drivers here (not backend but for crypto).
And I have been told that Oberon should (hopefully) be easier to debug than the previous solution.

Regards,
Sigurd Hellesvik

[Anthony Ambuehl]

I am currently developing with v2.3.0 but an update to 2.4.0 is planned.

Do you have any information about problems in 2.3.0 that might be relevant?  

Is it possible there is some sort of mis-configuration that is not detected as an error?

[Sigurd Hellesvik]

Anthony Ambuehl said:

Do you have any information about problems in 2.3.0 that might be relevant?  

The crypto driver has changed, so I do not think there are problems per say in the v2.3.0. v2.4.0 is just more optimized and different to work with. So it is not easy to point at specifics.

Anthony Ambuehl said:

Is it possible there is some sort of mis-configuration that is not detected as an error?

Yes, but I do not think that is it exactly. See where I go on from here.

So I thought: "I should be able to do the same as Anthony with the nrf/samples/crypto/aes_cbc"
Then when I tell it to save the key persistently, I get the same error as you: -135.

After some looking around, I found that nrf/samples/crypto/persistent_key_usage shows how I can use persistent keys, so I decide to copy what i think is relevant from this sample, and tada, it worked.
My guess is that you forgot one of these steps:

diff --git a/samples/crypto/aes_cbc/prj.conf b/samples/crypto/aes_cbc/prj.conf
index 2db6b4896..a4f11b049 100644
--- a/samples/crypto/aes_cbc/prj.conf
+++ b/samples/crypto/aes_cbc/prj.conf
@@ -14,3 +14,7 @@ CONFIG_MBEDTLS_PSA_CRYPTO_C=y
 
 CONFIG_MBEDTLS_ENABLE_HEAP=y
 CONFIG_MBEDTLS_HEAP_SIZE=8192
+
+# Enable persistent storage APIs
+CONFIG_MBEDTLS_PSA_CRYPTO_STORAGE_C=y
+CONFIG_PSA_NATIVE_ITS=y
diff --git a/samples/crypto/aes_cbc/src/main.c b/samples/crypto/aes_cbc/src/main.c
index 8748b1167..b0518941e 100644
--- a/samples/crypto/aes_cbc/src/main.c
+++ b/samples/crypto/aes_cbc/src/main.c
@@ -84,7 +84,8 @@ int generate_key(void)
        psa_key_attributes_t key_attributes = PSA_KEY_ATTRIBUTES_INIT;
 
        psa_set_key_usage_flags(&key_attributes, PSA_KEY_USAGE_ENCRYPT | PSA_KEY_USAGE_DECRYPT);
-       psa_set_key_lifetime(&key_attributes, PSA_KEY_LIFETIME_VOLATILE);
+       psa_set_key_lifetime(&key_attributes, PSA_KEY_LIFETIME_PERSISTENT);
+       psa_set_key_id(&key_attributes, 132);
        psa_set_key_algorithm(&key_attributes, PSA_ALG_CBC_NO_PADDING);
        psa_set_key_type(&key_attributes, PSA_KEY_TYPE_AES);
        psa_set_key_bits(&key_attributes, 128);

the key id is up to you, I just chose 132 as a random number.

Regards,
Sigurd Hellesvik

[Anthony Ambuehl]

What does CONFIG_PSA_NATIVE_ITS do ?  It has no description in KConfig.

[Anthony Ambuehl]

CONFIG_PSA_NATIVE_ITS is only for builds without TFM. 

warning: PSA_NATIVE_ITS (defined at D:/Bmmpr/v2.3.0/nrfxlib\nrf_security\Kconfig.psa:88) was
assigned the value 'y' but got the value 'n'. Check these unsatisfied dependencies:
(!BUILD_WITH_TFM) (=n). See docs.zephyrproject.org/.../kconfig.html
and/or look up PSA_NATIVE_ITS in the menuconfig/guiconfig interface. The Application Development
Primer, Setting Configuration Values, and Kconfig - Tips and Best Practices sections of the manual
might be helpful too.

As I said in my initial post, this was working without TFM but it started failing when I switched to building with TFM.

Did you test with nrf5340dk_nrf5340_cpuapp_ns ?

Also a bit more information, I import the key from a previously exported volatile key.  I did all the attribute configuration from the persistent_key_usage example first and then import the key as the final step.  This is exactly the same way it was working without TFM.

[Anthony Ambuehl]

I found the root-cause of the issue.  I setup the key to use PSA_ALG_CBC_NO_PADDING but I passed in a data input that was not a multiple of the cipher block size.    When I found it was working without TF-M it was actually because my test input was 16-bytes.