Real-World Authenticated Key Exchange Tibor Jager Paderborn - - PowerPoint PPT Presentation

▶
real world authenticated key exchange
SMART_READER_LITE
LIVE PREVIEW

Real-World Authenticated Key Exchange Tibor Jager Paderborn - - PowerPoint PPT Presentation

Nov 19, 2022 223 likes •1.09k views

Real-World Authenticated Key Exchange Tibor Jager Paderborn University Summer School on Real-World Crypto and Privacy ibenik, Croatia June 17 th , 2019 Outline Security of the Diffie-Hellman Key Exchange Man-in-the-Middle attacks

slide-1
SLIDE 1

Real-World Authenticated Key Exchange

Tibor Jager Paderborn University Summer School on Real-World Crypto and Privacy Šibenik, Croatia June 17th, 2019

slide-2
SLIDE 2

Outline

  • Security of the Diffie-Hellman Key Exchange

– Man-in-the-Middle attacks – Forward Security

  • TLS 1.3

– Overview – The cryptographic core of TLS 1.3

  • Real-World Problems

– Problems arising from backwards compatibility – Middleboxes and ETS

  • Further reading, open research problems

2

slide-3
SLIDE 3

Diffie-Hellman Key Exchange

3

Public parameters: Group description (G,g,q) a ß {0, …, q-1} tA := ga b ß {0, …, q-1} tB = gb tA tB kAB := tBa kAB := tAb

slide-4
SLIDE 4

Man-in-the-middle Attack on DH

4

a ß {0, …, q-1} tA := ga b ß {0, …, q-1} tB = gb tA a’ ß {0, …, q-1} tA’ := ga’ tA’

slide-5
SLIDE 5

Man-in-the-middle Attack on DH

5

a ß {0, …, q-1} tA := ga b ß {0, …, q-1} tB = gb tA tB a’ ß {0, …, q-1} tA’ := ga’ tA’ b’ ß {0, …, q-1} tB’ := gb’ tB’

slide-6
SLIDE 6

Man-in-the-middle Attack on DH

6

a ß {0, …, q-1} tA := ga b ß {0, …, q-1} tB = gb tA tB a’ ß {0, …, q-1} tA’ := ga’ tA’ b’ ß {0, …, q-1} tB’ := gb’ tB’

kAB’ = gab’ kA’B = ga’b

slide-7
SLIDE 7

Man-in-the-middle Attack on DH

7

a ß {0, …, q-1} tA := ga b ß {0, …, q-1} tB = gb tA tB a’ ß {0, …, q-1} tA’ := ga’ tA’ b’ ß {0, …, q-1} tB’ := gb’ tB’

kAB’ = gab’ kA’B = ga’b

  • This is an active attack
  • DH is provably secure against passive (”eavesdropping”) attacks
slide-8
SLIDE 8

Signed Diffie-Hellman

8

Public parameters: Group description (G,g,q) pkA, pkB (pkB, skB) ß SigKeyGen() (pkA, skA) ß SigKeyGen()

slide-9
SLIDE 9

Signed Diffie-Hellman

9

Public parameters: Group description (G,g,q) pkA, pkB a ß {0, …, q-1} tA := ga sA := Sign(skA,tA) tA, sA (pkB, skB) ß SigKeyGen() (pkA, skA) ß SigKeyGen()

slide-10
SLIDE 10

Signed Diffie-Hellman

10

Public parameters: Group description (G,g,q) pkA, pkB a ß {0, …, q-1} tA := ga sA := Sign(skA,tA) b ß {0, …, q-1} tB = gb sB := Sign(skB,tB) tA, sA tB, sB (pkB, skB) ß SigKeyGen() (pkA, skA) ß SigKeyGen()

slide-11
SLIDE 11

Signed Diffie-Hellman

11

Public parameters: Group description (G,g,q) pkA, pkB a ß {0, …, q-1} tA := ga sA := Sign(skA,tA) b ß {0, …, q-1} tB = gb sB := Sign(skB,tB) tA, sA tB, sB If Vfy(pkB, tB, sB) = TRUE then: kAB := tBa If Vfy(pkA, tA, sA) = TRUE then: kAB := tAb (pkB, skB) ß SigKeyGen() (pkA, skA) ß SigKeyGen()

slide-12
SLIDE 12

Signed Diffie-Hellman

12

