logical attestation: an authorization architecture for trustworthy computing emin gün sirer

88
Logical Attestation: An Authorization Architecture for Trustworthy Computing Emin Gün Sirer Willem de Bruijn , Patrick Reynolds * , Alan Shieh , Kevin Walsh, Dan Williams, Fred B. Schneider Cornell University * now at BlueStripe Software now at Nicira Networks now at Google, Inc.

Upload: bryanne-kennedy

Post on 30-Dec-2015

23 views

Category:

Documents


0 download

DESCRIPTION

Logical Attestation: An Authorization Architecture for Trustworthy Computing Emin Gün Sirer Willem de Bruijn † , Patrick Reynolds * , Alan Shieh ‡ , Kevin Walsh, Dan Williams, Fred B. Schneider Cornell University * now at BlueStripe Software ‡ now at Nicira Networks - PowerPoint PPT Presentation

TRANSCRIPT

Logical Attestation:An Authorization Architecture for

Trustworthy Computing

Emin Gün Sirer

Willem de Bruijn†, Patrick Reynolds*, Alan Shieh‡,Kevin Walsh, Dan Williams, Fred B. Schneider

Cornell University

*now at BlueStripe Software‡now at Nicira Networks

† now at Google, Inc.

Secure coprocessors provide a unique key and on-board cryptographic functions to capture software state

CheapRapidly becoming ubiquitousEvil

TPMs and Attestation

0xab...

TCBHash-basedAttestation

Trusted Platform Module

Evils of Hash-based Attestation

Supports only axiomatic trust

Eliminates user choice and control over platform

Requires database of trusted configurations

Attestation process violates privacy

Does not capture dynamic run time state or configuration

0xab...

Trust EstablishmentThree techniques for establishing trust:

Axiomatictrust by fiatbinary hashes, ACLs, vendor crypto-signatures

Analytican analyzer checked and ascertained a propertye.g. type checkers, binary analyzerscode contains only forward jumpscode is typesafe

Synthetican execution environment assures a desired propertye.g. reference monitors, sandboxes, SFI, binary rewriterscode cannot issue certain system callscode respects resource limits

Authorization

Comes down to a simple if statement…

“should this principal be allowed to perform this operation on this resource?”

But how that statement is implemented has profound consequences

what kinds of policies can be expressed

how practical the system is

what kind of performance it achieves

Goals and Contributions

Logical Attestation: A new attestation scheme that captures semantic properties of programs through labels

Nexus: A new OS with mechanisms for

generating meaningful and useful credentials

managing credentials, combining them with state

checking credentials efficiently

Applications: Fauxbook, Movie Player, Java Object Store, CertiPics, TruDocs, NBGP, …

Logical Attestation

principal says statement

A label is a statement attributed to a principal

Uttered by a labeling function

Unforgeable, backed by a TPM

Expressed in a variant of first-order logic

Logic

Labels are expressed in Nexus Authorization Logic (NAL)

• Similar to CDD and BAN logic, machine-parseable extensible, terms defined by label producers

• incorporates references to dynamic system state

• Constructive• reasoning requires positive evidence

• Logic of beliefs • inference rules preserve justification (not just truth) of statements • world-views restrict the impact of compromised principals

• Sub-principals and Groups• in addition to primary principals consisting of keys and processes

Establishing Trust with Logical Attestation

axiomatic hash

refmon says refmon.noaccess(pid1, disk)

user.egs says hash speaksfor user.egs

analyzer says analyzer.typesafe(“app”)analysis safe language

synthesis sandboxing

Chain of Trust in Logical Attestation

nexus says executed(labeling function)

bootloader says sha(nexus) = 0xab..

bios says sha(bootloader) = 0xbc..

labeling function …

tpm says sha(bios) = 0xcd..

atmel says tpm speaksfor atmel

lstore

Label Creation

Labels are issued into labelstores with the say(principal, statement) system call

Secure channel obviates crypto in the common case

Labels can be externalized to X.509, internalized, copied, deleted

nexus

LF1 LF2

Authorization with Labels

Nexus enables all resource accesses to be predicated on a guard

Guards perform authorization, by checking labels against a goal formula

A NAL statement that needs to be discharged for access

Can capture any provable characteristic

Goal formula provides policy flexibility

setgoal(object, method, goal) system call

setting the goal statement itself requires authorization

if not set, only the creator can set the goal, no super-user

Guards

Clients use labels to construct proofs that discharge the goal formula

Guards validate proofsprovides flexibility to clients

Validation may require consulting authorities

Halt! Prove goal formula to show that I can trust you with this resource.

Authorities

Certain statements are time-varying or non-monotonic

They cannot be safely issued as credentials

E.g. time, number of times a file has been read, current memory consumption, etc.

In logical attestation, the validity of time-varying labels is checked by consulting an authority

