This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

MICSTATUS is not set to 1 when decrypting packet

Hello Nordic team,

I am developing a proprietary radio protocol and i am using aes ccm peripheral for encryption (i am a begginer). The packets seem to be correctly encrypted ( the error event is not trigged while the endskgen and endcrypt event are trigged). I clear all events before start key generation task.

When i try to decrypt the packet i am using the same initialization vector and the same aes key than for encryption and i reset counter values to 0 in memory area pointed by CNFPTR. I do the same thing for encryption : before each encryption i reset the aes key value, initialization vector value and counters.

The decryption operation seems to work correctly (the mic is removed from payload) length field is updated (by substracting 4 to its value) and the decrypted payload is exactely the same than the unencrypted payload given to encryption as an input.

The length field seems to be good (corresponding to payload length) and its size is 8 bits (so i set the length bit of mode register to 1) because i'm not using S1 field (i include it in RAM).

The encrypted Payload in input of decryption is exactely the same than payload at output of encryption and buffers are separated.

At the output of encryption length field is correctly updated (by adding 4 to its value) and 4 bytes (the MIC) are appended to encrypted payload.

I try also to set length field to 0 (empty payload) so the mic check should always pass, but it doesn't and i have no idea why.

I see also data is written to scratch pointer very far after the recommended scratchpointer size (My packet is 13 bytes long but data is written 258 bytes after scratchpointer start address) and to the CNFPOINTER very far after the Initialization vector field address (the documentation specifies the Initialization vector is 8 bytes long but the memory is written 143 bytes after cnfpointer start address). Do i make a mistake during configuration?

Can you help me? Kevin

ps: I am using softdevice S132 v2.0 and i use radio and ccm through timeslot API. I'm using ppi channels to trig SW interrupt in the order to catch and clear the CCM events (the softdevice seems to not forward ccm interrupts ... only radio and timer 0 are forwarded through the handler function given in session_open function).

Parents
  • OK i found the problem: the buffer pointed by scratch pointer was placed in memory just before the buffer pointed by cnfpointer. So the data pointed by cnfpointer was overwritten by ccm peripheral! In my case data is written on 267 bytes after the scratchpointer start address (value stored in SCRATCHPTR register of CCM peripheral) . So if you use ccm peripheral and have the same problem you should try to reserve a big memory area for scratchpointer (>300 bytes). Ps : thanks you for your answer Roger!

Reply
  • OK i found the problem: the buffer pointed by scratch pointer was placed in memory just before the buffer pointed by cnfpointer. So the data pointed by cnfpointer was overwritten by ccm peripheral! In my case data is written on 267 bytes after the scratchpointer start address (value stored in SCRATCHPTR register of CCM peripheral) . So if you use ccm peripheral and have the same problem you should try to reserve a big memory area for scratchpointer (>300 bytes). Ps : thanks you for your answer Roger!

Children
Related