Public parameters: Group description (G,g,q) pkA, pkB a ß {0, …, q-1} tA := ga sA := Sign(skA,tA) b ß {0, …, q-1} tB = gb sB := Sign(skB,tB) tA, sA tB, sB If Vfy(pkB, tB, sB) = TRUE then: kAB := tBa If Vfy(pkA, tA, sA) = TRUE then: kAB := tAb (pkB, skB) ß SigKeyGen() (pkA, skA) ß SigKeyGen()

Security of the signature scheme prevents the MITM attack

slide-13
SLIDE 13

Forward Security

13

Objective: Make large-scale collection of encrypted data useless

slide-14
SLIDE 14

Forward Security

Time

14

Session 1 with Alice Session 3 with Charlie Session 2 with Bob Session 4 with Alice

Objective: Make large-scale collection of encrypted data useless

slide-15
SLIDE 15

Forward Security

Time

15

Secret key Session 1 with Alice Session 3 with Charlie Session 2 with Bob Session 4 with Alice

Objective: Make large-scale collection of encrypted data useless

slide-16
SLIDE 16

Forward Security

Time

16

Secret key Session 1 with Alice Session 3 with Charlie Session 2 with Bob Session 4 with Alice

Objective: Make large-scale collection of encrypted data useless

slide-17
SLIDE 17

Forward Security

Time

17

Secret key Session 1 with Alice Session 3 with Charlie Session 2 with Bob Session 4 with Alice

Objective: Make large-scale collection of encrypted data useless

slide-18
SLIDE 18

Forward Security

Time

18

Secret key Session 1 with Alice Session 3 with Charlie Session 2 with Bob Session 4 with Alice

Objective: Make large-scale collection of encrypted data useless

  • Widely used:
  • Standard security goal of modern protocols
slide-19
SLIDE 19

Forward Security of Signed DH

19

Public parameters: Group description (G,g,q) pkA, pkB a ß {0, …, q-1} tA := ga sA := Sign(skA,tA) b ß {0, …, q-1} tB = gb sB := Sign(skB,tB) tA, sA tB, sB If Vfy(pkBob, tB, sB) = TRUE then: kAB := tBa If Vfy(pkAlice, tA, sA) = TRUE then: kAB := tAb (pkB, skB) ß SigKeyGen() (pkA, skA) ß SigKeyGen()

Forward secure (if ephemeral exponents are not stored)

slide-20
SLIDE 20

Are we done?

  • Signed DH is a beautiful protocol…

– Clean and simple – Easy to implement and analyze – Forward Security

  • … but lacking features considered important in

the real world, for instance:

– How are public keys distributed? – No key confirmation – Fixed DH groups and signature schemes – Protocol for encryption of payload data not specified20

slide-21
SLIDE 21

Are we done?

  • Signed DH is a beautiful protocol…

– Clean and simple – Easy to implement and analyze – Forward Security

  • … but lacking features considered important in

the real world, for instance:

– How are public keys distributed? – No key confirmation – Fixed DH groups and signature schemes – Protocol for encryption of payload data not specified21

slide-22
SLIDE 22

Are we done?

  • Signed DH is a beautiful protocol…

– Clean and simple – Easy to implement and analyze – Forward Security

  • … but lacking features considered important in

the real world, for instance:

– How are public keys distributed? – No key confirmation – Fixed DH groups and signature schemes – Protocol for encryption of payload data not specified22

Further issues:

  • How to deal with errors

– Alert messages – Protocol spec.

  • Interoperability

– Message formats – Protocol headers

  • Possible extensions
  • Implementational issues
  • …
slide-23
SLIDE 23

Outline

  • Security of the Diffie-Hellman Key Exchange

– Man-in-the-Middle attacks – Forward Security

  • TLS 1.3

– Overview – The cryptographic core of TLS 1.3

  • Real-World Problems

– Problems arising from backwards compatibility – Middleboxes and ETS

  • Further reading, open research problems

23

slide-24
SLIDE 24

Network Transport Link Application Network Transport Link Application

Transport Layer Security (TLS)

Goal: provide confidential, authenticated, integrity-protected channel

24

TLS http, smtp, imap, pop3, ftp, sip, … Client Server Physical communication

slide-25
SLIDE 25

Network Transport Link Application Network Transport Link Application

Transport Layer Security (TLS)

Goal: provide confidential, authenticated, integrity-protected channel

25

TLS http, smtp, imap, pop3, ftp, sip, … Client Server Network communication

