Possible bug in AES CCM example

[XavierYin]

Torbjørn Øvrebekk from Nordic has made an example showing how to use AES CCM HW. It does "work" self-consistently during encryption & decryption. However, I think I found a critical bug that the AES-CCM operations may not actually doing correctly.

typedef struct
{
    uint8_t key[CCM_KEY_SIZE];
    uint64_t counter;
    uint8_t iv[CCM_IV_SIZE];    
}ccm_data_t;

static ccm_data_t m_ccm_config;

NRF_CCM->CNFPTR = (uint32_t)&m_ccm_config;

This structure differs from "nRF52832 PS V1.4 Table 58: CCM data structure overview" at address offset 24. Somehow Torbjørn Øvrebekk's example shows self-consistency in my test cases, but the crypt data are not matching my PC-based verifying scripts made with Python Crypto module. (this script works as expected on test vectors provided in RFC3610 document)

typedef struct
{
    uint8_t key[CCM_KEY_SIZE];
    uint64_t counter;
    uint8_t direction;    // 1 or 0, Bit7 of Nonce4 in Core_V4.2.pdf Vol.6, Part E Table 2.1
    uint8_t iv[CCM_IV_SIZE];    
}ccm_data_t;

With this modified structure I found it works as expected. Is it possible for a Nordic staff double check whether this fix is valid for the statement "The NONCE vector (as specified by the Bluetooth Core Specification) will be generated by hardware based on the information specified in the CCM data structure from Table 58" in PS?

[ovrebekk]

Hi Xavier

Thanks for the heads up!

For some reason the example appeared to work fine when I originally wrote it, but when I tested it again now it didn't work properly, and I got a MIC error.

I originally though the direction bit was the MSbit in the 64 bit counter, and fixing the struct seems to have solved the issue. The repo should be updated by now.

Thanks again for letting us know :)

Best regards
Torbjørn