automatic implementation of provable cryptography for confidentiality and integrity presented by...

37
Automatic Implementation Automatic Implementation of provable cryptography of provable cryptography for confidentiality and for confidentiality and integrity 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

Upload: pearl-pearson

Post on 22-Dec-2015

219 views

Category:

Documents


0 download

TRANSCRIPT

Automatic Automatic Implementation of Implementation of provable cryptography provable cryptography for confidentiality and for confidentiality and integrityintegrityPresented 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 30th, 2009

The problemThe 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 LET THE COMPILER DO THE HARD TASK!DO THE HARD TASK!

Our proposal:

Our proposalOur proposalA compiler that generates code:

◦from a simple specification

◦verifiable using concrete cryptography hypos

The big pictureThe big picture

SECURITY POLICIES SECURITY POLICIES AND INFORMATION AND INFORMATION FLOW SECURITYFLOW SECURITY

Confidentiality and Confidentiality and IntegrityIntegrity

confidentiality

(leak of secret information)

integrity

(tainted data)

A clean specification for A clean specification for securitysecurity

• 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

Inte

grity

writereadwrite

read

LL

LH

HH

HL

High

trusted

Low

tainted

High

secr

etLo

wpu

blic

secure info flows

declassification endo

rsem

ent

®

ADVERSARY ADVERSARY HYPOTHESES AND HYPOTHESES AND SECURITY SECURITY PROPERTIESPROPERTIES

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 Interaction of system and adversaryadversarySource program

contexts are of the form:

_; P;_;P’; _

Distributed programs contexts are of the form:

_ [ P , P’]

A note on integrityA note on integrityIntegrity 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 integrityThe 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 integrityA note on integrityIntegrity 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 integrityThe 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 integrityThe 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 COMPILERTHE COMPILER

A security compiler specA 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 Protocols

Compiler Compiler

Control Flow Protocol

Variable Replication

Programs with security policy

Distributed cryptographic

implementations

Crypto Protocols

Compiler Compiler

Type-based slicingType-based slicing

Source Code

Typed Slicing

Variable Replication

Programs with security policy

Distributed cryptographic

implementations

Crypto Protocols

Compiler Compiler

Control flow and integrity Control flow and integrity

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 Control flow and integrity

Target Threads

Source Code: integrity of A, B, C is H,L,H

Control flow and integrity 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 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

Programs with security policy

Distributed cryptographic

implementations

Crypto Protocols

Compiler Compiler

Example CodeExample 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 ImplementationExample Implementation

Control Flow Protocol

Typed Slicing

Variable Replication

Programs with security policy

Distributed cryptographic

implementations

Crypto ProtocolsCrypto Protocols

Compiler Compiler

Protocols implemented by the Protocols implemented by the compilercompiler

Protocols implemented by the Protocols implemented by the compilercompiler

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

Protocols implemented by the Protocols implemented by the compilercompiler

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 A type system for cryptographycryptography

We use static key labels K for separating keys

We use tags for separating signed values (F: t ¿)

RESULTSRESULTS

TheoremsTheorems

1. For typable source programs, compiled programs are typable

2. Typable distributed programs • with secure control flow • without declassification and endorsement • secure cryptographic schemesare 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 workImprove the compiler (and its underpinning type system)Experimental evaluationCryptographic back-end for the Jif/Split compiler?Mechanized proofs?

ConclusionsConclusions