Secure Crypto: “Lucky Thirteen” Attack

By Sean Parkinson, Consultant Software Engineer

Once again an attack against TLS has been published and again the attack targets cipher suites that use Cipher Block Chaining (CBC) mode encryption. This Man-in-the-Middle attack is easier to perpetrate than the previous Man-in-the-Browser attacks like “BEAST” and “CRIME,” but results in many failed TLS connections and requires statistical analysis of packet response times, which makes this plaintext recovery attack less practical.

This article will discuss the Lucky Thirteen attacks as applied to TLS and DTLS, the practicalities of the attack, and how to mitigate the attack.

Lucky Thirteen

Nadhelm Al Fardan and Kenny Paterson at Royal Holloway, University of London, developed the Lucky Thirteen attack. The name “Lucky Thirteen” was given to the attack because of how TLS performs the MAC calculation when authenticating packet data. The details of how the attack works are complicated and a summary follows.

A prerequisite for the attack is the ability to Man-in-the-Middle the connection between the client and server to read the clear text TLS handshake messages and inject modified ciphertext. This is most commonly achieved on an unsecured WiFi network.

By reading the handshake messages, the attacker knows that a vulnerable cipher suite was negotiated. Any cipher suite using CBC mode encryption, regardless of cipher or digest, is vulnerable. Cipher suites using SHA-1 are most easily attacked and were, until TLS v1.2, the most commonly used for reasons of security strength. The rest of the attack description assumes the use of SHA-1.

Once the attacker has established a vulnerable cipher suite is in use, they wait for application data to be sent. The client authenticates using HMAC-SHA1, and encrypts using a cipher in CBC mode. The data authenticated is:

|Sequence|Header|App Data|

|       8|     5|       n|

and the data encrypted is:

|Enc App Data|Enc MAC Tag|Enc Padding|

|           n|         20|          p|

Notice that the sequence and header in the authenticated data add up to 13 bytes. This is where the title of the paper comes from. The MAC tag is calculated using the sequence, header and application data: 13 + n. The CBC mode encryption is then performed on the application data, MAC tag and padding bytes: n + 20 + p.

Lucky Thirteen uses the same attack mechanism as the Padding Oracle Attack so this needs to be explained at this point.

Padding Oracle Attack

The Padding Oracle Attack was found to be applicable to implementations of SSL 3.0 and TLS 1.0. The SSL 3.0 and TLS 1.0 specifications state that if the decryption process fails due to a padding error, then an alert is sent. If the padding is correct then the MAC tag is checked. If the MAC tag is wrong then an alert is sent. Therefore the amount of work performed is dependent on whether the padding is correct. This means that alerts are sent at time differentials that can be distinguished.

CBC mode decryption takes the current encrypted block, decrypts it, and XORs in the previous ciphertext block. The Padding Oracle Attack uses this to determine the plaintext by modifying the previous ciphertext block. The first step in the attack is to truncate the message so that the plaintext to recover is the last block, where the padding is expected. Next the attack modifies the second last encrypted block. The last byte is XORed with a guess at the last plaintext byte. If the guess is correct, the last byte now decrypts to 0×00 – one byte of padding. Therefore, the decryption operation succeeds and the MAC operation is performed to check the authenticity of the data. The attacker detects that more time elapses before the alert is sent.

This attack was remediated by always performing the MAC. Most SSL 3.0 and TLS 1.0 implementations have this fix. TLS 1.1 specifications and beyond require the MAC operation be performed regardless of padding errors.

Back to Lucky Thirteen

Nadhelm and Kenny have found that always performing the MAC operation is not enough. The Lucky Thirteen attack assumes that the MAC is performed but finds differences in the amount of worked performed depending on the number of padding bytes.

In their example using TLS 1.1 and 1.2, the first application data packet is cut down to 85 bytes. The server interprets the packet as containing:

|Header|IV|Enc App Data|Enc MAC Tag|Enc Padding|

|     5|16|      44 – p|         20|          p|

Where p is the number of valid padding bytes. TLS requires the server decrypt:

