Slide1 l.jpg
This presentation is the property of its rightful owner.
Sponsored Links
1 / 22

Motivating Example PowerPoint PPT Presentation


  • 137 Views
  • Uploaded on
  • Presentation posted in: General

TrustVisor: Efficient TCB Reduction and Attestation Jonathan M. McCune, Yanlin Li, Ning Qu , Zongwei Zhou, Anupam Datta , Virgil Gligor , Adrian Perrig May 17, 2010. Motivating Example. Conscientious web server admin / dev Wants to protect most critical data

Download Presentation

Motivating Example

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Slide1 l.jpg

TrustVisor: Efficient TCB Reduction and AttestationJonathan M. McCune, Yanlin Li, NingQu, Zongwei Zhou, AnupamDatta, Virgil Gligor, Adrian PerrigMay 17, 2010


Motivating example l.jpg

Motivating Example

  • Conscientious web server admin / dev

  • Wants to protect most critical data

    • SSL private key, password file, ACL, …

  • Evaluates low-cost options

  • Her best efforts rest on a house of cards…


Challenge reducing the trusted computing base l.jpg

Challenge: Reducing the Trusted Computing Base

App 1

App

  • Today’s OSes have too much power

  • Total access to application data

  • App may require little OS support

    • Self-contained computation ‘S’

  • Trusted computing base for S includes majority of:OS, drivers, and privileged applications!!!

S

OS

App(ring 3)

Device

Driver

1

Kernel

Module

1

Device

Driver

2

Kernel

Module

2

Device

Driver

m

Kernel

Module

l

OS Kernel(ring 0)

Hardware


What is s l.jpg

What is S?

  • Self-contained code in an application

  • Data secrecy and integrity requirements

  • General-purpose computing

  • Some examples

    • Manages a private key for web server or CA

    • Manages Access Control List (ACL)

    • Is a compute client in distributed setting

    • Is similar to a Flicker session [McPaPeReIs2008]


Outline l.jpg

Outline

  • Motivation (done)

  • High-Level Overview

  • Detailed Description

  • Prototype: Apache + SSL

  • Limitations

  • Summary & Conclusions


Meet trustvisor l.jpg

Meet TrustVisor

  • Tiny hypervisor for isolation of code S

    • No scheduling or Inter-Process Communication

  • Efficient transitions between OS and S

  • External verification of Output = S(Input)

  • Protected storage for S

Untrusted

Trusted

App

App

Attestable

S

OS

white

TrustVisor

V

HW


External verification attestation l.jpg

What code are

you running?

Inputs

Outputs

S

TrustVisor

(

)

Sign

, K-1

External Verification: Attestation

Verifier

Target

KTPM, K-1

  • Trust in attestation rooted in hardware TPM (Trusted Platform Module)

  • SSL-enabled web server scenario:

    • Client can evaluate server before sending data

    • Enables more meaningful SSL server validation


Protected storage l.jpg

Protected Storage

  • Initially, S is “red” (untrusted)

  • App can register S  “blue” (attestable)

  • TV enables “blue” code to protect data…

  • Access-controlled by identity of S (hash)

  • Enabled by TPM-like Sealed Storage

  • “Micro-TPM” in software

App

1

App

n

S

OS

TrustVisor

S

μTPM


Alternative approaches l.jpg

Alternative Approaches

  • TrustVisor runtime TCB in lines of code:

  • ~6500 C/ASM + ~2800 Headers

  • Hypervisor + crypto

white

white

white

white

white

white

white


Outline10 l.jpg

Outline

  • Motivation (done)

  • High-Level Overview (done)

  • Detailed Description

  • Prototype: Apache + SSL

  • Limitations

  • Summary & Conclusions


Trustvisor os architecture l.jpg

TrustVisor  OS Architecture

TrustVisor:

  • Virtualizes RAM, CPU

  • Restricts DMA

  • Restricts TPM to Locality 1

App

1

App

n

OS

Device Drivers

White

TrustVisor

TPMDriver

Locality 1

Locality 2

Hardware

DMA Devices(Network, Disk,

USB, etc.)

TPM

CPU, RAM

Chipset


Trustvisor s architecture l.jpg

TrustVisorS Architecture

TrustVisor API

  • Registration

  • Invocation

  • Micro-TPM

App

1

App

n

S

OS

TrustVisor

SState

S

μTPM

DMA Devices(Network, Disk,

USB, etc.)

TPM

CPU, RAM

Chipset


Identifying s to trustvisor l.jpg

Identifying S to TrustVisor

  • Applications identify S via registration

    • Page-level protection granularity

  • Applications make “normal” function calls

    • TrustVisor detects switch to S via traps

  • S runs with no access to legacy OS

    • One set of Inputs and Outputs per invocation


Sensitive code timeline l.jpg

Sensitive Code Timeline

Multiple invocations duringa single registration cycle

Invoke S: SSL Session Init

S Complete: Session active

S Complete: Session active

Invoke S: SSL Session Init

Initialize TrustVisor

Application Starts

Application Exits

Unregister S

Register S

S’s Runtime State Protected


Micro tpm design l.jpg

Micro-TPM Design

  • Small subset of hardware TPM operations for:

    • Protected Storage + External Verification

  • TPMs are optimized for cost, not speed

  • TrustVisor implements critical-path TPM operations in software on main CPU

    • Extend, Seal, Unseal, Quote, GetRand

    • Reduces latency by orders of magnitude

  • Trust in Micro-TPM still rooted in hardware TPM

  • Infrequent TPM operations do not require virtualization


Outline16 l.jpg

Outline

  • Motivation (done)

  • High-Level Overview (done)

  • Detailed Description (done)

  • Prototype: Apache + SSL

  • Limitations

  • Summary & Conclusions


Example app apache ssl l.jpg

Example App: Apache + SSL

  • Goal: Protect long-term private key KSSL-1

    • Cert revocation is abysmal in practice

  • Desired properties

    • Malware, malicious admin unable to learn KSSL-1

    • Externally verifiable configuration

  • Two sensitive code modules (S)

    • S1: Generate and seal the long-term key (rare)

    • S2: Unseal and use the key during SSL session establishment (frequent)


Apache ssl performance l.jpg

Apache + SSL Performance

  • ‘ab’ with 10,000 txns / trial, avg 10 trials

Context

Switching

MemoryVirt.

Normalized to Vanilla Linux(higher is better)

200 Concurrent Transactions


Outline19 l.jpg

Outline

  • Motivation (done)

  • High-Level Overview (done)

  • Detailed Description (done)

  • Prototype: Apache + SSL (done)

  • Limitations

  • Summary & Conclusions


Limitations l.jpg

Limitations

  • Design-level

    • Does not currently provide trusted path to user

    • Requires application awareness

  • Prototype-level

    • No SMP support (currently single CPU)

    • Only protects KSSL-1

    • Executable code for S must be proactively paged into memory before registration

    • AMD-only


Summary conclusions l.jpg

Summary & Conclusions

  • Tiny hypervisor to support isolation

  • Externally verifiable via attestation

  • Frequent TPM operations in software

  • Compelling performance argument

  • Requires no OS changes

  • Conclusions

    • Interesting point in the design space

    • Foundation for future trustworthy systems


Slide22 l.jpg

Q & A

  • Thank you!

  • [email protected]

  • http://www.ece.cmu.edu/~jmmccune


  • Login