Terra: A Virtual Machine-Based Platform for Trusted Computing

1. Terra: A Virtual Machine-Based Platform for Trusted Computing Preston Church James Worsham

2. Terra: A Virtual Machine-Based Platform for Trusted Computing • Department of Computer Science, Stanford • Tal Garfinkel • Ben Pfaff • Jim Chow • Mendel Rosenblum • Dan Boneh • Presented October 19-22, 2003 • ACM Symposium on Operating Systems Principles (SOSP)

3. Terra • Flexible architecture for trusted computing • Virtualizes machines with varying semantics • Simultaneously run applications with varying security requirements • All run on the same commodity hardware • Closed and open box systems side-by-side • Dedicated, tamper resistant platform • Open, commercial systems

4. Why? • Commodity OS provides low-assurance • Millions of lines of code • Does not provide a trusted computing base • Poor application isolation • Poor authentication mechanisms • No trusted path between users and applications • A solution would be a closed-box platform • Game consoles • ATMs • Electronic voting

5. Why? (Cont.) • Closed-Box Platform • Tailored software stack • Unique to the system’s security requirements • Tamper-resistant hardware • Can identify software to remote systems • Offer high-assurance • Address a wide-range of threat models • Most applications do not need these semantics • Most software needs general security • Terra virtualizes both semantics on one platform

6. Architecture • Trusted Virtual Machine Monitor (TVMM) • High-assurance virtual machine monitor (VMM) • Partitions tamper-resistant commodity platform • Multiple, isolated virtual machines (VM) • Tailored to security requirements • Open-box • Closed-box • Cryptographic authentication of software stack • Attestation

7. Architecture (Cont.) • Hardware Interface • Identical to underlying, physical machine • Can run commodity software • Allows developers to specify what runs in each VM • Each application can have uniquely tailored software stack • Security • Compatibility • Performance • Isolation • Hardware memory protection • Cryptographic storage protection

8. Architecture (Cont.)

9. Development Target • Raw VM • (Virtual) hardware-up design • Operating System • Simple bootstrap loader • Complex commercial OS • Can use OS that best meets needs • Security • Portability • Efficiency

10. VM Communication • Virtualized I/O Interfaces • NICs • Serial Ports • Etc. • VMs appears as standard device/program • Normal program • Virtual network appliance • Virtual device

11. Management VM • Dictates policy • TVMM provides resource management • Management VM provides policy enforcement • VM storage • VM memory • VM state • Connected • Started • Stopped

12. TVMM • Virtualizes machine resources • Allows multiples VMs to run on single platform • Independent • Concurrent • Hypervisor • Acts as trusted party • Authenticates software running in VM • Hence the term Trusted Virtual Machine Monitor

13. TVMM Abstractions • Open-box • Semantics of commercial platforms • Run commodity operating systems • Appears as general-purpose system • Closed-box • Semantics of secure, closed-box platform • Content cannot be inspected or manipulated • Only the owner of the machine can access contents • NOTE: Owner of machine not platform

14. TVMM Isolation • Hardware Protection Domain • Strong isolation between VMs • Essential for closed-box VMs • Confidentiality • Integrity • TVMM abstracts a single ‘physical’ machine for each VM

15. TVMM Extensibility • “One size fits all” • Bad approach for providing OS for trusted platform • Ties all applications to one interface • If too complex… • Compromises simplicity of system • Forces applications to deal with low-assurance • If too simple… • Compromises performance and functionality of system • Limits variety of applications for OS

16. TVMM Extensibility (Cont.) • Terra views each VM as dedicated platform • Developers can… • Build unique software stack • Tailor OS • Terra extends its architecture to all requirements • High assurance applications • Electronic voting • Rich OS primitives • Security-Enhanced Linux (SELinux) • High performance • Online gaming • Etc.

17. TVMM Efficiency • Overhead • Virtualization provides (almost) no overhead • VMMs provide same properties of separate devices • Terra efficiency • Application on Terra is actually more efficient than on standard OS • OS abstractions can be tailored • Similar to functionality of an exokernel • Essential for flexible platform

18. TVMM Compatibility • Allows existing systems to run under Terra • Side-by-Side VMs • Standalone application targeted for Terra • Legacy application • Improves assurance • Untrusted application becomes low-assurance trusted application in Terra

