Attachments (0)
Nordic Case Info
  • Case ID: 342456
Options

Pushing keys from KMU to ECB?

SebastianA

Hi!

I'm storing a key in the KMU for use by the ECB.

If I set the slot's destination address to an address in RAM, the KMU pushes the key there correctly, but if I instead set the destination address to &NRF_ECU00->KEY.VALUE[0], I can't push the key.

I run this code to push they key:

I run this code in a mpsl timeslot handler.

I can write to the NRF_ECB00->KEY.VALUE[0] key registers there with the CPU.

Is there something more I have to do to be able to push they key directly to the ECB's KEY registers from the KMU?

Parents
  • 0

    Hi SebastianA,

    Let me look into this and follow up with you in 2-3 workdays.

    Hieu

  • 0 in reply to Hieu

    Sure!

    Btw I tried to push the key to CRACEN, that worked fine, probably. I didn't try to actually use the key, but got the PUSHED event. Pushing it to CCM fails in the same way as to ECB.

    We need AES in a timeslot so ECB seems much better for us than CRACEN so we don't compete with thread code for its usage.

  • 0 in reply to SebastianA

    Understood. On my end, I have to start an internal inquiry, and it seems this will take more time than I thought because the relevant contact point is unavailable now.
    Please rest assure that I will still keep you updated.

  • 0 in reply to Hieu

    Hi SebastianA,

    We unfortunately don't have a definite answer yet, but we are looking into it.

    We need one more piece of information. What is your speed/time requirement for loading the key from KMU to ECB/CCM? I.e., how long, at most, can it take to complete?

    An alternative was discussed, that is to load the key to RAM and then write it to ECB/CCM as you need it. I think you already thought of it too. There is one concern though, are you using TF-M? As a key is loaded to RAM, preferably it is do so with isolation.

Reply
  • 0 in reply to Hieu

    Hi SebastianA,

    We unfortunately don't have a definite answer yet, but we are looking into it.

    We need one more piece of information. What is your speed/time requirement for loading the key from KMU to ECB/CCM? I.e., how long, at most, can it take to complete?

    An alternative was discussed, that is to load the key to RAM and then write it to ECB/CCM as you need it. I think you already thought of it too. There is one concern though, are you using TF-M? As a key is loaded to RAM, preferably it is do so with isolation.

Children
  • 0 in reply to Hieu

    Yes, putting the key in ram is our fallback option. No applications are built yet so we could possibly use TF-M, but we are making a library for our customers to use so we want to have as little limitations on their possible architectures as possible though.

    I don't have the exact numbers for everything now, but we receive a full ble frame packet, then decrypt it (with aes), encrypt an ack (<=64 bytes, with aes) and that ack should be sent 6450us after the start of receiving the packet. Both crypto operations use the same key here, but we might do two decryption attempts with different keys for the start of the received packet.

    I guess this leaves ~4ms for encryption/decryption of the two packets.

  • 0 in reply to SebastianA

    I just got the information that due to hardware limitation, pushing keys directly from KMU to ECB or CCM isn't possible with the nRF54L15. I'm sorry for the bad news.

    I thought you were interleaving multiple protocols here, but do I understand right that you want to encrypt BLE packets? Is native BLE encryption insufficient for some of your use cases?

    Regarding whether to include TF-M or not, I recommend considering it. Cyber security regulations are getting stricter; think of the EU's Cybersecurity Resilience Act, for example.

    As for the time window, I think 4ms is a lot. I just picked the first AES sample available, Crypto: AES CCM, tested with the nRF54L15, and the process completed in under 2ms. Here is the log with timestamps:

Terms of service