# Lucky Thirteen

## Summary

The Lucky Thirteen vulnerability is a TLS vulnerability based on the Padding Oracle Attack. It was discovered by Nadhem AlFardan and Kenny Paterson (University of London) in 2013 and named as CVE-2013-0169. The Lucky Thirteen attack is a timing-side channel attack where the answer times of the server are analyzed.

## The Padding Oracle Attack

The Padding Oracle Attack is a TLS vulnerability which allows an attacker to retrieve the original plaintext from the ciphertext. There are 4 main things needed for the attack:

- XOR Operation
- Block Cipher (CBC Mode)
- Padding Standard
- Oracle

## XOR Operation

The XOR operation (short for "exclusive OR") is a logical operation that takes two input values and returns an output value of true (1) if and only if exactly one of the input values is true (1). If both input values are true or both input values are false, the output value is false (0). The truth table for the XOR operation is shown below:

The XOR operation is done byte-by-byte, bit-by-bit and it is important that if there are two known values it is possible to get the remaining:

- A ⨁ B = C
- A ⨁ C = B
- B ⨁ C = A

## Block Cipher (CBC Mode)

In CBC Mode the Plaintext is encrypted with the Initialization Vector and the key through XOR Operation.

- Encryption

- Decryption

### Padding Standard

With CBC-Mode the Ciphertext is split into Blocks. All Blocks have the same length of 8 bits. So, it could be necessary to fil up the last bits with padding.

A common system of padding is Public Key Cryptography Standard #7, or PKCS #7.

### Oracle

The Oracle is the server who answers to the question if the padding is valid.

## The attack

There are some important points for the attack:

- A “yes” from the Oracle helps narrow down things further than a “no“
- The attacker knows the ciphertext (and therefore the ciphertext blocks)
- The attacker can control which ciphertext is input into the Padding Oracle
- By changing the ciphertext input, the attacker also changes the decrypted plaintext that the Padding Oracle sees
- Force the decrypted plaintext to have valid padding by manipulating the input ciphertext

The attacker changes the last bit of the ciphertext t1 and waits for the server to answer if the padding is valid or invalid. If the padding is valid the attacker knows the last bit of C1 (t1) and the last bit of P2 (01). So X1 = t1 ⨁ 01. With this the attacker can guess the plaintext.

## Mitigation

- No answer from the server if the padding is valid or not
- Leads to timing attack (Lucky thirteen)
- Write the code in such a way that success and error cases consume same time so that an attacker cannot measure the time difference.
- Do not use CBC-Mode Encryption

## References

- Seminar paper

- References

- Kenny Paterson. Lucky 13, beast, crime, ... is tls dead, or just resting?, 2022.
- Pratik Guha Sarkar and Shawn Fitzgerald. Attacks on ssl a comprehensive study of beast, crime, time, breach, lucky 13 & rc4 biases. August 2013.
- Nadhem J. AlFardan and Kenneth G. Paterson. Lucky Thirteen: Breaking the TLS and DTLS Record Protocols. February 2013.

- Links

- https://en.wikipedia.org/wiki/Exclusive_or
- https://www.elektronik-kompendium.de/sites/dig/0205186.htm#:~:text=Das%20XOR%20ist%20ein%20zusammengeschaltetes,A%20und%20B%20ungleich%20sind
- https://web.engr.oregonstate.edu/~rosulekm/crypto/padding.html#attack
- https://samsclass.info/141/proj/p14pad.htm
- https://medium.com/@c0D3M/lucky-13-attack-explained-dd9a9fd42fa6
- https://www.youtube.com/watch?v=4EgD4PEatA8