Encrypting the nonce in AES-CCM

Question

I'm working on a network where nodes communicate using AES-CCM encryption, within a context of tight bandwidth limitations, making every bit count. The setup uses a nonce that combines a 16-bit node address, a timestamp incremented every 100 seconds (with only the offset transmitted), and a 10-bit counter unique to each node and timestamp. The size of the authentication code is 64 bits.

However I also need to encrypt the 16-bit node address which is used as a fixed part for the nonce.

My approach involves a two-step encryption process: first, encrypting the message with AES-CCM, and then encrypting the node address (and potentially the counter). During decryption, the node address is decrypted first and partly used as the nonce for the AES-CCM step. Separate keys are used for both steps and all inputs to the second step are authenticated. I've considered two methods for this.

First idea was to use AES-ECB. The node address and the counter essentially provide a network wide unique counter to encrypt. Also, since the node address is only 2 bytes and the counter part is not filling the AES block size of 16 bytes I intend to double encrypt some parts of the initial AES-CCM ciphertext. Otherwise I would have to pad the ECB input which is not desirable.

Another idea was to use AES-CTR for encrypting the address, utilizing the MAC from AES-CCM step, the timestamp, and the 10-bit counter as the nonce. The 64-bit randomness of the MAC, however, introduces a risk of nonce collision. Calculating the security level for the address encryption with this method is something I'm uncertain about.

These are two different approaches on how to achieve the 16-bit address encryption.

• Is ECB mode secure when encrypting already encrypted data?
• Is ECB mode secure when plaintext is guaranteed to be different for every encryption?
• How to evaluate the security of the CTR mode approach I described?

Answer 1

ECB mode is a bit of a misnomer if just a single input value is used. At that point it is just a single block cipher encrypt.

CCM only assumes that a unique nonce is used, it doesn't require an unpredictable or random IV.

A block cipher encrypt is deterministic, assuming that the block cipher will keep using the same key. That means that nonces that are not unique will not get any benefit by using a block cipher.

---

It is not entirely clear if you want to send the "nonce" with the ciphertext. If that is the case then there is no reason to encrypt the input data for it twice.

First of all, you could just consider a random nonce instead. Second, if you encrypt the data and the receiver is able to decrypt then there is no need to include it again.

If you are afraid that the encryption with the block cipher could break CCM then just encrypt it with a different key. You could derive one or two keys from the shared key using one or more calls to a key derivation function (KDF).

---

If you have a unique ciphertext and you're not afraid of a two pass algorithm with regard to processing required then SIV mode would probably the best mode to use. In that case if any bit of two messages are different then the ciphertext will use a different nonce.

If there is still a chance of collision then you can add additional information using a random salt sent with the messages to make this chance smaller.