Higher-Order π -RAT: A Calculus for Trusted Computing

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


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


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

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

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


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

Higher-Order π -RAT: A Calculus for Trusted Computing

Documents

Transcript of Higher-Order π -RAT: A Calculus for Trusted Computing