Is disabling padding integrity check in CBC implementations a good way of overcoming / mitigating padding oracle attack?

Question

Given that CBC mode has a padding oracle attack, would disabling the padding integrity check be a good way of overcoming the vulnerability (this may result in frustration among existing users with regard to troubleshooting initial vector mismatches, but this will at least not render the mode itself vulnerable)?

Answer 1

TL,DR: No. Use proper authenticated encryption, for example with a block cipher in GCM or CCM mode.

The principle of an oracle attack on a cipher is that the adversary has a ciphertext that they want to decrypt. The adversary makes some modification to the ciphertext, makes a plausible hypothesis about the corresponding plaintext, arranges for this modified ciphertext to be decrypted, and finds out whether the hypothesis was correct. The adversary then tries again with a different hypothesis.

An example of a plausible hypothesis is “maybe the last byte is this value”. It's plausible because a random plaintext has a 1/256 chance of matching it, so it takes less than 256 attempts to find out the value of the last byte. An example of an implausible hypothesis would be “maybe the last block is exactly this particular string”: it would take $2^{256}-1$ attempts to find the content of a block by repeating attempts of this form.

A padding oracle attack is an oracle attack where the information comes from knowledge of the padding. The system may leak this because it returns an “invalid padding” error, or because it treats valid and invalid padding differently so there's a timing difference between the two. Padding oracles may work regardless of the plaintext, although some like Lucky Thirteen leverage partial knowledge about the plaintext.

Padding validity may be a convenient component an oracle, but it's not the only one. The application that processes the decrypted data may have its own reaction to specially-crafted plaintexts which allows constructing oracles. To give a trivial example, consider two systems:

• System 1 uses CBC to encrypt arbitrary-length messages, with PKCS#7 padding.
• System 2 uses CBC to encrypt messages whose length is a multiple of 16. The application that generates the messages starts from arbitrary-length messages and applies PKCS#7 padding to them.

Those systems are exactly equivalent, but system 2 doesn't involve padding in the cryptography subsystem. So you could say a padding oracle attack on system 1 is an application data oracle on system 2 — moving the padding around didn't change anything.

To give another less trivial example, POODLE is a padding oracle against SSL 3.0. Even systems that don't check the padding as such are vulnerable, because the exact length of the message depends on the encrypted content, and determining the length is itself an oracle. (Arguably it can be considered a partial-padding oracle.)

There are three components in an oracle attack, and removing any of the three will defeat the attack.

1. The adversary must be able to inject specially crafted ciphertexts.
2. The system's response to different ciphertexts must have some observable difference, for example whether it returns an error message, whether it performs some follow-up action, the timing of the processing, etc.
3. The adversary must be able construct ciphertexts with a plausible hypothesis about the corresponding plaintext. Typically the attack is iterated: the adversary only learns a bit of information at a time, and uses each attempt to refine their knowledge of the system.

The first property is part of the security model. Either the adversary is active or passive. Oracle attacks require an active adversary. An example of a system where the adversary is purely passive is communication happening over a physically secure medium, where the adversary can observe the data through side channels such as electromagnetic radiations, but cannot send their own data. Another example is storage where the only threat is the theft of the storage media, and the system will never process tainted ciphertexts. If your threat model only has passive adversary, you don't need to worry about oracle attacks and you can use CBC.

The second property depends on the application, but it's practically impossible for it not to be true. Unless your application just discards the messages it receives, it's surely going to do something with them. And as soon as it does something that's externally visible, you've lost. So there's no hope there.

The third property depends on the construction of the cipher, on the data format, and on how the application processes the data. It's not a given that an oracle exists — but it's very hard to be sure that there's no oracle. It took years for Lucky Thirteen to be discovered, for example, and it relies on the fact that the TLS message header, which is 13 bytes long (hence the name), is just a bit shorter than an encryption block, but it's a devastating attack against efficiently implemented CBC in TLS. If padding isn't the problem, some other aspect of the data processing may be the problem.

A surefire way to invalidate the third property is to make it impossible to make plausible hypotheses about the plaintext by authenticating it. If the first thing the system does upon receiving a message is to check its authenticity, then the system's reponse is either “this message is authentic (and possibly further information)” or “this message is forged”. As long as the adversary can't break the authentication, the system's response will (with overwhelming probability) be “this message is forged” unless the message is one that the adversary intercepted from a valid sender. So the adversary won't be able to learn anything.

Thus, if your threat model includes active attackers, you need to authenticate your messages. You can do that by taking a MAC of the ciphertext and sending it along. This is an “encrypt-then-MAC” construction, and it avoids padding oracle attacks. In contrast, the POODLE and Lucky Thirteen attacks are possible because SSL/TLS uses a “MAC-then-encrypt” construction and the MAC protects the application data (so there can't be oracle attacks against the application behavior) but not the padding (allowing oracles on what looks like the padding). Should we MAC-then-encrypt or encrypt-then-MAC? discusses the relative benefits of the two approaches, and notes that both have pitfalls.

To avoid those pitfalls, don't roll your own combination of encryption and authentication. Use a standard authenticated encryption algorithm. Let the algorithm designer worry about how to set up keys, in what order to do things, etc.

Answer 2

The problem

The problem with the CBC is the existence of the oracle that returns information about padding. It is called the padding oracle. If there is no padding, there is no padding oracle to use. And, if CBC is used to encrypt data at rest, then there is no padding oracle, too.

Is padding integrity?

Padding is not integrity, it is necessary for the encryption of a full block in CBC mode. There are block cipher modes of operation like CTR that don't require padding since they are streaming modes that even enable encrypting one bit.

IV mismatch during decryption

Keep in mind that, If the IV doesn't mismatch in the decryption of the CBC mode, only the first block is affected. The IV inconsistent users may only lose the first block. One can see this either considering that each block uses IV as the previous or by looking at the decryption

\begin{align} P_1 =& D_k(C_1) \oplus IV\\ P_i =& D_k(C_i) \oplus C_{i-1},\;\; 1 < i < nb, \end{align}

So, IV only affects the first block during the decryption ( or see it on the CBC bit flipping attack).

If we are talking about the IV is not same during the encryption, the recipient may first try with their IV and if they see garbage then removes the first block and accept it IV and decrypt. This can be problematic since this is also an attack point where an active attacker can remove the initial blocks on their behalf. Integrity is the key here.

Padding oracle is a decryption oracle

The padding oracle attack, on the other hand, step by step decrypts each block with the help of the oracle. That is why it is dangerous.

Mitigation

CBC mode is removed from TLS as of TLS 1.3. In TLS 1.3 all cipher suites are Authenticated encryption modes like AES-GCM and ChaCha20-Poly1305 and all modes don't require padding since they are based on the CTR mode.

It is better to use either the modern cipher suites. Keep in mind that one has to be careful to use each one like never let (IV,key) pair used again. AES-GCM-SIV is the mode to mitigate this problem.

If you have to stick to CBC use the Enc-then-MAC fashion so that when the adversary modifies the block the MAC will notice the change and the server will only return the MAC error-tag. This is due to the fact that MAC is calculated on the ciphertext. You should use HMAC as your MAC since HMAC is the beast.

Using a single key for Enc and MAC

We don't prefer to use the same key for encryption and integrity. We learned that is dangerous from CBC-MAC. It can be, however, derived from the encryption key like GCM mode derives GHASH key with encryption a full zero block $H = CIPH_K(0^{128})$ (NIST 800-38d page 14). ChaCha20-Poly1305 had a similar way to generate the authenticator key.

A common method is deriving multiple keys and IVs using the HKDF and if your key is generated uniformly randomly then Expand of HKDF is enough to derive them.