A Standard-‐Model Security Analysis of TLS-‐DHE
Tibor Jager1, Florian Kohlar2, Sven Schäge3, and Jörg Schwenk2
1 Karlsruhe Ins-tute of Technology 2 Horst Görtz Ins-tute for IT Security, Bochum
3 University College London
Royal Holloway, University of London March 29, 2012
1
Outline
• Some facts about TLS • AuthenNcated Key Exchange (AKE) – TLS Handshake is not a secure AKE protocol – Truncated TLS Handshake is provably secure
• Auth. ConfidenNal Channel Establishment (ACCE) – ACCE security model – Full TLS is a secure ACCE protocol
• InterpretaNon, extensions, open problems
2
Outline
• Some facts about TLS • AuthenNcated Key Exchange (AKE) – TLS is not a secure AKE protocol – Truncated TLS is provably secure
• Auth. ConfidenNal Channel Establishment (ACCE) – ACCE security model – Security proof of full TLS
• InterpretaNon, extensions, open problems
3
Network
Transport
Data Link
Session
PresentaNon
ApplicaNon
Physical
Network
Transport
Data Link
Session
PresentaNon
ApplicaNon
Physical
Transport Layer Security (TLS)
4
TLS 🔒
Confiden3al and authen3c communicaNon channel
hZp, smtp, imap, pop3, [p, sip, …
Client Server
TLS and SSL
5
SSL 1.0 and 2.0 (Netscape)
1994 1995
SSL 3.0 (Netscape & Microso[ PCT)
1999
TLS 1.0 (=SSL 3.1) (IETF standard)
2006 2008
TLS 1.2 TLS 1.1
• TLS 1.0 and 1.1 are sNll widely used • In this talk: TLS ≈ TLS 1.0 ≈ TLS 1.1 ≈ TLS 1.2
TLS Sessions: Handshake + Record Layer
6
1. Handshake
2. Record Layer
Handshake: • NegoNaNon of cryptographic parameters (selecNon of Cipher Suite)
• (Mutual) authen3ca3on • Establishment of session key k
Record Layer: • Data encryp3on and authen3ca3on using key k
Client Server
Cipher Suites • Standardized selec3on of algorithms for key exchange, signature, hashing, encrypNon – TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
• 3 families of Cipher Suites: – Ephemeral Diffie-‐Hellman (TLS_DHE) – StaNc Diffie-‐Hellman (TLS_DH) – RSA encrypNon (TLS_RSA)
• Cipher Suite determines sequence and content of messages in handshake
7
TLS_DHE Handshake
8
C has signature key (pkC, skC)
S has signature key (pkS, skS)
rC, supported Cipher Suites
rS, selected Cipher Suite
1. Cipher suite agreement:
gs mod p, Sig(skS; all previous data) gc mod p, Sig(skC; all previous data) pms = gcs mod p
k = PRF(ms;L2,rC,rS) ms = PRF(pms;L1,rC,rS)
pms = gcs mod p
k = PRF(ms;L2,rC,rS) ms = PRF(pms;L1,rC,rS)
2. Key exchange:
Enc(k;constS, finS) finS = PRF(ms; L3,prev. data)
finC = PRF(ms; L4,prev. data)
“Accept” key k with partner S
Enc(k;constC, finC)
3. FINISHED messages:
Is this secure?
“Accept” key k with partner C
s ß Zq c ß Zq
Outline
• Some facts about TLS • AuthenNcated Key Exchange (AKE) – TLS is not a secure AKE protocol – Truncated TLS is provably secure
• Auth. ConfidenNal Channel Establishment (ACCE) – ACCE security model – Security proof of full TLS
• InterpretaNon, extensions, open problems
9
Secure AuthenNcated Key Exchange
• Desired properNes: – Authen3ca3on of communicaNon partners – Good cryptographic keys
• Several security models formalizing this noNon – We use enhanced version of Bellare-‐Rogaway [BR’93]
• Adopted to the public-‐key sesng • Cf. Blake-‐Wilson et al. [BJM’99]
• Model described by two components: – Execu3on model – Security defini3on
10
ExecuNon Model
11
Protocol Π
C1 (pkC1,skC1)
C2 (pkC2,skC2)
C3 (pkC3,skC3)
S1 (pkS1,skS1)
S2 (pkS2,skS2)
S3 (pkS3,skS3)
12
ExecuNon Model C1
(pkC1,skC1) C2
(pkC2,skC2)
C3 (pkC3,skC3)
S1 (pkS1,skS1)
S2 (pkS2,skS2)
S3 (pkS3,skS3)
13
ExecuNon Model C1
(pkC1,skC1) C2
(pkC2,skC2)
C3 (pkC3,skC3)
S1 (pkS1,skS1)
S2 (pkS2,skS2)
S3 (pkS3,skS3)
skC1
k
skC2,k
Security DefiniNon
14
• AZacker breaks the protocol if 1. C (or S) “accepts” with partner S (or C), but
S and C do not have matching conversa-ons, or 2. it dis3nguishes “real” from “random” key
“Test” k / rnd
“real” / “random”
Protocol Π
“accept” with key k and partner S
C (pkC,skC) S
(pkS,skS)
The TLS Handshake is not a Secure AKE Protocol
• Enc(k;constS,finS) allows to dis3nguish real key k from random
• AJack: Given k’ ∈ {k,rnd}, – Compute m’ = Dec(k’,(Enc(k;constS,finS)) – If m’ = (constS,finS) then output “real” – Else output “random”
• Applies to TLS_DHE, TLS_DHS, and TLS_RSA 15
Enc(k;constS, finS) finS = PRF(ms; L3,prev. data)
finC = PRF(ms; L4,prev. data) Enc(k;constC, finC)
2. Key exchange
1. Cipher suite agreement
3. FINISHED messages:
“Accept” key k with partner S
“Accept” key k with partner C
UnsaNsfying SituaNon
• TLS is the most important security protocol • TLS handshake is insecure in any indisNnguishability-‐based security model
• Two approaches to resolve this issue: 1. Consider a “truncated” TLS handshake,
without encryp3on of FINISHED messages 2. Develop a new security model which allows to
analyze full TLS (handshake + record layer)
16
1st Approach: Truncated TLS
17
finS finS = PRF(ms; L3,prev. data)
finC = PRF(ms; L4,prev. data) finC
2. Key exchange
1. Ciphersuite agreement
3. FINISHED messages:
Theorem: Truncated TLS-‐DHE is secure in the Bellare-‐Rogaway model, if • the PRF is a secure pseudo-‐random func3on, • the digital signature scheme is EUF-‐CMA secure, • and the DDH assump3on holds in the Diffie-‐Hellman group
“Accept” key k with partner S
“Accept” key k with partner C
Proof Sketch
18
C has signature key (pkC, skC)
S has signature key (pkS, skS)
rC, supported cipher suites
rS, selected cipher suite (here: eDH)
1. Cipher suite agreement:
gs mod p, Sig(skS; all previous data) gc mod p, Sig(skC; all previous data) pms = gcs mod p
k = PRF(ms;L2,rC,rS) ms = PRF(pms;L1,rC,rS)
pms = gcs mod p
k = PRF(ms;L2,rC,rS) ms = PRF(pms;L1,rC,rS)
2. Key exchange:
finS finS = PRF(ms; L3,prev. data)
finC = PRF(ms; L4,prev. data) finC
3. FINISHED messages:
“Accept” key k with partner S
“Accept” key k with partner C
Proof Sketch
19
C has signature key (pkC, skC)
S has signature key (pkS, skS)
rC, supported cipher suites
rS, selected cipher suite (here: eDH)
1. Cipher suite agreement:
gs mod p, Sig(skS; all previous data) gc mod p, Sig(skC; all previous data) pms = gcs mod p
k = PRF(ms;L2,rC,rS) ms = PRF(pms;L1,rC,rS)
pms = gcs mod p
k = PRF(ms;L2,rC,rS) ms = PRF(pms;L1,rC,rS)
2. Key exchange:
finS finS = PRF(ms; L3,prev. data)
finC = PRF(ms; L4,prev. data) finC
3. FINISHED messages:
“Accept” key k with partner S
“Accept” key k with partner C
Proof Sketch
20
C has signature key (pkC, skC)
S has signature key (pkS, skS)
rC, supported cipher suites
rS, selected cipher suite (here: eDH)
1. Cipher suite agreement:
gs mod p, Sig(skS; all previous data) gc mod p, Sig(skC; all previous data) pms = gr mod p
k = PRF(ms;L2,rC,rS) ms = PRF(pms;L1,rC,rS)
pms = gr mod p
k = PRF(ms;L2,rC,rS) ms = PRF(pms;L1,rC,rS)
2. Key exchange:
finS finS = PRF(ms; L3,prev. data)
finC = PRF(ms; L4,prev. data) finC
3. FINISHED messages:
“Accept” key k with partner S
“Accept” key k with partner C
Proof Sketch
21
C has signature key (pkC, skC)
S has signature key (pkS, skS)
rC, supported cipher suites
rS, selected cipher suite (here: eDH)
1. Cipher suite agreement:
gs mod p, Sig(skS; all previous data) gc mod p, Sig(skC; all previous data) pms = gr mod p
k = PRF(ms;L2,rC,rS) ms = R(L1,rC,rS)
pms = gr mod p
k = PRF(ms;L2,rC,rS) ms = R(L1,rC,rS)
2. Key exchange:
finS finS = PRF(ms; L3,prev. data)
finC = PRF(ms; L4,prev. data) finC
3. FINISHED messages:
“Accept” key k with partner S
“Accept” key k with partner C
Proof Sketch
22
C has signature key (pkC, skC)
S has signature key (pkS, skS)
rC, supported cipher suites
rS, selected cipher suite (here: eDH)
1. Cipher suite agreement:
gs mod p, Sig(skS; all previous data) gc mod p, Sig(skC; all previous data) pms = gr mod p
k = R’(L2,rC,rS) ms = R(L1,rC,rS)
pms = gr mod p
k = R’(L2,rC,rS) ms = R(L1,rC,rS)
2. Key exchange:
finS finS = R’(L3,prev. data)
finC = R’(L4,prev. data) finC
3. FINISHED messages:
“Accept” key k with partner S
“Accept” key k with partner C
Comparison to Previous Work
Morrissey, Smart, Warinschi ‘10 Our work Bellare-‐Rogaway Model Bellare-‐Rogaway Model
Modular analysis Monolithic analysis TLS_DHE, TLS_DH, TLS_RSA* TLS_DHE
Random Oracle Model Standard Model
23
* Assumes determinisNc OW-‐CPA or OW-‐CCA secure encrypNon scheme
Truncated TLS: Morissey, Smart, Warinschi ‘10
Both results do not consider real TLS…!
2nd Approach: New Security Model • Secure AKE provides indis3nguishable keys – Key can be used for any further applica3on – Too strong for TLS – Stronger than necessary: TLS uses keys for Record Layer
• Can we describe a new security model which is – strong enough to provide security, but – weak enough to be achievable by TLS?
24
but
Outline
• Some facts about TLS • AuthenNcated Key Exchange (AKE) – TLS is not a secure AKE protocol – Truncated TLS is provably secure
• Auth. ConfidenNal Channel Establishment (ACCE) – ACCE security model – Security proof of full TLS
• InterpretaNon, extensions, open problems
25
AuthenNcated ConfidenNal Channel Establishment (ACCE)
• Simple extension of the BR model: – Explicit authen3ca3on of communicaNon partners – Good cryptographic keys Authen3cated and confiden3al communicaNon channel
• Model described by two components: – Execu3on model – Security defini3on
26
27
ACCE ExecuNon Model C1
(pkC1,skC1) C2
(pkC2,skC2)
C3 (pkC3,skC3)
S1 (pkS1,skS1)
S2 (pkS2,skS2)
S3 (pkS3,skS3)
m
Enc(k,m)
c Dec(k,c) skC1
k
skC2,k
ACCE Security DefiniNon
28
• AZacker breaks the protocol if 1. S (or C) “accepts” with partner S, but
S and C do not have matching conversa-ons, or 2. Dis3nguishes encryp3on of m from rnd 3. It forges a new valid ciphertext C’ for key k
“Test”, m
Enc(k;m) / Enc(k;rnd)
“real” / ”random”
“accept” with key k and partner S
C (pkC,skC) S
(pkS,skS) Protocol Π
or C’
TLS-‐DHE is a Secure ACCE Protocol
29
Theorem: TLS-‐DHE is a secure ACCE protocol, if • the PRF is a secure pseudo-‐random func3on, • the digital signature scheme is EUF-‐CMA secure, • and the DDH assump3on holds in the Diffie-‐Hellman group • the record layer cipher is secure (sLHAE)
sLHAE [Paterson, Ristenpart, Shrimpton ’11]: • Security noNon for symmetric ciphers • Captures exactly what is expected from TLS
• Proof of Theorem = Truncated TLS proof + extra step for Record Layer
• Do the TLS Cipher Suites meet these condiNons?
Security Requirements on TLS Building Blocks (1/2)
DDH assump3on: • TLS uses prime-‐order subgroup of Zp* or ECC PRF security: • TLS 1.2: Security proof by Fouque, Pointcheval, Zimmer ’08
• Prior TLS versions: similar to TLS 1.2
30
Security Requirements on TLS Building Blocks (2/2)
EUF-‐CMA security of digital signatures: • RSASSA-‐PKCS#1 v1.5: No proof • DSA, ECDSA: Proofs only in the ROM • No aJacks
sLHAE-‐security of Record Layer protocol: • MAC-‐Encode-‐Encrypt in CBC mode: Security proof by Paterson, Ristenpart, Shrimpton ’11
• Stream-‐cipher-‐based Cipher Suites: Not invesNgated yet.
31
Outline
• Some facts about TLS • AuthenNcated Key Exchange (AKE) – TLS is not a secure AKE protocol – Truncated TLS is provably secure
• Auth. ConfidenNal Channel Establishment (ACCE) – ACCE security model – Security proof of full TLS
• InterpretaNon, extensions, open problems
32
InterpretaNon (1/2)
• Current TLS cipher suites: – Assume EUF-‐CMA secure signature scheme à complete standard-‐model proof
– Includes TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (mandatory in TLS 1.0)
• Composi3on of building blocks in TLS_DHE is sound – Recipe for provably secure TLS Cipher Suite
33
InterpretaNon (2/2) • TLS designed without provable security in mind – PKCS#1 v1.5 encrypNon – Choice of signature schemes – MAC-‐then-‐Encrypt
• Existence of standard model security proof disNngushes TLS_DHE from – Schnorr signatures, – DSA, ECDSA, – RSA Full-‐Domain Hash, – RSA-‐PKCS#1 v1.5 encrypNon and signature, – RSA-‐OAEP, etc.
34
Extensions • Server-‐only authenNcaNon – AZacker “wins”, if it modifies any message, and this is not detected by the client
• Server authenNcaNon via TLS + client authenNcaNon via passwords
• Security of TLS-‐based single sign-‐on protocols – Currently invesNgated in Bochum
• Perfect Forward Secrecy – Provided by ephemeral Diffie-‐Hellman
35
Open Problems • Existence of standard-‐model security proofs for – Cipher Suites based on RSA key transport
• Different message sequence • Would (most likely) require CCA security • RSA-‐PKCS#1 v1.5 is CCA-‐insecure [Bleichenbacher ’98]
– Cipher Suites based on sta3c Diffie-‐Hellman • No signatures over the first handshake messages • SimulaNon of “honest” key exchanges is problemaNc
• Streamcipher-‐based Record Layer protocols • Security against side-‐channel aJacks
36
Summary
• Standard-‐model security proof for Truncated TLS • New ACCE security model for TLS-‐like protocols • Full TLS is a secure ACCE protocol • Many open problems
37
Thank you for your aJen3on!