CCM failed at MICSTATUS check

RE: CCM failed at MICSTATUS check

Emil Lenngren — Tue, 30 Aug 2022 22:22:52 GMT

Some debugging tips:

1. Try to figure out if it's the encrypting + tag calculation that produces an incorrect result or if it is the decryption + tag validation that is incorrect. You can do that by skipping decryption when you receive the packet, and then decrypt and verify the tag manually with a generic AES-CCM library. If the result is correct, then it's the receiving part that fails.

2. The CCM module is built for BLE, which assumes LFLEN+S1LEN=8. If you set this to something else, it might affect the radio timing for when the CCM module starts to read each byte from RAM. My recommendation is to move "packetId" to the payload part instead, setting S1LEN to 0. As a bonus, packetId will then also be encrypted and authenticated. One thing that concerns me though is how you will be able to supply a unique and correct IV if you use real-time decryption. I assume your protocol can receive from any sender and you have unique keys or IV per sender, but that would be incompatible with on-the-fly-decryption since you need to set the key and IV before the packet is received.

3. Make sure the ccmScratchArea is big enough (16 + MAXPACKETSIZE). And generally make sure all other buffers are big enough. Your code posted does not show how big your buffers are.

4. When you test with CRC=0, make sure to wait for EVENTS_ENDCRYPT before you read MICSTATUS, since it's not documented how long time it takes for the CCM module to complete after the final MIC bit has been received.

5. Test to start decryption when the radio packet has been fully received, instead of on-the-fly. You can try the same with encryption also; don't send the packet until the encryption is complete. That will let you test and verify the correctness of the CCM module irrespective of radio settings. If you get a different result after enabling on-the-fly encryption/decryption, then some timings are incorrect.

6. Test with the BLE 1 MBit/s setting and in general apply the same radio settings as BLE uses, since we all know that the CCM module works correctly in this mode.

RE: CCM failed at MICSTATUS check

Kenneth — Tue, 30 Aug 2022 10:53:20 GMT

One thing I notice, from your code I can find that:

// Enable PPI channel between EVENTS_ADDRESS and TASKS_CRYPT
NRF_PPI->CHENSET = (PPI_CHENSET_CH25_Set << PPI_CHENSET_CH25_Pos);

