Presentation is loading. Please wait.

Presentation is loading. Please wait.

Logical Attestation: An Authorization Architecture for Trustworthy Computing Emin Gün Sirer Willem de Bruijn †, Patrick Reynolds *, Alan Shieh ‡, Kevin.

Similar presentations

Presentation on theme: "Logical Attestation: An Authorization Architecture for Trustworthy Computing Emin Gün Sirer Willem de Bruijn †, Patrick Reynolds *, Alan Shieh ‡, Kevin."— Presentation transcript:

1 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.

2 Secure coprocessors provide a unique key and on-board cryptographic functions to capture software state Cheap Rapidly becoming ubiquitous Evil TPMs and Attestation 0xab... TCB Hash-based Attestation Trusted Platform Module

3 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...

4 Trust Establishment Three techniques for establishing trust: Axiomatic trust by fiat binary hashes, ACLs, vendor crypto-signatures Analytic an analyzer checked and ascertained a property e.g. type checkers, binary analyzers code contains only forward jumps code is typesafe Synthetic an execution environment assures a desired property e.g. reference monitors, sandboxes, SFI, binary rewriters code cannot issue certain system calls code respects resource limits

5 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

6 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, …

7 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

8 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

9 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

10 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

11 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 LF1LF2

12 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

13 Guards Clients use labels to construct proofs that discharge the goal formula Guards validate proofs provides flexibility to clients Validation may require consulting authorities Halt! Prove goal formula to show that I can trust you with this resource.

14 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

15 1. Owner sets policy goal(*, write, file) = Authorization with Logical Attestation file says time<3 pm 3. User generates import L1; import L2; proof speaksfor; arithmetic-lt 4. Guard verifies proof and labels L1 timesrv says time=2:30 pm L2 file says timesrv speaksfor file 2. User gathers labels

16 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

17 Overview nexus Caller Authority Labelstore Guard Goal Store Object Proof Checker Proof Cache Interposition Service Decision Cache call(P, S, M, proof)

18 logical attestation nexus applications evaluation

19 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

20 Analysis some analysis involve examining the application no system support needed

21 Introspection: live kernel metadata Many analyses involve the application’s environment Nexus provides a /proc filesystem on steroids access by labeling functions is mediated by the app

22 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 guarded by a goal formula app nexus

23 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 guarded by a goal formula app nexus ref mon

24 logical attestation nexus applications evaluation

25 Movie Player nexus app labeling function labeling functions can be written by third-parties GNU

26 Movie Player nexus app labeling function they use the introspection and/or interposition service to examine and modify the application’s behavior GNU

27 Movie Player nexus app labeling function they generate attributable statements os says proc17 speaks-for sonyLF proc17 says sonyLF.nowrite(app, disk|network) GNU ref mon

28 Movie Player labels are combined into proofs, which are shipped to consumers to form the basis of trust decisions GNU nexus app labeling function ref mon

29 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

30 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

31 framework Fauxbook nexus net drv lighttpd cobufsocial db analyzer 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

32 framework Fauxbook nexus net drv lighttpd cobufsocial db analyzer Cloud Operator lighttpd is axiomatically trusted to deliver packets to the framework without modification it lacks the capability to leak to other processes

33 framework Fauxbook nexus net drv lighttpd cobuf fauxbook social db analyzer Analyzer ensures that fauxbook code does not use Python reflection to violate the cobuf interface fauxbook

34 framework Fauxbook nexus net drv lighttpd cobuf fauxbook social db analyzer 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)

35 framework Fauxbook nexus net drv lighttpd cobuf fauxbook social db analyzer fauxbook cobufs wrap user data into opaque objects, and tag it with the user’s id alice says hey!

36 framework Fauxbook nexus net drv lighttpd cobuf fauxbook social db analyzer fauxbook Fauxbook may slice and dice user data, but may not leak it to another user or gain raw access to it fauxbook

37 framework Fauxbook nexus net drv lighttpd cobuf fauxbook social db analyzer 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!

38 logical attestation nexus applications evaluation

39 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

40 Proof-checking overhead Cached decisions incur <500 cycles (<1usec) Guard invocations are 20x more expensive

41 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 , 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, …

42 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

43 screenshot

44 Macrobenchmark: Packet Processing Caching enables packet processing overhead to be <6%

45 Cryptographic Overhead Avoiding cryptography leads to 3 orders of magnitude performance gain

46 kernel size

47 application: web application server

48 interpositioning: kernel message hooks synthesis: (subject, operation, *) → ipcport authorization: (*, operation, object) → ipcport allow / block cache / nocache

49 CertiPics: problem

50 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 ?

51 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 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»

