TLS tripped up by "Lucky 13"

Researchers at Royal Holloway College, University of London, have discovered a technique which can be used to decrypt HTTP connections secured using TLS. With their method, PhD student Nadhem AlFardan and Professor Kenny Paterson exploit timing effects during decryption of TLS messages.

Such data is generally processed in cipher block chaining (CBC) mode. This involves encrypting fixed length blocks, padded out to the required length with padding bytes. Each padding byte contains information on how many padding bytes there are. If, for example, three padding bytes are required, three 0x2 bytes are used, if eight are required, eight 0x7 bytes are used. In TLS, in addition to the actual payload, each block contains a message authentication code (MAC), used to ensure the integrity of the data. This MAC does not, however, include the padding.

In TLS, the MAC value does not include the padding, which proves to be the key to this attack on the protocol
Source: Royal Holloway College, University of London

An attacker can copy and manipulate correctly encrypted data and send it on to the recipient for decryption. If the recipient responds with a padding error, rather than with a MAC error, this can be used to successively decrypt the data. A similar procedure to this padding oracle attack has previously been used to crack XML encryption.

SSL/TLS was also previously vulnerable to padding oracle attacks, but this has since been resolved by a series of patches. Current versions no longer return an error message when MAC checking fails. Time differences which could be used to identify incorrect padding have also been rendered harmless by calculating the MAC even when the padding is incorrect. A tiny time difference does, however, remain, since the decryption process does not know how many padding bytes it needs to remove. In this case, the recipient calculates the MAC over the entire block, including the damaged padding – this takes a little longer than it would if the padding were excluded from the calculation.

AlFardan and Paterson have now published a paper showing that these slight time differences can under some circumstances be exploited to completely decrypt TLS data. TLS always uses HMACs, which calculate the hash value for at most 55 bytes. The attack uses messages that are longer than 55 bytes with padding, but shorter than 55 bytes without padding. If the padding is damaged, the decryption process takes a little longer, as it has to calculate HMAC values for both the first 55 bytes and for the remainder.

The researchers carried out this attack on a LAN and were able to decrypt plain text after 2²³ sessions where SHA1 was used as the HMAC algorithm. If the attacker knows that the text is Base64 encoded, the number of sessions required is reduced to 2¹⁹. This is not quite good enough for a practical attack on TLS, but it can be used to attack the related DTLS (datagram TLS) protocol. In contrast to TLS, DTLS does not terminate a session immediately following an error.

At present, the attacks described can only be used at close proximity and only where the attacker is in a position to establish a sufficiently large number of sessions. AlFardan and Paterson therefore state that "the attacks do not pose a significant danger to ordinary users of TLS." They note, however, that it is a truism that attacks improve with time, "and we cannot anticipate what improvements to our attacks, or entirely new attacks, may yet be discovered."

The name "Lucky 13" originates from the fact that the header consists of 13 bytes, and that these are used in calculating the MAC value. Countermeasures are already available for some TLS implementations (GnuTLS, PolarSSL, CyaSSL, Opera and BouncyCastle). The OpenSSL developers have also released the updated versions 1.0.1d, 1.0.0k and 0.9.8v that are supposed to close the "Lucky 13" hole. The Firefox developers are still working to fix the browser's NSS. Microsoft states that its implementation is not affected. Apple was notified by the researchers, but has declined to comment. The hole has been given the CVE number CVE-2013-0169.

(fab)