143 lines
5.0 KiB
Markdown
143 lines
5.0 KiB
Markdown
# Padding Oracle Attacks
|
||
|
||
#### Block Cipher Modes
|
||
|
||
- Most messages don’t come in convenient 128-bit block lengths
|
||
- We’ll need to run a block cipher repeatedly on consecutive blocks
|
||
- Why not use stream ciphers?
|
||
- Historically, stream ciphers have proven harder to implement
|
||
|
||
##### Padding
|
||
|
||
- ECB and some other modes require message length to be a multiple of the block size
|
||
- Public Key Cryptography Standards `PKCS7` is a common padding scheme:
|
||
1. Padding bytes are always added to the plaintext **before it is encrypted**
|
||
2. Each padding byte has a *value equal to the total number of padding bytes* that are added
|
||
3. The total number of padding bytes is **at least one**
|
||
|
||
- 
|
||
|
||
- Note in this example there are 7 `7`s and 16 `16`s
|
||
- Note that in the bottom-left example there is 1 `1`. This could be interpreted as 1 byte of padding or some plaintext. This is why every block must contain at least one padding byte
|
||
|
||
### Electronic Code Book Mode (ECB)
|
||
|
||
- Just encrypt each block one after another
|
||
- This is quick as it can be easily parallelised
|
||
|
||
|
||
|
||
#### Weaknesses
|
||
|
||
- If $x_1$ and $x_3$ are the same, then $y_1$ and $y_3$ are also the same.
|
||
- ECB allows an attacker to infer information on the plaintext
|
||
- Consider a hypothetical bank transfer between two banks that use a fixed key, where the message format is roughly known
|
||
|
||
|
||
|
||
- If we start splicing parts of messages together, we can send a legitimate looking message to the bank
|
||
- We could also use a chosen plaintext attack by requesting a bank transfer, finding our bank account info and splicing that with another message
|
||
- ECB divulges whenever messages or blocks are the same
|
||
|
||
|
||
|
||
> Here the RGB pixel data of this image has been encrypted using AES in ECB mode
|
||
|
||
### Deterministic vs Probabilistic Encryption
|
||
|
||
- An encryption scheme is **deterministic** if some plaintext is mapped to a fixed ciphertext if the key is unchanged
|
||
- ECB is deterministic, but most modern modes of operation are **probabilistic**
|
||
- Probabilistic encryption schemes add randomness to the encryption process to achieve a non-deterministic generation of the ciphertext
|
||
|
||
|
||
|
||
- $r$ is not a secret
|
||
|
||
#### Cipher Block Chaining (CBC)
|
||
|
||
- `XOR` the output of each cipher block with the next input
|
||
- $IV$ - **Initialisation Vector**
|
||
- The initial random seed that randomises the whole stream
|
||
- If you encrypted the same plaintext later it will be different
|
||
- An attacker will be unable to tell if $y_1$ and $y_2$ are the same message but with different $IV$ or different messages with different $IV$
|
||
|
||
|
||
|
||
$$
|
||
y_1 = e_k(x_1 \oplus IV) \\
|
||
y_i = e_k(x_i \oplus y_{i-1})
|
||
$$
|
||
|
||
##### CBC Decryption
|
||
|
||
- Similar to encryption, but now `XOR` takes place after decryption
|
||
- This is much easier to parallelise
|
||
|
||
|
||
|
||
$$
|
||
x_1 = d_k(y_1) \oplus IV \\
|
||
x_i = d_k(y_i) \oplus y_{i-1}
|
||
$$
|
||
|
||
- If we lost $y_1$ we would be unable to decrypt $y_2$
|
||
- We would be able to decrypt $y_3$ though
|
||
|
||
##### Weaknesses
|
||
|
||
- CBC was the primary method of encryption for many years
|
||
- Now it is less common
|
||
|
||
- 
|
||
|
||
- If you flip the first bit in $y_2$, the same bit is flipped for $x_3$
|
||
- Changing $y_2$ means $x_2$ no longer decrypts properly
|
||
|
||
### Padding Oracles
|
||
|
||
- Here, an **oracle** is a system we can query and it will tell us if, once decrypted, some text has **valid padding**
|
||
- A system is unlikely to tell you directly, but it might give away some clue
|
||
- Imagine an example `api` that receives a CBC-encrypted authorisation token
|
||
|
||
|
||
|
||
#### Padding Oracle Attacks
|
||
|
||
- Let's look at a single decryption block in CBC
|
||
- The attack is essentially the same for multiple blocks, just one at a time
|
||
- You attack the last block, which contains the padding
|
||
|
||
> The general strategy is to manipulate bits in the IV to find valid padding and recover $z_i$
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
### Counter Mode (CTR)
|
||
|
||
- Encrypt a nonce + counter and use this to mask the plaintext with `XOR`
|
||
- This is very easily parallelised
|
||
- Each block is encrypted differently, avoiding the issues with ECB mode
|
||
|
||
|
||
|
||
- We are now using our block cipher as a stream cipher
|
||
- The keystream generation (AES) is run through blocks
|
||
- Decrypting is super easy, just the reverse
|
||
|
||
### Galois Counter Mode
|
||
|
||
- Extends counter mode to add authenticity
|
||
- The sender definitely sent that message and it hasn’t been modified
|
||
- Very similar to counter mode, but **adds an authentication tag**
|
||
- Uses multiplication in a Galois Finite field $GF(2^{128})$ modulo $x^{128} + x^7 + x^2 + x + 1$
|
||
- Extremely parallelisable
|
||
- Robust to message modification
|
||
- Is now standard in `TLS1.3`
|
||
|
||
|