Online Cryptography Course Dan Boneh

Authenticated Encryption

Active attacks on
CPA-secure encryption

Dan Boneh
 Recap: the story so far
Confidentiality: semantic security against a CPA attack
• Encryption secure against eavesdropping only

Integrity:
• Existential unforgeability under a chosen message attack
• CBC-MAC, HMAC, PMAC, CW-MAC

This module: encryption secure against tampering

• Ensuring both confidentiality and integrity

Dan Boneh
 Sample tampering attacks
TCP/IP: (highly abstracted)

a WWW
dat port = 80
packet
dest = 80 data

source machine
TCP/IP
stack Bob
port = 25
destination machine
Dan Boneh
 Sample tampering attacks
IPsec: (highly abstracted)

a WWW
TCP/IP dat port = 80
packet stack
dest = 80 data
stuff

dest = 25 stuff
k
k
packets encrypted Bob
port = 25
using key k
Dan Boneh
 Reading someone else’s data
Note: attacker obtains decryption of any ciphertext
beginning with “dest=25”
WWW
IV, dest = 80 data port = 80

Bob: data

k IV’, dest = 25 data

k
Bob
Easy to do for CBC with rand. IV port = 25

(only IV is changed)
Dan Boneh
IV , dest = 80 data IV’ , dest = 25 data

Encryption is done with CBC with a random IV.

What should IV’ be? m[0] = D(k, c[0]) ⨁ IV = “dest=80…”

IV’ = IV ⨁ (…25…)
IV’ = IV ⨁ (…80…)
IV’ = IV ⨁ (…80…) ⨁ (…25…)
It can’t be done
 An attack using only network access
Remote terminal app.: each keystroke encrypted with CTR mode
TCP/IP packet
k
IP hdr TCP hdr T D

k 16 bit TCP checksum 1 byte keystroke

for all t, s send: IP hdr TCP hdr ⨁t ⨁s

ACK if valid checksum, nothing otherwise

{ checksum(hdr, D) = t ⨁ checksum(hdr, D⨁s) } ⇒ can find D

Dan Boneh
 The lesson
CPA security cannot guarantee secrecy under active attacks.

Only use one of two modes:

• If message needs integrity but no confidentiality:
use a MAC
• If message needs both integrity and confidentiality:
use authenticated encryption modes (this module)

Dan Boneh
End of Segment

Dan Boneh
Online Cryptography Course Dan Boneh

Authenticated Encryption

Definitions

Dan Boneh
 Goals
An authenticated encryption system (E,D) is a cipher where
As usual: E: K × M × N ⟶ C
but D: K × C × N ⟶ M ∪{⊥}

ciphertext
Security: the system must provide is rejected
• sem. security under a CPA attack, and
• ciphertext integrity:
attacker cannot create new ciphertexts that decrypt
properly Dan Boneh
 Ciphertext integrity
Let (E,D) be a cipher with message space M.
m1  M m2 , …, mq
Chal. Adv.
kK c1  E(k,m1) c2 , …, cq

c
b
b=1 if D(k,c) ≠⊥ and c  { c1 , … , cq }
b=0 otherwise

Def: (E,D) has ciphertext integrity if for all “efficient” A:

Adv [A,E] = Pr[Chal. outputs 1] is “negligible.” Dan Boneh
 Authenticated encryption
Def: cipher (E,D) provides authenticated encryption (AE) if it is
(1) semantically secure under CPA, and
(2) has ciphertext integrity

Bad example: CBC with rand. IV does not provide AE

• D(k,⋅) never outputs ⊥, hence adv. easily wins CI game

Dan Boneh
 Implication 1: authenticity
Attacker cannot fool Bob into thinking a
message was sent from Alice

m1 , …, mq c
Alice Bob
ci = E(k, mi)
k k
Cannot create
valid c ∉ { c1, …, cq }

⇒ if D(k,c) ≠⊥ Bob knows message is from someone who knows k

(but message could be a replay)
Dan Boneh
 Implication 2

Authenticated encryption ⇒

Security against chosen ciphertext attacks

(next segment)

Dan Boneh
End of Segment

Dan Boneh
Online Cryptography Course Dan Boneh

Authenticated Encryption

Chosen ciphertext
attacks

Dan Boneh
 Example chosen ciphertext attacks
Adversary has ciphertext c that it wants to decrypt
• Often, adv. can fool server into decrypting certain ciphertexts (not c)

dest = 25 data data

• Often, adversary can learn partial information about plaintext