slide-26
SLIDE 26

TLS vs. SSL

26

SSL 1.0 and 2.0 (Netscape)

1994 1995

SSL 3.0 (Netscape & Microsoft PCT)

1999

TLS 1.0 (=SSL 3.1) (IETF standard)

2006 2008

TLS 1.2 TLS 1.1

2018

TLS 1.3

slide-27
SLIDE 27

Use of SSL/TLS Versions in Practice

27

https://www.ssllabs.com/ssl-pulse/

June 2019

slide-28
SLIDE 28

Use of SSL/TLS Versions in Practice

28

https://www.ssllabs.com/ssl-pulse/

June 2019

Standardized in 1999!

slide-29
SLIDE 29

Use of SSL/TLS Versions in Practice

29

https://www.ssllabs.com/ssl-pulse/

June 2019

Security protocols have an extremely long life time

Standardized in 1999!

slide-30
SLIDE 30

TLS Sessions: Handshake + Record Layer Encryption

30

  • 1. Handshake

Handshake:

  • Negotiation of cryptographic

algorithms (KE, Sig., Cipher Suite)

  • Authentication of comm. partners
  • Establishment of session key k

Client Server

slide-31
SLIDE 31

TLS Sessions: Handshake + Record Layer Encryption

31

  • 1. Handshake

Handshake:

  • Negotiation of cryptographic

algorithms (KE, Sig., Cipher Suite)

  • Authentication of comm. partners
  • Establishment of session key k

Client Server

Record Layer Encryption:

  • Data encryption and

authentication using key k

  • 2. Record Layer
slide-32
SLIDE 32

Server S

pk

The Cryptographic Core of the TLS 1.3 Handshake

Client

32

Server S

pk

The Cryptographic Core of the TLS 1.3 Handshake

Client

35 pkC

Optional

slide-33
SLIDE 33

Server S

pk

The Cryptographic Core of the TLS 1.3 Handshake

Client

33

Server S

pk

The Cryptographic Core of the TLS 1.3 Handshake

Client

35

slide-34
SLIDE 34

Server S

pk

The Cryptographic Core of the TLS 1.3 Handshake

Client

34

ClientHello:

  • Supported cipher suites,

sigs, (DH groups)

  • Client random rC
  • Diffie-Hellman share gc
slide-35
SLIDE 35

Server S

pk

The Cryptographic Core of the TLS 1.3 Handshake

Client

35

ServerHello:

  • Selected Cipher Suite
  • Server random rS
  • Diffie-Hellman share gs

ClientHello:

  • Supported cipher suites,

sigs, (DH groups)

  • Client random rC
  • Diffie-Hellman share gc
slide-36
SLIDE 36

Server S

pk

The Cryptographic Core of the TLS 1.3 Handshake

Client

36

ServerHello:

  • Selected Cipher Suite
  • Server random rS
  • Diffie-Hellman share gs

Replaced with HelloRetryRequest, if necessary

ClientHello:

  • Supported cipher suites,

sigs, (DH groups)

  • Client random rC
  • Diffie-Hellman share gc
slide-37
SLIDE 37

Server S

pk

The Cryptographic Core of the TLS 1.3 Handshake

Client

37

ServerHello:

  • Selected Cipher Suite
  • Server random rS
  • Diffie-Hellman share gs

k = KDF(gcs, rC, rS) k’ = KDF’(gcs, rC, rS) k = KDF(gcs, rC, rS) k’ = KDF’(gcs, rC, rS)

ClientHello:

  • Supported cipher suites,

sigs, (DH groups)

  • Client random rC
  • Diffie-Hellman share gc
slide-38
SLIDE 38

Server S

pk

The Cryptographic Core of the TLS 1.3 Handshake

Client

38

Signature over all previous messages

ServerHello:

  • Selected Cipher Suite
  • Server random rS
  • Diffie-Hellman share gs

Certified public key Certificate Verify

k = KDF(gcs, rC, rS) k’ = KDF’(gcs, rC, rS) k = KDF(gcs, rC, rS) k’ = KDF’(gcs, rC, rS) Encrypted with k

ClientHello:

  • Supported cipher suites,

sigs, (DH groups)

  • Client random rC
  • Diffie-Hellman share gc
slide-39
SLIDE 39

Server S

pk

The Cryptographic Core of the TLS 1.3 Handshake

Client

39

Signature over all previous messages