However looking at the zephyr implementation I can find they are doing this differently (they don't have a ppi between event address and task crypt, instead they have a delay by using events bcmatch to trigger task crypt:

https://github.com/zephyrproject-rtos/zephyr/blob/main/subsys/bluetooth/controller/ll_sw/nordic/hal/nrf5/radio/radio.c#L1498
https://github.com/zephyrproject-rtos/zephyr/blob/main/subsys/bluetooth/controller/ll_sw/nordic/hal/nrf5/radio/radio_nrf5_ppi.h#L199
https://github.com/zephyrproject-rtos/zephyr/blob/main/subsys/bluetooth/controller/ll_sw/nordic/hal/nrf5/radio/radio_nrf5.h#L33

From the comments I can find the following:

/* Configure Bit counter to trigger EVENTS_BCMATCH for CCM_TASKS_CRYPT-
* _DELAY_BITS bit. This is a time required for Radio to store
* received data in memory before the CCM TASKS_CRYPT starts. This
* makes CCM to do not read the memory before Radio stores received
* data.
*/

Maybe you can try this?

RE: CCM failed at MICSTATUS check

Kenneth — Mon, 29 Aug 2022 13:00:04 GMT

Let me check internally if someone can take a look now.

I did find that the LL in zephyr contain source code on how it's used in case that may provide any value, ref:

https://github.com/zephyrproject-rtos/zephyr/blob/main/subsys/bluetooth/controller/ll_sw/nordic/lll/lll_conn.c

https://github.com/zephyrproject-rtos/zephyr/blob/main/subsys/bluetooth/controller/ll_sw/nordic/hal/nrf5/radio/radio.c

Kenneth

RE: CCM failed at MICSTATUS check

MarekU — Fri, 26 Aug 2022 09:44:59 GMT

Hello Kenneth is there any update in this issue?

RE: CCM failed at MICSTATUS check

Kenneth — Fri, 15 Jul 2022 08:41:31 GMT

Sure, likely someone can comment in the middle of August. I am not aware of any other examples no.

Edit: I am on vacation until 15th of August, so will not be able to follow up on this before I am back from vacation.

Kenneth

RE: CCM failed at MICSTATUS check

MarekU — Thu, 14 Jul 2022 19:50:03 GMT

Can we to postpone this until one of designers is available again? If there is some specific requirements I think it's worth asking, and event put in documentation. And I really need this code to work. I can disable CRC for now but it may turn out this is only cover some bug or it stop working at some point anyway. Regarding work with code from Github, it's not using interrupts and I need that and on-the-fly encryption to meet project time requirements, unless you have example with on-the-fly encryption and interrupts? That would be very helpful.

RE: CCM failed at MICSTATUS check

Kenneth — Wed, 13 Jul 2022 11:26:19 GMT

At the moment most of the designers are on vacation, so I am not able to get their comment whether there are some combinations of requirements that needs to be satisfied. Until they are back my best suggestion is to still work on following the github repo I shared earlier as close as possible.

Kenneth

RE: CCM failed at MICSTATUS check

MarekU — Tue, 12 Jul 2022 16:17:30 GMT

It's getting weird now. I just found that when I set static payload to number of bytes in CRC, then MIC is valid, even when CRC is enabled. Somehow this extra space for CRC making MIC work.

Does anyone understand where this behavior comes from?

From what I understood from the documentation, the CRC is added at the end, regardless of the payload length. Whereas the MIC is added as an "extra payload". How can they conflict with each other?

RE: CCM failed at MICSTATUS check

MarekU — Tue, 12 Jul 2022 14:07:43 GMT

I just run the example from github. It works, but example uses Zephyr, I don't (also my code is based on interrupts) so it's hard to do any direct comparison. Anyway, it shows that CCM can work with proprietary mode with 2Mbit speed, in example MICSTATUS is validated.

I also check what happen when I change mode to BLE_2Mbit, it's kind a worked, but transmission was unreliable and most of a time data was distorted, MIC field and CRC was never both "1". I'm not sure what requirements this mode has.

I also tests almost all radio settings one by one, whitening, slower speed, preamble length, address length, S0 and S1 length, etc. Only MAXPACKETSIZE and CRC has any impact on MIC field. When MAXPACKETSIZE was smaller, MIC field was valid often as I described in first post, and when I disable CRC, then MIC is always valid but i don't have CRC.

I can upload my code to Github if that will be any help.

RE: CCM failed at MICSTATUS check

Kenneth — Tue, 12 Jul 2022 10:58:27 GMT

That is odd, what I do know in general is that the CCM module have only been designed and qualifed with BLE in mind, so it could be that when used with proprietary nRF there is something occuring. Though have you tried to use the example on github as-is, does it happen then? Is there any difference if you use BLE 1Mbit mode instead of 1Mbit nRF mode?

Kenneth

RE: CCM failed at MICSTATUS check

MarekU — Tue, 12 Jul 2022 09:24:44 GMT

I checked with all CRC setting 8, 16 and 24bit, only difference make if I disable CRC completely. I don't understand why this is behave this way.

RE: CCM failed at MICSTATUS check

Kenneth — Tue, 12 Jul 2022 09:19:42 GMT

It should work with CRC, does it work with any length of CRC (e.g. 8, 16 or 24bit)? I know BLE use 24-bit, so I guess that should at least work.

Kenneth

RE: CCM failed at MICSTATUS check

MarekU — Mon, 11 Jul 2022 22:44:18 GMT

I just notice, that when I set CRC to disabled (zero bytes), MIC is always valid. Is CRC and MIC are in conflict somehow?

CRC is on docs schematics, so it looks like it can be used with encryption.

RE: CCM failed at MICSTATUS check

MarekU — Mon, 11 Jul 2022 17:38:28 GMT

My code basically originate from that example, I will try to study this example further, but it doesn't use interrupts, so it's hard to compare. Maybe by trial and error I can find something.

This is in most of the part handled by hardware, so I just run out of options, what else can I check in code to change this behavior. Please let me know if you have any suggestions.

RE: CCM failed at MICSTATUS check

Kenneth — Mon, 11 Jul 2022 13:04:44 GMT

I suggest to try the example linked nevertheless just to verify for comparison.

Kenneth

RE: CCM failed at MICSTATUS check

MarekU — Mon, 11 Jul 2022 11:52:04 GMT

I study this example letter by letter, maybe I missed something, but I don't see any significant differences.

The radio configuration is:

- 2Mbit speed

- 8-bit S0 and S1

- 8-bit length field

- 8-bit preamble

- 16 bit of CRC

- max payload of 255 bytes

- 5 bytes address

- little endian

- whitening enabled (without address due to errata)

This is meet the requirements of CCM on-the-fly encryption, right?

RE: CCM failed at MICSTATUS check

Kenneth — Mon, 11 Jul 2022 11:38:05 GMT

Then I am not entirely sure, it could be that the radio configuration does not meet the requirements set in these chapters (edit: corrected links for nRF52840):
https://infocenter.nordicsemi.com/topic/ps_nrf52840/ccm.html#unique_2057001550
https://infocenter.nordicsemi.com/topic/ps_nrf52840/ccm.html#unique_557723459

In any case, can you also look at:
https://github.com/NordicPlayground/nrf52-esb-ccm-example

Kenneth

RE: CCM failed at MICSTATUS check

MarekU — Mon, 11 Jul 2022 10:25:01 GMT

Thank you for answer, I try this earlier, I also try this now just to be sure. It has no effect, it seems like EVENTS_ENDCRYPT is already done, when I read MICSTATUS.

RE: CCM failed at MICSTATUS check

Kenneth — Mon, 11 Jul 2022 10:06:09 GMT

The radio may receive the packet before the CCM has finished. So on receive event, the application need to wait before processing the decrypted packet:
/* Wait for CCM to complete */ while(NRF_CCM->EVENTS_ENDCRYPT == 0) { __WFE(); }

Best regards,
Kenneth