Downgrade Resilience in Key Exchange markulf kohlweiss joint work - - PowerPoint PPT Presentation

Downgrade Resilience in Key Exchange

markulf kohlweiss

joint work with:

• k. bhargavan, c. brzuska, c. fournet,
• m. green, s. zanella-beguelin

1

Downgrade as an everyday phenomen

https:// http://

2

TLS protocol suite – not a single protocol

Client Server

Hello Messages Finished Messages

3

Crypto failures

2007 2008 2009 2010 2011 2012 2013 2014 2015 2016

Protocol weaknesses Implementation bugs

EarlyCCS Heartbleed POODLE Triple Handshake SKIP FREAK Logjam SLOTH DROWN Renegotiation Attack ECDHE Cross- protocol Attack BEAST (Rogaway 02) Lucky13 RC4 MD5 OpenSSL entropy CRIME RSA 512 bit SHA1

4

5

Our contribution

• 1. Definition that tolerate weak algorithms

– and capture downgrade attacks

• 2. Modular proof strategy
• Analyse downgrade security of SSH, IKE, ZRTP, TLS
• Prove downgrade security for SSH and TLS 1.3

– New countermeasures designed together with core-design team of TLS 1.3

6

Negotiation

• Inputs:

– configC & configS: supported versions, ciphers, groups, long-term keys

• Outputs:

– mode: negotiated version, cipher, group, etc.

• Ideal negotiation:

– 𝑛𝑝𝑒𝑓 = Nego(c𝑝𝑜𝑔𝑗𝑕𝐷, c𝑝𝑜𝑔𝑗𝑕𝑇)

7

Transcript authentication vs. Downgrades

• Authentication

If my negotiated mode uses only strong algorithms, then my partner and I agree on keys, identities and mode.

• Authentication does not guarantee

negotiation of a strong mode.

– Intersection of configC & configS must be strong! – What if configC & configS include a legacy algorithm? – What are minimal requirements on configC & configS?

8

Client Server

POODLE

[Dowling and Stebila 2015]

Hello Messages Finished Messages

9

MitM Server S Client C Knows 𝑡𝑙𝐷, 𝑞𝑙𝑇 𝑑𝑝𝑜𝑔𝑗𝑕𝐷: 𝐻2048, 𝐻512 [𝐻2048, 𝐻512] [𝐻512] [𝐻512] 𝑛1 = 𝑕𝑦 𝑛𝑝𝑒 𝑞512 𝑛2 = 𝑕𝑧 𝑛𝑝𝑒 𝑞512

k= 𝑙𝑒𝑔(𝑕𝑦𝑧 𝑛𝑝𝑒 𝑞512) 𝑙 = 𝑙𝑒𝑔(𝑕𝑦𝑧 𝑛𝑝𝑒 𝑞512) 𝑧 = 𝑒𝑚𝑝𝑕(𝑛2) 𝑙 = 𝑙𝑒𝑔(𝑕𝑦𝑧 𝑛𝑝𝑒 𝑞512)