19. TVMM Security • VMMs are simple • ~13,000 source lines of code • Narrow, stable interface • Only provides simple abstractions • CPU • Memory • VMMs are proven for secure operating systems • Currently leveraged for… • Banking • Finance • Health • Etc.

20. TVMM Security (Cont.) • TVMM adds more to the secure VMM model • Root secure • Not even admin can break privacy and isolation of closed-box VMs • Attestation • Application in closed box can identify itself to remote party • Tell remote party what is running inside VM • Allows remote party to trust the application • Trusted path • User to VM • VM to user

21. Attestation • Enables an application in a VM to authenticate itself to remote parties • Authenticates… • who built the platform hardware • what software was started at each layer of the software stack • Requires building a certificate chain from the hardware • Private key embedded in a tamper-resistant chip • Certifies the system firmware • PC BIOS

22. Certificate Chain • Generates a public/private key pair • Makes an ENDORSE API call to the lower level component • Lower level component generates and signs a certificate containing… • a SHA-1 has of the attestable parts of the higher-level component • the higher level component’s public key and application data

23. Attestation Example • Quicken – a home banking application • Attests its validity to a remote banking server • VM and remote server authentication through SSL session key exchange protocol • SSL handshake • Attestation certificate chains and private keys are used for authentication • 3 stages of verification • Verifies lowest certificates in the chain • Verifies that all hashes in the certificate chain are on the remote servers list • Verifies that the hash of the VM’s attested storage is on a list of authorized applications

24. Establishing Trust • Applications have numerous versions • Unreasonable for the remote server to keep track of all the version hashes (The Bank) • Instead, remote server requires the application to send a certificate from the software vendor (Quicken) • Two chains of trust from certificate authority (CA) to VM • First chain certifies what software binary image is running • Second chain certifies that the binary image is the correct version of the application

25. Revocation • A user could successfully undermine the attestation process by extracting the private key from the tamper-resistant hardware • Convince a remote peer that the local machine is running trusted software but it may actually be running malicious software • Could easily publish the private key and certificate which would allow anyone to weaken the attestation process

26. Privacy • The attestation process alone identifies the machine doing the attestation • The Trusted Computing Group proposal • Privacy CA (PCA) • Verifies the machines' hardware certificate • Issues a certificate containing a random pseudonym in place of • Machine will use anonymous certificate for attestation

27. Privacy (Cont.) • Cryptographic techniques • Enable private attestation without the need for a third-party • Group signatures • Enables private attestation without any extra work from the user

28. Interoperability and Consumer Protection • Attestation • Helps build secure distributed systems • Simplifies system design and reduces protocol complexity • Not perfect though • Right now, programs from any source can interoperate freely which allows for… • innovation • competition • prevention of product lock-in

29. Interoperability and Consumer Protection (Cont.) • Attestation would allow software companies to produce software that would only interoperate with other software that they provided • Another concern is attestations ability to facilitate digital rights management (DRM)

30. Secure User Interface • Provides a trusted path to applications • Prevents malicious applications from confusing the user about which VM is in use • KVM (keyboard, video, mouse) switch model • User is presented with separate virtual consoles that the user can select using the KVM switch • Section at the top of the screen that displays which VM the physical console is currently showing • Compartmented Mode Workstation Systems • Secure window manager controls the entire desktop and applications can only write to portions of the display they’ve been granted access to

31. Local Security Model • Terra’s basic access control model is specified by the TVMM and the management VM • Management VM makes distinction between… • platform owner (system administrator) • platform users (system users) • TVMM runs at the highest privilege level • Root secure • Secure from tampering even by the platform owner who has root level access

32. Local Security Model (Cont.) • The TVMM only dictates policy that is required for attestation. • Isolates VMs from each other • Doesn’t guarantee availability • All other policy decisions is left to the platform owner • Management VM • Formulates all platform access control and resource management policies. • Grants access to peripherals • Divides storage among VMs • Issues CPU and memory limits • Starts, stops, suspends VMs

33. Application Assurance • Terra improves application assurance • Allow applications to determine own level of assurance • Benefitted by attestation • Assurance of application in Terra • Still limited by assurance of the OS

34. Application Assurance (Cont.) • Applications can ensure that they only interact with trusted peers by adding additional level of depth to their defenses • Example • An attacker wishing to exploit the application must first either exploit its peer or find come means of impersonating its peer in order to provide a way to attack