TCP/IP packet ACK

if valid
checksum
Dan Boneh
 Chosen ciphertext security

Adversary’s power: both CPA and CCA

• Can obtain the encryption of arbitrary messages of his choice
• Can decrypt any ciphertext of his choice, other than challenge
(conservative modeling of real life)

Adversary’s goal: Break sematic security

Dan Boneh
 Chosen ciphertext security: definition
E = (E,D) cipher defined over (K,M,C). For b=0,1 define EXP(b):

Chal. for i=1,…,q: Adv.

b (1) CPA query:
kK
mi,0 , mi,1  M : |mi,0| = |mi,1|
ci  E(k, mi,b)

(2) CCA query:

ci  C : ci ∉ {c1, …, ci-1}

mi  D(k, ci) b’  {0,1}

Dan Boneh
 Chosen ciphertext security: definition
E is CCA secure if for all “efficient” A:
AdvCCA [A,E] = |Pr[EXP(0)=1] – Pr[EXP(1)=1] | is “negligible.”

Example: CBC with rand. IV is not CCA-secure

m0 , m1 : |m0| = |m1|=1
Chal. Adv.
b c  E(k, mb) = (IV, c[0])
kK
c’ = (IV⨁1, c[0])
b
D(k, c’) = mb⨁1
Dan Boneh
 So what?
Authenticated encryption:
• ensures confidentiality against an active adversary
that can decrypt some ciphertexts

Limitations:
• does not prevent replay attacks
• does not account for side channels (timing)

Dan Boneh
End of Segment

Dan Boneh
Online Cryptography Course Dan Boneh

Authenticated Encryption

Constructions from
ciphers and MACs

Dan Boneh
 … but first, some history
Authenticated Encryption (AE): introduced in 2000 [KY’00, BN’00]

Crypto APIs before then: (e.g. MS-CAPI)

• Provide API for CPA-secure encryption (e.g. CBC with rand. IV)
• Provide API for MAC (e.g. HMAC)

Every project had to combine the two itself without

a well defined goal
• Not all combinations provide AE …
Dan Boneh
 Combining MAC and ENC (CCA)
Encryption key kE. MAC key = kI

Option 1: (SSL) S(kI, m) E(kE , mlltag)

msg m msg m tag

Option 2: (IPsec)
E(kE, m) S(kI, c)
always msg m tag
correct
Option 3: (SSH) S(kI, m)
E(kE , m)
msg m tag
Dan Boneh
 A.E. Theorems
Let (E,D) be CPA secure cipher and (S,V) secure MAC. Then:

1. Encrypt-then-MAC: always provides A.E.

2. MAC-then-encrypt: may be insecure against CCA attacks

however: when (E,D) is rand-CTR mode or rand-CBC
M-then-E provides A.E.
for rand-CTR mode, one-time MAC is sufficient
Dan Boneh
 Standards (at a high level)
• GCM: CTR mode encryption then CW-MAC (HW1)
(accelerated via Intel’s PCLMULQDQ instruction)
• CCM: CBC-MAC then CTR mode encryption (802.11i) (HW2)
• EAX: CTR mode encryption then CMAC (HW3)
All support AEAD: (auth. enc. with associated data). All are nonce-based.
encrypted

associated data encrypted data

authenticated
Header of the file need integrity not encryption Dan Boneh
 An example API (OpenSSL)
int AES_GCM_Init(AES_GCM_CTX *ain,
unsigned char *nonce, unsigned long noncelen,
unsigned char *key, unsigned int klen )

int AES_GCM_EncryptUpdate(AES_GCM_CTX *a,

unsigned char *aad, unsigned long aadlen,
unsigned char *data, unsigned long datalen,
unsigned char *out, unsigned long *outlen)
Dan Boneh
 MAC Security -- an explanation
Recall: MAC security implies (m , t) ⇏ (m , t’ )
Why? Suppose not: (m , t) ⟶ (m , t’)
Then Encrypt-then-MAC would not have Ciphertext Integrity !!

m0, m1
Chal. Adv.
b c  E(k, mb) = (c0, t) (c0, t)
kK
c’ = (c0 , t’ ) ≠ c
(c0, t’) b
D(k, c’) = mb
Dan Boneh
 OCB: a direct construction from a PRP
More efficient authenticated encryption: one E() op. per block.

m[0] m[1] m[2] m[3] checksum

P(N,k,0)  P(N,k,1)  P(N,k,2)  P(N,k,3)  P(N,k,0) 

