journey beyond full abstraction · 2019-06-29 · –shared responsibility: compiler, linker,...
TRANSCRIPT
Journey Beyond Full Abstraction:Exploring Robust Property Preservation
for Secure Compilation
CarmineAbate
DeepakGarg
MarcoPatrignani
CătălinHrițcu
JérémyThibault
MPI-SWS Stanford& CISPA
Inria ParisInria Paris Inria Paris
RobBlanco
Inria Paris
Good programming languages providehelpful abstractions for writing more secure code
2
Good programming languages providehelpful abstractions for writing more secure code
• structured control flow, procedures, modules, interfaces, correctness and security specifications, ...
2
Good programming languages providehelpful abstractions for writing more secure code
• structured control flow, procedures, modules, interfaces, correctness and security specifications, ...
2
abstractions not enforced when compiling and linking with adversarial low-level code
Good programming languages providehelpful abstractions for writing more secure code
• structured control flow, procedures, modules, interfaces, correctness and security specifications, ...
2
abstractions not enforced when compiling and linking with adversarial low-level code
• all source-level security guarantees are lost
HACL* verified cryptographic library, in practice
3
HACL* library
~100.000 LOC in F*
HACL* verified cryptographic library, in practice
3
HACL* library Firefox web browser
~100.000 LOC in F* 16.000.000+ LOC in C/C++ 160x
, in practice
HACL* verified cryptographic library, in practice
3
HACL* library Firefox web browser
ASM ASM
~100.000 LOC in F* 16.000.000+ LOC in C/C++
KreMLin+ CompCert GCC
160x
, in practice
HACL* verified cryptographic library, in practice
3
HACL* library Firefox web browser
ASM ASM
Insecure interoperability: linked code can read and writedata and code, jump to arbitrary instructions, smash the stack, ...
~100.000 LOC in F* 16.000.000+ LOC in C/C++
KreMLin+ CompCert GCC
160x
, in practice
We need secure compilation chains
• Protect source-level abstractionseven against linked adversarial low-level code
4
We need secure compilation chains
• Protect source-level abstractionseven against linked adversarial low-level code– various enforcement mechanisms: processes, SFI, ...
– shared responsibility: compiler, linker, loader, OS, HW
4
We need secure compilation chains
• Protect source-level abstractionseven against linked adversarial low-level code– various enforcement mechanisms: processes, SFI, ...
– shared responsibility: compiler, linker, loader, OS, HW
• Goal: enable source-level security reasoning
4
We need secure compilation chains
• Protect source-level abstractionseven against linked adversarial low-level code– various enforcement mechanisms: processes, SFI, ...
– shared responsibility: compiler, linker, loader, OS, HW
• Goal: enable source-level security reasoning– linked adversarial target code cannot break the security of
compiled program any more than some linked source code
4
We need secure compilation chains
• Protect source-level abstractionseven against linked adversarial low-level code– various enforcement mechanisms: processes, SFI, ...
– shared responsibility: compiler, linker, loader, OS, HW
• Goal: enable source-level security reasoning– linked adversarial target code cannot break the security of
compiled program any more than some linked source code
– no "low-level" attacks
4
Robustly preserving security
5
Robustly preserving security
sourcecontext
source secureprogram
5
sourcecontext∀
Robustly preserving security
sourcecontext
source secureprogram
5
sourcecontext∀
Robustly preserving security
sourcecontext
target context
source
compiled
compiler
secure
secure
program
program
5
sourcecontext∀
targetcontext∀
⇒
Robustly preserving security
sourcecontext
target context
source
compiled
compiler
secure
secure
program
program
no extra powerprotected
5
But what should "secure" mean?
sourcecontext∀
targetcontext∀
⇒
6
What properties should we robustly preserve?
6
What properties should we robustly preserve?
trace properties(safety & liveness)
6
What properties should we robustly preserve?
trace properties(safety & liveness)
hyperproperties(noninterference)
6
What properties should we robustly preserve?
trace properties(safety & liveness)
hyperproperties(noninterference)
relationalhyperproperties(trace equivalence)
6
What properties should we robustly preserve?
trace properties(safety & liveness)
hyperproperties(noninterference)
relationalhyperproperties(trace equivalence)
6
More secure
More efficientto enforce
Easier to prove
What properties should we robustly preserve?
trace properties(safety & liveness)
hyperproperties(noninterference)
relationalhyperproperties(trace equivalence)
No one-size-fits-all security criterion
6
More secure
More efficientto enforce
Easier to prove
What properties should we robustly preserve?
trace properties(safety & liveness)
hyperproperties(noninterference)
relationalhyperproperties(trace equivalence)
only integrity
No one-size-fits-all security criterion
6
More secure
More efficientto enforce
Easier to prove
What properties should we robustly preserve?
trace properties(safety & liveness)
hyperproperties(noninterference)
relationalhyperproperties(trace equivalence)
only integrity
+ data confidentiality
No one-size-fits-all security criterion
6
More secure
More efficientto enforce
Easier to prove
What properties should we robustly preserve?
trace properties(safety & liveness)
hyperproperties(noninterference)
relationalhyperproperties(trace equivalence)
only integrity
+ data confidentiality
+ code confidentiality
No one-size-fits-all security criterion
6
More secure
More efficientto enforce
Easier to prove
What properties should we robustly preserve?
trace properties(safety & liveness)
hyperproperties(noninterference)
relationalhyperproperties(trace equivalence)
only integrity
+ data confidentiality
+ code confidentiality
No one-size-fits-all security criterion
Robust Trace Property Preservation
7
sourcecontext
targetcontext
source program
compiledprogram
sourcecontexttrace t∀
target contexttrace t
∀
.
.
compiler
∀source programs.∀π trace property.
⇒
⇝t⇒ t∈π
property-based characterization
⇝t⇒ t∈π
what one might want to achieve
Robust Trace Property Preservation
7
sourcecontext
targetcontext
source program
compiledprogram
sourcecontext∃
target context∃
.
.
compiler
∀source programs.∀(bad/attack) trace t.
⇒
sourcecontext
targetcontext
source program
compiledprogram
sourcecontexttrace t∀
target contexttrace t
∀
.
.
compiler
∀source programs.∀π trace property.
⇒
⇝t⇒ t∈π
property-based characterization
⇝t⇒ t∈π
property-free characterization
⇔
⇝t
⇝t
back-translation
what one might want to achieve how one can prove it
8
back-translatingprog & context & trace∀P∀CT∀t∃CS...
Some of the proof difficulty is manifest inproperty-free characterization
8
back-translatingfinite trace prefix∀P∀CT∀m≤t∃CS...
back-translatingprog & context & trace∀P∀CT∀t∃CS...
Some of the proof difficulty is manifest inproperty-free characterization
8
back-translatingfinite trace prefix∀P∀CT∀m≤t∃CS...
back-translatingfinite set offinite trace prefixes∀k∀P1..Pk∀CT
∀m1..mk ∃CS...
back-translatingprog & context & trace∀P∀CT∀t∃CS...
Some of the proof difficulty is manifest inproperty-free characterization
8
back-translatingfinite trace prefix∀P∀CT∀m≤t∃CS...
back-translatingprog & context∀P∀CT∃CS∀t...
back-translatingcontext
∀CT∃CS∀P∀t...
back-translatingfinite set offinite trace prefixes∀k∀P1..Pk∀CT
∀m1..mk ∃CS...
back-translatingprog & context & trace∀P∀CT∀t∃CS...
Some of the proof difficulty is manifest inproperty-free characterization
Journey Beyond Full Abstraction
• First to explore space of secure compilation criteriabased on robust property preservation
9
Journey Beyond Full Abstraction
• First to explore space of secure compilation criteriabased on robust property preservation
• Carefully studied the criteria and their relations
– Property-free characterizations
– implications, collapses, separations results
9
Journey Beyond Full Abstraction
• First to explore space of secure compilation criteriabased on robust property preservation
• Carefully studied the criteria and their relations
– Property-free characterizations
– implications, collapses, separations results
• Introduced relational (hyper)properties (new classes!)
9
Journey Beyond Full Abstraction
• First to explore space of secure compilation criteriabased on robust property preservation
• Carefully studied the criteria and their relations
– Property-free characterizations
– implications, collapses, separations results
• Introduced relational (hyper)properties (new classes!)
• Clarified relation to full abstraction ...
9
Journey Beyond Full Abstraction
• First to explore space of secure compilation criteriabased on robust property preservation
• Carefully studied the criteria and their relations
– Property-free characterizations
– implications, collapses, separations results
• Introduced relational (hyper)properties (new classes!)
• Clarified relation to full abstraction ...
• Embraced and extended proof techniques ...
9
Journey Beyond Full Abstraction
• First to explore space of secure compilation criteriabased on robust property preservation
• Carefully studied the criteria and their relations
– Property-free characterizations
– implications, collapses, separations results
• Introduced relational (hyper)properties (new classes!)
• Clarified relation to full abstraction ...
• Embraced and extended proof techniques ...
9https://github.com/secure-compilation/exploring-robust-property-preservation
Where is Full Abstraction?
10
(i.e. robust behavioral equivalence preservation)
without internal nondeterminism,full abstraction is here
Where is Full Abstraction?
10
(i.e. robust behavioral equivalence preservation)
without internal nondeterminism,full abstraction is here
Where is Full Abstraction?
10
doesn't imply any other criterion
(i.e. robust behavioral equivalence preservation)
Full abstraction does not implyany other criterion in our diagram
11
Full abstraction does not implyany other criterion in our diagram
• Intuitive counterexample adapted from Marco&Deepak [CSF'17]
11
Full abstraction does not implyany other criterion in our diagram
• Intuitive counterexample adapted from Marco&Deepak [CSF'17]
• When context passes in bad input value (e.g. ill-typed):
11
Full abstraction does not implyany other criterion in our diagram
• Intuitive counterexample adapted from Marco&Deepak [CSF'17]
• When context passes in bad input value (e.g. ill-typed):
– lunch the missiles - breaks Robust Safety Preservation
11
Full abstraction does not implyany other criterion in our diagram
• Intuitive counterexample adapted from Marco&Deepak [CSF'17]
• When context passes in bad input value (e.g. ill-typed):
– lunch the missiles - breaks Robust Safety Preservation
– or loop forever - breaks Robust Liveness Preservation
11
Full abstraction does not implyany other criterion in our diagram
• Intuitive counterexample adapted from Marco&Deepak [CSF'17]
• When context passes in bad input value (e.g. ill-typed):
– lunch the missiles - breaks Robust Safety Preservation
– or loop forever - breaks Robust Liveness Preservation
– or leak secret inputs - breaks Robust NI Preservation
11
Full abstraction does not implyany other criterion in our diagram
• Intuitive counterexample adapted from Marco&Deepak [CSF'17]
• When context passes in bad input value (e.g. ill-typed):
– lunch the missiles - breaks Robust Safety Preservation
– or loop forever - breaks Robust Liveness Preservation
– or leak secret inputs - breaks Robust NI Preservation
• Yet this doesn't break full abstraction or compiler correctness!
11
Full abstraction does not implyany other criterion in our diagram
• Intuitive counterexample adapted from Marco&Deepak [CSF'17]
• When context passes in bad input value (e.g. ill-typed):
– lunch the missiles - breaks Robust Safety Preservation
– or loop forever - breaks Robust Liveness Preservation
– or leak secret inputs - breaks Robust NI Preservation
• Yet this doesn't break full abstraction or compiler correctness!
• Full abstraction only ensures code confidentiality
– no integrity, no safety, no data confidentiality, ...
11
Embraced and extended™ proof techniques
12
for simple translation from statically to dynamically typed language with first-order functions and I/O
Embraced and extended™ proof techniques
12
back-translatingcontext
∀CT∃CS∀P∀t...
[New et al,ICFP'16]
for simple translation from statically to dynamically typed language with first-order functions and I/O
strongestcriterion
achievable
Embraced and extended™ proof techniques
12
back-translatingcontext
∀CT∃CS∀P∀t...
[New et al,ICFP'16] generic techniqueapplicableback-translatingfinite set offinite trace prefixes∀k∀P1..Pk∀CT
∀m1..mk ∃CS...
[Jeffrey & Rathke, ESOP'05][Patrignani et al,TOPLAS'15]
for simple translation from statically to dynamically typed language with first-order functions and I/O
strongestcriterion
achievable
Some open problems
• Practically achievingsecure interoperability with lower-level code
– more realistic languages and compilation chains
13
Some open problems
• Practically achievingsecure interoperability with lower-level code
– more realistic languages and compilation chains
• Verifying robust satisfaction for source programs
– program logics, logical relations, partial semantics, ...
13
Some open problems
• Practically achievingsecure interoperability with lower-level code
– more realistic languages and compilation chains
• Verifying robust satisfaction for source programs
– program logics, logical relations, partial semantics, ...
• Different traces for source and target semantics
– connected by some arbitrary relation
– mappings between source and target properties
– interesting even for correct compilation
13
My dream: secure compilation at scale
14
HACL*language
My dream: secure compilation at scale
14
HACL*
C language+ components+ memory safety
language
My dream: secure compilation at scale
14
HACL*
C language+ components+ memory safety
language
My dream: secure compilation at scale
14
HACL*
memory safe C component
legacy C component
ASM component
C language+ components+ memory safety
ASM language(RISC-V + micro-policies)
language
My dream: secure compilation at scale
14
HACL*
memory safe C component
legacy C component
ASM component
C language+ components+ memory safety
ASM language(RISC-V + micro-policies)
language
My dream: secure compilation at scale
14
HACL*
memory safe C component
legacy C component
ASM component
C language+ components+ memory safety
ASM language(RISC-V + micro-policies)
language
Journey Beyond Full Abstraction
• First to explore space of secure compilation criteriabased on robust property preservation
• Carefully studied the criteria and their relations
– Property-free characterizations
– implications, collapses, separations results
• Introduced relational (hyper)properties (new classes!)
• Clarified relation to full abstraction ...
• Embraced and extended proof techniques ...
15https://github.com/secure-compilation/exploring-robust-property-preservation