ServerHello:

  • Selected Cipher Suite
  • Server random rS
  • Diffie-Hellman share gs

Certified public key Certificate Verify

k = KDF(gcs, rC, rS) k’ = KDF’(gcs, rC, rS) k = KDF(gcs, rC, rS) k’ = KDF’(gcs, rC, rS)

Server Finished SFIN

Encrypted with k SFIN = MAC(k’, all prev. msgs.)

ClientHello:

  • Supported cipher suites,

sigs, (DH groups)

  • Client random rC
  • Diffie-Hellman share gc
slide-40
SLIDE 40

Server S

pk

The Cryptographic Core of the TLS 1.3 Handshake

Client

40

Signature over all previous messages

ServerHello:

  • Selected Cipher Suite
  • Server random rS
  • Diffie-Hellman share gs

Certified public key Certificate Verify

k = KDF(gcs, rC, rS) k’ = KDF’(gcs, rC, rS) k = KDF(gcs, rC, rS) k’ = KDF’(gcs, rC, rS)

Server Finished SFIN Client Finished CFIN

Encrypted with k SFIN = MAC(k’, all prev. msgs.) CFIN = MAC(k’, all prev. msgs.)

ClientHello:

  • Supported cipher suites,

sigs, (DH groups)

  • Client random rC
  • Diffie-Hellman share gc
slide-41
SLIDE 41

Server S

pk

The Cryptographic Core of the TLS 1.3 Handshake

Client

41

Signature over all previous messages

ServerHello:

  • Selected Cipher Suite
  • Server random rS
  • Diffie-Hellman share gs

Certified public key Certificate Verify

k = KDF(gcs, rC, rS) k’ = KDF’(gcs, rC, rS) k = KDF(gcs, rC, rS) k’ = KDF’(gcs, rC, rS)

Server Finished SFIN Client Finished CFIN

Encrypted with k SFIN = MAC(k’, all prev. msgs.) CFIN = MAC(k’, all prev. msgs.)

  • Public key distribution ✓
  • Key confirmation ✓
  • Possible to use various DH groups, signature and encryption schemes ✓
  • 1 RTT before cryptographically protected payload can be sent ✓

ClientHello:

  • Supported cipher suites,

sigs, (DH groups)

  • Client random rC
  • Diffie-Hellman share gc
slide-42
SLIDE 42

Server S

pk

The Cryptographic Core of the TLS 1.3 Handshake

Client

42

Signature over all previous messages

ServerHello:

  • Selected Cipher Suite
  • Server random rS
  • Diffie-Hellman share gs

Certified public key Certificate Verify

k = KDF(gcs, rC, rS) k’ = KDF’(gcs, rC, rS) k = KDF(gcs, rC, rS) k’ = KDF’(gcs, rC, rS)

Server Finished SFIN Client Finished CFIN

Encrypted with k SFIN = MAC(k’, all prev. msgs.) CFIN = MAC(k’, all prev. msgs.)

  • Public key distribution ✓
  • Key confirmation ✓
  • Possible to use various DH groups, signature and encryption schemes ✓
  • 1 RTT before cryptographically protected payload can be sent ✓

ClientHello:

  • Supported cipher suites,

sigs, (DH groups)

  • Client random rC
  • Diffie-Hellman share gc
slide-43
SLIDE 43

Server S

pk

The Cryptographic Core of the TLS 1.3 Handshake

Client

43

Signature over all previous messages

ServerHello:

  • Selected Cipher Suite
  • Server random rS
  • Diffie-Hellman share gs

Certified public key Certificate Verify

k = KDF(gcs, rC, rS) k’ = KDF’(gcs, rC, rS) k = KDF(gcs, rC, rS) k’ = KDF’(gcs, rC, rS)

Server Finished SFIN Client Finished CFIN

Encrypted with k SFIN = MAC(k’, all prev. msgs.) CFIN = MAC(k’, all prev. msgs.)

  • Public key distribution ✓
  • Key confirmation ✓
  • Possible to use various DH groups, signature and encryption schemes ✓
  • 1 RTT before cryptographically protected payload can be sent ✓

ClientHello:

  • Supported cipher suites,

sigs, (DH groups)

  • Client random rC
  • Diffie-Hellman share gc
slide-44
SLIDE 44

Server S

pk

The Cryptographic Core of the TLS 1.3 Handshake

Client

44

Signature over all previous messages

ServerHello:

  • Selected Cipher Suite
  • Server random rS
  • Diffie-Hellman share gs

