TLS 1.2. Modular Code-Based Cryptographic Verification for. Cédric Fournet, Markulf Kohlweiss Microsoft Research

Transcription

1 Modular Code-Based Cryptographic Verification for F7 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 1994 Netscape s Secure Sockets Layer (SSL) 1994 SSL2 (known attacks) 1995 SSL3 (fixed them) 1999 IETF s TLS1.0 (RFC2246, SSL3) 2006 TLS1.1 (RFC4346) 2008 TLS1.2 (RFC5246) Many implementations SChannel, OpenSSL, NSS, GnuTLS, JSSE, PolarSSL, Several security patches every year Schneier & Wagner Analysis of the SSL3.0 protocol, informal, full protocol Mitchell, Schmatikov, Stern Finite state analysis of SSL 3.0, model-checking Paulson Inductive Analysis of the Internet protocol TLS, theorem-proving, h Krawczyk The Order of Encryption and Authentication for Protecting Commu Yasinac, Childs "Analyzing Internet Security Protocols", automatic symbolic a Jonsson, Kaliski, On the Security of RSA Encryption in TLS, computational an Diaz, Curtero, Valero, Pelayo, "Automatic Verification of the TLS Handshake P Ogata, Futatsugi "Equational Approach to Formal Analysis of TLS, symbolic a He, Sundararajan, Datta, Derek, Mitchell, "A modular correctness proof of IEE Kamil, Lowe Analysing TLS in the Strand Spaces Model, manual symbolic an Chaki, Datta Automated verification of security protocol implementation, a Morrisay, Smart, Warinschi, A modular security analysis of SSL/TLS, manua ( ) 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 T is the base type x refers to value, and C is a logical formula x: T C e.g. x: int{x > 0} Values of the type are values M of type T such that C{M/x} holds. In set notation: M M T C(M)} 5

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

7 Perfect Secrecy by Typing (Parametricity) [CCS2011] Probabilistic variant of F7 Probabilistic equivalence: A 0 A 1 : A 0 and A 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 A i as P i A where equal part A is not allowed to look at any of the details in P i parts in which code may differs. (formalized using α) We have P 0 A P 1 A. Cédric Fournet, Markulf Kohlweiss, Pierre-Yves Strub: Modular code-based cryptographic verification. ACM CCS 2011:

8 Computational Cryptography [CCS2011] Series A η η 0 of expressions parameterized by η. (Short A) Asymptotic security A is asymptotically safe when the series of probabilities of A η being unsafe is negligible in η. A 0 and A 1 are asymptotically equivalent, A 0 ε A 1, when 1 2 M P r A 0 M P r A 1 M is negligible for closed values M. Probabilistic polynomial time (PPT) A η runs in time polynomial in η. PPT for expressions A such that I A: T and modules B such that I 0 B I. Top most attacker interface I unrefined, power of A corresponds to Oracle Turing machine. 8

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

10 Defining Security using Games C G A (systems), C functions describing cryptographic primitives G game or protocol accessed by the adversary A adversary program that tries to win game or break protocol Encryption: C Enc defines ENC, and DEC. Chosen plaintext attack (CPA) security defined as p.p.t. adversary A. C Enc CPA 0 A ε C ENC CPA 1 A, where let enc p 0 p 1 = CPA b let p = p b in let c = ENC p in 10

11 Defining Security using Ideal Functionalities Ideal functionality implements same interface as C Enc 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 F Enc F Enc only needs to implement encryption partially, non-security critical part provided by simulator S. Only needs to exist (but often S = C Enc ). S p.p.t. A, C Enc A ε S F Enc A 11