E(k,) E(k,) E(k,) E(k,) E(k,)

P(N,k,0)  P(N,k,1)  P(N,k,2)  P(N,k,3)  auth 

c[0] c[1] c[2] c[3] c[4]

Dan Boneh
 Performance: Crypto++ 5.6.0 [ Wei Dai ]

AMD Opteron, 2.2 GHz ( Linux)

code Speed
Cipher size (MB/sec)

AES/GCM large **
108 AES/CTR 139
AES/CCM smaller 61 AES/CBC
109
AES/EAX smaller 61
AES/CMAC 109
AES/OCB 129* HMAC/SHA1 147
* extrapolated from Ted Kravitz’s results ** non-Intel machines
Dan Boneh
End of Segment

Dan Boneh
Online Cryptography Course Dan Boneh

Authenticated Encryption

Case study: TLS

Dan Boneh
 The TLS Record Protocol (TLS 1.2)

HDR TLS record

TLS:- MAC then Encrypt

kb⇾s , ks⇾b kb⇾s , ks⇾b
Unidirectional keys: kb⇾s and ks⇾b

Stateful encryption:
• Each side maintains two 64-bit counters: ctrb⇾s , ctrs⇾b
• Init. to 0 when session started. ctr++ for every record.
• Purpose: replay defense
Dan Boneh
 TLS record: encryption (CBC AES-128, HMAC-SHA1)

MAC then Encrypt type ll ver ll len

kb⇾s = (kmac , kenc)
data
Type:- type of the packet
Ver:- version of the protocol tag pad
Len:- the length of the packet

Browser side enc(kb⇾s , data, ctrb⇾s ) :

step 1: tag ⟵ S( kmac , [ ++ctrb⇾s ll header ll data] )

step 2: pad [ header ll data ll tag ] to AES block size
step 3: CBC encrypt with kenc and new random IV
What is the difference between TLS and normal
step 4: prepend headerMAC then Encrypt?why? Dan Boneh
 TLS record: decryption (CBC AES-128, HMAC-SHA1)

Server side dec(kb⇾s , record, ctrb⇾s ) :

step 1: CBC decrypt record using kenc
step 2: check pad format: send bad_record_mac if
invalid
step 3: check tag on [ ++ctrb⇾s ll header ll data]
send bad_record_mac if invalid

Provides authenticated encryption

(provided no other info. is leaked during decryption) Dan Boneh
 Bugs in older versions (prior to TLS 1.1)
IV for CBC is predictable: (chained IV)
IV for next record is last ciphertext block of current record.
Not CPA secure. (a practical exploit: BEAST attack)
Exam
Padding oracle: during decryption
if pad is invalid send decryption failed alert
if mac is invalid send bad_record_mac alert
⇒ attacker learns info. about plaintext (attack in next segment)
Lesson: when decryption fails, do not explain why
Dan Boneh
 Leaking the length
The TLS header leaks the length of TLS records
• Lengths can also be inferred by observing network traffic

For many web applications, leaking lengths reveals sensitive info:

• In tax preparation sites, lengths indicate the type of return being
filed which leaks information about the user’s income
• In healthcare sites, lengths leaks what page the user is viewing
• In Google maps, lengths leaks the location being requested

No easy solution
Dan Boneh
 802.11b WEP: how not to do it
802.11b WEP:
m CRC(m)

k PRG( IV ll k ) k
IV ciphetext

Previously discussed problems:

two time pad and related PRG seeds

Dan Boneh
 Active attacks
Fact: CRC is linear, i.e. ∀m,p: CRC( m ⨁ p) = CRC(m) ⨁ F(p)

WEP ciphertext: IV dest-port = 80 data CRC

⨁
attacker: 000…….00…..XX…0000… F(XX)

XX = 25⨁80 IV dest-port = 25 data CRC’

Upon decryption: CRC is valid, but ciphertext is changed !!

Dan Boneh
End of Segment

Dan Boneh
Online Cryptography Course Dan Boneh

Authenticated Encryption

CBC paddings attacks

Dan Boneh
 Recap
Authenticated encryption: CPA security + ciphertext integrity
• Confidentiality in presence of active adversary
• Prevents chosen-ciphertext attacks

Limitation: cannot help bad implementations … (this segment)

Authenticated encryption modes:

• Standards: GCM, CCM, EAX
• General construction: encrypt-then-MAC
Dan Boneh
 The TLS record protocol (CBC encryption)
Decryption: dec(kb⇾s , record, ctrb⇾s ) :

