tls 1 2
play

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

Feb 04, 2024 •361 likes •690 views

Modular Code-Based F7 Cryptographic Verification for TLS 1.2 Cdric Fournet , Markulf Kohlweiss Microsoft Research Karthik Bhargavan, Alfredo Pironti, Pierre-Yves Strub MSR-INRIA Joint Centre Transport Layer Security (1994 ) The most

  1. 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

  2. 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

  3. 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

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

  5. 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

  6. 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

  7. 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

  8. 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

  9. 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

  10. 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

  11. 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

  12. 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

  13. 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

  14. Application: Verifying our TLS 1.2 implementation

  15. 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

  16. 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

  17. 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

  18. Agile Length-Hiding Stateful Authenticated Encryption with Additional Data

Recommend

More recommend