CCM — AES CCM mode encryption

The CCM shares the same AES module as the AAR and ECB peripherals. The ECB will always have the lowest priority. If an operation is aborted due to a conflict among the shared resources, an ERROR event will be generated.

Additionally, the CCM shares registers and other resources with the peripherals that have the same ID as the CCM. See Peripherals with shared ID for more information.

CCM supports both packet encryption and decryption.

The following table shows the different CCM input/output and parameters supported by the CCM module for encryption and decryption:

During packet encryption, CCM will read the unencrypted packet located in memory at the address specified in register IN.PTR, encrypt the packet and append an M byte long message authentication code (MAC) field to the packet.

The message to authenticate and encrypt (m) and additional authenticated data (a) are included in the MAC generation. The first byte in the packet header can be masked by configuring the ADATAMASK register. This is useful for Bluetooth header masking. For protocols other than Bluetooth, the ADATAMASK register must be set to 0xFF for correct CCM operation; the reset value is configured to support Bluetooth.

Encryption is started by triggering the START task with the MODE register set to Encryption. The END event will be generated when packet encryption is completed.

The AES CCM will modify the l(c) output field of the packet to adjust for the appended MAC field, that is, add MODE.MACLEN bytes to l(m), and store the resulting packet back into memory at the locations specified in the OUT.PTR list, as illustrated in the following figure. The maximum length of l(m) plus MODE.MACLEN cannot exceed 65535 bytes.

Any values of l(m) and l(a) are allowed. If encrypting empty packets, i.e. l(m) = l(a) = 0, no encryption will take place; the END event is generated, and CCM operation is stopped.

For Bluetooth (MODE.PROTOCOL=Ble), valid packets with 0 payload (l(a) is larger than 0 but l(m) is 0) will not be authenticated but instead moved unmodified through the AES CCM peripheral, and thus no MAC will be generated.

For IEEE 802.15.4 (MODE.PROTOCOL=Ieee802154), valid packets with 0 payload (l(a) is larger than 0 but l(m) is 0) will be authenticated, and thus a MAC will be generated as part of the output data.

During packet decryption, CCM will read the encrypted packet located in memory at the address specified in the IN.PTR pointer, decrypt the packet, authenticate the packet's MAC field and generate the appropriate MAC status.

The encrypted message in (c), is decrypted and authenticated together with additional authenticated data (a) and then matched against the decrypted MAC value. The decrypted MAC value is part of (c). Bits in the first byte of the data can be masked away before calculating the MAC value by configuring the ADATAMASK register. This is useful for Bluetooth header masking. For protocols other than Bluetooth, the ADATAMASK register must be set to 0xFF for correct CCM operation; the reset value is configured to support Bluetooth.

Decryption is started by triggering the START task with the MODE register set to FastDecryption.

CCM will write the l(m) value of the decrypted packet to the location provided in OUT.PTR, and then store the decrypted packet into memory at the locations given by the OUT.PTR list as illustrated in the following figure.

For Bluetooth (MODE.PROTOCOL=Ble), CCM is only able to authenticate messages where l(c) is at least MACLEN+1 bytes long. If l(c) is less than MACLEN+1, CCM will generate an END event and clear the MACSTATUS (indicating MAC check failure). Furthermore, empty packets (l(c)=0) will be moved unmodified through the AES CCM peripheral even though ERROR event shall be generated. In any other case that leads to a failed MACSTATUS or an ERROR event, the contents of the job addresses given in OUT.PTR are undefined.

For IEEE 802.15.4 (MODE.PROTOCOL=Ieee802154), CCM will also perform authentication on messages where only ADATA is present (i.e. l(m)=0 and l(a)>0). In this case MACSTATUS reflects the result of the authentication. If l(c)<MACLEN, then the ERROR event is generated, and the contents of the locations given in OUT.PTR are undefined.

When the AES CCM is encrypting a packet at the same time as the radio is transmitting it, the radio must read the encrypted packet from the same memory location as the AES CCM is writing to.

The OUT.PTR pointer in the AES CCM must therefore point to the same memory location as the PACKETPTR pointer in the radio, see Example configuration of encryption during radio transmission.

The START task must be triggered by RADIO READY event to ensure that the payload is encrypted in time for radio transmission. This is illustrated in the following figure, using a PPI connection between RADIO.EVENTS_READY and CCM.TASKS_START.

To decrypt a packet received by the radio immediately upon its reception, CCM can be started when the RADIO PAYLOAD event is generated. The packet is decrypted when the CCM.END event is generated. Typically, CCM will decrypt the packet before or during the reception of the CRC. However, if the packet is large and the bitrate is high, CCM will not finish before the PHYEND event, but shortly afterward. After the CCM.END event is generated; the MACSTATUS can be checked.

AES CCM must therefore operate on the same memory location as RADIO, as illustrated in the following figure.

The CCM implements an EasyDMA with scatter/gather mechanism for reading and writing to memory.

In cases where the CPU and other EasyDMA enabled peripherals are accessing the same RAM block at the same time, a high level of bus collisions may cause too slow operation for correct on the fly encryption. In this case the ERROR event will be generated.

EasyDMA will have finished accessing the memory when the END event is generated.

If the IN.PTR and the OUT.PTR are not pointing to memory with DMA connectivity, an EasyDMA transfer may result in a HardFault or memory corruption. See Memory for more information about the different memory regions.

For instances supporting DMA error detection, the ERRORSTATUS register will report if a bus error has occurred during DMA access.