AES-GCM IV Sizes failing with nRF54 and CRACEN Backend

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

Parents
  • 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

  • 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

  • When we use the 64 bit IV that is required by the protocol we're adhering to

    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.

Reply Children
No Data
Related