35. Trusting Software • Assuming a client is safe based on attestation alone is dangerous • Can make applications fragile and degrade the security instead of improving it • Attestation can’t make a promise about the future • Trusted node can fail at any time • At best, can only ensure the integrity and confidentiality of the software that is running • Hardware can only be trusted up to the level of tamper resistance

36. TVMM Storage Interface • Encrypted disks • Transparent (en|de)cryption • Ensures storage privacy and integrity • Integrity-checked disks • Mutable data • High integrity, but not private • Raw disks • Unchecked storage • Sharing data outside VM

37. TVMM Disks • Attested • Program binary • Immutable state • Makes up VM identity for attestation • Encrypted or plain text • Hash is primary identity of disk • Unattested • Variable configuration/application data • Data not meaningful to remote parties

38. VM Identity • Primary Identity • VM hash • VM firmware • Immutable VM state • One per VM • Secondary Identity • Hash of any additional disks for VM • 0 or more per VM

39. TVMM Storage Protection • Cryptographic keys • Protect storage • Sealed under TVMM’s public key • Hardware releases TVMM ‘s private key only to TVMM itself • Maintains key confidentiality

40. Implementing Attestation • TVMM responsibility • Loaded data matches VM hashes • Fixed-sized blocks • Attestable entities • Hashed separately • VM descriptor • Hash over separate VM hashes • Verification • Blocks verified as they are pulled off disk

41. Ahead-of-Time Attestation • Each stage of boot process signs hash of next stage then invokes it • Hashed in entirety before control is received • TVMM reads entire VM • Verifies attestable components against VM descriptor • Pins VM into physical memory • Avoid possibly of malicious tampering • Small, high-assurance VMs

42. Optimistic Attestation • Large VMs • Data must be both read and hashed • Significant cost • Optimistic approach • Attests all hashes VM descriptor claims • Does not verify at startup • Individual blocks of VM lazily checked by TVMM • Runtime attestation • Block failure • TVMM halts VM immediately

43. Attestation Interface • Cert  endorse(cert-req) • Creates certificate • VM’s hash • Contents of cert-req • Signed with TVMM’s private key • Cert-req • VM’s public key • Application data • Basis of attestation • Hash  get_id() • Receives hash of calling VM

44. Management Interface • device_id create_device(type, params) • connect(device_id_1, device_id_2) • disconnect(device_id_1, device_id_2) • vm_id create_vm(config) • attach(vm_id, device_id) • detach(vm_id, device_id) • on(vm_id) • off(vm_id) • suspend(vm_id) • resume(vm_id)

45. Device Driver Security • Commodity platform • Huge range of devices • Video cards • Wireless cards • Software modems • Huge range of related drivers • Often written by unskilled programmers • Typically worst quality code in kernel • Greatest source of security bugs • Therefore, not included in TVMM trusted computing base

46. TVMM Driver Security • TVMM needs protection from… • Direct tampering by driver code • Confining drivers via hardware memory protection • Restricting driver access to sensitive interfaces • Example: a clever microkernel • Driver modifying kernel via DMA • I/O MMU or equivalent chip set • Example: run drivers at user level, prevents DMA outside each driver’s address space

47. TVMM Driver Support • Leverage device drivers of untrusted OS • Untrusted OS runs concurrently on same platform • Trusted OS • Runs in curtained memory • Memory protected from… • tampering by untrusted OS • attacks from below via DMA • Leverages device drivers of untrusted OS • Explicit interface in untrusted OS

48. TVMM Hardware Support • Hardware Attestation • Must be attestable to the booted OS • Sealed Storage • Data encrypted under private key of tamper-resistant coprocessor • Stored hash of booted, trusted OS • Coprocessor will only allow a trusted OS with same hash that sealed it to unseal it • Allows TVMM to store private key on persistent storage

49. TVMM Hardware Support (Cont.) • Virtualization • Efficiently handle virtualization of diverse Oss • Interface assistance to complex hardware • Graphics cards • 3D accelerators • Simplify TVMM itself • Secure I/O • Need trusted path from TVMM to devices • Cryptographically secure communication

50. TVMM Hardware Support (Cont.) • Secure Counter • Counter that can only be incremented • Prevent filesystem rollback attacks • Secure, real-time clock • Expiring old session keys • Defending against replay attacks • Rate limiting • Device Isolation • Control access to devices • Isolation requires less trust in drivers