463.7 Remote Attestation

1. 463.7 Remote Attestation Computer Security II CS463/ECE424 University of Illinois

2. Overview • Discussion in two parts: • Motivation and Approaches • Assessment and Applications

3. 463.7.1 Remote Attestation: Motivation and Approaches

4. Introduction • Remote attestation is a trusted computing technology that permits a computer to measure properties of a remote system in such a way that the remote system will be detected if it is lying

5. What Gets Measured? Process Process Configur-ation Data Configur-ation Data Security Module Kernel Device Driver Module Configuration Data Security Policy BIOS Bootloader

6. Motivating Applications • Online banking • Vulnerable to rootkits sniffing passwords or undermining browser security mechanisms • Anonymous networks • Mix node running on untrusted base can have its internal operation inspected by operator • Mobile agents • Similar to online banking (web browser is essentially a non-mobile agent of the bank with a user interface) • DRM • Data can be replicated or access controls undermined

7. Motivating Applications (cont.) • Online Games • Players have incentive (often financial) to enhance their avatars’ performance • Corporate Network Clients (laptops, smart phones, etc.) • Particularly prone to introduce malware into the network since they are not administered internally • P2P, Distributed Computing, and Cycle-Selling • Some peers may undetectably cheat • Online Shopping • Website bearing TRUSTe logo may not actually be running privacy-preserving systems

8. Remote Attestation Objectives • Objective: Verifier determines whether a remote system satisfies some property • Example: Is the remote system running the standard Ubuntu Linux v.2.6.18 kernel? • Problem: Can’t just ask the system, since it could lie!

9. Remote Attestation Process • Three phases: • Measurement: machine to be attested must measure its properties locally • Attestation: transfer measurements from machine being attested to remote machine • Verification: remote machine examines measurements transferred during attestation and decides whether they are valid and acceptable

10. Sample Approach: Blizzard Warden • Anti-cheating tool used in several Blizzard games to enforce the EULA • Detected cheaters are sometimes stripped of their account access • Monitors or has monitored: • All window titles on desktop • Process names • Communicates “cheater” or “non-cheater” back to central system using encrypted channel • Switched to apparently randomized encryption scheme in late 2007, locking out reverse engineers • Bots still exist for WoW, so either they are not detected or Blizzard is not penalizing their users • Drawbacks of this approach: • Privacy violations due to access to all processes and windows • Unreliable assurances to Blizzard: Sony music rootkit allowed arbitrary files to be hidden from Warden by simply renaming them [“On Warden” Blog] [Lemos03]

11. Hardware TTP for Remote Attestation: TPM • Pure software TTPs impose severe restrictions on remote attestation assurances, so hardware solutions are an alternative • Most popular: Trusted Platform Module (TPM)

12. TPM Interconnection

13. TPM 1.0 Components [TCG]

14. Credential Types • TPM contains 5 types of credentials: • Commonly-used: • Endorsement or EK credential: uniquely identifies TPM, privacy concern • Identity or AIK credential: Issued by privacy CA to preserve privacy of EK credential • Less commonly-used: • Conformance credential: Certifies that TPM meets specifications • Platform credential: Identifies TPM manufacturer and capabilities • Validation credential: Associated with peripheral or software to guarantee integrity

15. Threat Model • Threat model dictated by hardware capabilities: • Tamper-evident, not tamper-resistant TPM • Not required to zero information when compromised • CPU and memory protected against tampering • Unprotected disk • Can be removed and inserted into new machine • Threat model has been demonstrated to be too weak to defend against moderately-skilled attackers http://www.youtube.com/watch?v=f_Zx8sKCiTo

16. Linux Integrity Measurement [Sailer IMA]

17. How Does It Get Measured? Program code: BIOS Bootloader Kernel Module Module App App SHA1 Hash function: Hashes: BIOS Bootloader Kernel Module Module App App SHA1 SHA1 SHA1 … H1 H2 PCR

18. Linux Attestation

19. Linux Verification

20. Attestation Challenges • Attestation results may lack significance • Chain may be too complex to analyze • Element within chain may be unverified, invalidating entire result • Even a simple software patch requires re-verification • Identity may be less significant than a higher-level security property corresponding to information flow or some other metric

