21.1 Lucky 13

In 2013, Nadhem AlFardan and Kenneth Paterson, two researchers from the Information Security Group at Royal Holloway, University of London, published a new attack that can recover plaintexts by exploiting timing differences in the decryption process of then-current TLS versions 1.1 and 1.2 [4].

Lucky 13 – we will explain the reason for the attack’s unusual name in a moment – targets the TLS Record protocol. More specifically, it exploits an implementation detail stemming from a recommendation in the TLS 1.1 and 1.2 standards.

If, during decryption, Alice encounters a TLS record with malformed padding, she still has to perform MAC verification to prevent trivial timing attacks (we will talk more about timing attacks and, in general, side-channel attacks in Chapter 22, Attacks on TLS Implementations). The question is, what data should Alice use for that calculation?

The TLS 1.1 and 1.2 standards recommend checking the MAC as if it had a zero-length padding. They also remark that ”this leaves a small timing channel, since MAC performance depends to some extent on the size of the data fragment, but it is not believed to be large enough to be exploitable, due to the large block size of existing MACs and the small size of the timing signal.”

AlFardan and Paterson discovered that this recommendation indeed introduces a timing signal and that – contrary to the statement in the standards – this timing signal can be exploited to compromise TLS security.

21.1.1 The encryption process

The TLS Record protocol of the vulnerable TLS versions uses a MAC-Encode-Encrypt (MEE) construction. As shown in Figure 21.1, sender Bob first computes the MAC tag using the actual payload to be transmitted and certain header bytes as input to the MAC algorithm. All MAC algorithms in TLS 1.1 and 1.2 are HMAC based, with MD5, SHA-1, and SHA-256 being the available hash functions. The header consists of an 8-byte sequence number SQN, which Bob increments with each transmitted TLS record, and a 5-byte field HDR, which holds a 2-byte version field, a 1-byte type field, and a 2-byte length field.

Figure 21.1: TLS 1.1 encryption process. The order of operations is MAC-Encode-Encrypt (MEE)

Next, Bob computes padding bytes to ensure that the byte length of the final data that will be encrypted is an integer multiple of the block cipher’s block size. To ensure that receiver Alice can tell the actual data and the padding apart, the padding bytes must follow a specific format.

In TLS 1.1 and 1.2, padding must consist of at least one byte, and the value of padding bytes must be equal to the number of bytes added. So, valid padding sequences are 0x00 when no bytes were added, 0x01∥0x01 when 1 padding byte was added, 0x02∥0x02∥0x02 when 2 padding bytes were added, and so on.

Finally, to encrypt the data using the CBC mode of operation, Bob concatenates the payload, the MAC tag, and the padding into an integer number of plaintext blocks pj, and computes the ciphertext blocks as:

where c0 is the initialization vector and the supported block ciphers are DES, 3DES, or AES in the case of TLS 1.1 and 3DES or AES in the case of TLS 1.2.

Later in this chapter, we will see that the MEE construction together with the CBC mode of operation gives rise to several more attacks.