Page 1
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
Page 2
Good programming languages providehelpful abstractions for writing more secure code
2
Page 3
Good programming languages providehelpful abstractions for writing more secure code
• structured control flow, procedures, modules, interfaces, correctness and security specifications, ...
2
Page 4
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
Page 5
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
Page 6
HACL* verified cryptographic library, in practice
3
HACL* library
~100.000 LOC in F*
Page 7
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
Page 8
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
Page 9
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
Page 10
We need secure compilation chains
• Protect source-level abstractionseven against linked adversarial low-level code
4
Page 11
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
Page 12
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
Page 13
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
Page 14
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
Page 15
Robustly preserving security
5
Page 16
Robustly preserving security
sourcecontext
source secureprogram
5
sourcecontext∀
Page 17
Robustly preserving security
sourcecontext
source secureprogram
5
sourcecontext∀
Page 18
Robustly preserving security
sourcecontext
target context
source
compiled
compiler
secure
secure
program
program
5
sourcecontext∀
targetcontext∀
⇒
Page 19
Robustly preserving security
sourcecontext
target context
source
compiled
compiler
secure
secure
program
program
no extra powerprotected
5
But what should "secure" mean?
sourcecontext∀
targetcontext∀
⇒
Page 20
6
What properties should we robustly preserve?
Page 21
6
What properties should we robustly preserve?
trace properties(safety & liveness)
Page 22
6
What properties should we robustly preserve?
trace properties(safety & liveness)
hyperproperties(noninterference)
Page 23
6
What properties should we robustly preserve?
trace properties(safety & liveness)
hyperproperties(noninterference)
relationalhyperproperties(trace equivalence)
Page 24
6
What properties should we robustly preserve?
trace properties(safety & liveness)
hyperproperties(noninterference)
relationalhyperproperties(trace equivalence)
Page 25
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
Page 26
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
Page 27
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
Page 28
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
Page 29
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
Page 30
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
Page 31
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
Page 32
8
back-translatingprog & context & trace∀P∀CT∀t∃CS...
Some of the proof difficulty is manifest inproperty-free characterization
Page 33
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
Page 34
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
Page 35
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
Page 36
Journey Beyond Full Abstraction
• First to explore space of secure compilation criteriabased on robust property preservation
9
Page 37
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
Page 38
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
Page 39
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
Page 40
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
Page 41
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
Page 42
Where is Full Abstraction?
10
(i.e. robust behavioral equivalence preservation)
Page 43
without internal nondeterminism,full abstraction is here
Where is Full Abstraction?
10
(i.e. robust behavioral equivalence preservation)
Page 44
without internal nondeterminism,full abstraction is here
Where is Full Abstraction?
10
doesn't imply any other criterion
(i.e. robust behavioral equivalence preservation)
Page 45
Full abstraction does not implyany other criterion in our diagram
11
Page 46
Full abstraction does not implyany other criterion in our diagram
• Intuitive counterexample adapted from Marco&Deepak [CSF'17]
11
Page 47
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
Page 48
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
Page 49
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
Page 50
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
Page 51
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
Page 52
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
Page 53
Embraced and extended™ proof techniques
12
for simple translation from statically to dynamically typed language with first-order functions and I/O
Page 54
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
Page 55
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
Page 56
Some open problems
• Practically achievingsecure interoperability with lower-level code
– more realistic languages and compilation chains
13
Page 57
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
Page 58
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
Page 59
My dream: secure compilation at scale
14
HACL*language
Page 60
My dream: secure compilation at scale
14
HACL*
C language+ components+ memory safety
language
Page 61
My dream: secure compilation at scale
14
HACL*
C language+ components+ memory safety
language
Page 62
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
Page 63
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
Page 64
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
Page 65
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