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