automatic implementation of provable cryptography for confidentiality and integrity presented by...
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
Our proposalOur proposalA compiler that generates code:
◦from a simple specification
◦verifiable using concrete cryptography hypos
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
®
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,...]
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)
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’
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
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
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 ¿)
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