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:

    if (nrf_kmu_status_get(NRF_KMU) != NRF_KMU_STATUS_READY) {
        printf("ERROR: KMU not ready\n");
        return;
    }
    nrf_kmu_keyslot_set(NRF_KMU, slot_id);

    nrf_kmu_event_clear(NRF_KMU, NRF_KMU_EVENT_KEYSLOT_PUSHED);
    nrf_kmu_task_trigger(NRF_KMU, NRF_KMU_TASK_PUSH_KEYSLOT);
    while (nrf_kmu_status_get(NRF_KMU) == NRF_KMU_STATUS_BUSY) {
        /* Busy wait */
    }

    if (!nrf_kmu_event_check(NRF_KMU, NRF_KMU_EVENT_KEYSLOT_PUSHED)) {
        printf("Failed to push key\n");
        return;
    }

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?

[Hieu]

Hi SebastianA,

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

Hieu

[SebastianA]

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.

[Hieu]

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.

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

[SebastianA]

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.

[Hieu]

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:

*** Booting nRF Connect SDK v2.9.1-60d0d6c8d42d ***
*** Using Zephyr OS v3.7.99-ca954a6216c9 ***
[00:00:00.425,943] <inf> aes_cbc: Starting AES-CBC-NO-PADDING example...
[00:00:00.425,948] <inf> aes_cbc: Generating random AES key...
[00:00:00.426,097] <inf> aes_cbc: AES key generated successfully!
[00:00:00.426,103] <inf> aes_cbc: Encrypting using AES CBC MODE...
[00:00:00.426,515] <inf> aes_cbc: Encryption successful!
[00:00:00.426,532] <inf> aes_cbc: ---- IV (len: 16): ----
[00:00:00.426,542] <inf> aes_cbc: Content:
                                  f3 27 c4 66 2e 4c db fb  6a ae 1d 4e e8 53 7d c4 |.'.f.L.. j..N.S}.
[00:00:00.426,553] <inf> aes_cbc: ---- IV end  ----
[00:00:00.426,564] <inf> aes_cbc: ---- Plaintext (len: 64): ----
[00:00:00.426,577] <inf> aes_cbc: Content:
                                  45 78 61 6d 70 6c 65 20  73 74 72 69 6e 67 20 74 |Example  string t
                                  6f 20 64 65 6d 6f 6e 73  74 72 61 74 65 20 62 61 |o demons trate ba
                                  73 69 63 20 75 73 61 67  65 20 6f 66 20 41 45 53 |sic usag e of AES
                                  20 43 42 43 20 6d 6f 64  65 2e 00 00 00 00 00 00 | CBC mod e.......
[00:00:00.426,588] <inf> aes_cbc: ---- Plaintext end  ----
[00:00:00.426,599] <inf> aes_cbc: ---- Encrypted text (len: 64): ----
[00:00:00.426,612] <inf> aes_cbc: Content:
                                  c3 8f c1 10 e0 30 20 ec  5b 81 9a 1f d0 aa b7 d9 |.....0 . [.......
                                  be b5 ec fb 4a e2 56 15  b2 d0 f7 3b 32 ce e2 be |....J.V. ...;2...
                                  c2 b5 5e 30 13 34 bb f1  53 39 61 0e ad 03 7d f8 |..^0.4.. S9a...}.
                                  92 23 08 b3 bb b7 8d 4f  4a 65 0a be 8a 42 da a9 |.#.....O Je...B..
[00:00:00.426,623] <inf> aes_cbc: ---- Encrypted text end  ----
[00:00:00.426,691] <inf> aes_cbc: Decrypting using AES CBC MODE...
[00:00:00.427,064] <inf> aes_cbc: ---- Decrypted text (len: 64): ----
[00:00:00.427,079] <inf> aes_cbc: Content:
                                  45 78 61 6d 70 6c 65 20  73 74 72 69 6e 67 20 74 |Example  string t
                                  6f 20 64 65 6d 6f 6e 73  74 72 61 74 65 20 62 61 |o demons trate ba
                                  73 69 63 20 75 73 61 67  65 20 6f 66 20 41 45 53 |sic usag e of AES
                                  20 43 42 43 20 6d 6f 64  65 2e 00 00 00 00 00 00 | CBC mod e.......
[00:00:00.427,090] <inf> aes_cbc: ---- Decrypted text end  ----
[00:00:00.427,101] <inf> aes_cbc: Decryption successful!
[00:00:00.427,226] <inf> aes_cbc: Example finished successfully!