CCM — AES CCM mode encryption

CCM shares the same AES module as the ECB and AAR peripherals. ECB will always have the lowest priority. If there is a sharing conflict during encryption, the ECB operation will be aborted and an ERRORECB event will be generated in ECB.

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

A new keystream needs to be generated before a new packet encryption or packet decryption operation can start.

A keystream is generated by triggering the KSGEN task. An ENDKSGEN event is generated after the keystream has been generated.

Keystream generation, packet encryption, and packet decryption operations utilize the configuration specified in the data structure pointed to by CNFPTR. It is necessary to configure this pointer and its underlying data structure, and register MODE before the KSGEN task is triggered.

The keystream will be stored in CCM’s temporary memory area, specified by the SCRATCHPTR, where it will be used in subsequent encryption and decryption operations.

For default length packets (MODE.LENGTH = Default), the size of the generated keystream is 27 bytes. When using extended length packets (MODE.LENGTH = Extended), register MAXPACKETSIZE specifies the length of the keystream to be generated. The length of the generated keystream must be greater than or equal to the length of the subsequent packet payload to be encrypted or decrypted. The maximum length of the keystream in extended mode is 251 bytes, which means that the maximum packet payload size is 251 bytes.

If a shortcut is used between ENDKSGEN event and CRYPT task, pointers INPTR and OUTPTR must also be configured before the KSGEN task is triggered.

CCM is able to read an unencrypted packet, encrypt it, and append a four byte MIC field to the packet.

Encryption is started by triggering the CRYPT task with register MODE set to Encryption. An ENDCRYPT event is generated when packet encryption is completed.

CCM will also modify the length field of the packet to adjust for the appended MIC field. It adds four bytes to the length and stores the resulting packet in RAM at the address specified in pointer OUTPTR, as illustrated in the figure below.

Figure 2. Encryption

Empty packets (length field is set to 0) will not be encrypted, but instead moved unmodified through CCM.

CCM supports different widths of the length field in the data structure for encrypted packets. This is configured in register MODE.

CCM is able to read an encrypted packet, decrypt it, authenticate the MIC field, and generate an appropriate MIC status.

The packet header (S0) and payload are included in the MIC authentication. Bits in the packet header can be masked away by configuring register HEADERMASK.

Decryption is started by triggering the CRYPT task, by setting the register MODE to Decryption. An ENDCRYPT event will be generated when packet decryption is completed.

CCM modifies the length field of the packet to adjust for the MIC field. It subtracts four bytes from the length and stores the decrypted packet in RAM at the address specified in the OUTPTR pointer.

CCM is only able to decrypt packet payloads that are at least five bytes long (one byte or more encrypted payload (EPL) and four bytes of MIC). CCM will therefore generate a MIC error for packets where the length field is set to 1, 2, 3, or 4.

Empty packets (length field is set to 0) will not be decrypted but instead moved unmodified through CCM. These packets will always pass the MIC check.

CCM supports different widths of the LENGTH field in the data structure for decrypted packets. This is configured in register MODE.

Figure 3. Decryption

The CCM is only able to decrypt packet payloads that are at least 5 bytes long, 1 byte or more encrypted payload (EPL) and 4 bytes of MIC. The CCM will therefore generate a MIC error for packets where the length field is set to 1, 2, 3 or 4. Empty packets (length field is set to 0) will not be decrypted, but instead moved unmodified through CCM. These packets will always pass the MIC check.

CCM supports different widths of the length field in the data structure for decrypted packets. This is configured in register MODE.

The CCM peripheral is able to encrypt/decrypt data synchronously to data being transmitted or received by RADIO.

In order for CCM to run synchronously with the radio, the data rate setting in register MODE needs to match the radio data rate. The settings in this register apply whenever either the KSGEN or CRYPT tasks are triggered.

The data rate setting of register MODE can also be overridden on-the-fly during an ongoing encrypt/decrypt operation by the contents of register RATEOVERRIDE. The data rate setting in this register applies whenever the RATEOVERRIDE task is triggered. This feature can be useful in cases where the radio data rate is changed during an ongoing packet transaction.

When CCM encrypts a packet on-the-fly while RADIO is transmitting it, RADIO must read the encrypted packet from the same memory location that CCM is writing to.

The OUTPTR pointer in CCM must point to the same memory location as the PACKETPTR pointer in RADIO, as illustrated in the following figure.

Figure 4. Configuration of on-the-fly encryption

In order to match RADIO’s timing, the KSGEN task must be triggered early enough to allow the keystream generation to complete before packet encryption begins.

For short packets (MODE.LENGTH = Default), the KSGEN task must be triggered before or at the same time as the START task in RADIO is triggered. In addition, the shortcut between the ENDKSGEN event and the CRYPT task must be enabled. This use-case is illustrated in On-the-fly encryption of short packets (MODE.LENGTH = Default), using a PPI connection. It uses a PPI connection between the READY event in RADIO and the KSGEN task in CCM.

For long packets (MODE.LENGTH = Extended), the keystream generation needs to start earlier, such as when the TXEN task in RADIO is triggered.

Refer to Timing specification for information about the time needed for generating a keystream.

Figure 5. On-the-fly encryption of short packets (MODE.LENGTH = Default), using a PPI connection

For long packets (MODE.LENGTH = Extended), the keystream generation will need to be started even earlier, for example at the time when the TXEN task in the radio is triggered.

When CCM decrypts a packet on-the-fly while RADIO is receiving it, CCM must read the encrypted packet from the same memory location that RADIO is writing to.

The pointer INPTR in CCM must therefore point to the same memory location as the PACKETPTR pointer in RADIO.

Figure 6. Configuration of on-the-fly decryption

In order to match RADIO's timing, the KSGEN task must be triggered early enough to allow the keystream generation to complete before the decryption of the packet starts.

For short packets (MODE.LENGTH = Default), the KSGEN task must be triggered no later than when the START task in RADIO is triggered. In addition, the CRYPT task must not be triggered earlier than when the ADDRESS event is generated by RADIO. If the CRYPT task is triggered exactly at the same time as the ADDRESS event is generated by RADIO, CCM will guarantee that the decryption is completed no later than when the END event in RADIO is generated. This use case, using a PPI connection between the ADDRESS event in RADIO and the CRYPT task in CCM, is illustrated in figure below.

Figure 7. On-the-fly decryption of short packets (MODE.LENGTH = Default), using a PPI connection

The KSGEN task is triggered from the READY event in RADIO, through a PPI connection.

For long packets (MODE.LENGTH = Extended) the keystream generation will need to start even earlier, such as when the RXEN task in RADIO is triggered.

Refer to Timing specification for information about the time needed for generating a keystream.

The CCM implements an EasyDMA mechanism for reading from and writing to RAM.

When the CPU and EasyDMA enabled peripherals access the same RAM block at the same time, increased bus collisions might disrupt on-the-fly encryption. In this case, the ERROR event will be generated.

EasyDMA stops accessing RAM when the ENDKSGEN and ENDCRYPT events are generated.

If the CNFPTR, SCRATCHPTR, INPTR and the OUTPTR are not pointing to the data RAM region, an EasyDMA transfer may result in a HardFault or RAM corruption. See Memory for more information about the different memory regions.