Automatic Implementation of provable cryptography for confidentiality and integrity

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 30th, 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)

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
Confidentiality b ? 0,1 I if b then B
else B g ? PA
PrC bg ½ is negligible
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)

lreceive() if (l4) then h 10
else Q
l4 send(l)
4
If the adversary does not change anything
h10 (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)

lreceive() if (l4) then h 10
else Q
l4 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 2Accommodate 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 PA g ? T
16
Integrity b ? 0,1 I if b then B else
B PA g ? T
I
If PrI all variables in T are defined 1
then PrI bg ½ is negligible
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
Compiler
20
Compiler
21
Type-based slicing
Source Code
22
Compiler
23
Control flow and integrity
Target Threads
Source Code integrity of A, B, C is H,L,H
Source Code
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
Compiler
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
Example Implementation

• 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

30
Compiler
31
Protocols implemented by the compiler
32
Protocols implemented by the compiler
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

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

37
Conclusions

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