ClientHello:

  • Supported cipher suites,

sigs, (DH groups)

  • Client random rC
  • Diffie-Hellman share gc

Certified public key Certificate Verify

k = KDF(gcs, rC, rS) k’ = KDF’(gcs, rC, rS) k = KDF(gcs, rC, rS) k’ = KDF’(gcs, rC, rS)

Server Finished SFIN Client Finished CFIN

Encrypted with k SFIN = MAC(k’, all prev. msgs.) CFIN = MAC(k’, all prev. msgs.)

  • Public key distribution ✓
  • Key confirmation ✓
  • Possible to use various DH groups, signature and encryption schemes ✓
  • 1 RTT before cryptographically protected payload can be sent ✓
slide-45
SLIDE 45
  • Removed:

– RSA-PKCS #1 v1.5 encryption

  • 20 years after Bleichenbacher‘s attack from 1998

– Compression of plaintext data (e.g., CRIME attack) – RC4 encryption – CBC-mode encryption, only Authenticated Encryption – Custom DH groups

  • Only 5 ECC and 5 finite field groups supported

– …

  • New:

– Forward Security as an explicit design goal – 1 RTT key establishment, “0-RTT” mode – First version where the modern “provable security” approach was used to justify design decisions

45

Cool Innovations of TLS 1.3

slide-46
SLIDE 46
  • Removed:

– RSA-PKCS #1 v1.5 encryption

  • 20 years after Bleichenbacher‘s attack from 1998

– Compression of plaintext data (e.g., CRIME attack) – RC4 encryption – CBC-mode encryption, only Authenticated Encryption – Custom DH groups

  • Only 5 ECC and 5 finite field groups supported

– …

  • New:

– Forward Security as an explicit design goal – 1 RTT key establishment (2 RTT in TLS 1.2), “0-RTT” mode – First version where the modern “provable security” approach was used to justify design decisions

46

Cool Innovations of TLS 1.3

slide-47
SLIDE 47
  • Removed:

– RSA-PKCS #1 v1.5 encryption

  • 20 years after Bleichenbacher‘s attack from 1998

– Compression of plaintext data (e.g., CRIME attack) – RC4 encryption – CBC-mode encryption, only Authenticated Encryption – Custom DH groups

  • Only 5 ECC and 5 finite field groups supported

– …

  • New:

– Forward Security as an explicit design goal – 1 RTT key establishment (2 RTT in TLS 1.2), “0-RTT” mode – First version where the modern “provable security” approach was used to justify design decisions

47

Cool Innovations of TLS 1.3

TLS 1.3 is simpler, more efficient, and more secure

slide-48
SLIDE 48

Outline

  • Security of the Diffie-Hellman Key Exchange

– Man-in-the-Middle attacks – Forward Security

  • TLS 1.3

– Overview – The cryptographic core of TLS 1.3

  • Real-World Problems

– Problems arising from backwards compatibility – Middleboxes and ETS

  • Further reading, open research problems

48

slide-49
SLIDE 49

Typical use of TLS 1.3 in practice

49

Server S TLS 1.3 TLS 1.0

(Backwards compatibility)

RSA

TLS 1.0 TLS 1.3

slide-50
SLIDE 50

Typical use of TLS 1.3 in practice

50

Server S TLS 1.3 TLS 1.0

(Backwards compatibility)

RSA

TLS 1.0 TLS 1.3 Assumption Secure?

slide-51
SLIDE 51

Bleichenbacher‘s Attack

Daniel Bleichenbacher, CRYPTO 1998

51

Server S TLS 1.3 TLS 1.0

(Backwards compatibility)

RSA

Bleichenbacher‘s Attack

Enables the attacker to create a valid digital signature w.r.t. the server’s RSA public key, for an arbitrary message

slide-52
SLIDE 52

52

TLS 1.3 Server S TLS 1.3 TLS 1.0

(Backwards compatibility)

RSA

Backwards Compatibility Attack on TLS 1.3

[J., Schwenk, Somorovsky; ACM CCS 2015]

slide-53
SLIDE 53

53

TLS 1.3 Server S TLS 1.3 TLS 1.0

(Backwards compatibility)

RSA

ServerHello ClientHello Certificate

Backwards Compatibility Attack on TLS 1.3

[J., Schwenk, Somorovsky; ACM CCS 2015]

slide-54
SLIDE 54

54

