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

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

2

This Talk

Automated program verification under computational security assumptions (rather than automated symbolic verification

• r 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
• n 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

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

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
• nly on correctly-encrypted ciphertexts,

returns an error otherwise (need INT-CTXT)

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

• ur 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

• n the protocol state

29

• ur 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