12 Defining Security using Ideal Interfaces Split encryption into P and C Enc and treat plain as secret. type plain i I 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: i I PLAIN C Enc I Enc Ciphertexts of C Enc 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 C Enc = S F Enc. i Can check using typing that I PLAIN i i S F Enc I Enc. i I Enc 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 We focus on 3 ideal interfaces 1. AEAD 2. Handshake 3. Main API Handshake protocol CS Ka Ke Change ciphersuite Alert protocol Application I/O bytestreams Application data plain fragments dispatch Record Layer CS Ka Ke fragment ; compress stateful authenticated encryption authenticated encryption with additional data encrypted fragments TCP/IP 15

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 TCP Null CS CCS first epoch (ciphersuite & keys) new S finished data rehandshake S data close CCS TCP first handshake next handshake interleaved with data (different peer cert) TCP resume S data rekey data alert (fatal) abbreviated handshake next handshake just for rekeying 16

17 Ciphersuites & crypto agility TLS_NULL_WITH_NULL_NULL = { 0x00,0x00 } 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 } ( ) 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

19 Fragment; MAC; Encode; then Encrypt sent earlier plaintext message sent by the application fragment to be sent later fragment fragment MAC MAC pad encrypted record hdr encrypted record sent/received on TCP connection Padding-oracles, error-oracles: TLS decodes the decrypted text before authentication We need ciphertext integrity Proof for CBC depends on MAC > Block (depends on CS) (attack and proof by Paterson et al. at ASIACRYPT 11) 19

20 Fragment-then-Compress? (New Attack) Large messages are sliced into many fragments max. plaintext fragment length Fragments are independently compressed An eavesdropper can record fragment ciphertext lengths: precise message fingerprints 20

21 Fragment-then-Compress? (New Attack) Experimental data: downloading songs over HTTPS: 21

22 0 Hiding lengths within public ranges (;range) plain: an abstract plain fragment whose length is within range The application chooses its own bucket sizes: any secret URL of size bytes any 3MB image +/- 10%. Fragmentation and encoding depends only on the range, 22

23 Abstract interface for Plaintext Fragments module PlainAEAD type data = b:bytes{ } type (;ki:keyinfo,rg:range,ad:data) fragment val leak: ki:keyinfo{not(safe(ki))} -> rg:range -> ad:data -> (;ki,rg,ad) fragment -> b:bytes{length(b) in rg} val coerce: ki:keyinfo{not(safe(ki))} -> rg:range -> ad:data -> b:bytes{length(b) in rg} ->(;ki,rg,ad) fragment Abstract plaintext fragments are indexed by key info including negotiated algorithms and connection info range for the (secret) plaintext length additional data, encoding e.g. TLS version & fragment number Type abstraction yields conditional security for plaintexts with safe key info 23

24 Interface for Authenticated Encryption module PlainAEAD type data = b:bytes{ } type (;ki:keyinfo,rg:range,ad:data) fragment module val AEAD LEAK: type key ki:keyinfo{not(safe(ki))} -> rg:range -> ad:data -> val encrypt: (;ki,rg,ad) fragment -> b:bytes{length(b) in rg} ki:keyinfo val COERCE: -> (;ki)key -> ad:data -> rg:range ki:keyinfo{not(safe(ki))} * p:(;ki,rg,ad) fragment -> -> rg:range c:(;ki) -> cipher ad:data { CTXT(ki,ad,p,c) -> } val decrypt: b:bytes{length(b) in rg} ->(;ki,rg,ad) fragment ki:keyinfo -> (;ki)key -> ad:data -> c:cipher -> rg:range * r:(;ki,rg,ad) fragment option { Safe(ki) =>!p. r = Some(p) <=> CTXT(ki,ad,p,c) } encryption & decryption with a safe keyinfo do not access the plaintext bytes (need IND-CPA) decryption with a safe keyinfo succeeds only on correctly-encrypted ciphertexts, returns an error otherwise (need INT-CTXT) 24

25 Handshake (Work in Progress)