53 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 54 TruDocs: document integrity examples Wesleyan Cinema Archive l may quote 75 words at a time l 20 quotes per derivative work New International Version Bible l at most 500 verses, verbatim only l at most 25% of derivative work W3C Logo l may embed if validator passes l must retain attribution, link to W3C URL

55 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

56 56 TruDocs: labeling function design Approximating: E  Src(E) usePol D’ (E,D): an analytic basis for trust: – Find some E’ in D’; – make “acceptable” edits to E’, getting E in D. D’ says ( usePol D’ (E,D)  E  D’ ) usePol is defined by author of D’. TruDocs says (  E

57 Existing networks cannot provide strong security guarantees All networks look the same All clients look the same Cannot tell what a router is actually doing Network elements constructed from untrustworthy components No mechanisms for querying the properties of network participants trust in the network

58 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

59 ? ? ? Identical Ethernet stations! networks cannot differentiate between clients

60 networks cannot differentiate between other networks Identical IP packet delivery interface! ISP B DoS filter ISP A Forward all packets Customer AS ?? no mechanisms for querying network properties

61 M1 L5 S R1 L1 T L2 L3 R2 L4 R1: Type = Router R1: NextHop = { [IP_T] = L2,...] } S: Type = Host S: Name = HostS S: NextHop = { [IP_T] = L2,... } ISP: Type = Link ISP: Ends = (S, R1) ISP: Type = Link ISP: Ends = (R1, R2) ISP: Type = Link ISP: Ends = (R1, R3) R2: Type = Router R2: NextHop = { [IP_T] = L3,... } M1: Type = Sniffer M1: NextHop = { [IP_T] = L5,... } T: Type = Host T: Name = HostT ISP: Type = Link ISP: Ends = (R2, T) ISP: Type = Link ISP: Ends = (R3, T) Network Tuplespace Every network participant corresponds to a tuple U

62 a single, distributed tuplespace covers the Internet every information provider is responsible for provisioning a sub-tuplespace for storing local information AS1AS2 POP1 R1 POP2 R2 Global Tuplespace AS1 R1POP1 AS2 R2POP2

63 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

64 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] QueriesDetected properties Apps can detect properties at a single point in time

65 monitoring the tuplespace Detect new packet sniffers on (S,T) path install_trigger( R1.NextHop[IP_T],IP_S) Trigger installation S R1 T L2 L4 X L5 M1 R1.NextHop Apps can maintain properties over time R1: Type = Router R1: NextHop = { [IP_T] = L2,... } R1: Type = Router R1: NextHop = { [IP_T] = L4,... } Trigger notification Path(S,T) = [L1,R1,L4,M1,L5]

66 collaborators Fred Schneider William de Bruijn Alan Shieh Patrick Reynolds Kevin Walsh

67 backups

68 proof evaluation cost

69 control operation cost

70 dynamic state labels can be shared labels may not encode false statements → live authority protocol over ipc or network subscribes to statement, but without attribution statement cannot be shared

71 protected storage confidentiality: block cipher integrity: hash trees

72 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

73 Safe Python

74 Analysis: Safe Python restrict python to safe subset: no arbitrary system access no modules os,.. no builtins file, exec,.. no reflection no modules ast, inspect,.. no builtins compile, eval,.. no arbitrary import pruned builtins alternative interface to webserver and storage unchecked_... no access to global & builtins __dict__ offline analyzer

75 Safe Python: module protect restricted namespace restricted fileops: append, remove restricted import pbuf pbufres = app.callback(pbufreq)

76 Safe Python: PBuf  list of strings..

77 Safe Python: PBuf  list of strings and pbufs

78 Safe Python: PBuf  list of strings and pbufs  with protection bit  and optional dictionary python iterable & map operations privileged unchecked_.. extensions

79 Safe Python: module protect

80 Secure Persistent Storage confidentiality CTR mode random-access AES integrity Merkle hash tree interface unix fcntl flags: F_SETENC, F_SIGN, F_SIGNED root lockbox: virtualize TPM

81 Storage: Lockbox hierarchy lockbox application table of keys and signatures software seal/sign/encrypt ipc interface minimizes key access (TCB) hierarchy store bundles backed by TPM (or remotely)

82 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

83 define private notions of trust os says... user.bob says os speaksfor user.bob

84 example revisited


86 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 demonstrate the desired goal formula

87 authorization today Access control list for f: [ …. A-(read,write), … ] Client A File system A says read(f) authorization based on requestor identifier

88 88 Client A File system Policy for read(f): Exists i : 0900

Download ppt "Logical Attestation: An Authorization Architecture for Trustworthy Computing Emin Gün Sirer Willem de Bruijn †, Patrick Reynolds *, Alan Shieh ‡, Kevin."

Similar presentations

Ads by Google