NRF_CCM->MICSTATUS bit not set, even though it's computed correctly

[Elias]

I'm developing a minimal bootloader on the nrf52832 that just reads/writes flash and decrypts some data already present in flash. I'm using the Bluetooth Spec's own sample data, specifically Sample Data 2 (Vol 2, Part G, 1.2.2 - p1547 of v5.0 spec).

K: 89678967 89678967 45234523 45234523
Initialization vector: 66778899 aabbccdd
Payload counter: 0000bc614e
Payload: 68696a6b 6c6d6e6f

T: 08d78b32

S0: b90f2b23 f63717d3 38e0559d 1e7e785e

MIC: b1d8a011
Encrypted payload: b0ae898a 6e6864d4

My code is derived from Nordic's CCM example. The differences are that I've added arguments to ccm_crypt_init() to pass a Key and Initialization Vector, and m_ccm_config.counter is hard-coded to start at the value given in the sample data.

I'm using Keil to look at memory while inside ccm_crypt_packet_decrypt(). Just before the function returns, clear_buffer[] contains the properly decrypted data, NRF_CCM->SCRATCHPTR points to the expected S0[0-3], and SCRATCHPTR+8 contains the expected T. The XOR of S0[0-3] and T is equal to the MIC passed appended to the end of Encrypted Payload. The problem is that NRF_CCM->MICSTATUS is still not set.

[Hung Bui]

Hi Elias,

I think there is a misunderstanding here. Both MIC and data payload are encrypted after the CCM block. This is why you don't receive MIC check passed when you put b1d8a011 at the end of the payload. It has to be the encrypted MIC you need to put there.

You can find at section 2.3 Vol 6 Part 5 Bluetooth 5:

The CCM algorithm uses the Ai blocks to generate keystream that is used to
encrypt the MIC and the Data Channel PDU payload. Block A0 is always used
to encrypt and decrypt the MIC.

Same, inside nRF52832 spec, you can find at Table 59 Data structure for encrypted packet, it's the 4 byte encrypted MIC at the end.

You can find the encrypted MIC using ccm_crypt_packet_encrypt() function.