Automatic Implementation of provable cryptography for confidentiality and integrity Presented by Tamara Rezk – INDES project - INRIA Joint work with: Cédric Fournet – Microsoft Research Gurvan Le Guernic – INRIA-MSR Joint Centre FMCrypto Meeting, Campinas April 30 th, 2009

The problem Confidentiality and integrity properties in distributed systems ◦ These properties are not always simple to specify ◦ Their enforcement may involve several different protocols ◦ Systems may become complex very fast

LET THE COMPILER DO THE HARD TASK! Our proposal:

Our proposal A compiler that generates code: ◦ from a simple specification ◦ verifiable using concrete cryptography hypos

The big picture

SECURITY POLICIES AND INFORMATION FLOW SECURITY

Confidentiality and Integrity confidentiality (leak of secret information) integrity (tainted data)

A clean specification for security Data is labeled with confidentiality and integrity levels from a security lattice The adversary is modeled as a level ( ® ) in the lattice There are typed programming languages that support information flow control (Jif by A.Myers et al, FlowCaml by F.Pottier et al) Confidentiality Integrity write read write read L LHLH H HLHL High trusted Low tainted High secret Low public secure info flows declassification endorsement ®

ADVERSARY HYPOTHESES AND SECURITY PROPERTIES

What can an adversary observe or do? Adversary is an arbitrary program but polynomially bounded. [Modern cryptography: Yao, Goldwasser, Micali, Rivest,...] A (r,w)-adversary can read variables under r, write variables above w. [Information flow security: Denning, Myers, Liskov,...]

|Pr[C; b=g] – ½ | is negligible Confidentiality= b  {0,1}; I ; if b then B else B’ g  P[A]

Interaction of system and adversary Source program contexts are of the form: _; P;_;P’; _ Distributed programs contexts are of the form: _ [ P, P’]

A note on integrity Integrity non-interference (rightfully) excludes implicit flows All cryptographic checks create “implicit” flows! E.g. we dynamically check whether a signature is correct We refine our model to accommodate runtime errors If the program completes, then it guarantees integrity The command context is considered correct, as it preserves the integrity of h (or leaves h uninitialized) l:=receive(); if (l=4) then {h:= 10} else Q l:=4 send(l) 4 If the adversary does not change anything: h=10 (correct behaivour) If the adversary changes the value of l, then Q is executed.

A note on integrity Integrity non-interference (rightfully) excludes implicit flows All cryptographic checks create “implicit” flows! E.g. we dynamically check whether a signature is correct We refine our model to accommodate runtime errors If the program completes, then it guarantees integrity The command context is considered correct, as it preserves the integrity of h (or leaves h uninitialized) l:=receive(); if (l=4) then {h:= 10} else Q l:=4 send(l) 4 Option 1: We consider implicit flows are insecure. All cryptographic checks create “implicit” flows! E.g. we dynamically check whether a signature is correct Option 2:Accommodate runtime errors If the program completes, then it guarantees integrity The command where Q is skip is considered correct, as it preserves the integrity of h (or leaves h uninitialized)

Integrity= b  {0,1}; I ; if b then B else B’ P[A] g  T

If |Pr[I’; all variables in T are defined] = 1 then |Pr[I; b=g] – ½ | is negligible Integrity= b  {0,1}; I ; if b then B else B’ P[A] g  T I’

THE COMPILER

A security compiler spec The programmer specifies a high-level security policy (confidentiality and integrity of data using information flow security) The compiler implements cryptography and distribution issues (transparent to the programmer)

Control Flow Protocol Typed Slicing Variable Replication Programs with security policy Distributed cryptographic implementations Crypto ProtocolsCompiler

Control Flow Protocol Typed Slicing Variable Replication Programs with security policy Distributed cryptographic implementations Crypto ProtocolsCompiler

Type-based slicing Thread 1 Thread 2 Thread 3 Thread 4 Source Code

Control Flow Protocol Typed Slicing Variable Replication Programs with security policy Distributed cryptographic implementations Crypto ProtocolsCompiler

Control flow and integrity Thread 1 Thread 2 Thread 3 Thread 4 Source Code Target Threads Source Code: integrity of A, B, C is H,L,H A correct implementation should enforce the original control flow: A, B, A, C

Control flow and integrity Target Threads Source Code: integrity of A, B, C is H,L,H

Control flow and integrity Target Threads Source Code: integrity of A, B, C is H,L,H This implementation is not correct! An adversary corrupting B might try to execute thread 2 before thread 1!!

Control flow and integrity Target Threads Source Code: integrity of A, B, C is H,L,H A better implementation.

Control Flow Protocol Typed Slicing Variable Replication Programs with security policy Distributed cryptographic implementations Crypto ProtocolsCompiler

Example Code In a less abstract implementation, a needs to pass x securely to b, b needs to pass y security to a,...

The command may be implemented as Here, we cannot rely on the same keys for protecting x and y ◦ Besides, the adversary can “break” integrity using Example Implementation

Control Flow Protocol Typed Slicing Variable Replication Programs with security policy Distributed cryptographic implementations Crypto Protocols Compiler

Protocols implemented by the compiler

The compiler implements protocols for key establishment, one encryption key per confidentiality level of shared variables among hosts.

Protocols implemented by the compiler The compiler implements protocols for key establishment, one encryption key per confidentiality level of shared variables among hosts. The compiler generates typable code if the original code is typable

A type system for cryptography We use static key labels K for separating keys We use tags for separating signed values (F: t  ¿ )

RESULTS

Theorems 1.For typable source programs, compiled programs are typable 2.Typable distributed programs with secure control flow without declassification and endorsement secure cryptographic schemes are secure 3.Compiled programs do not have more attacks than source programs 4.Absence of adversary: the compiler preserves the semantics

This work is about simple programming language abstractions for security of distributed programs and their robust crypto implementation Connections between high-level security goals and the usage of crypto protocols Ongoing work Improve the compiler (and its underpinning type system) Experimental evaluation Cryptographic back-end for the Jif/Split compiler? Mechanized proofs? Conclusions