|Enc App Data|Enc MAC Tag|Enc Padding|

|      44 – p|         20|          p|

Then, the authentication is performed on:

|Sequence|Header|App Data|

|       8|     5|  44 – p|

If no padding bytes are valid then p is 0 bytes and the application data is 44 bytes.

There are three scenarios to consider:

1. The padding is wrong and 57 bytes are MACed.
2. The last plaintext byte is 0×00 and 56 bytes are MACed.
3. The last two plaintext bytes are 0×01, 0×01 and 55 bytes are MACed.

The attack tries different values in the second last ciphertext block, this time in the last two bytes, in an attempt to force the last plaintext block to be the correct two bytes of padding. The attacker wants 55 bytes to be authenticated with HMAC-SHA1 because this can be distinguished computationally from 56 or 57 bytes. To understand why, an explanation of how SHA-1 processes its input data is required.

SHA-1

SHA-1 has an input block size of 64 bytes. That is, SHA-1 buffers up to 64 bytes before mixing the input with the internal state. But, the last thing SHA-1 and other hash functions do before generating the output is add padding of at least 1 byte and 8 bytes holding the length of the input data for a minimum of 9 extra bytes of input data. Therefore the last block of application data can be at most 55 bytes long.

And Back to Lucky Thirteen Again …

Therefore in scenarios 1 and 2 above, 66 (= 57 + 9) and 65 (= 56 + 9) bytes respectively, are mixed into the state which results in two blocks being processed. In Scenario 3, 64 (= 55 + 9) bytes are mixed into the state which results in one block being processed.

The thirteen is ‘lucky’ as only two bytes of padding need to be guessed: 55 authenticated bytes (13 header bytes + 42 application data bytes) and 64 decrypted bytes (42 application data bytes + 20 MAC tag + 2 padding bytes). As noted in the paper, 12 bytes would only require one byte of padding to be guessed and would have been ‘luckier’.

Practicalities of the Attack

In practice, to distinguish between the different scenarios requires measuring the difference between when the modified packet is sent and when the alert message is received. Looking for a difference of a thousand clock cycles, or 0.5 microseconds, when communicating across the Internet is a tall order.

Instead the authors found that each guess needed to be used multiple times – in fact, 128 times. By using basic statistical techniques the timing difference can be discerned. The experimental results used a single core server, but on a busy multi-processor server that uses a secure random (i.e. a noisy server system) it might not be as easy as described. If the TLS server is on an embedded system then the statistical analysis might prove more effective.

One important problem with the attack is that each attempt causes the TLS server to drop the connection. The packets being sent, even when the padding is correct, are not valid. If a client causes many failed connections on a continuous basis, hopefully the server will block them.

The attack can also be used on DTLS connections. DTLS is TLS over datagram protocols like UDP. UDP is unreliable. That is, the packets might not arrive, might come in out of order or might be corrupted. Therefore DTLS does not treat decryption and authentication errors as fatal and will keep accepting bad packets and reporting errors. DTLS is far more vulnerable to this attack than TLS.

Mitigation

The simplest way to protect against the “Lucky Thirteen” attack is to disable CBC cipher suites on the client and server. This leaves cipher suites that use RC4 and, if TLS 1.2 is available, AES-GCM.

Patches are being released that authenticate the same number of blocks regardless of padding. It is recommended that TLS servers be patched as soon as practically possible.

Summary

The “Lucky Thirteen” attack required the careful analysis of the TLS protocol and its use of cryptographic algorithms. It is not surprising that only now, many years after TLS 1.1 and 1.2 were released to fix the original Padding Oracle Attack, a new attack has been devised. The practicality of the attack is still in question when applied to heavily loaded TLS server machines, but DTLS and embedded TLS servers are easier targets.

While it is not clear that the attack is practical in all cases, it is clear that fixes need to be implemented to all TLS and DTLS servers.

Keep your servers secure by using secure cryptographic protocols.

Sean Parkinson is a Consultant Software Engineer at RSA based in Brisbane, Australia.