modular code-based cryptographic verification for f7 tls 1...modular code-based cryptographic...
TRANSCRIPT
Modular Code-Based Cryptographic Verification for
TLS 1.2 Cédric Fournet, Markulf Kohlweiss Microsoft Research
Karthik Bhargavan, Alfredo Pironti, Pierre-Yves Strub MSR-INRIA Joint Centre
F7
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
• Many papers on its crypto, security & verification – Security theorems… mostly for small simple models of TLS
1996 - Schneier & Wagner “Analysis of the SSL3.0 protocol”, informal, full protocol 1998 - Mitchell, Schmatikov, Stern “Finite state analysis of SSL 3.0”, model-checking, handshake 1999 - Paulson “Inductive Analysis of the Internet protocol TLS”, theorem-proving, handshake protocol 2001 - Krawczyk “The Order of Encryption and Authentication for Protecting Communications (or: How Secure Is SSL?)“, computational analysis, record protocol 2001 - Yasinac, Childs "Analyzing Internet Security Protocols", automatic symbolic analysis, handshake 2002 - Jonsson, Kaliski, “On the Security of RSA Encryption in TLS”, computational analysis, handshake 2004 - Diaz, Curtero, Valero, Pelayo, "Automatic Verification of the TLS Handshake Protocol", model-checking, handshake protocol 2005 - Ogata, Futatsugi "Equational Approach to Formal Analysis of TLS“, symbolic analysis, handshake 2005 - He, Sundararajan, Datta, Derek, Mitchell, "A modular correctness proof of IEEE802.11i and TLS" manual symbolic analysis, handshake protocol 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 OpenSSL code 2008 - Morrisay, Smart, Warinschi, “A modular security analysis of SSL/TLS”, manual comp. analysis of a variant of the TLS handshake (…)
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, A0 ≈𝜖 𝐴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 I0 ⊢ 𝐵 ↦ 𝐼.
• Top most attacker interface 𝐼 unrefined, ⇒ power of 𝐴 corresponds to Oracle Turing machine.
8
Modular Code-Based Crypto Verification
symmetric encryption (AES-CBC)
cryptographic primitives
public-key encryption (RSA-PKCS)
Secure RPC
Adversary
TLS 1.2
adversaries
security protocols
cryptographic construction
encrypt then-MAC
fragment-MAC- encode-then-encrypt
typed interfaces (security guarantees)
typed interfaces (attacker model)
some attack
some attack
some attack
MAC (HMACSHA1)
typed interfaces (security guarantees)
INT-CMA IND-CPA
Authenticated encryption
secure channels Adversary
Game
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.
• 𝐹𝐸𝑛𝑐 only needs to implement encryption partially,
non-security critical part provided by simulator 𝑆.
Only needs to exist (but often 𝑆 = 𝐶𝐸𝑛𝑐).
∃𝑆 ∀p.p.t. 𝐴, CEnc ⋅ 𝐴 ≈𝜖 𝑆 ⋅ 𝐹𝐸𝑛𝑐 ⋅ 𝐴
let log = ref [] let ENC (p:plain) = let c = S.ENC zero in log := (c,p) :: !log; c let DEC c = assoc c !log
𝐹𝐸𝑛𝑐
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
– Real encryption doesn’t meet this interface,
but ideal functionality does 𝐶𝐸𝑛𝑐′ = 𝑆 ⋅ 𝐹𝐸𝑛𝑐.
Can check using typing that 𝐼PLAIN𝑖 ⊢ 𝑆 ⋅ 𝐹𝐸𝑛𝑐 ↦ 𝐼𝐸𝑛𝑐
𝑖 .
val ENC: p:plain → c:cipher {CTXT(p,c)} val DEC: c:cipher → o:plain option {∀p. o = Some(p) <=> CTXT(p,c) }
𝐼𝐸𝑛𝑐𝑖
13
Application:
Verifying our TLS 1.2 implementation
Transport Layer Security
• Interleaving of four protocols on top of the record layer
• We focus on 3 ideal interfaces
1. AEAD
2. Handshake
3. Main API
Record Layer
Handshake protocol
Change ciphersuite
Alert protocol
Application data
authenticated encryption with additional data
stateful authenticated encryption
fragment ; compress
dispatch
CS Ka Ke
CS’ Ka’ Ke’
TCP/IP
plain fragments
encrypted fragments
I/O bytestreams
Application
web pages
15
data data
data
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
new S finished rehandshake S’ close
resume S’ data rekey data alert (fatal)
TCP TCP
TCP’
first epoch (ciphersuite & keys)
CCS CCS
next handshake interleaved with data (different peer cert) first handshake
abbreviated handshake
next handshake just for rekeying
data data
16
Null CS
Ciphersuites & crypto agility
• 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
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
17
Agile Length-Hiding Stateful
Authenticated Encryption with Additional Data
MAC
Fragment; MAC; Encode; then Encrypt
plaintext message sent by the application
fragment to be sent later
fragment
pad MAC fragment
sent earlier
encrypted record
hdr
sent/received on TCP connection
encrypted record
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
Fragment-then-Compress? (New Attack)
• Large messages are sliced into many fragments
• Fragments are independently compressed
• An eavesdropper can record fragment ciphertext lengths: precise message fingerprints
max. plaintext fragment length
20
Fragment-then-Compress? (New Attack)
• Experimental data: downloading songs over HTTPS:
21
Hiding lengths within public ranges
• (;range) plain: an abstract plain fragment whose length is within range
– 0
The application chooses its own bucket sizes:
– any secret URL of size 0..200 bytes
– any 3MB image +/- 10%.
• Fragmentation and encoding depends only on the range,
22
Abstract interface for Plaintext Fragments
• 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
val ENC: k:key -> p:plain{Msg(k,p)} -> cipher val DEC: k:key -> cipher -> p:plain{Msg(k,p)} option
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
23
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
Interface for Authenticated Encryption
• 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)
val ENC: k:key -> p:plain{Msg(k,p)} -> cipher val DEC: k:key -> cipher -> p:plain{Msg(k,p)} option
module AEAD
type key val encrypt: ki:KeyInfo -> (;ki)key -> ad:data -> rg:range * p:(;ki,rg,ad) fragment -> c:(;ki) cipher { CTXT(ki,ad,p,c) }
val decrypt: 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) }
24
Handshake (Work in Progress)
Internal interface for Handshake & CCS protocols (simplified)
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
• New keys are delivered before handshake completion
• Refinements imply matching conversations with compatible parameters
26
Main TLS API
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
our main TLS API (outline)
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
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
29
our verified modular TLS implementation
TLS.fs7
any typed F# program
any safe Handshake implementation
Handshake.fs7
Main theorem: concrete TLS and ideal TLS are indistinguishable
Our typed ideal API for TLS thus yields strong application security by typing
application data streams
TLS application verified by typing
30
fragment-MAC- encode-then-encrypt
any typed F# program
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