TLS 1.2 Cdric Fournet , Markulf Kohlweiss Microsoft Research - PowerPoint PPT Presentation

Modular Code-Based F7 Cryptographic Verification for TLS 1.2 Cédric Fournet , Markulf Kohlweiss Microsoft Research Karthik Bhargavan, Alfredo Pironti, Pierre-Yves Strub MSR-INRIA Joint Centre

Transport Layer Security (1994 — ) • The most widely deployed cryptographic protocol? – HTTPs, 802.1x (EAP), FTPS, VPN, SMPT, XMPP, …. • 18 years of attacks, fixes, and extensions 1996 - Schneier & Wagner “Analysis of the SSL3.0 protocol”, informal, full protocol 1994 – Netscape’s Secure Sockets Layer (SSL) 1998 - Mitchell, Schmatikov, Stern “Finite state analysis of SSL 3.0”, model-checking, 1994 – SSL2 (known attacks) 1999 - Paulson “ Inductive Analysis of the Internet protocol TLS ”, theorem -proving, han 2001 - Krawczyk “ The Order of Encryption and Authentication for Protecting Commun “, computational analysis, record protocol 1995 – SSL3 (fixed them) 2001 - Yasinac, Childs " Analyzing Internet Security Protocols ", automatic symbolic an 2002 - Jonsson, Kaliski , “ On the Security of RSA Encryption in TLS ”, computational analysis, handshake 1999 – IETF’s TLS1.0 (RFC2246, ≈SSL3) 2004 - Diaz, Curtero, Valero, Pelayo, " Automatic Verification of the TLS Handshake Pr 2005 - Ogata, Futatsugi " Equational Approach to Formal Analysis of TLS “, symbolic analysis, handshake 2006 – TLS1.1 (RFC4346) 2005 - He, Sundararajan, Datta, Derek, Mitchell, " A modular correctness proof of IEEE 2008 – TLS1.2 (RFC5246) 2008 - Kamil , Lowe “ Analysing TLS in the Strand Spaces Model ”, manual symbolic analysis, full handshake and record protocols 2008 - Chaki, Datta “ Automated verification of security protocol implementation ”, automatic (with Copper) symbolic analysis of 2008 - Morrisay, Smart, Warinschi , “ A modular security analysis of SSL/TLS ”, manual comp. analysis of a variant of the TLS • Many implementations (…) – SChannel, OpenSSL, NSS, GnuTLS, JSSE, PolarSSL , … – Several security patches every year • Many papers on its crypto, security & verification – Security theorems… mostly for small simple models of TLS 2

This Talk Automated program verification under computational security assumptions (rather than automated symbolic verification or hand written proofs of models) Method: Refinement types & type parametricity Application: TLS 1.2 3

Outline • Modular Code-Based Crypto Verification based on Types • Verifying our TLS implementation • Traffic analysis resistance?

Basis for Verification: Refinement Types A refinement type is base type qualified by a logical formula 𝑦: 𝑈 𝐷 e.g. 𝑦: 𝑗𝑜𝑢{𝑦 > 0} • 𝑈 is the base type • 𝑦 refers to value, and • 𝐷 is a logical formula Values of the type are values 𝑁 of type 𝑈 such that 𝐷{𝑁/𝑦} holds. In set notation: 𝑁 𝑁 ∈ 𝑈 ∧ 𝐷(𝑁)} 5

Modular Typing & Runtime Safety [POPL 2010] Safety means that all logical refinements hold at runtime. Theorem 1 (Safety by Typing) If ∅ ⊢ 𝐵: 𝑈 then 𝐵 is safe. Modularity We write 𝐽 0 ⊢ B ↦ 𝐽 when in type environment 𝐽 0 – expression context B is well typed and – exports interface 𝐽 . If ∅ ⊢ 𝐶 ↦ 𝐽 and 𝐽 ⊢ 𝐵: 𝑈 , then ∅ ⊢ 𝐶 ⋅ 𝐵: 𝑈 . Karthikeyan Bhargavan, Cédric Fournet, Andrew D. Gordon: Modular verification of security protocol code by typing. POPL 2010: 445-456 6

Perfect Secrecy by Typing (Parametricity) [CCS2011] Probabilistic variant of F7 Probabilistic equivalence: 𝐵 0 ≈ 𝐵 1 : 𝐵 0 and 𝐵 1 same output distribution. Abstract type: type α Expression parametric in 𝛽 , i.e., it cannot access it’s representation. Theorem 2 (Secrecy by Typing) (Paraphrased) Write 𝐵 𝑗 as 𝑄 𝑗 ⋅ 𝐵 where equal part A is not allowed to look at any of the • details in 𝑄 𝑗 parts in which code may differs. (formalized using 𝛽 ) • We have 𝑄 0 ⋅ 𝐵 ≈ 𝑄 1 ⋅ 𝐵 . Cédric Fournet, Markulf Kohlweiss, Pierre-Yves Strub: Modular code-based cryptographic verification. ACM CCS 2011: 341-350 7

Computational Cryptography [CCS2011] Series 𝐵 𝜃 𝜃≥0 of expressions parameterized by 𝜃 . (Short 𝐵 ) Asymptotic security 𝐵 is asymptotically safe when the series of probabilities of 𝐵 𝜃 being unsafe is negligible in 𝜃 . • 𝐵 0 and 𝐵 1 are asymptotically equivalent, A 0 ≈ 𝜗 𝐵 1 , when • 1 2 |𝑄 𝑠 𝐵 0 ⇓ 𝑁 − 𝑄 𝑠 𝐵 1 ⇓ 𝑁 | is negligible for closed values 𝑁 . 𝑁 Probabilistic polynomial time (PPT) 𝐵 𝜃 runs in time polynomial in 𝜃 . • PPT for expressions 𝐵 such that 𝐽 ⊢ 𝐵: 𝑈 and modules 𝐶 such that I 0 ⊢ 𝐶 ↦ 𝐽 . • • Top most attacker interface 𝐽 unrefined, ⇒ power of 𝐵 corresponds to Oracle Turing machine. 8

