View
214
Download
0
Category
Preview:
Citation preview
Higher-Order π-RAT:A Calculus for Trusted Computing
Andrew Cirillo
joint work with James Riely
DePaul University, CTI
Chicago, IL USATrustworthy Global Computing 2007
Trust: “The expectation that a device will behave in a particular manner for a specific purpose.”
- TCG Specification Architecture Overview
2
Example
AlicePrivacy Sensitive Data
Can I trust this server with my sensitive data?
Is customer hacked or
robot?
Expects That Bob:1.Complies with a Particular Privacy Policy2.Running Server Software at Latest Patch Level
Expects That Alice:1.No Spyware to Intercept e-tickets2.Request Coming from a Human User
Data with Monetary Value
BobsTickets.com
3
Trust, Behavior and Static Analysis
Security Depends on the Behavior of Others Trust = Expectation that Other Will Behave According to X Trustworthy = Other Guaranteed to Behave According to X
Behavioral Specifications Include: Type/Memory Safety, Non-Interference Compliance with MAC, DAC or Ad-Hoc Policies
Static Analysis Used to Guarantee Behavior Type Systems (Maybe False Negatives) Bounded Model Checking (Maybe False Positives)
In Open Distributed Systems: Safety Depends on Properties of Remote Systems Need to Authenticate Code
4
Very Brief Overview of Remote Attestation
Integrity Measurement Metric for Identifying Platform Characteristics E.g. SHA-1 Hash of Loaded Executable Files (#)
Platform Configuration Register (PCR) Protected Registers for Storing Measurements Segmented into 5 Levels (0-4) Levels 3 and 4 Protected by Hardware Each Level Protected from Subsequent Levels
Measurements Stored In Registers[#(BIOS)|#(TSS)|#(OS)|#(App.EXE)]
Attestation Contents of PCR + Arbitrary Payload, Signed by TPM Key
5
Hypothesis: We can use attestation to solve trust issues in open distributed systems.
Solution: Enforce access control based on behavioral properties established through static analysis.
6
Our Solution: HOπ-RAT
Distributed Higher-Order Pi Calculus Locations Identify Executable(s) Access Control Logic based on Code Identity Include Primitive Operations for Loading Code and Building
Attestations Focus is on Concepts Relating to Code Identity - Is Abstract
w.r.t. Attestation Protocol
7
Our Solution: HOπ-RAT
Starting Point: Distributed HOπ with Pairs
Terms M,N ::= n | x | (M,N) | (x)P
Processes P,Q ::= 0 | M!N | M?N | new n; P | P|Q
| split (x,y) = M; P | M N
Configurations G,H ::= l[P] | new n; G | G|H
split (x,y) = (M,N); P P{x := M}{y := N}
((x)P) N P{x := N}
Structural Rule l[P|Q] ≡ l[P] | l[Q]
8
Our Solution: HOπ-RAT
Interpretation of Locations (l) Physical Addresses (Dπ, Distributed Join Calculus, …) Principals (Fournet/Gordon/Maffeis, DaISy, …) Code Identity (This Talk)
Processes Located at Measurements P Running on Host with [tss|myos|widget] in PCR
(tss|myos|widget)[P]
On a well-functioning trustworthy system, this means:n widget = #(M) for some executable M n P is a residual of M
9
Access Control: Overview
Access Control Logic Code Identities (Represent Hashes of Executables) Security Classes (Represent Static Properties) Compound Principals
Policy Consists of: Dynamic: Map Identities to Properties Static: Security Annotations on Channels Partial Order (=>) Ranks Principals by Trustedness
a la Abadi,Burrows,Lampson,Plotkin. ’93 (hereafter ABLP)
10
New Stuff
Principals A,B ::= a | αidentities/classes
| 0 | any bottom/top
| A|B quoting
| A˄B | A˅B and/or
Processes P,Q ::= ... | a => α Σ = a1 => α1 | ... | an => αn
Types T,S ::= Un | T×S | T→Prc Un/pairs/abs
| Ch‹A,B›(T) read-write
| Wr‹A,B›(T) write only
Encodes measurements
Access Control: Principals and Types
11
Access Control: Channel Types
Authorizations Specified in Type Annotations
new n : Ch‹A,B›(T);
Indirection via ABLP-style Calculus, e.g.Σ├─ a => α implies Σ├─ a => α ˅ β
Subtyping Uses Principal Calculus, e.g.
Σ├─ Wr‹A,B›(T) <: Wr‹A’,B’›(T)if Σ├─ A => A’ and Σ├─ B’ => B
Writers
Readers
Content Type
12
Access Control: Example
Ex. Writers must have both prop1 and prop2 properties,
new n : Wr‹(prop1˄prop2), any›(T)
Then, if we have:
(...|widget)[n!M]
Then it should be the case that:
Σ├─ widget => (prop1˄prop2)
13
Access Control: Runtime Error
New Stuff
Runtime Errors
Σ ► A[wr-scope n is C] | B[n!M] if not Σ |- B => C
Σ ► A[rd-scope n is C] | B[n?(x)M] if not Σ |- B => C
Distinction Between Possession and Use
Processes P,Q ::= ... | wr-scope N is C | rd-scope N is C
14
New Stuff
Terms M,N ::= ... | [(x)P] | {M:T @ a}
Processes P,Q ::= ... | load M N | let x = attest(N:T); M
| check {x:T} = N; M
Our Solution: HOπ-RAT
host[load [(x)P] N] (host|a)[P{x:=N}]if a = #([(x)P])
a[let x = attest(N:T); M] a[M{x:={N:T @ a}]
b[a => cert] | b[check {x:T} = {N:T @ a}; M] b[a => cert] | b[M{x:=N}]
15
Type System: Overview
The cert Security Class Indicates Type Annotations in Attested Messages are Accurate Will Not Expose Secret-Typed Data to Attackers Will Not Write/Read Channels Without Authorization
Main Components: Classify Data with Kinds (PUB/PRV/TNT/UN) Subtyping Constraints on Well-Formed Policies Correspondence Assertions A la Gordon/Jeffrey 2003 and Haack/Jeffrey 2004
16
Type System: Attacker Model
Attacker Model Create Attestations with Bad Type Annotations Falsify Subsequent Measurements* Extract Names from Executables* Spy on (i.e. Debug) Running Child Processes
New Stuff (Attackers Only)
Processes P,Q ::= ... | spoof B; P | let x1,…,xn = fn(M); P
a[spoof b; P] (a|b)[P]
a[let x = fn([(y)n!unit]); P] a[P{x:=n}]
17
Type System: Results
Definition: A configuration is considered a Σ-Initial Attacker if it is of the form A1[P1] … An[Pn] where for all Ai, Σ does not map Ai to cert, and all Pi contain no attestations.
Definition: A configuration G is robustly Σ-safe if the evaluation of G|H can never cause a runtime error relative to Σ for an arbitrary Σ-initial attacker H.
Theorem: Let Δ be a type environment where every term is a channel of kind UN. If Σ;Δ├─ G , then is robustly Σ-safe.
18
Extended Example from Paper
19
Conclusions
We Have: Proposed a New Extension to HOπ for Modeling Trusted Computing Enable Access Control based on Static Properties of Code Developed a Type System for Robust Safety
For Future Work We Are Considering: Internalizing Program Analysis (e.g. model certifying compilers) Using Attestations to Sign Output of Certifiers Exploring an Implementation for Web Services
20
Thanks!
See tech. rep. at http://reed.cs.depaul.edu/acirillo (next week)
21
Static Analysis for Open Distributed Systems
Heterogeneous/Open Systems Components under the Control of Different Parties Different Trust Requirements Who’s Analyzing Who?
Problems for Hosts Safety Depends on Code Received From Outside Code Distributed in Compiled Format, Analysis Intractable Solution: Bytecode Verification or Proof-Carrying Code
Problems for Remote Parties Safety Depends on Properties of Code on Remote System Need to Authenticate the Remote Code Solution: Trusted Computing with Remote Attestation
22
Recommended