Authorities are designated by the goal formula

Multiple authorities can coexist

1. Owner sets policy goal(*, write, file) =

Authorization with Logical Attestation

file says time<3pm

3. User generates import L1; import L2; proof speaksfor; arithmetic-lt

4. Guard verifies proof and labels

L1 timesrv says time=2:30pm

L2 file says timesrv speaksfor file

2. User gathers labels

Caching

Cache extensively to speed up authorization

An in-kernel decision-cache avoids re-invoking a guard

Hashtable indexed by subject, object, method, proof

A user-level guard-cache avoids re-validating a previously checked proof or lemma

Dynamically varying parts of the proof are not cached

All caches contain soft-state

Invalidated as necessary when goal formulas are modified

Overview

nexus

Caller Authority

Authority

Labelstore

GuardGoal Store

Object

Proof CheckerProofCache

Interposition Service

DecisionCache

call(P, S, M, proof)

logical attestation

nexus

applications

evaluation

Nexus OS Overview

Microkernel unique driver architecture 21K loc

Somewhat Posix compatible python, lighttpd, sqlite, mplayer, … Xen, Linux

Non-standard services labels, labelstores, guards, authorities introspection & interposition protected persistent storage

Analysis

some analysis involve examining the applicationno system support needed

Introspection: live kernel metadata

Many analyses involve the application’s environmentNexus provides a /proc filesystem on steroids

access by labeling functions is mediated by the app

Interpositioning

interpose(prin, obj, method) system call enables a process to interpose on any IPC

Can interpose on any subject, object, operation triple, with wildcards

interposition itself is guardedby a goal formula

app

nexus

Interpositioning

interpose(subj, obj, method) system call enables a process to interpose on any IPC

Can interpose on any subject, object, operation triple, with wildcards

interposition itself is guardedby a goal formula

app

nexus

ref mon

logical attestation

nexus

applications

evaluation

Movie Player

nexus

app

labelingfunction

labeling functions can be written by third-parties

GNU

Movie Player

nexus

app labelingfunction

they use the introspection and/or interposition serviceto examine and modify the application’s behavior

GNU

Movie Player

nexus

app labelingfunction

they generate attributable statements

os says proc17 speaks-for sonyLF

proc17 says sonyLF.nowrite(app, disk|network)

GNU

refmon

Movie Player

labels are combined into proofs, which are shipped toconsumers to form the basis of trust decisions

GNU

nexus

app labelingfunction

refmon

Fauxbook

• Privacy-preserving social networking application deployed in the cloud

• Three classes of principals:– Cloud operator– Cloud application developers– Users

• Cloud application developer receives assurance that he will get a desired share of resources

• User receives assurance that her data will not leak beyond her social circle, even if the developer is adversarial

Fauxbook Mechanism

• Insight: many applications are data-independent

– Possible to implement the core data-sharing functionality in a social networking application without examining the data

• Core mechanism:

– A reference monitor wraps all incoming data into a Python object, called a constrained buffer (cobuf)

– Applications may slice, dice, concatenate cobufs, but may not peek at contents

• Bases of trust:

– Axiomatic trust in the device driver

– Analytic trust in a Python analyzer that ensures that Fauxbook code will not use Python features to violate the cobuf abstraction

– Synthetic trust in Fauxbook’s access to the social graph

framework

Fauxbook

nexus

netdrv

lighttpd

cobuf social dbanalyzer

Cloud Operator

Driver provides labels showing that it can only talk to the web framework and that it lacks the ability to modify or divert packets

framework

Fauxbook

nexus

netdrv

lighttpd

cobuf social dbanalyzer

Cloud Operator

lighttpd is axiomatically trusted to deliver packets to the framework without modificationit lacks the capability to leak to other processes

framework

Fauxbook

nexus

netdrv

lighttpd

cobuf

fauxbook

social dbanalyzer

Analyzer ensures that fauxbook code does not use Python reflection to violate the cobuf interface

fauxbook

framework

Fauxbook

nexus

netdrv

lighttpd

cobuf

fauxbook

social dbanalyzer

fauxbook

adding a friend adds a speaks-for label into the social database

friend(egs, alice)friend(egs, bob)

friend(bob, charlie)friend(alice, bob)

framework

Fauxbook

nexus

netdrv

lighttpd

cobuf

fauxbook

social dbanalyzer

fauxbook

cobufs wrap user data into opaque objects, and tag it with the user’s id

alice says hey!

framework

Fauxbook

nexus

netdrv

lighttpd

cobuf

fauxbook

social dbanalyzer

fauxbook

Fauxbook may slice and dice user data, but may not leak it to another user or gain raw access to it

fauxbook

framework

Fauxbook

nexus

netdrv

lighttpd

cobuf

fauxbook

social dbanalyzer

fauxbook

