|
When encrypting a message in TLS/SSL using block ciphers in CBC mode, a Message Authentication Code (MAC) of the message is calculated. Then the string containing (message + MAC) is padded so that the length of (message + MAC + padding) is a mutiple of the block cipher input size (8 bytes is the usual value). The concatenated (message + MAC + padding + length) is then cut into blocks of length the input size of the block cipher and encrypted with your chained block cipher.
When the encrypted message is received, it is first decrypted back into (message + MAC + padding + length). The validity of the padding is verified against the length. If the padding is found not to be valid, a padding error is generated. Otherwise the MAC value is then checked. If the MAC is not valid, a MAC error is generated.
In cases where multiple SSL or TLS connections have a fixed plaintext block in common (passwords are a common example), a real-time attacker can inject crafted ciphertext blocks in place of legitimate blocks of plaintext. This will generate an error, but the attacker can clock the time until a response arrives and differentiate between two different types of error conditions, a MAC verification error or a chained block cipher padding error. Knowing the difference between these two errors allows for eventual determination of the plaintext.
OpenSSL versions since 0.9.6c supposedly treat block cipher padding errors like MAC verification errors during record decryption, but MAC verification was still skipped after detection of a padding error, which allowed the timing attack. To fix this information leak, OpenSSL 0.9.6i, 0.9.7a, and later versions perform a MAC computation even if incorrrect block cipher padding has been found, thereby evening out the processing time and minimizing the information leak.
|
epfl.ch -
EPFL
