Enabling CONFIG_PSA_CRYPTO_DRIVER_CC3XX causes incorrect tag when using AES-GCM

[Diego]

Hello,

Our devices utilize AES-GCM to establish a secure channel with our servers. The system works as expected without any issues when CONFIG_PSA_CRYPTO_DRIVER_CC3XX is disabled, but as soon as we enable that flag to take advantage of the cyrptocell in nRF5340, we're seeing an incorrect tag generated by the psa_aead_encrypt function. We're using a 256 bit key and we have already validated that the output from the software implementation (CONFIG_PSA_CRYPTO_DRIVER_CC3XX=n) is correct, by running the same data, nonce and key through a Python script that performs the encryption and prints the tag bytes. The encrypted data itself is consistent across both implementations, it's just the MAC that differs.

Why would cryptocell generate a different tag? Is there another step we're missing that it's required to utilize the cyrpto hardware accelerator, or any limitations we're not aware? Given the cc3xx_ library is statically linked it's hard to debug.

Thanks,

Diego

[dejans]

Hi,

Which NCS version do you use?

Which crypto library do you use?

Could you provide your project configuration file?

Best regards,
Dejan

[Diego]

Hi Dejan

NCS version 2.3.0

We're using the mbed psa crypto libray with calls like psa_aead_encrypt

Here's the relevant Kconfig flags in our project 

CONFIG_NRF_SECURITY=y
CONFIG_MBEDTLS_PSA_CRYPTO_C=y
CONFIG_MBEDTLS_ENABLE_HEAP=y
CONFIG_MBEDTLS_HEAP_SIZE=8192
CONFIG_MBEDTLS_PSA_CRYPTO_STORAGE_C=y
CONFIG_PSA_NATIVE_ITS=y
CONFIG_BASE64=y
CONFIG_PSA_CRYPTO_DRIVER_OBERON=n
CONFIG_PSA_CRYPTO_DRIVER_CC3XX=y

I don't have access to a devkit this week but I can try to reproduce with one of the samples next.

Please let me know if you have any other questions.

Thanks,
Diego

[dejans]

Hi Diego,

This issue might be related to the nonce length. You should ensure that you use nonce of size 12 bytes. If you want to use nonce value other than 12 bytes you would need to use software for that (nrf_oberon).

Best regards,
Dejan

[Diego]

Hi Dejan,

Yes, that seems to be the issue. Using 12 bytes produces a consistent MAC across both. A couple of followup questions/notes:

1. Is this an actual limitation with the hardware in the CryptoCell or with the driver for it provided by Nordic?

2. In my opinion this is a bug since the nonce size is for the user to define as stated in section 8.2 here https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-38d.pdf. As long as it's unique, the size doesn’t matter. Why would this be a limitation with CyrpoCell?

3. At a minimum I would expect the driver to return an error such as PSA_ERROR_NOT_SUPPORTED if the nonce is not 12. With the current implementation there's no indication that something went wrong until you're testing against another valid implementation.

Thanks,

Diego

[dejans]

Hi Diego,

Diego said:

1. Is this an actual limitation with the hardware in the CryptoCell or with the driver for it provided by Nordic?

The limitation comes from CryptoCell low-level driver. We are investigating if the source of this limitation is in hardware or software. 

Diego said:

2. In my opinion this is a bug since the nonce size is for the user to define as stated in section 8.2 here https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-38d.pdf. As long as it's unique, the size doesn’t matter. Why would this be a limitation with CyrpoCell?

NIST special publication for GCM mentions the following "For IVs, it is recommended that implementations restrict support to the length of 96 bits, to promote interoperability, efficiency, and simplicity of design.".  PSA Crypto API Specification mentions "GCM requires a nonce of at least 1 byte in length. The maximum supported nonce size is IMPLEMENTATION DEFINED. Calling psa_aead_generate_nonce() will generate a random 12-byte nonce.". For CryptoCell the size of the nonce is hard-coded to 12 bytes (96 bits). 

Diego said:

3. At a minimum I would expect the driver to return an error such as PSA_ERROR_NOT_SUPPORTED if the nonce is not 12. With the current implementation there's no indication that something went wrong until you're testing against another valid implementation.

Returning error code will be fixed in the updated version of the CryptoCell runtime library.

Best regards,
Dejan