Fauxbook may slice and dice user data, but may not leak it to another user or gain raw access to it

fauxbook

alice says hey!

logical attestation

nexus

applications

evaluation

Microbenchmarks

Protected Nexus calls incur overheads comparable to regular Linux calls

but the microkernel architecture of the Nexus can necessitate additional and costly process boundary crossings

Proof-checking overhead

Cached decisions incur <500 cycles (<1usec)Guard invocations are 20x more expensive

Related Work

• Secure boot– Gasser et al 89, Haertig et al 93, Arbaugh et al. 97

• Attestation– Property-based: Haldar et al. 04, Sadeghi et al. 08

– Binary: TCGLinux

– Software: Seshadri et al. 04-05, BIND, Flicker

• Credentials-based Authorization– Appel & Felten 99, Lampson ‘04, Parno & Perrig ‘10

• Systems– Terra, Nizza, BirliX, XOMOS, sHype, Wedge, HiStar, Asbestos, EROS,

Flask

• Others– Not-a-bot, TrInc, …

Conclusions and Future Work

• TPMs can be used to build the next generation of trustworthy applications

– need not impinge on user choice over software

– can provide qualitatively richer guarantees

• Novel labeling functions enable new functionality

http://www.cs.cornell.edu/people/egs/nexus/

git.systems.cs.cornell.edu/nexus

screenshot

Macrobenchmark: Packet Processing

Caching enables packet processing overhead to be <6%

Cryptographic Overhead

Avoiding cryptography leads to 3 orders of magnitude performance gain

kernel size

application: web application server

interpositioning: kernel message hooks

synthesis: (subject, operation, *) → ipcportauthorization: (*, operation, object) → ipcport

allow / block<transformed call>cache / nocache

CertiPics: problem

CertiPics: certified chain-of-custody

• NY Times Policy: Image comes from a legitimate camera ,with only acceptable adjustments:

– Cropping, captions, redaction, color balancing, …

– Compositing/splicing after adding borders

IRAN

?

CertiPics: design options• trusted photo editor:

– Incapable of modifying image in undesirable ways– evidence: editor is the trusted version

• image analysis:– evidence: analyzer input and output

• audit trail:– image modification tools generate logical labels at each

step– evidence: data from each modification

IRAN

?

52

CertiPics: demo

crop.exe

Nexus

splice.exe

Nexus

caption.exe

Nexus

IRAN

?

user input

ipd3 says crop(«im1», 20%) = «im2»

EOS says pristine(«im1»)

NYTimes policy

nexus says hash(ipd3) = «hash1»nexus says hash(ipd3) = «hash1»nexus says hash(ipd3) = «hash1»nexus says hash(ipd3) = «hash1»nexus says hash(ipd3) = «hash1»nexus says hash(ipd3) = «hash1»

53

One cannot look at this Universe with all living productions & man without believing that all has been intelligently designed;yet when I look to each individual organism, I can see no evidence of this.

– Charles Darwin, 1861

“ ””

TruDocs: documents with excerpts

54

TruDocs: document integrity examples

Wesleyan Cinema Archive may quote 75 words at a time 20 quotes per derivative work

New International Version Bible at most 500 verses, verbatim only at most 25% of derivative work

W3C Logo may embed if validator passes must retain attribution, link to W3C URL

TruDocs with logical attestation

Let

• D be a document

– D is a corresponding principal

– W(D) are statements conveyed in D

• E be an excerpt from D’ appearing in D

– Src(E) =D’ Src(E) = D’

– E<D: E appears in D

TruDocs says (E<D: E Src(E))

56

TruDocs: labeling function design

Approximating: E Src(E)

usePolD’(E,D): an analytic basis for trust:

– Find some E’ in D’;

– make “acceptable” edits to E’, getting E in D.

D’ says ( usePolD’(E,D) E D’ )

usePol is defined by author of D’.

TruDocs says (E<D: usePolSrc(E)(E,D))

Existing networks cannot provide strong security guarantees

All networks look the sameAll clients look the sameCannot tell what a router is actually doingNetwork elements constructed from untrustworthy components

No mechanisms for querying the properties of network participants

trust in the network

Internet

ISP B 99% uptime fault-tolerant

ISP A 90% uptime

? ?

1 Mb/s

Identical WiFi base stations!

clients cannot differentiate between different networks

100 Mb/s

no mechanisms for querying network properties

no mechanisms for querying network properties

? ? ?

Identical Ethernet stations!

networks cannot differentiate between clients

networks cannot differentiate between other networks

Identical IP packet delivery interface!

ISP B DoS filter

ISP AForward all packets

Customer AS??

no mechanisms for querying network properties

M1

L5

S

R1L1T

L2 L3R2

L4

R1: Type = RouterR1: NextHop = { [IP_T] = L2, ...] }

S: Type = HostS: Name = HostSS: NextHop = { [IP_T] = L2, ... }

