A Verified Information-Flow Architecture Arthur Azevedo de Amorim, - - PowerPoint PPT Presentation
A Verified Information-Flow Architecture Arthur Azevedo de Amorim, Nathan Collins, Andr DeHon, Delphine Demange, C at alin Hri tcu, David Pichardie, Benjamin Pierce, Randy Pollack, Andrew T olmach January 2014 1 What if we could
Arthur Azevedo de Amorim, Nathan Collins, André DeHon, Delphine Demange, C˘ at˘ alin Hri¸ tcu, David Pichardie, Benjamin Pierce, Randy Pollack, Andrew T
January 2014
1
2
Clean-slate redesign of entire system stack
http://www.crash-safe.org
3
❼ Support for critical security primitives from hardware
to application levels
❼ Memory safety ❼ Strong dynamic typing ❼ Dynamic information flow and access control
❼ Design of key components informed by verification
4
❼ Integrate well-known mechanisms for security (e.g.
fat-pointers, type tags, . . . )
❼ Focus of this paper: flexible mechanism for
supporting information-flow control (IFC) using a hardware cache and tags
tag payload 5
Formalize and verify the core IFC mechanism proposed by SAFE using the Coq proof assistant
6
Track and limit information dependency in computations Noninterference (NI): Varying secret inputs does not affect public observations
7
1@L 0@H
8
H L 1@L 0@H
8
H L 1@L 0@H 1@L 0@H
8
H L 1@L 0@H 1@L 0@H 1,0 1
8
H L 1@L 42@H
8
H L 1@L 42@H 1@L 42@H
8
H L 1@L 42@H 1@L 42@H 1,42 1
8
Concrete Machine
Core model of SAFE
9
Concrete Machine NI
9
Concrete Machine NI
How can we prove it?
9
Abstract Machine Concrete Machine NI
IFC baked into semantics Refined by
9
Abstract Machine NI
Easier to show
Concrete Machine NI
Refined by
9
Abstract Machine NI Concrete Machine NI
Preserved
NI
Refined by
9
Abstract Machine NI Concrete Machine NI
Preserved
NI
Refined by Relies on determinism
9
Using Coq, we
❼ Model the core mechanism for supporting IFC in
SAFE (our so-called “concrete machine”)
❼ Develop a proof methodology (by refinement) for
proving this mechanism correct
10
11
Abstract Machine NI Concrete Machine NI
Refined by
12
Stack machine with
❼ ❼
1 5 8
stack
13
Input/output model:
❼ The input of a program
is its initial stack
❼ The result of executing
a program is the sequence of its
1 5 8
13
Label data with security levels H = high security L = low security (or, more generally, any IFC lattice) 1@L 5@L 8@H
14
Machine has semantics with standard dynamic IFC baked-in Mechanizing proof of NI is relatively straightforward 1@L 5@L 8@H
14
When low-security
the result is low-security · · · Add Add Output · · · PC 1@L 5@L 8@H
14
When low-security
the result is low-security · · · Add Add Output · · · PC 1@L 5@L 8@H
14
When low-security
the result is low-security · · · Add Add Output · · · PC 6@L 8@H
14
When one operand is high- security, result is high- security · · · Add Add Output · · · PC 6@L 8@H
14
When one operand is high- security, result is high- security · · · Add Add Output · · · PC 6@L 8@H
14
When one operand is high- security, result is high- security · · · Add Add Output · · · PC 14@H
14
Labels on outputs mark who is able to see them · · · Add Add Output · · · PC 14@H
14
Labels on outputs mark who is able to see them · · · Add Add Output · · · PC 14@H
14
Labels on outputs mark who is able to see them · · · Add Add Output · · · PC 14@H
14
Labels on outputs mark who is able to see them · · · Add Add Output · · · PC 14@H
14
15
Abstract Machine NI Concrete Machine NI
Refined by
16
Similar to previous one, but with hardware mechanisms for supporting IFC 1@0 5@0 8@1
17
Plain integer tags instead
Uninterpreted in hardware 1@0 5@0 8@1
17
Hardware cache governs tag propagation Cache 1@0 5@0 8@1
17
Cache line relates combination of instruction and operand tags to result tag Add 0 0 0
result
1@0 5@0 8@1
17
1@0 5@0 8@1 Cache Add 0 0 ?
18
1@0 5@0 8@1 Cache Add 0 0 ? Add 0 0 0
18
1@0 5@0 8@1 Cache Add 0 0 ? Add 0 0 0 Result is 0
18
6@0 8@1 Cache
18
6@0 8@1 Cache
18
6@0 8@1 Cache Add 0 1 ?
18
6@0 8@1 Cache Add 0 1 ?
18
6@0 8@1 Cache Add 0 1 ?
18
6@0 8@1 Cache Add 0 1 ?
Control is transferred to fault handler
18
Fault Handler Handler is a piece of machine code running in privileged mode Add 0 1 ?
19
Fault Handler It can modify the cache, as well as bypass it Add 0 1 ?
19
Fault Handler It analyzes the fault context
Add 0 1 ?
19
Fault Handler It analyzes the fault context
Add 0 1 ?
19
Fault Handler It analyzes the fault context
Add 0 1 ?
19
Fault Handler It analyzes the fault context
Add 0 1 ?
19
Fault Handler . . . and computes corresponding result tag Add 0 1 1
19
Fault Handler The handler then installs that line in the cache, returning to faulting instruction Add 0 1 1 Cache
19
Cache look-up will then succeed, allowing code to continue Cache 6@0 8@1
19
Cache look-up will then succeed, allowing code to continue Cache 6@0 8@1 Result is 1
19
Cache look-up will then succeed, allowing code to continue Cache Result is 1 14@1
19
20
Abstract Machine NI Concrete Machine NI
Refined by
21
a1 c1 Concrete Abstract
labels correctly rep- resented, cache com- patible with IFC rules, machine in user mode
22
a1 c1 Concrete Abstract . . . tc
machine runs, producing output trace
22
a1 c1 Concrete Abstract . . . tc . . .
want corresponding abstract trace combine two execution lemmas
ta
22
a1 c1 Concrete Abstract . . . tc . . . ta c2
cache hit step
22
a1 c1 Concrete Abstract . . . tc . . . ta c2
a2
hit case simulation lemma
22
a1 c1 Concrete Abstract . . . tc . . . ta c2
a2
p1 pk c3 . . .
cache miss step
22
a1 c1 Concrete Abstract . . . tc . . . ta c2
a2
p1 pk c3 . . .
handler executes . . .
22
a1 c1 Concrete Abstract . . . tc . . . ta c2
a2
p1 pk c3 . . .
. . . and returns to user code
22
a1 c1 Concrete Abstract . . . tc . . . ta c2
a2
p1 pk c3 . . .
handler correctness lemma
22
a1 c1 Concrete Abstract . . . tc . . . ta c2
a2
p1 pk c3 . . .
proceed inductively
22
Interesting issues involved in these proofs
❼ Verification of machine code is difficult ❼ Need to formalize notion of compatibility between
cache and IFC rules
❼ How to make it work for any IFC lattice?
23
24
Abstract Machine Concrete Machine Fault Handler
Refined by
25
Abstract Machine Symbolic-Rule Machine Concrete Machine Fault Handler
Refined by Refined by
25
Abstract Machine Symbolic-Rule Machine IFC Rules
IFC side-conditions symbolically represented by
Concrete Machine Fault Handler
Refined by Refined by
25
Abstract Machine Symbolic-Rule Machine IFC Rules
IFC side-conditions symbolically represented by
Concrete Machine Fault Handler
Refined by Refined by Easy to show
25
Abstract Machine Symbolic-Rule Machine IFC Rules
IFC side-conditions symbolically represented by
Concrete Machine Fault Handler
Refined by Refined by Provide formulation of cache compatibility
25
Abstract Machine Symbolic-Rule Machine IFC Rules
IFC side-conditions symbolically represented by
Concrete Machine
Refined by Refined by
Fault Handler
Correctly compiled to
25
Abstract Machine Symbolic-Rule Machine IFC Rules
IFC side-conditions symbolically represented by
Concrete Machine
Refined by
Fault Handler
Correctly compiled to Refined by Combine hit and miss simulation lemmas
25
Instruction Result Label Add LAB1⊔LAB2 Output LAB1 . . . . . .
if the current instruction is
26
Instruction Result Label Add LAB1⊔LAB2 Output LAB1 . . . . . .
label the result with
26
Instruction Result Label Add LAB1⊔LAB2 Output LAB1 . . . . . .
for Add, result is as secret as operands
26
Instruction Result Label Add LAB1⊔LAB2 Output LAB1 . . . . . .
for Output, use same label
26
27
Structured programming instead of assembly programming
❼ Define structured-code generators as Coq functions ❼ Generators provide a structured language for the
machine (if, case, and, or, while, . . . )
❼ Prove Hoare-logic rules for each generator
28
Write a rule table compiler in Coq
❼ Use generators as a backend ❼ Parameterized over correct implementation of lattice
primitives
❼ Compose Hoare triples to show compiler correctness
29
❼ Fetch instruction and operand tags from faulting
context
❼ Compute the result tag from this data using
compiled rule table
❼ Install computed line into the cache
Proven correct by composing compiler lemma with triples for the glue code
30
Abstract Machine NI Symbolic-Rule Machine IFC Rules
IFC side- conditions symbolically represented by
Concrete Machine Fault Handler NI
Refined by Refined by Correctly compiled to
31
Abstract Machine NI Symbolic-Rule Machine IFC Rules
IFC side- conditions symbolically represented by
Concrete Machine Fault Handler
Refined by Refined by Correctly compiled to
NI
Preserved
31
32
Complete model includes more features
❼ Control flow and user-level procedures ❼ Block-structured memory with dynamic allocation ❼ System calls for implementing new IFC primitives ❼ Richer IFC labels (sets of principals represented as
pointers to memory arrays)
33
❼ Track implicit flows ❼
❼
❼ ❼
34
❼ Track implicit flows ❼ Allocation and noninterference
❼
❼ ❼
34
❼ Track implicit flows ❼ Allocation and noninterference
❼ Pointer values could leak secrets
❼ ❼
34
❼ Track implicit flows ❼ Allocation and noninterference
❼ Pointer values could leak secrets
❼ Label representation depending on machine state ❼
34
❼ Track implicit flows ❼ Allocation and noninterference
❼ Pointer values could leak secrets
❼ Label representation depending on machine state ❼ Low-level code for array manipulation and
corresponding proofs
34
35
❼ Described a hardware mechanism for dynamic
tag-checking and propagation
❼ Proof architecture for connecting it to high-level
property
❼ Refinement provides structure to proof
❼ Everything formalized in Coq
36
Entire formalization available at www.crash-safe.org Complete machine and corresponding proofs in approximately 15k LOC
37
❼ More interesting IFC features (concurrency,
declassification, dynamic principal generation, . . . )
❼ Make model more realistic
❼ Incorporate more features of SAFE ❼ Study tag cache in the context of conventional
architectures ❼ Mechanism is not IFC-specific, investigate other
applications.
38
39