AES CBC with fixed or predictable IV, what are the risks?

Question

I am making a call with parameters from application "A" to a web application "B". Parameters are in the query string of the URL. They don't need to be hidden. But I want to be sure that nobody can change the parameters. And web application "B" must ensure that the query comes from application "A".

So, I encoded the parameters in AES with CBC. I know that HMAC is best for this kind of situation. But AES with CBC is the only one algo that the 2 applications have in common.

The security of the system relies on the fact that nobody in application "A" can choose arbitrary plaintext to be encrypted (to avoid request with modified parameters). Parameters are not an input for the users.

I would like to know the risk if I use a fixed IV or a predictable IV?

It seems that the risk is a chosen plaintext attack. With this article: https://stackoverflow.com/questions/3008139/why-is-using-a-non-random-iv-with-cbc-mode-a-vulnerability, I understand how chosen plaintext attack can lead to reveal the content of the ciphertext.
But I don't mind if the content of the ciphertext is discovered.

What are the other risks?

Can someone build unauthorized request? CWE-329 says yes. But does that only imply the reusing and adaptaptation of blocks of older messages? Or does the attacker can build his own request with whatever plaintext he wants?

Does the secret key can be discovered? From Wikipedia it seems that chosen plaintext attack can reveal the secret key, but I don't understand how.

Answer 1

You are hoping to get integrity protection by applying CBC mode; the problem with this is that CBC mode isn't great at providing integrity protection.

One way an attacker can exploit this, if he guesses what the plaintext is, he could modify block N of the plaintext to anything we wants by changing block N-1 of the ciphertext. This will modify block N of the resulting plaintext to be exactly what the attacker picked; this also has the side effect to setting block N-1 of the plaintext to be something random. However, the attacker might not care about what block N-1 is (alternatively, he might just hope it results in an innocuous value).

Also, if an explicit IV is given (so that the attacker can freely modify it), he can modify the IV to make the resulting first block of the plaintext be anything he wants, without any other changes anywhere in the resulting plaintext.

Given that you do have a CBC mode primitive, the obvious thing to try is to implement CMAC; this would involve taking the plaintext message, padding it out, computing the CBC mode encryption of that padded message (with a fixed IV), and throw away the entire encrypted message except for the last block. Then, you'd send the original plaintext message, along with that last encrypted block. On the receiver side, it would take the received plaintext message, pad and encrypt it in exactly the same way, and see if that results in exactly the same last block.

The advantages of this approach is that it does give you real integrity protection (in that no one in the middle who doesn't know the keys can modify the message in a way that would not be immediately be rejected, except for deliberate replays); and it does all this using only a CBC primitive.