21. Policy-Reduced Integrity Measurement Architecture [JaegerSS06]

22. Simplification • Practically necessary to obtain significant attestation results • Operating systems: • Microkernels • Hypervisors • Kernels in safe languages • Simplifies analysis by providing strong isolation between portions of kernel, even if kernel is still complex • Applications: • Use of safe programming languages and/or modularization

23. Monolithic Kernel Case Study: Linux • SLOC for Linux as of Oct. 2008: ~6.4 million • Kernel Interfaces: • Filesystems • Networking • Individual hardware drivers • Security hooks for fine-grained access control instantiated by in-kernel modules • Audio • Video • … • All in the same address space, with few access restrictions Process Process Process Kernel FS, Net, Drivers, Access, Audio, Video, …

24. Microkernel Case Study: seL4 • Based on L4 microkernel • Very simple API: • Capabilities for access control • Threads • IPC between threads • Other interfaces provided by userspace “servers” that are only permitted to access specific hardware and software resources • Adheres more closely to principle of least privilege Application Application Video Driver Kernel Audio Net Driver FS [seL4]

25. Hypervisor Case Study: Xen • Attempts to export an interface to userspace that resembles the underlying hardware • Deviates from hardware whenever such a deviation provides sufficiently improved performance • E.g. special functions for manipulating page tables and communicating between VMs Process Process Isolated Process Kernel FS, Net, Drivers, … Kernel Hypervisor

26. Formal Verification • Step 1: Formalize the system • E.g. translate its code into a logic that is easily analyzed • Step 2: Express a mathematical theorem about a system: “If process A is granted exclusive access to memory region M, then all other processes are prevented from accessing M” • Step 3: Prove the theorem using whatever logic the system was formalized in using model checker or theorem prover • Only feasible if system is simple. See link below for summary of OS verification efforts to date. [Klein 08]

27. Attestation Challenges (cont.) • May lack firm root-of-trust • Chain of trust may start at OS kernel, permitting malicious BIOS or bootloader to remain undetected

28. Reading [Sailer IMA] Integrity Measurement Architecture (IMA) http://domino.research.ibm.com/comm/research_people.nsf/pages/sailer.ima.html [Klein08] Operating System Verification—An Overviewhttp://ertos.nicta.com.au/publications/papers/Klein_08.pdf

29. Discussion Questions • What dis/advantages do hardware attestation solutions exhibit compared to software solutions like Warden? • What other applications could benefit from remote attestation?

30. Motivating Applications (cont.) • Pay-As-You-Drive Insurance • Customers have financial incentive to falsify data from device that records driving behavior • Transportation Loggers • Transportation company has incentive to falsify data if expensive shipment is mishandled • Advanced Electric Meters • Customers have financial incentive to reduce their recorded consumption

31. 463.7.2 Remote Attestation: Assessment and Applications

32. Intel Trusted Execution Technology (TET) [Intel TET Overview]

33. TET System Implementation • Enter VMM mode using GETSEC[SENTER] instruction, measures VMM before transferring control • Enables the attestation chain to that point to be discarded, giving a fresh reset. Referred to as Dynamic Root of Trust for Measurement (DRTM) • CPU provides internal RAM that can execute code after hashing code and verifying against embedded digital signature. Enter Authenticated Code (AC) mode using GETSEC[ENTERACCS] instruction. • Will only run software signed by Intel using a private key corresponding to a public key in the chipset itself [Intel TET Implementation]

34. ARM TrustZone [ARM TrustZone Home]

35. Attestation Limitations • Compromising a TPM key undermines entire process • Difficult to maintain CRLs • Attestation can only guarantee past and present system properties, it can say very little about the future. • Owner can always turn machine off • Operator can often load new software that violates trust (can be prevented) • Must decide how much state to attest. Should saving a new cookie in your browser invalidate its security?

36. Attestation Limitations (cont.) • Can’t directly detect MITM exploits • Attestation simply tells you what software is running on system, not the identity of the system (for privacy reasons) • Can you solve this? • Useful for clients attempting to verify security of servers? • Only if attestation result has semantic meaning (e.g. verified by TRUSTe) • Only if server operator lacks resources to compromise TPM • Might be worth it for him to spend a lot of money doing so if it enables him to perpetrate lucrative crime