TLS 1.3 Server S TLS 1.3 TLS 1.0

(Backwards compatibility)

RSA

CertVerify ServerHello ClientHello Certificate

Backwards Compatibility Attack on TLS 1.3

[J., Schwenk, Somorovsky; ACM CCS 2015]

slide-55
SLIDE 55

55

TLS 1.3 Server S TLS 1.3 TLS 1.0

(Backwards compatibility)

RSA

Bleichenbacher‘s Attack CertVerify ServerHello ClientHello Certificate

Backwards Compatibility Attack on TLS 1.3

[J., Schwenk, Somorovsky; ACM CCS 2015]

slide-56
SLIDE 56

56

TLS 1.3 Server S TLS 1.3 TLS 1.0

(Backwards compatibility)

RSA

Bleichenbacher‘s Attack CertVerify ServerHello ClientHello Certificate S-Finished C-Finished

Backwards Compatibility Attack on TLS 1.3

[J., Schwenk, Somorovsky; ACM CCS 2015]

slide-57
SLIDE 57

57

TLS 1.3 Server S TLS 1.3 TLS 1.0

(Backwards compatibility)

RSA

Bleichenbacher‘s Attack CertVerify ServerHello ClientHello Certificate S-Finished C-Finished

TLS 1.3 may be vulnerable to Bleichenbacher‘s attack, even though PKCS#1 v1.5 encryption is not used!

Backwards Compatibility Attack on TLS 1.3

[J., Schwenk, Somorovsky; ACM CCS 2015]

slide-58
SLIDE 58

Practical Impact

58

  • Practical impact on TLS 1.3 rather limited

– Typical Bleichenbacher-attacks take hours or days – Machine-to-machine communication?

  • Nevertheless:

– Backwards compatibility must be considered

(cf. Jager, Paterson, Somorovsky, NDSS 2013)

– Future improvements of Bleichenbacher’s attack?

(Bardou et al., CRYPTO 2012)

  • Use DROWN’s approach to forge signature in
  • ne minute on a single CPU

(Aviram et al., USENIX Security 2016)

– Leverages vulnerability in openSSL – All openSSL versions from 1998 to early 2015 – 26% of HTTPS servers were vulnerable

slide-59
SLIDE 59

Practical Impact

59

  • Practical impact on TLS 1.3 rather limited

– Typical Bleichenbacher-attacks take hours or days – Machine-to-machine communication?

  • Nevertheless:

– Backwards compatibility must be considered

(cf. Jager, Paterson, Somorovsky, NDSS 2013)

– Future improvements of Bleichenbacher’s attack?

(Bardou et al., CRYPTO 2012)

  • Use DROWN’s approach to forge signature in
  • ne minute on a single CPU

(Aviram et al., USENIX Security 2016)

– Leverages vulnerability in openSSL – All openSSL versions from 1998 to early 2015 – 26% of HTTPS servers were vulnerable

slide-60
SLIDE 60

Practical Impact

60

  • Practical impact on TLS 1.3 rather limited

– Typical Bleichenbacher-attacks take hours or days – Machine-to-machine communication?

  • Nevertheless:

– Backwards compatibility must be considered

(cf. Jager, Paterson, Somorovsky, NDSS 2013)

– Future improvements of Bleichenbacher’s attack?

(Bardou et al., CRYPTO 2012)

  • Use DROWN’s approach to forge signature in
  • ne minute on a single CPU

(Aviram et al., USENIX Security 2016)

– Leverages vulnerability in openSSL – All openSSL versions from 1998 to early 2015 – 26% of HTTPS servers were vulnerable

slide-61
SLIDE 61

The difficulty of preventing such attacks (example)

61

TLS 1.3

RSA1

Server S TLS 1.3 TLS 1.0

(Backwards compatibility)

RSA1 RSA2

Bleichenbacher‘s Attack

slide-62
SLIDE 62

The difficulty of preventing such attacks (example)

62

TLS 1.3

RSA2

Server S TLS 1.3 TLS 1.0

(Backwards compatibility)

RSA1 RSA2

  • X.509 certificates do not

contain protocol version

Bleichenbacher‘s Attack

slide-63
SLIDE 63

Further difficulties

  • X.509 supports “sign/encrypt-only” certs

– “Sign-only” certs for “signing” cipher suites (incl. TLS 1.3) – “Encrypt-only” keys for TLS-RSA cipher suites

  • Key separation not supported