𝑡𝑗𝑕𝑜(𝑡𝑙𝑇, ℎ𝑏𝑡ℎ(𝑛1||𝑛2) 𝑛𝑏𝑑(𝑙, transcript) 𝑛𝑏𝑑(𝑙, transcript′) Knows 𝑡𝑙𝑇, 𝑞𝑙𝐷 𝑑𝑝𝑜𝑔𝑗𝑕𝑇: 𝐻2048, 𝐻512

𝑡𝑗𝑕𝑜 𝑡𝑙𝑇, transcript′ ?

LOGJAM

10

Client Server

11

Client Server

12

md5(m1 ԡ 𝑛′2) =md5(m’1 ԡ m2)

Downgrade secure configurations

• Downgrade protection (DP) only if

– config𝐷 requires good public keys and signatures scheme – configS has preference for downgrade secure version

• Clients and servers interoperate with everyone;

get desired mode only when DP(c𝑝𝑜𝑔𝑗𝑕𝐷, c𝑝𝑜𝑔𝑗𝑕𝑇).

13

Protocol execution model

Adversary controls generation of keys and sessions Configurations: algorithms and keys supported by sessions Sessions assign variables

sk

𝐿𝑓𝑧𝐻𝑓𝑜()

𝐽𝑜𝑗𝑢(𝑑𝑝𝑜𝑔𝑗𝑕𝐷) 𝑛′ ← 𝑇𝑓𝑜𝑒(𝑛) MitM pk S C C S 𝑑𝑝𝑜𝑔𝑗𝑕: = 𝑑𝑝𝑜𝑔𝑗𝑕𝐷 𝑣𝑗𝑒 ≔ … 𝑛𝑝𝑒𝑓 ≔ …. 𝑑𝑝𝑜𝑔𝑗𝑕: = 𝑑𝑝𝑜𝑔𝑗𝑕𝐷 𝑣𝑗𝑒 ≔ … 𝑛𝑝𝑒𝑓 ≔ ….

14

MitM S C C S 𝑑𝑝𝑜𝑔𝑗𝑕 ∶= 𝐝𝐩𝐨𝐠𝐣𝐡𝐃 𝑣𝑗𝑒 ≔ uid 𝑛𝑝𝑒𝑓 ≔ mode 𝑑𝑝𝑛𝑞𝑚𝑓𝑢𝑓 ≔ true 𝑑𝑝𝑜𝑔𝑗𝑕 ∶= 𝒅𝒑𝒐𝒈𝒋𝒉𝑻 𝑣𝑗𝑒 ≔ uid 𝑛𝑝𝑒𝑓 ≔ 𝑑𝑝𝑛𝑞𝑚𝑓𝑢𝑓 ≔

DP(𝐷. 𝑑𝑝𝑜𝑔𝑗𝑕, 𝑇. 𝑑𝑝𝑜𝑔𝑗𝑕) but 𝑛𝑝𝑒𝑓 ≠ Nego(𝐷. 𝑑𝑝𝑜𝑔𝑗𝑕, 𝑇. 𝑑𝑝𝑜𝑔𝑗𝑕)

Downgrade security

What if server does not exist?

sk pk

15

Our contribution

• 1. Definition that tolerate weak algorithms

– and capture downgrade attacks

• 2. Modular proof strategy
• Analyse downgrade security of SSH, IKE, ZRTP, TLS
• Prove downgrade security for SSH and TLS 1.3

– New countermeasures designed together with core-design team of TLS 1.3

16

Reducing complex real-world protocol analysis …

17

… using simulation …

sk

𝐿𝑓𝑧𝐻𝑓𝑜()

𝐽𝑜𝑗𝑢(𝑑𝑔𝑕𝐷) 𝑇𝑓𝑜𝑒(𝑛) MitM pk C S S C sk

𝐿𝑓𝑧𝐻𝑓𝑜()

𝐽𝑜𝑗𝑢(𝑑𝑔𝑕𝐷) 𝑇𝑓𝑜𝑒(𝑛) MitM pk 𝑇′ 𝐷′ 𝐷′ 𝑇′

≈

Sim 𝑑𝑔𝑕 ∶= 𝑑𝑔𝑕𝐷 𝑣𝑗𝑒 ≔ … 𝑛𝑝𝑒𝑓 ≔ …. 𝑑𝑔𝑕 ∶= 𝑑𝑔𝑕𝐷 𝑣𝑗𝑒 ≔ … 𝑛𝑝𝑒𝑓 ≔ ….

=

[Rogaway and Steger 2009]

18

… into analysis of downgrade sub-protocol (TLS 1.3)

Server S Client C 𝑛1 = (𝑜𝐷, 𝐺

1 𝑑𝑝𝑜𝑔𝑗𝑕𝐷 )

𝑛2 = (𝑜𝑇, 𝑤, 𝑏𝑇, 𝐻𝑇, 𝑞𝑙𝑇)

𝑑𝑝𝑛𝑞𝑚𝑓𝑢𝑓 = 𝑢𝑠𝑣𝑓

𝑡𝑗𝑕𝑜(𝑡𝑙𝑇, ℎ𝑏𝑡ℎ1 𝐼 𝑛1, 𝑛2, − ) 𝑣𝑗𝑒 = 𝑜𝐷, 𝑜𝑇 𝑛𝑝𝑒𝑓 = 𝑜𝑓𝑕𝑝 𝐺

1 𝑑𝑝𝑜𝑔𝑗𝑕𝐷 , 𝑑𝑝𝑜𝑔𝑗𝑕𝑇

= (𝑤, 𝑏𝑇, 𝐻𝑇, 𝑞𝑙𝑇, ℎ𝑏𝑡ℎ1) 𝑣𝑗𝑒 = 𝑜𝐷, 𝑜𝑇 𝑛𝑝𝑒𝑓 = (𝑤, 𝑏𝑇, 𝐻𝑇, 𝑞𝑙𝑇, ℎ𝑏𝑡ℎ1) 𝑑ℎ𝑓𝑑𝑙(𝑑𝑝𝑜𝑔𝑗𝑕𝐷, 𝑛𝑝𝑒𝑓) 𝑑𝑝𝑛𝑞𝑚𝑓𝑢𝑓 = 𝑢𝑠𝑣𝑓 Initialized with 𝑑𝑝𝑜𝑔𝑗𝑕𝑇 Initialized with 𝑑𝑝𝑜𝑔𝑗𝑕𝐷 𝑛0 = (𝑜𝐷, 𝐺0 𝑑𝑝𝑜𝑔𝑗𝑕𝐷 ) 𝑛0′ = 𝐻𝑇

Server signs full transcript with strong signature and hash algorithms?

19

Server S Client C 𝑛1 = (𝑜𝐷, 𝐺

1 𝑑𝑝𝑜𝑔𝑗𝑕𝐷 )

𝑛2 = (𝑜𝑇

′ , 𝑤, 𝑏𝑇, 𝐻𝑇, 𝑞𝑙𝑇)

𝑑𝑝𝑛𝑞𝑚𝑓𝑢𝑓 = 𝑢𝑠𝑣𝑓

𝑡𝑗𝑕𝑜(𝑡𝑙𝑇, ℎ𝑏𝑡ℎ1 𝐼 𝑛0, 𝑛0

′ , 𝑛1, 𝑛2, − )

𝑣𝑗𝑒 = 𝑜𝐷, 𝑜𝑇 ; 𝑜𝑇

′ = 𝑜𝑇|| 𝑛𝑏𝑦𝑤(𝑑𝑝𝑜𝑔𝑗𝑕𝑇)

𝑛𝑝𝑒𝑓 = 𝑜𝑓𝑕𝑝 𝐺

1 𝑑𝑝𝑜𝑔𝑗𝑕𝐷 , 𝑑𝑝𝑜𝑔𝑗𝑕𝑇

= (𝑤, 𝑏𝑇, 𝐻𝑇, 𝑞𝑙𝑇, ℎ𝑏𝑡ℎ1) 𝑣𝑗𝑒 = 𝑜𝐷, 𝑜𝑇 𝑛𝑝𝑒𝑓 = (𝑤, 𝑏𝑇, 𝐻𝑇, 𝑞𝑙𝑇, ℎ𝑏𝑡ℎ1) 𝑑ℎ𝑓𝑑𝑙(𝑑𝑝𝑜𝑔𝑗𝑕𝐷, 𝑛𝑝𝑒𝑓) 𝑑𝑝𝑛𝑞𝑚𝑓𝑢𝑓 = 𝑢𝑠𝑣𝑓 Initialized with 𝑑𝑝𝑜𝑔𝑗𝑕𝑇 Initialized with 𝑑𝑝𝑜𝑔𝑗𝑕𝐷 𝑛0 = (𝑜𝐷, 𝐺0 𝑑𝑝𝑜𝑔𝑗𝑕𝐷 ) 𝑛0′ = 𝐻𝑇

20

Downgrade security of TLS 1.3

• Good news:

TLS 1.3 now has secure downgrade sub-protocol

– nonce and signatures: unique server signs all network input to 𝑜𝑓𝑕𝑝 and result.

• What do we do about version downgrade?

– Can an attacker downgrade TLS 1.3 to TLS 1.2 and remount Logjam?

21

Version downgrade resilience

• TLS 1.3 server signatures cover versions

But TLS 1.2 signatures do not cover the version

• How do we patch TLS 1.2 to prevent downgrades?

– Finished messages cannot help – Look away: put max server version in server nonce signed in all versions of TLS

• Good news: DP(𝑑𝑝𝑜𝑔𝑗𝑕𝐷, 𝑑𝑝𝑜𝑔𝑗𝑕𝑇) for TLS 1.0-1.3 if

– countermeasure implemented – no RSA key transport

22

Downgrade Resilience in Key Exchange

https://www.mitls.org/ https://eprint.iacr.org/2016/072

23

24