step 1: CBC decrypt record using kenc

step 2: check pad format: abort if invalid

step 3: check tag on [ ++ctrb⇾s ll header ll data]

abort if invalid
type ll ver ll len
Two types of error:
data
• padding error
• MAC error tag pad
Dan Boneh
 Padding oracle
Suppose attacker can differentiate the two errors
(pad error, MAC error):

⇒ Padding oracle:
attacker submits ciphertext and learns if
last bytes of plaintext are a valid pad
type ll ver ll len

Nice example of a data

chosen ciphertext attack
tag pad
Dan Boneh
Padding oracle via timing OpenSSL

Credit: Brice Canvel

(fixed in OpenSSL 0.9.7a)

In older TLS 1.0: padding oracle due to different alert messages.

Dan Boneh
Using a padding oracle (CBC encryption)

Attacker has ciphertext c = (c[0], c[1], c[2]) and it wants m[1]

IV c[0] c[1] c[2]

D(k,) D(k,) D(k,)

  
m[0] m[1] m[2] ll pad

Dan Boneh
Using a padding oracle (CBC encryption)

step 1: let g be a guess for the last byte of m[1]

IV c[0] c[1]
⨁ g ⨁ 0x01

D(k,) D(k,)
= last-byte ⨁ g ⨁ 0x01
 
m[0] m[1]
if last-byte = g: valid pad
otherwise: invalid pad
Dan Boneh
Using a padding oracle (CBC encryption)

Attack: submit ( IV, c’[0], c[1] ) to padding oracle

⇒ attacker learns if last-byte = g

Repeat with g = 0,1, …, 255 to learn last byte of m[1]

Then use a (02, 02) pad to learn the next byte and so on …

Dan Boneh
 IMAP over TLS
Problem: TLS renegotiates key when an invalid record is received

Enter IMAP over TLS: (protocol for reading email)

• Every five minutes client sends login message to server: in order

to check if their new mails?
LOGIN "username” "password”

• Exact same attack works, despite new keys

⇒ recovers password in a few hours.
Dan Boneh
 Lesson

1. Encrypt-then-MAC would completely avoid this problem:

MAC is checked first and ciphertext discarded if invalid

2. MAC-then-CBC provides A.E., but padding oracle destroys it

Dan Boneh
Will this attack work if TLS used counter mode instead of CBC?
(i.e. use MAC-then-CTR )

Yes, padding oracles affect all encryption schemes

It depends on what block cipher is used
No, counter mode need not use padding
End of Segment

Dan Boneh
Online Cryptography Course Dan Boneh

Authenticated Encryption

Attacking non-atomic
decryption
 SSH Binary
This is CBC with IV is encrypted?CPA
Packet Protocol
CBC encryption (chained IV)
seq. packet pad MAC
payload pad
num. len. len. tag

SSH is encrypt and MAC?MAC is the MACed of the plaintext MAC computed
Decryption: over plaintext

• step 1: decrypt packet length field only (!)

• step 2: read as many packets as length specifies
• step 3: decrypt remaining ciphertext blocks
• step 4: check MAC tag and send error response if invalid
Dan Boneh
 An attack on the enc. length field (simplified)

Attacker has only one ciphertext block c = AES(k, m) and it wants m

one AES block
seq.
num.
c
k
decrypt
and obtain
len “len” field
send bytes one at a time

when “len” bytes read:

server sends “MAC error”
attacker learns 32 LSB bits of m !!
Dan Boneh
 Lesson
The problem: (1) non-atomic decrypt
(2) len field decrypted and used before it is authenticated

How would you redesign SSH to resist this attack?

Send the length field unencrypted (but MAC-ed)

Replace encrypt-and-MAC by encrypt-then-MAC
Add a MAC of (seq-num, length) right after the len field
Remove the length field and identify packet boundary
by verifying the MAC after every received byte
 Further reading
• The Order of Encryption and Authentication for Protecting
Communications, H. Krawczyk, Crypto 2001.
• Authenticated-Encryption with Associated-Data,
P. Rogaway, Proc. of CCS 2002.
• Password Interception in a SSL/TLS Channel,
B. Canvel, A. Hiltgen, S. Vaudenay, M. Vuagnoux, Crypto 2003.
• Plaintext Recovery Attacks Against SSH,
M. Albrecht, K. Paterson and G. Watson, IEEE S&P 2009
• Problem areas for the IP security protocols,
S. Bellovin, Usenix Security 1996.
Dan Boneh
End of Segment

Dan Boneh