Terra: A Virtual Machine-Based Platform for

Download Report

Transcript Terra: A Virtual Machine-Based Platform for

Slashdot Treat
• MICROSOFT WINDOWS VISTA HOME
4. USE WITH VIRTUALIZATION TECHNOLOGIES. You may not
use the software installed on the licensed device within a virtual (or
otherwise emulated) hardware system.
• MICROSOFT WINDOWS VISTA BUSINESS/ULTIMATE
6. USE WITH VIRTUALIZATION TECHNOLOGIES. You may use
the software installed on the licensed device within a virtual (or
otherwise emulated) hardware system on the licensed device. If you
do so, you may not play or access content or use applications
protected by any Microsoft digital, information or enterprise rights
management technology or other Microsoft rights management
services or use BitLocker. We advise against playing or accessing
content or using applications protected by other digital, information
or enterprise rights management technology or other rights
management services or using full volume disk drive encryption.
Terra: A Virtual MachineBased Platform for Trusted
Computing
Tal Garfinkel, Ben Pfaff, Jim Chow,
Mendel Rosenblum, Dan Boneh
(Stanford)
SOSP’03
Presented by: Michael LeMay
Introduction
• VM-based architecture for supporting
various security models on a single
physical machine
• Context: Old paper, not fully
implementable at the time and many of the
techniques are outdated, but principles
have still been very influential
Outline
•
•
•
•
•
•
Background
Security Requirements
Terra Design
Limitations of Terra
Enhanced Technologies
Conclusion
Standard Operating Systems
• Large codebases
– Difficult to verify correctness and bugfreeness
• Offer poor isolation between applications
– Compromise in one can affect entire system
• Security reduced to level of most
vulnerable application
– Applications with varying security
requirements are unable to share a machine
• Don’t provide trusted paths
Closed-Box Platforms
• Advantages:
– Greater security provided by custom
hardware and software, perhaps including
tamper-resistance
– Embedded cryptographic keys can be used to
authenticate platform to remote entity
• Disadvantages:
– Expensive
– Unable to utilize standard software for
commodity systems
Example Closed Boxes
•
•
•
•
•
Automated Teller Machines
Many cellphones
Game consoles
All three of the above have been cracked!
Advanced meters
– These can be easily attacked
• Are there any other closed-box platforms
you can think of?
What is a closed-box, really?
• Something that doesn’t support standard
development interfaces by default
– Linux: GDB, /dev/kmem, cp, etc.
• Open-box
– Cellphone: Windows Mobile File Explorer
– PS3: ?
• Closed boxes
Terra Objectives
• Combine best aspects of open- and
closed-box platforms:
– Strong support for privacy and integrity
– Support for standard hardware and software
• Provide semantics of dedicated, tamperevident hardware platform to each
application
• Doesn’t actually use trusted hardware in
implementation! Think about
implications…
Realization
• Trusted Virtual Machine Monitor (TVMM)
– Assurances:
• Isolates VMs
• Will not falsely attest VM state
• Will not disclose or allow tampering with contents
of closed-box VM
• These assurances are root-secure
– Limitations:
• Unable to guarantee availability
– Relies on Management VM to provide
additional functionality
Terra Architecture
Trusted Platform Module
TPM Interconnection
TPM 1.0 Components
TCG 1.0 Architecture Overview
14
Credential Types
• TPM contains 5 types of credentials:
– Important:
• Endorsement or EK credential: uniquely identifies
TPM, privacy concern
• Identity or AIK credential: Issued by privacy CA to
preserve privacy of EK credential
– Not-so-important:
• 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
• Sets bit internally when compromised, but doesn’t
zero information
– Hardware-protected CPU and memory
against adversaries lacking electrical analysis
equipment and expertise
• Joe pointed out that this assumption was violated
on the Xbox
– Unprotected disk
• Can be removed and inserted into new machine
Remote Attestation
• 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
Linux Integrity Measurement
Linux Attestation
Linux Verification
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
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 nonencrypted disks all supported
– Keys used to protect disks placed in sealed
storage, to prevent attackers from removing
disks and performing an offline compromise
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
• Check software hashes and attested data
contained within certificates, ensure they
are all trusted.
Attestation Binding
• Verification must be bound to attested
process in some way
• Exchange certificate chains during SSL
handshake
• If software is good, it will not persist
session key
• Prevents system from rebooting and
continuing execution in unattested state
– This problem was pointed out by John
Attestation Limitations
• In Terra, PCRs are not necessarily
utilized, so no boot history is maintained
• Verifying entity must have comprehensive
and up-to-date list of trusted software
configurations
– A simple patch or software upgrade generates
entirely new hash
• Difficult to obtain meaningful security
assurances from simple software hashes
Policy-Reduced Integrity
Measurement Architecture
JaegerSS 2006
Attestation Limitations (cont.)
• Compromising a TPM key undermines
entire process
– TPM vendors do not maintain CAs or CRLs
• Platform privacy compromised by
attestation
– Endorsement Key uniquely identifies platform
– Privacy CAs issue alternative keys (AIKs), but
have an unsustainable business model
– Terra proposes group signatures
Attestation Limitations (cont.)
• Attestation can increase vendor lock-in
and platform discrimination by permitting
verifying entities to check the exact,
complete software stack of the system.
• 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)
Attestation Limitations (cont.)
• John pointed out that TPM revocation is
an issue. Fortunately, TPMs are unlikely
to be compromised while the system is
running.
• Must decide how much state to attest.
Should updating the high scores in
Trusted Quake break the attestation?
– Use separate images for configuration data
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
– Could corrupt DNS or routing tables and run
legitimate server, client wouldn’t be able to
detect.
– Is this a bad thing?
– No, leads to privacy problems.
Attestation Limitations (cont.)
• Useful for clients attempting to verify
security of servers?
– No, clients couldn’t possibly be provided with
source code for major websites, so attestation
would be meaningless.
• Is isolation important from the standpoint
of attestation?
– Somewhat orthogonal, but often an important
property being attested.
Management VM
• Analogous to Xen Dom0
• Performs administrative functions:
– Create virtual device (NIC, block dev, etc.)
– Creates new VM
– Attach/detach virtual device to/from VM
– Powers VM up or down
– Suspends and resumes VM
• Hosts drivers
Driver Security
• Terra designers do not wish to include
drivers in TCB, since they are often buggy
– They suggest nooks, but the VM-based driver
isolation technique we discussed would also
be applicable
• Just one of the problems with the
suggested Terra architecture
Security-Enhanced Xen
• Would provide significant benefits to Terra
• Mandatory Access Control (MAC) for VM
objects and commands
– Would permit controlled data sharing between
Terra VMs, using shared memory buffers
– Currently implemented by IBM as sHype
– Xen Security Modules (XSM) provides
extended hooks, backwards compatibility with
sHype, and support for SELinux-style Type
Enforcement policies
Security-Enhanced Xen (cont.)
• Better TPM support:
– Trusted/secure boot
– TPM virtualization
• Dom0 decomposition
– Break management interface into pieces,
allow different domains to use various parts
– Run drivers in separate domains
• Secure I/O
– IO-MMU support
http://www.xensource.com/files/xs0106_intel_xen_security.pdf,
http://www.xensource.com/files/XenSecurity_SHand.pdf
TPM Virtualization
http://www.xensource.com/files/XenSecurity_Intel_CRozas.pdf
Intel LaGrande
Intel Trusted Execution
Technology (TET)
http://www.intel.com/technology/security/downloads/arch-overview.pdf
TET System Architecture
TET System Implementation
• Enter VMM mode using GETSEC[SENTER]
instruction, measures VMM before
transferring control
• 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
– Is this a good thing? What if Intel decides they
don’t like ATI, so you have to choose between an
ATI graphics card and an Intel processor?
http://download.intel.com/technology/security/downloads/31516803.pdf
ARM TrustZone
http://www.arm.com/products/esd/trustzone_home.html
Microsoft NGSCB
• Microsoft, AMD, HP, IBM, Infineon, Intel,
Sun, … all members of TCG
• Uses TPM to partition
system into two parts:
Nexus and L.H.S.
• NCAs: Nexus Computing Agents
• Only two compartments
42
NGSCB Architecture – WinHEC 2004
Windows
Services and User
I/O
Scenarios
TSP
TSP
Windows
Windows
Apps
Windows
Apps
Apps
Administration &
Management
Trusted User
Engine (TUE)
Agent
Agent
Runtime
Runtime
Runtime
Main OS
USB
Driver
Driver
•Little device diversity
•Only a few drivers
•KLOC
NexusMgr.sys
HAL
•Great device diversity
•Thousands of drivers
•MLOC
TSP
TSP
Nexus
Most hardware
Secure
Input
Secure
Video
 Windows
 Owns most HW
 Only real-time OS
 Security benefits via scenarios