Modular Code-Based Crypto Verification symmetric cryptographic public-key MAC encryption encryption ( HMACSHA1 ) primitives (AES-CBC) (RSA-PKCS) INT-CMA IND-CPA typed interfaces (security guarantees) encrypt fragment-MAC- cryptographic then-MAC encode-then-encrypt construction Game Authenticated encryption typed interfaces (security guarantees) security TLS 1.2 Secure RPC protocols Adversary secure channels typed interfaces (attacker model) some some some attack adversaries attack Adversary attack 9

Defining Security using Games • 𝐷 ⋅ 𝐻 ⋅ 𝐵 (systems), – 𝐷 functions describing cryptographic primitives – 𝐻 game or protocol accessed by the adversary – 𝐵 adversary program that tries to win game or break protocol • Encryption: 𝐷 𝐹𝑜𝑑 defines ENC, and DEC. – Chosen plaintext attack (CPA) security defined as ∀ p.p.t. adversary 𝐵 . 𝐷 𝐹𝑜𝑑 ⋅ 𝐷𝑄𝐵 0 ⋅ 𝐵 ≈ 𝜗 𝐷 𝐹𝑂𝐷 ⋅ 𝐷𝑄𝐵 1 ⋅ 𝐵 , where 𝐷𝑄𝐵 𝑐 let enc 𝑞 0 𝑞 1 = let p = 𝑞 𝑐 in let c = ENC p in 10

Defining Security using Ideal Functionalities • Ideal functionality implements same interface as 𝐷 𝐹𝑜𝑑 but provides nicer properties. 𝐺 𝐹𝑜𝑑 let log = ref [] let ENC (p:plain) = let c = S.ENC zero in log := (c,p) :: !log; c let DEC c = assoc c !log • 𝐺 𝐹𝑜𝑑 only needs to implement encryption partially, non-security critical part provided by simulator 𝑇 . Only needs to exist (but often 𝑇 = 𝐷 𝐹𝑜𝑑 ). ∃𝑇 ∀p.p.t. 𝐵, C Enc ⋅ 𝐵 ≈ 𝜗 𝑇 ⋅ 𝐺 𝐹𝑜𝑑 ⋅ 𝐵 11

Defining Security using Ideal Interfaces Split encryption into 𝑄 and 𝐷 𝐹𝑜𝑑 and treat plain as secret. 𝑗 𝐽 𝑄𝑀𝐵𝐽𝑂 type plain val leak: p:plain → b:bytes {Len(b)=plainsize} val coerce: b:bytes{Len(b)=plainsize} → p:plain 12

Defining Security using Ideal Interfaces Express perfect, i.e., information theoretic, properties on interfaces: 𝑗 ′ 𝑗 𝐽 𝑄𝑀𝐵𝐽𝑂 ⊢ 𝐷 𝐹𝑜𝑑 ↦ 𝐽 𝐹𝑜𝑑 ′ – Ciphertexts of 𝐷 𝐹𝑜𝑑 are independent of abstractly typed plaintext. – Refinements express additional authenticity properties 𝑗 𝐽 𝐹𝑜𝑑 val ENC: p:plain → c:cipher {CTXT(p,c)} val DEC: c:cipher → o:plain option { ∀ p. o = Some(p) <=> CTXT(p,c) } – Real encryption doesn’t meet this interface, ′ but ideal functionality does 𝐷 𝐹𝑜𝑑 = 𝑇 ⋅ 𝐺 𝐹𝑜𝑑 . 𝑗 𝑗 Can check using typing that 𝐽 PLAIN ⊢ 𝑇 ⋅ 𝐺 𝐹𝑜𝑑 ↦ 𝐽 𝐹𝑜𝑑 . 13

Application: Verifying our TLS 1.2 implementation

Transport Layer Security web pages • Interleaving of four protocols on top of the record layer Application • We focus on 3 ideal interfaces 1. AEAD I/O bytestreams 2. Handshake 3. Main API Handshake Change Alert Application protocol ciphersuite protocol data CS’ Ka ’ Ke ’ plain fragments dispatch fragment ; compress Record Layer stateful authenticated encryption CS Ka Ke authenticated encryption with additional data encrypted fragments 15 TCP/IP

Sessions and Connections • Sessions (S, S’) are for key establishment: DH, RSA, KDF,… • Connections are for transporting records (AE), within a series of “epochs” possibly with different long-term keys and ciphersuites first epoch (ciphersuite & keys) Null CS CCS CCS data data finished rehandshake S’ data close TCP new S TCP first handshake next handshake interleaved with data (different peer cert) TCP’ resume S’ data rekey data data alert (fatal) data next handshake abbreviated just for rekeying handshake 16

TLS_NULL_WITH_NULL_NULL = { 0x00,0x00 } Ciphersuites TLS_RSA_WITH_NULL_SHA256 = { 0x00,0x3B } TLS_RSA_WITH_RC4_128_MD5 = { 0x00,0x04 } TLS_DH_anon_WITH_AES_256_CBC_SHA = { 0x00,0x3A } & crypto agility (…) 38 ciphersuites in TLS 1.2 (…) many others in recent TLS extensions TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA • Not all algorithms are equal! • Intuitively, users get the security for the ciphersuites principals accept, not for the weakest supported ones – Non trivial: there is a circular dependency, as TLS relies on the ciphersuites being negotiated • We verify TLS generically , for multiple ciphersuites 17

Agile Length-Hiding Stateful Authenticated Encryption with Additional Data