# Encryption of small data with fixed key and incremental IV

I have a Bluetooth device that sends a small package periodically (without receiving). I want to encrypt and authenticate the data using AES-128. It has an embedded random and unique key which is burned to the memory at production and it is known to the receiver. I have the following message structure:

4 bytes 10 bytes 4 bytes 2 bytes

Counter is not encrypted and will increment sequentially for each message (never to be repeated) and it will be used as IV to the AES-CTR mode. It will also serve to protect against replay attacks, i.e. older packages will be ignored.

Magic is fixed and known number to check that the decrypted message is not gibberish and a valid data.

Padding is ignored in the receiver side and used to complete the encrypted data to 16 bytes.

Payload + Magic + Padding will be encrypted together before sending, i.e.

Counter Encrypted Data
4 bytes 16 bytes

The questions are:

1. Can a passive listener break this encryption and/or craft legitimate messages?
2. Is this also provide authentication since no one except the key holder can craft such a message?
3. Is it OK to use IV/nonce with prepending 0 to the Counter? Should I append the counter to a random number (which is also burned at factory)?
4. What to put to the padding, 0 or random numbers? Is it even necessary?
5. Is using the magic number this way logical? Do I need to generate random magic and send it both unencrypted and encrypted for validation by the receiver?
6. What is the correct/well-established method for encryption and authentication in such a setting?

1. Can a passive listener break this encryption and/or craft legitimate messages?

A passive listener should not be able to reverse AES, so getting the plaintext should be impossible, unless each session is restarted. However, this scheme would be vulnerable to plaintext oracle attacks. Read on.

As for crafting legitimate messages: that's not a passive attack.

1. Is this also provide authentication since no one except the key holder can craft such a message?

No. If you perform a man in the middle you can change every bit of the message and leave the magic intact. In CTR mode all bits of the plaintext / ciphertext are independent of each other. It also lets an attacker perform plaintext oracle attacks (by changing a bit of plaintext and then detect to how the system responds to it).

1. Is it OK to use IV/nonce with prepending 0 to the Counter? Should I append the counter to a random number (which is also burned at factory)?

As long as the counter never repeats CTR mode is relatively secure - as long as it is used correctly, which is not the case here.

1. What to put to the padding, 0 or random numbers? Is it even necessary?

No, for CTR mode padding is not necessary.

1. Is using the magic number this way logical? Do I need to generate random magic and send it both unencrypted and encrypted for validation by the receiver?

You'd normally use an authenticated mode to create an authentication tag. 32 bit is usually too small, but depending on the use case it could be enough for real time systems etc.

1. What is the correct/well-established method for encryption and authentication in such a setting?

If you just have AES then CCM mode would be the normal mode.

NB

• The scheme you are currently describing seems more appropriate for direct AES encryption or AES-CBC. For instance, if you would pad and encrypt the counter you could use it as IV for AES-CBC. If you would put the value 02 in the padding bytes of the message then you would have PKCS#7 compatible padding. The advantage of this is that the bits in the AES block encrypt of the message are now all dependent on each other, hence the magic would work somewhat better.

• Your current scheme seems to be limited to one session only. Normally you would derive new session keys for each session.

• Even if the mode is changed to CBC, there is a $$1 \over 2^{32}$$ chance of an attacker creating a message with a valid magic, just by randomly trying. The rest of the message would probably be garbled, but processing garbled text might not be a good idea either. Maybe additional countermeasures could be implemented against that (however, most of those could lead to DoS attacks).

• Thanks for the detailed response. I guess the key vulnerability here is: "In CTR mode all bits of the plaintext / ciphertext are independent of each other", but I don't quite understand what it actually means. Jul 19 at 7:45
• There is no guarantee that the receiver gets all the messages, in fact package drops are quite common. Can we still recover the plaintext in this case when using AES-CBC? Also payload might be different for each message. Jul 19 at 7:48
• In CTR mode you XOR the plaintext with the key stream, bit by bit. So any flip of the ciphertext bits simply flips the plaintext bits of the same location. I.e. you can change any plaintext bits without affecting the magic. Jul 19 at 13:44
• In the scheme I described I padded and encrypted the counter so it can be used as an IV. That makes the CBC decryption only dependent on the counter and - of course - the key. Jul 19 at 13:46
• Whole thing is more clear now. I've read the NIST CCM mode specification - which was surprisingly easy to read - and I think this mode is the correct one for my application. As far as I understand it doesn't suffer the vulnerabilities with the magic scheme, which was a poor choice to begin with. Thanks for the help. Jul 25 at 8:46