How difficult is it to modify AES ciphertext in a meaningful way

Question

Say I have the text user:123 encrypted with AES/ECB/PKCS5Padding, resulting in the ciphertext vnjlWxfkYuTK3juNY38NKQ==. How difficult is it to modify the ciphertext in order to get another meaningful 3-digit numerical value? Is it similar in difficulty to brute-forcing the encryption key?

If I just modify one byte of the ciphertext I get garbled data in the entire block, so I need quite an elaborate change to the ciphertext in order to affect just the value part in a meaningful way. Just how elaborate would this change be?

Background: I come fairly often across cases in which encryption is used as a means to "secretly" transmit data between applications, most of the times using some mode of AES encryption. In most of these cases it is however more critical that the data does not get modified in transit or by the user, as opposed to not being readable.

Example: User X is logged into application A, and goes via a link, with parameters containing the user identity, to application B. The link parameters are AES/ECB encrypted, using a key that is known to both applications. HTTPS is used by both applications, so the threat of the parameters being read by a third party is covered. More important is that the user cannot change their identity and impersonate another user.

I would like to point out this common misconception to the developers and architects of applications A and B, that encryption means that data can't be changed, by showing an attack scenario where the ciphertext is changed, so that upon decryption, valid data is received. This way they can understand better that in such cases an authenticated encryption algorithm is a must.

hmakholm left over Monica · Accepted Answer · 2018-01-15 11:06:13Z

If the padded plaintext fits into a single block, then editing it in a meaningful way without knowing the key ought to be pretty darn impossible -- in the technical sense that being able to do that (even just some of the time) would count as a full-scale break of AES.

In other words, single-block AES encryption is self-auththenticating to the exact degree that the space of valid plaintexts is small compared to the space of all possible blocks (assuming that the recipient actually verifies that the deciphered block is valid). It does not matter whether the valid plaintexts are mostly similar or look very different; all that counts is only how many of them there are. This is because AES, like any other good block cipher, is supposed to behave like a pseudo-random permutation of the space of all possible blocks.

This of course ignores the possibility of higher-level protocol attacks, such as tricking the recipient into accepting an block that was already encrypted separately (say, for a different run of the protocol).

Once your plaintext is longer than one block, using ECB makes it trivially easy to mix and match between pieces of separately encoded messages at block boundaries. But this is a property of ECB, not of AES in particular. No halfway serious application should use ECB for data that are not strongly known always to fit in a single block.

In your example it sounds like it would be a lot more relevant to attack application A directly than to attack the communication between A and B. For example, if application A runs on a device or account that the user controls, the user could likely modify the data before application A even encrypts them, and/or inspect the (running?) application to extract the key.

Alternatively, it sounds like the protocol you're sketching would likely be vulnerable to replay attacks, without bothering to edit any messages. This means that an attack on the TLS transport (such as by tricking the client end into trusting a CA root that you control) could be escalated into an attack on the authentication part -- i.e. the additional encryption of the credentials may give much less additional security than the designers intend to.

Sjoerd · Accepted Answer · 2018-01-15 12:37:33Z

Modification of encrypted data is sometimes possible through a bitflip attack. This is more an attack of the block cipher mode of operation and not really on the encryption algorithm. In some modes of operation (but not in ECB) the ciphertext is XORed with plaintext from the next or previous block. This means that flipping a bit garbles one whole block, and flips one bit in another block.

For a practical example, consider we are served an encrypted cookie that contains the following:

{"user": "johndoe", "nick": "john", "admin": 0}

When this is encrypted using CBC mode, it is split up in blocks of 16 bytes. Each block is XORed with the previous block (or the initialization vector) and encrypted. The message consists of the following blocks:

{"user": "johndo
e", "nick": "joh
n", "admin": 0}

In our bitflip attack, we flip a bit in the ciphertext of block 2. This will cause block 2 in the decrypted plaintext to become garbage, but it will also flip a bit in block 3. This happens because the decryption result is XORed with the ciphertext of the previous block, which is under our control:

The result is a cookie containing valid JSON, with the admin flag set to 1:

{"user": "johndoaRbUTPasBIrmAnO5n", "admin": 1}

Stack Exchange Network

How difficult is it to modify AES ciphertext in a meaningful way

2 Answers 2

You must log in to answer this question.

Hot Network Questions

How difficult is it to modify AES ciphertext in a meaningful way

2 Answers 2

You must log in to answer this question.

Related

Hot Network Questions