37. Attestation Drawbacks • Platform privacy compromised by some attestation protocols • Endorsement Key uniquely identifies platform • Privacy CAs can issue alternative anonymous keys (AIKs), but have a difficult business model • Involved in every transaction to verify certificates against CRLs, requiring high availability and confidentiality, two requirements often in opposition • Direct Anonymous Attestation based on group signatures • Compromised TPM keys are distributed to all verifiers without necessarily using a centralized CA • Attestation can increase vendor lock-in and platform discrimination by permitting verifying entities to check the exact, complete software stack of the system. [IBM DAA]

38. Attestation-Based DRM • Refuse to provide content to network client until it proves that it is running a configuration that will not misuse that content • High-bandwidth Digital Content Protection (HDCP) is a weak example • Relies upon pre-installed private keys and revocation lists. • If the keys of a device are compromised, it is place on the revocation list and compliant devices will no longer communicate with it. • Note: If you purchase an HDCP-enabled device, and someone else cracks the same model and publicly distributes the keys, your device may be blacklisted! • Otherwise, it is assumed to have an acceptable configuration without further verification.

39. Attestation-Based DRM Concept Music Server Music Client Listener No. Will the computer let the Listener copy the music?

40. Bringing it All Together: Terra Architecture [GarfinkelPCRB03]

41. Terra Attestation Process • Lower layers certify higher layers: • TPM → Firmware → Boot Loader → TVMM → VM → Application • For each layer above TPM: • Upper layer generates public/private keypair • Upper layer requests that lower layer certify its public key and perhaps other data • Lower layer signs certificate with hash over attestable parts of requests as the common name (main identifier) and the hashed data as auxiliary information

42. TVMM Attestation (cont.) • VM disk contents included in attestation • Simple hash tree used to optimize performance • Permits VM to run for indefinite time using false disk hash • Encrypted, integrity-protected, and non-encrypted disks all supported • Keys used to protect disks placed in sealed storage, to prevent attackers from removing disks and performing an offline compromise

43. Attestation Verification • Verify certificate in each layer by ensuring that it is signed by lower layer • TPM certificate is signed by TPM manufacturer, which is also responsible for issuing CRLs • No TPM manufacturer currently does this that I am aware of • Check software hashes and attested data contained within certificates, ensure they are all trusted.

44. Attestation Binding • Verification must be bound to attested process in some way • Exchange certificate chains inside SSL tunnel • If software is good, it will not persist session key • Prevents system from rebooting and continuing execution in unattested state

45. Trusted Quake • Game clients and servers can be modified to provide additional functionality to players • Aiming proxies: modify network commands to stabilize or otherwise assist in aiming weapons • Eavesdropping: determine information about other players’ activities • Puts other players at disadvantage

46. Implementation Performance • Trusted Quake: • Direct boot (no attestation): 26.6 seconds • Optimistic attestation: 27.1 seconds • Encrypted optimistic attestation: 29.1 seconds • Ahead-of-time attestation: 57.1 seconds • Interactive performance apparently equal across the board (but much slower than native I’m sure!)

47. Trusted Quake Weaknesses • Bugs and Undesirable Features: Rendered polygon OSD permits prediction of impending character appearances • Network DoS Attacks: Terra does nothing in this regard • Out-of-Band Collusion: Players can still communicate if they’re sitting together in a basement and glancing at each others’ monitors

48. In the Real World: Security-Enhanced Xen • Similar to Terra in many ways • Mandatory Access Control (MAC) for VM objects and commands • Permits controlled data sharing between VMs, using shared memory buffers • Originally implemented by IBM as sHype • Xen Security Modules (XSM) provides extended hooks, backwards compatibility with sHype, and support for SELinux-style Type Enforcement policies

49. Security-Enhanced Xen (cont.) • Support for TPM virtualization • VM decomposition • Break management interface into pieces, allow different domains to use various parts • Run drivers in separate domains • More like a microkernel than traditional VM-based system • Secure I/O • IO-MMU support [Hand05]

50. Windows BitLocker • Volume encryption • Encryption key can be stored in TPM and only released if TPM detects unmodified Windows instance booting [Hensing09]