AES-GCM IV Sizes failing with nRF54 and CRACEN Backend

[bvyates]

Hello,

We have an application that uses AES-GCM for AEAD with a 128-bit key and an 64 bit initialization vector (IV). Using the psa_aead_encrypt API seems to work well for us on the nRF52840 where I believe we are using the Oberon backend currently. However, when using the same code on an nRF54L15, the psa_aead_encrypt function is returning an error, -134, PSA_ERROR_NOT_SUPPORTED. From the PSA documentation I saw that a possible cause of this error was an unsupported IV length. As the default AES-GCM length is 96 bits, I tried adjusting our length to match that, and found that the encryption succeeded.

It seems then that the IV length of 64 bits is causing the psa_aead_function to fail on the nRF54L15. I did also try 88 and 104 bit IVs as well and got the same error. It is my understanding that 96 bits is the recommended and default IV length for AES-GCM, but that other lengths should be supported. As I mention, the 64 bit length works for us on the nRF52 with the Connect SDK, and that length also for on the 52 with the nRF5 SDK.

I'm not entirely clear which module would be causing this failure, but I am looking to know if support for other IV lengths is expected to work at this time or if support is expected to be added in the future. As far as I can tell from the generated configs, we are using the CRACEN security backend. My understanding is that we could use Oberon on the nRF54, which may be a workaround for us, but I was surprised to encounter this different limitation on the CRACEN backend.

Thank you,

Ben

[Einar Thorsrud]

Hi Ben,

My understanding is that implementations that support less than 96 bit / 12 byte IV does zero padding under the hood. Did you padd the wrong "end" of the array? I have forwarded the request for supporting IV length othar than 96 bit, but it is currently not supported and I cannot say when it will be.

[Emil Lenngren]

No, non-96-bit IV are handled differently:

https://wikimedia.org/api/rest_v1/media/math/render/svg/623cf4e63a38c4555d651bf235473ca894c8604a

See https://en.wikipedia.org/wiki/Galois/Counter_Mode under Mathematical basis, the assignment of Counter0.

For this to work, the implementation must support it. The user cannot simply pad the IV to 96 bits.

[Einar Thorsrud]

Hi,

I was not aware of that. We are looking into if/how we can support other IV lengths, but for now that meanst that you cannot use HW crypto acceleration with an IV different from 96 bits on nRF54L.

[bvyates]

Hello,

Since CRACEN will not work for our application's use of AES-GCM at this time, I have used the following workaround. Enabling both the CRACEN and Oberon backends, and disabling the CRACEN AEAD component specifically got everything working.

CONFIG_PSA_CRYPTO_DRIVER_CRACEN=y
CONFIG_PSA_CRYPTO_DRIVER_OBERON=y
CONFIG_PSA_USE_CRACEN_AEAD_DRIVER=n

I originally tried to disable CRACEN and enable only Oberon, but I was running into an error with EC key generation failing elsewhere in our application. I was not expecting this since the Oberon backend is working fine with the same application on an nRF52 based board. The symptom was similar to these other DevZone posts [1], [2], but none of the config option changes recommended there resolved my issue. Enabling both backends got all of our crypto operations working.

So our application is all working at this point with the workaround of using both backends. As development continues, we would certainly like to consolidate down to using one backend, ideally CRACEN to make use of the hardware-acceleration.

Please let me know if is possible that a future update NCS version could include a change that would support non-default IVs on CRACEN. If it is not possible due to the hardware implementation, or just unlikely to be pursued, we will look at only using Oberon.

Thanks,

Ben

[Einar Thorsrud]

Hi Ben,

There is a hardware limitation that prevents non-standard IV lengths in nRF54L15. But we are looking into this and wonder if you can share a bit about your use-case and why your application need a 64 bit IV?

[bvyates]

Hey Einar,

This is just an internally defined protocol that we implemented several years ago. It could be changed to use a 96 bit IV, or to use 0 padding to get to 96 bits instead of feeding the smaller IV into AES-GCM directly. That change would just require updating code on a good number of fielded devices, so the cost of just using Oberon is probably less for us than making the change on all the other systems to accommodate this limitation of CRACEN at least for the time being.

We had originally chosen 64 bits just to save a few bytes in a size-constrained communication environment. The additional time of AES-GCM running a hash to increase the IV size is inconsequential to us. We send few enough messages before key rotation such that reuse of a random IV even at the smaller size is sufficiently unlikely. We could have done the 0 padding prior to feeding in the IV as mentioned above, but it did not occur to anyone at the time that security stacks would not have support for other IV sizes.

Thanks

[Einar Thorsrud]

Hi Ben,

I see, thank you for sharing the background. It will not be possible to support IV different than 96 bit in CRACEN, and we plan to update the documentation to make that clear. So the alternatives are to either use Oberon as you do now or modify/update your protocol. (Note that Oberon on the nRF54L is not fully supported, so there will be some limitations such as not being able to use HW protected keys).