# Attacks on AES-128 (ECB) based on some knowledge of plaintext

I'm working with a third party protocol which employs AES-128 in ECB mode of operation to encrypt a packet composed of 16-byte blocks (it encrypts each block independently). I'm trying to determine if there are any reasonable attacks against the encryption.

One of the plaintext blocks it encrypts has a 4-octet nonce followed by 12-octets that are always the same (part of the device's unique ID). It is also known that those 12 constant octets are one of 16 different values (ASCII hex digits). Not knowing anything else about those 12 constant digits or how the nonce is generated (assume truly random), is there a practical attack against the encryption?

Further, there is a single key shared by all devices which use the protocol, so in theory I could collect these blocks from lots of different devices, all are encrypted with the same key. All of the devices having different IDs, but all packets from a given device having the same ID.

Another plaintext block (this one is actually encrypted with a different key, specific to the device) has a 4-octet nonce, an 8-octet millisecond timestamp, one octet that is always zero, one octet of arbitrary non-constant data, and two octets that give the length of the unpadded message in octets, and can therefore be narrowed down to one of 12 values by counting the number of blocks in the entire packet (each block cannot hold more than 12 octets of message). I don't know if maybe having the timestamp (i.e., a 64-bit value that increases monotonically and by a more-or-less knowable amount between any pair of packets) is useful in breaking the encryption, but I guess if CTR mode isn't a problem, than this wouldn't be either.

I'm looking for basically anything that could compromise the security of the protocol, so anything that significantly narrows down the keyspace, or even the possible values for those 12 constant octets.

• What are your security goals with your protocol? – Paŭlo Ebermann Jul 1 '14 at 20:51
• As I said, it's not my protocol, it's a third party protocol. My goal is to be able to communicate privately between a client and a server using this protocol, but I'm not convinced that the protocol is very secure in this regard (the protocol does not provide authentication, but it is shared key). – brianmearns Jul 1 '14 at 22:42
• The only thing that looked questionable was the CTR mode but after looking into it a little, CTR mode seems legit, nothing to worry about. So, looks good to me. – Andrew Hoffman Jul 2 '14 at 18:35
• I'm in a similar situation. Is your protocol io-homecontrol by any chance? – jjmontes Mar 12 '17 at 13:36
• @jjmontes - No, this was a protocol for transferring firmware updates to an embedded device. – brianmearns Mar 13 '17 at 12:41

A 32-bit nonce means you need to see on average $2^{16}$ such blocks from the same ID + key to see a collision. Even seeing just a few hundred gives an attacker a larger chance to see one than is usually considered secure. Such a collision shows the attacker the two messages came from the same device/ID.