A channel has been established between two parties and they have come to share some secrets, at least a symmetric session key.
I had long assumed that ordinary symmetric encryption would authenticate packets from one party to the other for any packets formed without knowledge of the symmetric key would produce garbage upon decryption.
Several things can go wrong with this simple plan:
- Either
- the plain-text payload may not be redundant
- or the receiving program was designed assuming a strong error control and fails to apply redundancy checks
The system thinks it is behaving correctly whereas unknown corruption has occurred.
Garbage is acted upon leading to deleterious effects, which may achieve the attacker’s ends.
- The attacker may be a legitimate recipient of some of the plain-text.
If he can see the results of his introduced errors he may learn about shared secrets.
- The attacker may be a legitimate source of data to be transmitted.
This may allow him greater control in his attack.
He is likely to be a legitimate recipient if he is a legitimate source.
- If redundancy of plain-text is to be relied upon it must be strategically placed.
The self-synchronizing nature of CBC, once considered a benefit in the era before good error control, means that portions of low redundancy data within the plain text may be vulnerable even when the entire packet may otherwise have “enough checked redundancy”.
Note that high grade error control applied near the physical communications channel is:- peculiar to the failure modes of that channel
- does not involve secrets and can be easily subverted by an attacker.
The bottom line is that a communications protocol that is supposed to transmit the data, and only the data supplied by the source to the sink and only the sink, needs much more sophistication than simple checking of the natural redundancy of the plain-text, even if it is well encrypted.
In cases where compute cycles or bandwidth is dear, an efficient immodular design is possible but at the cost of accurate assessment and placement of redundancy in the plain-text.
This is a difficult design consideration to maintain as the system evolves.
There are several other better known integrity vulnerabilities:
- Replay or loss (number your messages and acknowledge receipt and demand acknowledgment)
- Replay after crash of recipient — dispense money from ATM like you did just before it crashed (keep message count in non-volatile memory)
- Send message back to sender (devote a bit in plain-text to identifying the sender)