by major server implementations

  • Do browsers really check this?
  • Mozilla developer: “No. And we have no intention to

change this, because of usability/compatibility.”

slide-64
SLIDE 64

Further difficulties

  • X.509 supports “sign/encrypt-only” certs

– “Sign-only” certs for “signing” cipher suites (incl. TLS 1.3) – “Encrypt-only” keys for TLS-RSA cipher suites

  • Key separation not supported

by major server implementations

  • Do browsers really check this?
  • Mozilla developer: “No. And we have no intention to

change this, because of usability/compatibility.”

slide-65
SLIDE 65

Further difficulties

  • X.509 supports “sign/encrypt-only” certs

– “Sign-only” certs for “signing” cipher suites (incl. TLS 1.3) – “Encrypt-only” keys for TLS-RSA cipher suites

  • Key separation not supported

by major server implementations

  • Do browsers really check this?

– Mozilla developer: “No. And we have no intention to change this, because of usability and to maximise compatibility.”

slide-66
SLIDE 66

Take home message

  • Removing RSA-PKCS#1 v1.5 from TLS was an

excellent decision

– Not sufficient to protect completely against its weaknesses

  • Proper key separation is difficult in practice

– Support in future versions of X.509? – Support by browsers?

  • Backwards compatibility requirements must be

taken into account when designing protocols!

66

slide-67
SLIDE 67

Server-Side Middleboxes

67

Figure from ETSI TS 103 523-3 V1.2.1 (03/2019)

  • Purpose:

traffic inspection

  • For regulatory

compliance in some industry branches?

slide-68
SLIDE 68

Server-Side Middleboxes

68

Figure from ETSI TS 103 523-3 V1.2.1 (03/2019)

  • Purpose:

traffic inspection

  • For regulatory

compliance in some industry branches?

  • Solution: perform MITM “attack”
  • Difficulty: requires active attack for TLS 1.3

– Performance – Server’s secret key must be stored on middlebox

slide-69
SLIDE 69

Middlebox-Support of TLS 1.3?

69

  • TLS is standardized by IETF (RFC 8446)

– Support of middleboxes was requested for inclusion in TLS 1.3 – Rejected by the TLS 1.3 working group

  • Forward security considered more important
  • Therefore ETSI was asked

– Original name: eTLS – IETF objected to this use of the name TLS – Now called ETS

slide-70
SLIDE 70

70

slide-71
SLIDE 71

Middlebox-Support of TLS 1.3? ETS

71

  • ETSI: European Telecommunications Standards

Institute

  • Standardized variant of TLS 1.3

– Called ETS, original name: eTLS – IETF objected to this use of the name TLS – Without proper security analysis

slide-72
SLIDE 72

Server S

pk

The Cryptographic Core of the TLS 1.3 ETS Handshake

Client

72

ServerHello:

  • Selected Cipher Suite
  • Server random rS
  • Diffie-Hellman share gs

ClientHello:

  • Supported cipher suites
  • Client random rC
  • Diffie-Hellman share gc

Certified public key Certificate Verify Server Finished SFIN Client Finished CFIN

  • Fixed exponent s
  • “Master key” to decrypt all sessions
  • No forward security!

Exponent s

slide-73
SLIDE 73

ETSI Standard ETS (aka. eTLS)

73

Figure from ETSI TS 103 523-3 V1.2.1 (03/2019)

Exponent s

slide-74
SLIDE 74

A Statement of the EFF

“Don’t use ETS, don’t implement it, and don’t standardize it.”

74

https://www.eff.org/deeplinks/2019/02/ets- isnt-tls-and-you-shouldnt-use-it

slide-75
SLIDE 75
  • The protocol version field:

– Used in TLS 1.2 (and before) to indicate the protocol version – Some middleboxes fail when presented with new values

  • TLS 1.3 disguises as TLS 1.2 (version = 0x0303), and adds an

additional supported_versions extension

  • TLS 1.3 introduces a message type (“opaque”)

– This confuses middleboxes that are “accustomed to parsing previous versions”

  • TLS 1.3 disguises these messages as “application data”
  • The actual content type of a message can be found somewhere else

75

More Fun with Middleboxes

slide-76
SLIDE 76
  • The protocol version field:

– Used in TLS 1.2 (and before) to indicate the protocol version – Some middleboxes fail when presented with new values

  • TLS 1.3 disguises as TLS 1.2 (version = 0x0303), and adds an

