# AES multiple devices to server communication

I have multiple devices connecting to a server, whose communication needs to be encrypted. At the moment I have an AES library doing the job (possibly inadequately): I am using a database of keys on the server, that corresponds to the keys stored on the devices (one per device).

Each message from the device to the server is preceded by an unencrypted ID identifying that message as coming from that particular device and thereby showing the server which key to use to decrypt the rest of the message.

As this is sent unencrypted, I think this is somewhat insufficient to identify the device so I placed a device specific "secret" in the bit of the message that is encrypted which, if absent or incorrect will lead to the server discarding the message.

<device ID>"<device secret><device status>"


Where the "" mark the encrypted part. The device secret is the same every time and the device status is constantly changing.

My question is: Will the presence of this "secret" (presuming it is the same in every message coming from that device, and in the same location within the message) cause repeating patterns in the ciphertext making some form of attack possible? If this is the case, then how could this be avoided?

I can think of one way using a random message, sent from the server, that is then "mixed in" with the message before it is encrypted so the message is different every time, but this significantly increases the traffic. So I wanted to check to see if this was necessary or if there is a better way of doing this!

-
out of curiosity, is there are reason you can't use IPSEC SSL TLS etc when your devices are communicating with the server? –  Anthony Jul 21 at 13:32
limited resources, I would be very happy with any embedded library recomendations. –  jayjay Jul 21 at 13:34

Will the presence of this "secret" (presuming it is the same in every message coming from that device, and in the same location within the message) cause repeating patterns in the ciphertext making some form of attack possible?

As long as the AES mode uses an IV and the IV is different for each message, there will be no patterns in the ciphertext.

However, there may be other attacks.

As this is sent unencrypted, I think this is somewhat insufficient to identify the device so I placed a device specific "secret" in the bit of the message that is encrypted which, if absent or incorrect will lead to the server discarding the message.

A better way to do that would be to use authenticated encryption. Either AES in GCM mode or AES CTR + HMAC would work, for example. That will also prevent changes to messages, which may currently allow an attacker to change the device status in a message.

Even then, replay attacks may be possible. To prevent those you could verify the IV is never reused, for example by using a counter as the IV (in CTR or GCM modes) and storing the last value on both server and device, or by having the server send a random session number the device needs to include in its message.

-
Thanks for your reply, I have very limited resources on the "devices" instead of using authenticated encryption, could I use a crc (or or other integrity check) on the message? discarding the message if this fails. If I understand correctly this is similar to what authenticated encryption does. –  jayjay Jul 21 at 10:24
@jayjay, a CRC or even a strong hash will not give you authentication. See e.g. Is there a generic attack on encrypted CRC32 when used as a MAC? and the question linked in the comments there. If the device has AES hardware, CBC-MAC might work, if it doesn't then HMAC is probably faster than the encryption, so it should work. –  otus Jul 21 at 10:32
also, could I use the "random session number" as the IV? –  jayjay Jul 21 at 10:33
@jayjay, if it's authenticated, yes. Otherwise an attacker could cause IV collisions which may allow them to decrypt those messages. –  otus Jul 21 at 10:34

I guess it doesn't matter. The "device secret" here doesn't need to be called secret IMHO. Its something like your public identity (like your email address, your github account, etc..), if its randomly chosen and has no relation to its corresponding key stored in the server then it shouldn't do any harm.

-