Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

On the Security of TLS-DHE in the Standard Model

826 views

Published on

Tibor Jager, Florian Kohlar, Sven Schäge, and Jörg Schwenk
Horst Görtz Ins,tute for IT Security, Bochum
1st BIU Security Day: The Current Status of TLS Security
May 1, 2016
Bar-Ilan University, Israel
Sponsored by vpnMentor.com

Published in: Internet
  • Be the first to comment

On the Security of TLS-DHE in the Standard Model

  1. 1. On the Security of TLS-DHE in the Standard Model Tibor Jager, Florian Kohlar, Sven Schäge, and Jörg Schwenk Horst Görtz Ins,tute for IT Security, Bochum 1st BIU Security Day: The Current Status of TLS Security May 1, 2016 Bar-Ilan University, Israel 1
  2. 2. TLS and SSL Versions 2 SSL 1.0 and 2.0 (Netscape) 1994 1995 SSL 3.0 (Netscape & MicrosoY PCT) 1999 TLS 1.0 (=SSL 3.1) (IETF standard) 2006 2008 TLS 1.2 TLS 1.1 •  This talk: TLS ≈ TLS 1.0 ≈ TLS 1.1 ≈ TLS 1.2 •  This talk is not about TLS 1.3! 2016? TLS 1.3
  3. 3. Support of TLS versions in prac`ce 3 SSL Labs, haps://www.trustworthyinternet.org/ssl-pulse/, Jan 5, 2016 TLS v1.3 (2016?) (1999) (1995) (1994) (2006) (2008) Support of more than one version is very common
  4. 4. TLS Sessions: Handshake + Record Layer 4 1. Handshake Handshake: •  Nego`a`on of cryptographic parameters (selec`on of Cipher Suite) •  Authen7ca7on •  Establishment of session key k Client Server
  5. 5. TLS Sessions: Handshake + Record Layer 5 1. Handshake 2. Record Layer Handshake: •  Nego`a`on of cryptographic parameters (selec`on of Cipher Suite) •  Authen7ca7on •  Establishment of session key k Record Layer: •  Data encryp7on and authen7ca7on using key k Client Server
  6. 6. Cipher Suites •  Standardized selec7on of algorithms for key exchange, signature, encryp`on, hashing – TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA •  3 groups of Cipher Suites: – Ephemeral Diffie-Hellman (TLS-DHE) – Sta`c Diffie-Hellman (TLS-DH) – RSA encryp`on (TLS-RSA) – Handshake protocol is (slightly) different for each group 6
  7. 7. Cipher Suites •  Standardized selec7on of algorithms for key exchange, signature, encryp`on, hashing – TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA •  3 families of Cipher Suites: – Ephemeral Diffie-Hellman (TLS-DHE) – Sta`c Diffie-Hellman (TLS-DH) – RSA encryp`on (TLS-RSA) – Handshake protocol is (slightly) different for each group 7
  8. 8. The Cryptographic Core of the TLS-DHE Handshake 8 C has signature key (pkC, skC) S has signature key (pkS, skS)
  9. 9. The Cryptographic Core of the TLS-DHE Handshake 9 C has signature key (pkC, skC) S has signature key (pkS, skS) rC, supported Cipher Suites rS, selected Cipher Suite 1. Cipher suite agreement:
  10. 10. The Cryptographic Core of the TLS-DHE Handshake 10 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, Sig(skS; gs, some previous data) gc, Sig(skC; gc, some previous data) pms = gcs k = PRF(ms;L2,rC,rS) ms = PRF(pms;L1,rC,rS) pms = gcs k = PRF(ms;L2,rC,rS) ms = PRF(pms;L1,rC,rS) 2. Key exchange: s ß Zq c ß Zq
  11. 11. The Cryptographic Core of the TLS-DHE Handshake 11 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, Sig(skS; gs, some previous data) gc, Sig(skC; gc, some previous data) pms = gcs k = PRF(ms;L2,rC,rS) ms = PRF(pms;L1,rC,rS) pms = gcs 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: “Accept” key k with partner C s ß Zq c ß Zq
  12. 12. The Cryptographic Core of the TLS-DHE Handshake 12 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, Sig(skS; gs, some previous data) gc, Sig(skC; gc, some previous data) pms = gcs k = PRF(ms;L2,rC,rS) ms = PRF(pms;L1,rC,rS) pms = gcs 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
  13. 13. Secure Authen`cated Key Exchange •  Desired proper`es: –  Authen7ca7on of communica`on partners –  Good cryptographic keys •  Several security models formalizing this no`on –  We use enhanced version of Bellare-Rogaway [BR’93] •  Adopted to the public-key sewng •  Cf. Blake-Wilson et al. [BJM’99] •  Model described by two components: –  Execu7on model –  Security defini7on 13
  14. 14. Secure Authen`cated Key Exchange •  Desired proper`es: –  Authen7ca7on of communica`on partners –  Good cryptographic keys •  Several security models formalizing this no`on –  We use enhanced version of Bellare-Rogaway [BR’93] •  Adopted to the public-key sewng •  Cf. Blake-Wilson et al. [BJM’99] •  Model described by two components: –  Execu7on model –  Security defini7on 14
  15. 15. Secure Authen`cated Key Exchange •  Desired proper`es: –  Authen7ca7on of communica`on partners –  Good cryptographic keys •  Several security models formalizing this no`on –  We use enhanced version of Bellare-Rogaway [BR’93] •  Adopted to the public-key sewng •  Cf. Blake-Wilson et al. [BJM’99] •  Model described by two components: –  Execu7on model –  Security defini7on 15
  16. 16. Execu`on Model 16 Protocol Π C1 (pkC1,skC1) C2 (pkC2,skC2) C3 (pkC3,skC3) S1 (pkS1,skS1) S2 (pkS2,skS2) S3 (pkS3,skS3)
  17. 17. 17 Execu`on Model C1 (pkC1,skC1) C2 (pkC2,skC2) C3 (pkC3,skC3) S1 (pkS1,skS1) S2 (pkS2,skS2) S3 (pkS3,skS3)
  18. 18. 18 Execu`on Model C1 (pkC1,skC1) C2 (pkC2,skC2) C3 (pkC3,skC3) S1 (pkS1,skS1) S2 (pkS2,skS2) S3 (pkS3,skS3) skC1
  19. 19. 19 Execu`on Model C1 (pkC1,skC1) C2 (pkC2,skC2) C3 (pkC3,skC3) S1 (pkS1,skS1) S2 (pkS2,skS2) S3 (pkS3,skS3) skC1 k
  20. 20. Security Defini`on 20 •  Aaacker 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 dis7nguishes “real” from “random” key Protocol Π C (pkC,skC) S (pkS,skS)
  21. 21. Security Defini`on 21 •  Aaacker 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 dis7nguishes “real” from “random” key Protocol Π C (pkC,skC) S (pkS,skS) “accept” with key k and partner S
  22. 22. Security Defini`on 22 •  Aaacker 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 dis7nguishes “real” from “random” key “Test” k / rnd “real” / “random” Protocol Π C (pkC,skC) S (pkS,skS) “accept” with key k and partner S
  23. 23. The TLS Handshake is not a Provably Secure AKE Protocol 23 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
  24. 24. The TLS Handshake is not a Provably Secure AKE Protocol •  Enc(k;constS,finS) allows to dis7nguish real key k from random –  Applies to TLS-DHE, TLS-DHS, and TLS-RSA –  Theore7cal aFack in the security model 24 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
  25. 25. Unsa`sfying Situa`on •  TLS is the most important security protocol in prac`ce •  TLS Handshake is insecure in any AKE security model based on key-indis`nguishability •  Two approaches to resolve this issue: 1.  Consider “truncated” TLS Handshake [MSW’10], without encryp7on of FINISHED messages 2.  Develop a new security model 25
  26. 26. Unsa`sfying Situa`on •  TLS is the most important security protocol in prac`ce •  TLS Handshake is insecure in any AKE security model based on key-indis`nguishability •  Two approaches to resolve this issue: 1.  Consider “truncated” TLS Handshake [MSW’10], without encryp7on of FINISHED messages 2.  Develop a new security model 26
  27. 27. 1st Approach: “Truncated TLS” 27 finS finS = PRF(ms; L3,prev. data) finC = PRF(ms; L4,prev. data) finC 2. Key exchange 1. Ciphersuite agreement 3. FINISHED messages: “Accept” key k with partner S “Accept” key k with partner C
  28. 28. 1st Approach: “Truncated TLS” 28 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 Handshake is a secure AKE protocol, if •  the PRF is a secure pseudo-random func7on, •  the digital signature scheme is EUF-CMA secure, •  the DDH assump7on holds, and •  the PRF-ODH assump7on holds “Accept” key k with partner S “Accept” key k with partner C
  29. 29. Comparison to Previous Work Morrissey, Smart, Warinschi ‘10 Our work Bellare-Rogaway Model Bellare-Rogaway Model TLS_DHE, TLS_DH, TLS_RSA1 TLS_DHE Random Oracle Model Standard Model2 29 1 Assumes different RSA encryp`on scheme 2 Requires PRF-ODH assump`on Modular analysis Monolithic analysis Truncated TLS: Morissey, Smart, Warinschi ‘10
  30. 30. Comparison to Previous Work Morrissey, Smart, Warinschi ‘10 Our work Bellare-Rogaway Model Bellare-Rogaway Model TLS_DHE, TLS_DH, TLS_RSA1 TLS_DHE Random Oracle Model Standard Model2 30 1 Assumes different RSA encryp`on scheme 2 Requires PRF-ODH assump`on Modular analysis Monolithic analysis Truncated TLS: Morissey, Smart, Warinschi ‘10 Both results do not consider the real TLS Handshake…!
  31. 31. 2nd Approach: New Security Model •  Secure AKE provides indis7nguishable keys –  Key can be used in any further applica7on –  Too strong for TLS Handshake –  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? 31
  32. 32. 2nd Approach: New Security Model •  Secure AKE provides indis7nguishable keys –  Key can be used in any further applica7on –  Too strong for TLS Handshake –  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? 32 but
  33. 33. Authen`cated Confiden`al Channel Establishment (ACCE) •  Simple extension of the AKE model: – Explicit authen7ca7on of communica`on partners – Good cryptographic keys Authen7cated and confiden7al channel •  ACCE considers Handshake + Record Layer – Encryp`ons should be indis7nguishable – Ciphertexts should be authen7cated 33
  34. 34. TLS-DHE is a Secure ACCE Protocol 34 Theorem: TLS-DHE is a secure ACCE protocol, if •  the PRF is a secure pseudo-random func7on, •  the digital signature scheme is EUF-CMA secure, •  the DDH assump7on holds in the Diffie-Hellman group, •  the PRF-ODH assump7on holds, and •  the Record Layer cipher is secure (sLHAE)
  35. 35. TLS-DHE is a Secure ACCE Protocol 35 Theorem: TLS-DHE is a secure ACCE protocol, if •  the PRF is a secure pseudo-random func7on, •  the digital signature scheme is EUF-CMA secure, •  the DDH assump7on holds in the Diffie-Hellman group, •  the PRF-ODH assump7on holds, and •  the Record Layer cipher is secure (sLHAE) Stateful Length-Hiding Authen7cated Encryp7on [PRS’11]: •  Security no`on for symmetric ciphers •  Captures exactly what is expected from TLS Record Layer •  Achieved by CBC-based ciphersuites in TLS 1.1 and 1.2
  36. 36. The PRF-ODH Assump`on 36 •  Let G = <g> be a group with order p, let PRF : G x M à R be a func`on
  37. 37. The PRF-ODH Assump`on 37 Adversary A Challenger C m∈M •  Let G = <g> be a group with order p, let PRF : G x M à R be a func`on
  38. 38. The PRF-ODH Assump`on 38 Adversary A Challenger C m∈M U,V∈G PRF(guv,m) or rand∈R •  Let G = <g> be a group with order p, let PRF : G x M à R be a func`on U := gu, V := gv where u,v ß Zp
  39. 39. The PRF-ODH Assump`on 39 Adversary A Challenger C m∈M U,V∈G PRF(guv,m) or rand∈R W∈G,m’∈M PRF(Wu,m’) •  Let G = <g> be a group with order p, let PRF : G x M à R be a func`on U := gu, V := gv where u,v ß Zp
  40. 40. The PRF-ODH Assump`on 40 Adversary A Challenger C m∈M U,V∈G PRF(guv,m) or rand∈R “real” or “random” W∈G,m’∈M PRF(Wu,m’) •  Let G = <g> be a group with order p, let PRF : G x M à R be a func`on U := gu, V := gv where u,v ß Zp
  41. 41. The PRF-ODH Assump`on •  PRF-ODH assump7on: no efficient aaacker can dis`nguish PRF(guv,m) from random –  Variant of Oracle Diffie-Hellman assump`on [ABR’01] 41 Adversary A Challenger C m∈M U,V∈G PRF(guv,m) or rand∈R “real” or “random” W∈G,m’∈M PRF(Wu,m’) •  Let G = <g> be a group with order p, let PRF : G x M à R be a func`on U := gu, V := gv where u,v ß Zp
  42. 42. The PRF-ODH Assump`on •  PRF-ODH assump7on: no efficient aaacker can dis`nguish PRF(guv,m) from random –  Variant of Oracle Diffie-Hellman assump`on [ABR’01] 42 Adversary A Challenger C m∈M U,V∈G PRF(guv,m) or rand∈R “real” or “random” W∈G,m’∈M PRF(Wu,m’) •  Let G = <g> be a group with order p, let PRF : G x M à R be a func`on U := gu, V := gv where u,v ß Zp
  43. 43. Is PRF-ODH really necessary? •  Not if –  no corrup7ons of long-term secrets are allowed, or –  small changes are made to TLS-DHE Handshake •  E.g. making it more similar to Σ0 [CK’02] •  Impossible to avoid, if –  security model with corrup7ons is considered, and –  reduc`on uses aFacker and PRF as black-box 43
  44. 44. Is PRF-ODH really necessary? •  Not if –  no corrup7ons of long-term secrets are allowed, or –  small changes are made to TLS-DHE Handshake •  E.g. making it more similar to Σ0 [CK’02] •  Impossible to avoid, if –  security model with corrup7ons is considered, and –  reduc`on uses aFacker and PRF as black-box 44
  45. 45. Subsequent Works using ACCE (This work: CRYPTO 2012) •  Further TLS cipher suites: –  Krawczyk et al., Crypto 2013 –  Li et al., PKC 2014 •  Secure re-nego`a`on of TLS session keys: –  Giesen et al., CCS 2013 •  Other prac`cal protocols: –  EMV channel establishment (Brzuska et al., CCS 2013) –  SSH (Bergsma et al., CCS 2014) –  QUIC (Lychev et al., S&P 2015). 45
  46. 46. Subsequent Works using ACCE (This work: CRYPTO 2012) •  Further TLS cipher suites: –  Krawczyk et al., Crypto 2013 –  Li et al., PKC 2014 •  Secure re-nego`a`on of TLS session keys: –  Giesen et al., CCS 2013 •  Other prac`cal protocols: –  EMV channel establishment (Brzuska et al., CCS 2013) –  SSH (Bergsma et al., CCS 2014) –  QUIC (Lychev et al., S&P 2015). 46 ACCE: Not beau`ful, but useful
  47. 47. ACCE: Not beau`ful, but useful 47 The ACCE security model Cryptographers analyzing “real-world” protocols
  48. 48. Subsequent Works on the Provable Security of TLS <= 1.2 (This work: CRYPTO 2012) For example: •  Krawczyk, Paterson, Wee (CRYPTO 13): ACCE-based analysis of TLS-RSA and TLS-sDH •  Bhargavan e.a. (Oakland 13): Formally-verified implementa`on of TLS (miTLS) •  Alterna`ves to ACCE: –  Brzuska et al. (Informa`on Security 2013): Relaxed yet composable security no`ons for key exchange –  Bharghavan e.a. (CRYPTO 14): Use real-or-random key for encryp`on of FIN-message 48
  49. 49. Subsequent Works on the Provable Security of TLS 1.3 For example: •  Krawczyk, Wee (Euro-S&P 16): Theore`cally-sound founda`on of TLS 1.3 •  Dowling, Fischlin, Günther, Stebila (ACM CCS 2015): Formal analysis of TLS 1.3 handshake candidates •  Cremers, Horvat, Scoa, Van Der Merwe (Oakland 16): Automated Analysis of TLS 1.3 •  … 49
  50. 50. Summary •  New ACCE security model •  First full security proof for TLS-DHE •  Many follow-up works, but also many open problems: – TLS is much more complex – we (and subsequent “pencil-and-paper” proofs) considered only the cryptographic core – Other promising approaches: •  Verified implementa`ons (miTLS) •  Automated Analysis (see Thyla’s talk) 50
  51. 51. Summary •  New ACCE security model •  First full security proof for TLS-DHE •  Many follow-up works, but also many open problems: – TLS is much more complex – we (and subsequent “pencil-and-paper” proofs) considered only the cryptographic core – Other promising approaches: •  Verified implementa`ons (miTLS) •  Automated Analysis (see Thyla’s talk) 51 Thank you!

×