additional supported_versions extension

  • TLS 1.3 introduces a message type (“opaque”)

– This confuses middleboxes that are “accustomed to parsing previous versions”

  • TLS 1.3 disguises these messages as “application data”
  • The actual content type of a message can be found somewhere else

76

More Fun with Middleboxes

slide-77
SLIDE 77
  • The protocol version field:

– Used in TLS 1.2 (and before) to indicate the protocol version – Some middleboxes fail when presented with new values

  • TLS 1.3 disguises as TLS 1.2 (version = 0x0303), and adds an

additional supported_versions extension

  • TLS 1.3 introduces a message type (“opaque”)

– This confuses middleboxes that are “accustomed to parsing previous versions”

  • TLS 1.3 disguises these messages as “application data”
  • The actual content type of a message can be found somewhere else

77

More Fun with Middleboxes

slide-78
SLIDE 78

Outline

  • Security of the Diffie-Hellman Key Exchange

– Man-in-the-Middle attacks – Forward Security

  • TLS 1.3

– Overview – The cryptographic core of TLS 1.3

  • Real-World Problems

– Problems arising from backwards compatibility – Middleboxes and ETS

  • Further reading, open research problems

78

slide-79
SLIDE 79

Further Reading

  • Dowling et al.: A Cryptographic Analysis of the TLS 1.3 Handshake

Protocol Candidates https://eprint.iacr.org/2015/914.pdf

  • Bhargavan et al.: Implementing and Proving the TLS 1.3 Record Layer

https://eprint.iacr.org/2016/1178.pdf

  • Jager et al.: On the Security of TLS 1.3 and QUIC Against Weaknesses in

PKCS#1 v1.5 Encryption https://www.nds.ruhr-uni- bochum.de/media/nds/veroeffentlichungen/2015/08/21/Tls13QuicAtt acks.pdf

  • Aviram et al., DROWN: Breaking TLS using SSLv2,

https://drownattack.com/

  • Kelsey: Compression and Information Leakage of Plaintext

https://www.iacr.org/cryptodb/archive/2002/FSE/3091/3091.pdf

  • ...and many references therein

79

slide-80
SLIDE 80

https://tls13.ulfheim.net/

80

slide-81
SLIDE 81

Qualys SSL Labs

  • https://www.ssllabs.com/

81

slide-82
SLIDE 82

Interesting Research Problems

  • Many AKE protocols with “provable security”

– “Asymptotically secure”, but for reasonable concrete parameters often meaningless – Efficient protocols for provably-secure large-scale deployments? (Cf. [BHJKL15, GJ18, CCGJJ19])

  • Security against state compromise

– “Coarse-grained”: eCK model [LLM01] – “Fine-grained”: considered mostly for instant messaging (“ratcheting”, cf. [PS18, JS18, ACD19])

  • Simplify security models and formal analysis

– Via modularity?

82

slide-83
SLIDE 83

Interesting Research Problems

  • Many AKE protocols with “provable security”

– “Asymptotically secure”, but for reasonable concrete parameters often meaningless – Efficient protocols for provably-secure large-scale deployments? (Cf. [BHJKL15, GJ18, CCGJJ19])

  • Security against state compromise

– “Coarse-grained”: eCK model [LLM01] – “Fine-grained”: considered mostly for instant messaging (“ratcheting”, cf. [PS18, JS18, ACD19])

  • Simplify security models and formal analysis

– Via modularity?

83

slide-84
SLIDE 84

Interesting Research Problems

  • Many AKE protocols with “provable security”

– “Asymptotically secure”, but for reasonable concrete parameters often meaningless – Efficient protocols for provably-secure large-scale deployments? (Cf. [BHJKL15, GJ18, CCGJJ19])

  • Security against state compromise

– “Coarse-grained”: eCK model [LLM01] – “Fine-grained”: considered mostly for instant messaging (“ratcheting”, cf. [PS18, JS18, ACD19])

  • Simplify security models and formal analysis

– Via modularity?

84

slide-85
SLIDE 85

85

tibor.jager@upb.de @tibor_jager Thank you for your attention! Lecture on 0-RTT protocols:

  • 0-RTT mode of TLS 1.3
  • Forward-secure 0-RTT protocols
  • Seemingly impossible?
  • Basic constructions
  • Forward security for TLS 1.3 0-RTT
  • Survey of recent results from EUROCRYPT 2017/2018/2019