26 Internal interface for Handshake & CCS protocols (simplified) New keys are delivered before handshake completion Refinements imply matching conversations with compatible parameters type (;r:role,o:config) state // for each local instance of the protocol type (;ki:keyinfo) fragment // content type for the Handshake protocol type (;ki:keyinfo) ccs // content type for the CCS protocol // Control Interface val init: r:role -> o:config -> (;r,o) state val resume: si:sessioninfo -> o:config -> (;Client,o) state val rehandshake: (;Client,idle) state -> o:config -> (;Client,o) state val rekey: (;Client,idle) state -> o:config -> (;Client,o) state val request: (;Server,idle) state -> o:config -> (;Server,o) state // Network Interface (output) type (;r:role,o:config,ki:keyinfo) outgoing = OutFragment of (;r,o) state * (;ki) fragment option OutCCS of s:(;r,o) state * (;ki) ccs * (;OutKi(s)) key OutComplete of s:(;r,o) state {Complete(r,o,s)}... val nextfragment: r:role -> o:config -> ki:keyinfo -> (;r,o) state -> (;r,o,ki) outgoing // Network Interface (input) type (;r:role,o:config) incoming = InTLSVersion of (;r,o) state * ProtocolVersion InComplete of s:(;r,_) state {Complete(r,o,s)}... val recvfragment: r:role -> o:config -> ki:keyinfo -> (;r,o) state -> (;ki) fragment -> (;r,o) incoming val recvccs: r:role -> o:config -> ki:keyinfo -> (;r,o) state -> (;ki) ccs -> s:(;r,o) state * (;InKi(s)) key 26

27 Main TLS API

28 The TLS API & ideal functionality Our API is similar but more informative than mainstream APIs We give more control and provide more information to the application, (lengths and fragmentation; authorization queries, ) Enables us to state security theorems More challenging to use? 28

29 our main TLS API (outline) Each application provides its own plaintext module for payload streams: Typing ensures payload secrecy and authenticity at safe indexes Each application creates and runs connections in parallel Parameters select ciphersuites and certificates Results provide detailed information on the protocol state type cn // for each local instance of the protocol // creating new client and server instances val connect: TcpStream -> p:params -> (;Client) nullcn Result val resume: TcpStream -> p:params -> sessionid -> (;Client) nullcn Result val accept: TcpStream -> p:params -> (;Server) nullcn Result // triggering new handshakes, and closing connections val rekey: c:cn {Role(c)=Client} -> c':cn { } Result val rehandshake: c:cn {Role(c)=Client} -> c':cn { } Result val request: c:cn {Role(c)=Server} -> c':cn { } Result val shutdown: c:cn -> TcpStream Result // writing data type (;c:cn,data:(;c) msg_o) ioresult_o = WriteComplete of c':cn { } WritePartial of c':cn * rest:(;c') msg_o { Split_o(c,c,data,rest) } WriteError of alertdescription option { } MustRead of c':cn { } val write: c:cn -> data:(;c) msg_o -> (;c,data) ioresult_o // reading data type (;c:cn) ioresult_i = Read of c':cn * data:(;c) msg_i { } CertQuery of c':cn { } Handshake of c':cn { } NoWrite of c':cn { } Warning of c':cn * a:alertdescription { } Close of TcpStream { } ReadError of alertdescription option { } Fatal of a:alertdescription { } val read : c:cn -> (;c) ioresult_i 29

30 any safe Handshake implementation Handshake.fs7 fragment-macencode-then-encrypt application data streams Main theorem: concrete TLS and ideal TLS are indistinguishable our verified modular TLS implementation any typed F# program TLS.fs7 TLS application verified by typing Our typed ideal API for TLS thus yields strong application security by typing any typed F# program 30

31 TLS in F# & F7 We develop a reference implementation for SSL 3.0 TLS 1.2 & extensions 1. Standard compliance: we closely follow the RFCs concrete message formats support for multiple ciphersuites, sessions and connections, re-handshakes and resumptions, alerts, message fragmentation, interop with other implementations such as web browsers and servers 2. Verified security: we structure our code to enable its automated modular verification, from its main API down to standard assumptions on its base cryptography formal computational security theorems for a 5000-line functionality (automation required) 3. Experimental platform: for testing corner cases, trying out attacks, analysing new extensions and patches, 31

32 32