How does encrypt-then-MAC protect from CCA?

Question

I am an application developer, implementing client-side crypto to protect data that is then transmitted to be stored on a server. The application uses AES with CBC mode with a resulting encrypt-then-mac HMAC to authenticate.

The process looks something like this:

key_material = kdf(password, salt)
mac_key = first_half(key_material)
enc_key = second_half(key_material)

iv = random_bits()
ct = aes_cbc(plaintext, iv, enc_key)
mac = hmac_sha256(ct, iv, mac_key)

This results in a ct, iv, and mac that are then transmitted to the server. The server then delivers that information back to the client each time the application starts (and user enters their password) in which the whole process is then reversed for decryption.

1. Validate mac. If validation fails, abort with error.
2. Decrypt to plaintext with enc_key, iv, and ct.

I understand the need for the mac in order to validate the authenticity of the message before the application proceeds to decrypt the plaintext to display to the user.

However, I am having trouble understanding how authentication protects against anything else. I have read that authentication will protect against things like Chosen Ciphertext Attacks (CCA). My understanding of a CCA attack is:

A class of attacks in which the attacker modifies encrypted traffic in specific ways and may learn plaintext by observing how the decryption fails.

If an attacker obtains access to the stored ct, iv, and mac don't they have everything that they need to "observe how the decryption fails"?

From my understanding, mac validation is an application implementation. The attacker doesn't necessarily have to use my application to observe how the decryption fails. They could just write their own application that doesn't do the mac check (or just modify my open source application and remove the mac check).

Am I missing something here? How does authentication (more specifically encrypt-then-mac) protect against attacks like CCA?

Answer 1

What CCA basically means is that attacker supplies for decryption any ciphertext he/she wants and observes the reaction of the system. This reaction can be used to infer information about plaintext/key. Many dangerous attacks are based on changing some bits in the ciphertext and observing how when and how the system fails. This is often enough to partially or fully recover plaintext or key. What authenticated encryption (particularly encrypt-then-mac approach) basically does is prevent attackers from being able to change ciphertext. Doing so requires recomputing of mac, which by definition can't be done without knowing the mac key, otherwise decryption immediately fails due to incorrect mac, and as the system doesn't know anything about the plaintext at this point, the attacker can't possibly learn anything too.

Attacker's own application is useless in this case, as without the key itself any decryption failure just points to one and only obvious reason - wrong key.

Answer 2

I don't understand exactly what you mean but I would recommend to have look at the Padding Oracle attack SSL/TLS which used MAC-then-encrypt i.e. the attacker can figure out stuff about the plaintext by using MAC errors and PAD errors. Because the plaintext was MACed, contrary to encrypt-then-mac

However, me personally would have choosd AES counter mode instead of CBC. Because it has some advantages in terms of performance, no padding etc.