Logical Attestation: An Authorization Architecture for Trustworthy Computing Emin Gün Sirer

1. Logical Attestation: An Authorization Architecture for Trustworthy Computing EminGünSirer 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. TCB TPMs and Attestation • Secure coprocessors provide a unique key and on-board cryptographic functions to capture software state • Cheap • Rapidly becoming ubiquitous • Evil 0xab... Hash-based Attestation Trusted Platform Module

3. Evils of Hash-based Attestation 0xab... 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

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-parseableextensible, 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-principalsand Groups • in addition to primary principals consisting of keys and processes

9. axiomatic hash analyzer saysanalyzer.typesafe(“app”) saysrefmon.noaccess(pid1, disk) refmon user.egs sayshash speaksfor user.egs Establishing Trust with Logical Attestation analysis safe language synthesis sandboxing

10. nexus saysexecuted(labeling function) bootloader labeling function sayssha(nexus) = 0xab.. … bios tpm atmel says sha(bootloader) = 0xbc.. sayssha(bios) = 0xcd.. saystpmspeaksforatmel Chain of Trust in Logical Attestation

11. 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 LF1 LF2 lstore nexus

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 says time<3pm file says time=2:30pm L1 timesrv 2. User gathers labels saystimesrvspeaksfor file L2 file 3. User generates import L1; import L2; proofspeaksfor; arithmetic-lt 4. Guard verifies proof and 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 Caller Guard Authority Object Authority Goal Store Labelstore call(P, S, M, proof) Proof Cache Proof Checker nexus Interposition Service Decision Cache

18. logical attestation nexus applications evaluation

19. 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 Nexus OS Overview

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 ref mon nexus

24. logical attestation nexus applications evaluation

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

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

27. proc17 sayssonyLF.nowrite(app, disk|network) saysproc17 speaks-forsonyLF os Movie Player GNU app labeling function refmon nexus they generate attributable statements

28. Movie Player GNU app labeling function refmon nexus labels are combined into proofs, which are shipped toconsumers to form the basis of trust decisions

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. Fauxbook 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 Cloud Operator cobuf social db analyzer net drv lighttpd nexus

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

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

34. Fauxbook adding a friend adds a speaks-for label into the social database fauxbook fauxbook framework cobuf social db analyzer net drv lighttpd friend(egs, alice) friend(egs, bob) friend(bob, charlie) nexus friend(alice, bob)

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

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

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

38. logical attestation nexus applications evaluation

39. 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 Microbenchmarks

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

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 http://www.cs.cornell.edu/people/egs/nexus/ git.systems.cs.cornell.edu/nexus

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. synthesis: (subject, operation, *) → ipcport authorization: (*, operation, object) → ipcport allow / block <transformed call> cache / nocache interpositioning: kernel message hooks

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 ?