I\'m working with a third party protocol which employs AES-128 in ECB mode of op
ID: 652810 • Letter: I
Question
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.
Explanation / Answer
If the protocol doesn't provide authentication, an attacker can probably mount replay attacks or make deterministic changes to messages.
If the nonces in different blocks are not compared in any way, they can just take the ID block of a previous message and use it with a new one, to forge it being from that device. If nonces are required e.g. to be equal in all the blocks of a message, the attacker can still reorder them freely, which reorders the message in the same way. If there are any blocks without nonce, those can be freely moved within and between messages.
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).
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.
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.
You cannot find the key even with known plain/ciphertext pairs (unless it's been chosen in a non-random way that allows an attack). If the attacker ever sees two blocks with equal ciphertext, they will know the plaintexts are equal and may be able to derive information about the ID, depending on which block matched which.