ISP: Type = LinkISP: Ends = (S, R1)

ISP: Type = LinkISP: Ends = (R1, R2)

ISP: Type = LinkISP: Ends = (R1, R3)

R2: Type = RouterR2: NextHop = { [IP_T] = L3, ... }

M1: Type = SnifferM1: NextHop = { [IP_T] = L5, ... }

T: Type = HostT: Name = HostT

ISP: Type = LinkISP: Ends = (R2, T)

ISP: Type = LinkISP: Ends = (R3, T)

Network

Tuplespace

Every network participant corresponds to a tuple

U

a single, distributed tuplespace covers the Internet

every information provider is responsible for provisioning a sub-tuplespace for storing local information

AS1 AS2POP1

R1

POP2

R2

Global Tuplespace

AS1

R1 POP1

AS2

R2 POP2

information management

anyone can annotate any tuple

– New, unanticipated attributes are organically supported

attributes can be added by anyone

– best done by a TPM, signed, unforgeable

– signed attributes can be inserted manually attributes are masked for privacy according to an

export policy

applications import annotations only from sources they trust, according to an import policy

querying the tuplespace

Is there a packet sniffer on (S,T) path?

retrieve(S.nexthop[IP_T])-> S:S.NextHop[IP_T] = L1

retrieve(L1.endpoints)-> S:L1.endpoints = (S,R1)...

Path(S,T) = [L1,R1,L2,R2,L3]

Queries Detected properties

Apps can detect properties at a single point in time

monitoring the tuplespace

Detect new packet sniffers on (S,T) path

install_trigger( R1.NextHop[IP_T],IP_S)

Trigger installation

S

R1

TL2

L4

X

L5M1Change @ R1.NextHopApps can maintain

properties over time

R1: Type = RouterR1: NextHop = { [IP_T] = L2, ... }

R1: Type = RouterR1: NextHop = { [IP_T] = L4, ... }

Trigger notification

Path(S,T) = [L1,R1,L4,M1,L5]

collaborators

• Fred Schneider

• William de Bruijn

• Alan Shieh

• Patrick Reynolds

• Kevin Walsh

backups

proof evaluation cost

control operation cost

dynamic state

labels can be sharedlabels may not encode false statements

live authority protocolover ipc or network

subscribes to statement, but without attributionstatement cannot be shared

protected storage

confidentiality: block cipherintegrity: hash trees

proof caching

1. kernel decision cache

2a. guard credential cache only labels: revisit all missing and authorities

2b. guard deduction cache also cache goal/conclusion matching

Safe Python

Analysis: Safe Python

restrict python to safe subset:

no arbitrary system accessno modules os, ..

no builtins file, exec, ..

no reflectionno modules ast, inspect, .. no builtins compile, eval, ..

no arbitrary importpruned builtinsalternative interface to webserver and storage

unchecked_...

no access to global & builtins __dict__

offline analyzer

Safe Python: module protect

restricted namespacerestricted fileops: append, removerestricted import

pbuf

pbufres = app.callback(pbufreq)

Safe Python: PBuf

list of strings ..

Safe Python: PBuf

list of strings and pbufs

Safe Python: PBuf

list of strings and pbufs

with protection bit

and optional dictionary

python iterable & map operationsprivileged unchecked_.. extensions

Safe Python: module protect

Secure Persistent Storage

confidentialityCTR mode random-access AES

integrityMerkle hash tree

interfaceunix fcntl flags: F_SETENC, F_SIGN, F_SIGNED

rootlockbox: virtualize TPM

Storage: Lockbox hierarchy

lockbox applicationtable of keys and signaturessoftware seal/sign/encryptipc interfaceminimizes key access (TCB)

hierarchystore bundles backed by TPM (or remotely)

introspectionfs

per process: to display state kernel: process memory, network ports, ipc channels, …

nonvolatile statements exported as labels os says netport.80 speaksfor process.www

volatile state exported only as authority os says not netport.81 speaksfor process.www

may still change

define private notions of trust

os says ...

user.bob says os speaksfor user.bob

example revisited

example revisited

label consumers

• Every entity that wants to reason about the state of a remote computer can act as a label consumer

• Typically, the consumer is looking for a goal formula

• The user has one or more labels available

Is this principal trustworthy?

labels are combined to create proofs that demonstratethe desired goal formula

authorization today

Access control list for f: [ …. A-(read,write), … ]

Client A File systemA says read(f)

authorization based on requestor identifier

88

Client A File system

Policy for read(f): Exists i : 0900 <timeNow < 1700 and i says read(f) and Univ says student(i )

A says read(f)RC says student(A)Univ says RC Univ

Policy is decentralized (“speaksfor”) models delegation

Policy involves state Policy involves deduction

Univ says RC Univ

RC says student(A)

authorization with labels