AES-GCM IV Sizes failing with nRF54 and CRACEN Backend

RE: AES-GCM IV Sizes failing with nRF54 and CRACEN Backend

Einar Thorsrud — Thu, 08 May 2025 08:18:58 GMT

Thank you for sharing this. I have forwarded it internally and we will consider if and how we can incorporate this approach in the SDK future.

RE: AES-GCM IV Sizes failing with nRF54 and CRACEN Backend

Emil Lenngren — Wed, 07 May 2025 21:22:12 GMT

After some experimentation, I found out that it is indeed possible to perform AES-GCM encryption/decryption with CRACEN with any-sized IV. You just need to add extra DMA descriptors to perform that additional GHASH step in the beginning of the operation to calculate the correct J0 (initial counter), and then additionally make sure that J0 is used at the end when encrypting the tag in the final step.

I am attaching code that performs arbitrary AES-GCM encryption/decryption using the CRACEN peripheral directly (the existing CRACEN PSA library was to messy too modify for my test). If you want to use it together with nRF Connect SDK, you should probably wrap CRACEN usage between `cracen_acquire` + `nrf_security_mutex_lock(cracen_mutex_symmetric)` and `cracen_release` + `nrf_security_mutex_unlock(cracen_mutex_symmetric)` and remove my ENABLE register writes.

It would be nice to have code that uses this approach in the nRF Connect SDK, probably behind a Kconfig flag because implementations are recommended by the GCM standard to by default restrict IV size to 12 bytes, to promote interoperability.

devzone.nordicsemi.com/.../aes_2D00_gcm_2D00_cracen.c

RE: AES-GCM IV Sizes failing with nRF54 and CRACEN Backend

Einar Thorsrud — Tue, 28 Jan 2025 10:04:21 GMT

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).

RE: AES-GCM IV Sizes failing with nRF54 and CRACEN Backend

bvyates — Fri, 24 Jan 2025 20:09:21 GMT

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

RE: AES-GCM IV Sizes failing with nRF54 and CRACEN Backend

Einar Thorsrud — Fri, 24 Jan 2025 08:18:17 GMT

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?

RE: AES-GCM IV Sizes failing with nRF54 and CRACEN Backend

Emil Lenngren — Thu, 23 Jan 2025 16:30:26 GMT

[quote userid="98335" url="~/f/nordic-q-a/118102/aes-gcm-iv-sizes-failing-with-nrf54-and-cracen-backend/518898"]When we use the 64 bit IV that is required by the protocol we're adhering to[/quote]

What protocol are you using that requires 64-bit IVs? Everything less than 96-bit IV is in my opinion bad design since that requires an extra GHASH operation, which takes time. Padding the IV to 96 bits instead would result in the same security level at a lower performance cost.

RE: AES-GCM IV Sizes failing with nRF54 and CRACEN Backend

bvyates — Thu, 23 Jan 2025 16:23:00 GMT

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

RE: AES-GCM IV Sizes failing with nRF54 and CRACEN Backend

Einar Thorsrud — Tue, 21 Jan 2025 10:18:53 GMT

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.

RE: AES-GCM IV Sizes failing with nRF54 and CRACEN Backend

Emil Lenngren — Mon, 20 Jan 2025 15:52:39 GMT

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.

RE: AES-GCM IV Sizes failing with nRF54 and CRACEN Backend

Einar Thorsrud — Mon, 20 Jan 2025 15:20:16 GMT

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.

RE: AES-GCM IV Sizes failing with nRF54 and CRACEN Backend

bvyates — Fri, 17 Jan 2025 17:17:28 GMT

Hi Einar,

Thank you for the information. For my reference, is this the result of a hardware limitation on the MCUs that use the CRACEN backend or a software limitation that might be updated in a future release?

My understanding is that the extension (or reduction) of the IV to be 12 bytes is built in to the AES-GCM algorithm and is done using the GHASH primitive that is used elsewhere within it. When we use the 64 bit IV that is required by the protocol we're adhering to, all other systems we've encountered (including other Nordic offerings) use the AES-GCM standard mechanism of expanding the IV. Padding with 0s unfortunately then does seem to not produce the same result as any other system, and the encrypted material is invalid.

I believe that if we were able to GHASH our shorter IV separately in the application to produce a 12 byte value, and fed that value into the the aead function, then it would not be hashed again with the AES-GCM operation, and the IV used would be the same as on another system where the smaller IV was fed in and then hashed internal to AES-GCM. I do not see an obvious way to perform our own GHASH with any APIs within the SDK though, is there any existing access to this primitive?

If not it seems like we would have either bring in a different implementation of GHASH or not be able to use the CRACEN backend.

Please let me know if I'm missing something here or if there is a straightforward way for use to perform the GHASH operation ourselves.

Thank you,

Ben

RE: AES-GCM IV Sizes failing with nRF54 and CRACEN Backend

Einar Thorsrud — Fri, 17 Jan 2025 13:04:58 GMT

Hi Ben,

CRACEN only support a 96 bit (12 byte) IV. However, you can zero pad the IV to effecively use shorter, so to use a 64 bit one, you can pass a 12 byte array where 4 are set to 0 and pass that to psa_aead_encrypt().

Br,

Einar