1. 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

2. 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

3. LET THE COMPILER DO THE HARD TASK! Our proposal:

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

5. The big picture

6. SECURITY POLICIES AND INFORMATION FLOW SECURITY

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

8. 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 ®

9. ADVERSARY HYPOTHESES AND SECURITY PROPERTIES

10. 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,...]

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

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

13. 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.

14. 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)

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

16. 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’

17. THE COMPILER

18. 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)

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

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

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

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

23. 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

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

25. 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!!

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

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

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

29. 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

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

31. Protocols implemented by the compiler

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

33. 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

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

35. RESULTS

36. 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

37. 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