TPM
1.2
CPU
RAM
 Compartments are Windows-based
 Significantly reduced footprint
 Strongly Isolated, hardened and armored
 Secure device ownership
 Nexus or service compartments
Biddle, 2004
43
Additional Questions
• What are some closed-box platforms that
could not be easily adapted to run within
Terra?
• What are some closed-box platforms that
could benefit from Terra?
• What changes to Terra or its infrastructure
are necessary to shrink the first list and/or
expand the second?
Additional Questions (cont.)
• Are Terra-provided closed-box platforms
more secure than standard closed-box
platforms?
– Use tamper-evident hardware for key storage
– Would your answer change if the TPM were
integrated into the CPU so it can’t be
snooped?
Conclusion
• Very influential general architecture
• Proposed before much needed
functionality was available, but could be
easily updated to use new functionality
• More general than NGSCB, but should
benefit from NGSCB-inspired hardware
APPENDICES
Attested Meter
• Distributed Energy
Resource
management
• Demand
Reducation/Load
Management
• Automated Meter
Reading/Real Time
Pricing
48
Problem
• For real-time pricing to work, power
company has to know exactly how much
power was used by each customer at each
point in time
– Could be privacy problem
• User should be able to access consumer
portal software on meter from local
network
– We’re taking a closed-box platform, a meter,
and adding an isolated open-box application
– Same thing suggested by Ravinder for Xbox
49
Attested Meter Architecture
Motivating Applications
•
•
•
•
•
•
Trusted Access Point
High-Assurance Terminals
Isolated Monitors
Virtual Secure Coprocessors
Trusted Quake
Attested Meter
Trusted Access Point
High-Assurance Terminals
• E-voting machines that attest their proper
operation to the central tallying authority
• Stock feed viewers
Isolated Monitors
• Key stores
– Confidentiality must be very carefully
protected
• Intrusion detection systems and virus
scanners
– The VMI paper covered these in detail
• Secure loggers
– Should not be possible for compromised
system being logged to remove entries
Virtual Secure Coprocessors
• Privacy-preserving databases
• Secure auctions
• Online commerce applications
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
SECURITY REQUIREMENTS
Root Security
• System administrator should not be able to
compromise fundamental security
assurances of system
– Non-traditional security model: protect system
from its owner/user
Remote Attestation
• Allow remote entity to determine
properties about particular system
– What hardware is present?
– What software is running?
– What security properties does the software
provide?
Trusted Path
• Guarantees that specific input was
received from legitimate user
• Guarantees that output is only provided to
legitimate user
• Addresses social engineering attacks,
such as phishing
PROPERTIES OF COMMODITY
SYSTEMS
Implications of Characteristics
• Remote systems must be assumed to be
malicious
– E.g. Game server must assume that game
clients have been modified to cheat
– May prevent cooperation between
components, or necessitate additional
external monitoring of behavior
• Example: P2P client
– If trusted, not necessary to audit operation
– If untrusted, might ask surrounding clients to monitor
behavior of client.
• Increases system complexity
TERRA DESIGN
TVMM Attestation
• Each layer of software has a keypair
• Lower layers certify higher layers
Application
• Enables attestation of
VM
entire stack
Operating System
Hash of Attestable Data
TVMM (Terra)
Higher Public Key
Bootloader
Other Application Data
Firmware
Signed by Lower Level
Hardware (TPM)
Certificate
Layers
64
HARDWARE SUPPORT
Required Hardware
• Hardware attestation
– Securely measure system
configuration and issue digitallysigned certificates for that state
• Sealed storage
– Store persistent data such that
only system with specific
configuration can access it
TPM
Required Hardware (cont.)
• Hardware virtualization acceleration
– False requirement, just helps to minimize
VMM (TCB) size and increase performance
• Secure I/O
– Secure connection between TVMM and
mouse, keyboard, video card, etc.
• Secure counter
– Prevents replay/rollback attacks
Required Hardware (cont.)
• Device isolation
– Prevent devices from using DMA to overwrite
TVMM structures, etc.
• Real-time support
– Many closed-box platforms have real-time
requirements that are not supported by
current commodity architectures
TCG Layers
http://trousers.sourceforge.net
69
TPM 1.2
• Additions:
– Direct Anonymous Attestation
– Symmetric crypto: 3-DES, AES192,256
– Removable Endorsement Key
Next Try TCG 1.2: Trustworthy or Treacherous? (warning: conspiratorial)
Opposition
• Trusted Computing has many opponents,
because it considers the computer
operator to be a potential attacker:
– EFF: Trust Computing: Promise and Risk
– Against-TCPA
– LAFKON - A movie about Trusted Computing
• And, a rebuttal:
– TCPA Misinformation Rebuttal and Linux
drivers
71
Credential Relationships
DevID Relationship to TPM
TERRA IMPLEMENTATION
Basic Implementation
• VMware Server GSX 2.0.1 on
Debian
• Python management VM
interface
• Serial port interface to TVMM
attestation mechanism
– Doesn’t use TPM
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!)
SAMPLE APPLICATIONS REVISITED
Trusted Access Points
• VPN client can be implemented as closedbox VM and distributed to visitors when
they first connect to a regulated network
• VM can attest to VPN gateway that it is
operating properly, and will enforce
intended traffic regulations
78
TAP Benefits
• Prevents source forgery: TAP can reliably
check all outgoing packets
• Prevents DoS attacks: TAP can block DoS
attacks at their source, before they even
reach the network
• Scalability: Clients enforce regulations on
their own traffic
• Network Scalability: TAP can perform local
vulnerability scan on host before
permitting it to connect
79
Example #1
• Online gaming: Quake
• Players often modify Quake to provide additional
capabilities to their characters, or otherwise
cheat
• Quake can be transformed into a closed-box VM
and distributed to players
• Remote attestation shows that it is unmodified
• Very little performance degradation
• Covert channels remain, such as frame rate
statistics
80
Trusted Quake Assurances
• Secure Communication: VM can’t be
inspected, so shared key can be
embedded in VM image to protect network
communication
– Any software can be reverse engineered, so
is this a good idea?
• Client Integrity: maps and media files are
protected from modification on client
• Server Integrity: Bad clients can’t connect
81
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 or using IM
82
ANALYSIS
Advantages of Terra
• Applications can customize their software
stacks
• Supports attestation primitives directly
• Same hardware interface as physical
machine
• Hardware memory and CPU protection,
and software protection of disks prevents
tampering by platform owner and other
attackers
Limitations of Terra
• Obsolete attestation system (easily
enhanced)
• Lack of trusted path support (coming
soon)
• Lack of any inter-VM sharing (porting to
Xen would provide this)
• Monolithic management VM (resolved by
XenSE)
RELATED WORK