documentct

45
CLOUD TERMINAL: SECURE ACCESS TO SENSITIVE APPLICATIONS FROM UNTRUSTED SYSTEMS Lorenzo Martignoni, Pongsin Poosankam, Matei Zaharia, Jun Han, Stephen McCamant, Dawn Song, Vern Paxson, Adrian Perrig, Scott Shenker, and Ion Stoica University of California, Berkeley and Carnegie Mellon University

Upload: yama-haku

Post on 24-Jun-2015

161 views

Category:

Documents


1 download

DESCRIPTION

It's just my representation after reading the paper.

TRANSCRIPT

Page 1: DocumentCT

CLOUD TERMINAL: SECURE ACCESS TO SENSITIVE APPLICATIONS FROM

UNTRUSTED SYSTEMS

Lorenzo Martignoni, Pongsin Poosankam, Matei Zaharia, Jun Han, Stephen McCamant, Dawn Song, Vern Paxson,

Adrian Perrig, Scott Shenker, and Ion Stoica

University of California, Berkeley and Carnegie Mellon University

Page 2: DocumentCT

2

Outline

Introduction Overview Secure Thin Terminal Cloud Rendering Engine Setup and Session Protocols Implementation and Evaluation Related Work Conclusion

Page 3: DocumentCT

3

Introduction(1/3)

Poor of end-to-end information protectionMultiple tiers have many vulnerabilityComplexity leads to vulnerabilities

VM for protect sensitive applicationsStrong isolationHeavyweightTCB(trusted computing base) is too large

Page 4: DocumentCT

4

Introduction(2/3)

Cloud TerminalSTT : Simple client side softwareMicrovisor : a small hypervisor-like layerCloud Rendering Engine(CRE) : executes

an application, produce/send bitmap to the STT

Page 5: DocumentCT

5

Introduction(3/3)

Introduce the Cloud Terminal architecture

Evaluate this architecture with realistic applications

Page 6: DocumentCT

6

Overview

Use Cases Goals and Threat Model Existing Approaches and Comparison Architecture

Page 7: DocumentCT

7

Use Cases

• Applications that require high information security

• Not for intensive computation or rendering

• public service scenario○ User access financial services (e.g. online

banking)

• corporate scenario○ Employees access data of organizations (e.g.

email)

Page 8: DocumentCT

8

Goals and Threat model(1/3) Installable on existing PCs Not require trust in the host OS Attest its presence to both ends Support a wide range of sensitive

applications TCB of the system should be small

Page 9: DocumentCT

9

Goals and Threat model(2/3) Adversary can …

controls the OSintercept all its network trafficnot have physical access (example)not infer the user’s input

Page 10: DocumentCT

10

Goals and Threat model(3/3) Prevent viewing and modifying Protects against some social

engineering attacksA shared secret between the user and STTuse the user’s TPM

Not designed to prevent DoS

Page 11: DocumentCT

11

Existing Approaches and Comparison(1/3)

Page 12: DocumentCT

12

Existing Approaches and Comparison(2/3) Red/Green VMs

Red for untrusted application and green for trusted ones Per-APP VMs [ Terra , QubesOS]

one VM for each sensitive application Browser OS

E.x. Chrome OS VDI (virtual desktop infrastructure)

Access virtual desktop VMs through thin client software Flicker

Run small pieces of application logic (PALs) in an isolated, attestable environment

Page 13: DocumentCT

13

Existing Approaches and Comparison(3/3) Cloud Terminal

Small, general client○ displaying arbitrary remote UI○ applications are isolated from each other○ be protected from the untrusted host OS

Microvisor○ isolates itself from the OS○ smaller than a full hypervisor○ not need for managing multiple VMs ○ protect an area of memory from the OS

Page 14: DocumentCT

14

Architecture

Page 15: DocumentCT

15

Architecture (Secure Thin Terminal) Runs on a user’s computer Provides secure access to a remote

application Common graphical terminal functionality Isolates itself Lightweight Using a hardware root of trust

Page 16: DocumentCT

16

Architecture(Cloud Rendering Engine)

Contain almost all the application functionality Isolated instance of the application Run a minimal software stack VMs share disk and memory pages Manage centrally

Page 17: DocumentCT

17

Architecture(Cloud Terminal Protocol) Extends an existing RBP protocol (VNC) Adding additional levels of security Using end-to-end encryption

Page 18: DocumentCT

18

Architecture(Public Infrastructure Services)

For public service, rather than corporation

Directory serviceProvide a list of CREs

Verification serviceCheck that users installed a genuine STT

Page 19: DocumentCT

19

Secure Thin Terminal

Microvisor Cloud Terminal Client Securing the Execution of the Client Untrusted User-Space Helper

Page 20: DocumentCT

20

Screenshot of the STT

Page 21: DocumentCT

21

Microvisor(1/2)

Hardware virtualization support (Intel VT)

Intel’s trusted execution extension (TXT) for attestation

Makes its address space inaccessible Intercepts keystrokes (trap reads to

PS/2 port) Maps the video memory

Page 22: DocumentCT

22

Microvisor(2/2)

Installed after the untrusted OS Complete control of the system

using a similar manner to malicious hypervisors[9,28]

Establish a dynamic root of trustuse code from the FlickerEnsure the code of installation can’t be temper stores a measurement (hash) in the TPM

Generates a key pair private key is kept in volatile RAM

Page 23: DocumentCT

23

Cloud Terminal Client A process

Runs in the context of the microvisorInteracts only through the microvisor’s API

Encrypts the input arguments Decrypts the output arguments Data transmitted using the shared session

key Data stored are encrypted

with a symmetric keystore persistently in the TPM using sealed storage

Page 24: DocumentCT

24

Securing the Execution of the Client Hijack the virtual mapping of the video

memory configure the MMU to redirect accesses

to the memory region Restore the original mapping after Cloud

Terminal client is terminated

Page 25: DocumentCT

25

Untrusted User-Space Helper Runs in user-space Provides basic networking and storage

capabilities Cannot violate data confidentiality or

integrity Share a memory region with microvisor

Page 26: DocumentCT

26

Cloud Rendering Engine

CRE Scalability CRE Security

Page 27: DocumentCT

27

CRE Scalability

Spend most of their time waiting for input

Share a high fraction of memory Key optimizations

Memory sharingDisk sharingStripped-down OSReduced timer interrupts

Page 28: DocumentCT

28

CRE Security

Accepts only sessions from attested STTs

Network isolationseparate virtual networks behind a NAT

Resource isolation Restricted user environment

user account with minimal privileges Still be possible for attacking

Cross-VM information leakage (link)

Page 29: DocumentCT

29

Setup and Session Protocols Cloud Terminal Installation Session Protocol

Page 30: DocumentCT

30

Cloud Terminal Installation

Certifying to the user that installing a genuine STTverification serviceVerify through a secondary channel (a phone)

Stablishing a shared secret between the STT and the useruser select a background image as reverse

passwordTPM’s private key as a second authentication

factor

Page 31: DocumentCT

31

Session Protocol(1/2)

UI displays a list of available applicationsobtains from a directory serviceStore a master public key in STT and

application public key for each application Using TLS-like protocol

Page 32: DocumentCT

32

Session Protocol(2/2)

Page 33: DocumentCT

33

Implementation and Evaluation

Implementation Applications Performance Evaluation Cost Analysis

Page 34: DocumentCT

34

Implementation(1/2)

Secure Thin TerminalAll components are available for Linuxnot yet support to protect STT from malicious

DMAs or SMI handlersImplement on a Lenovo W510 laptop

Page 35: DocumentCT

35

Implementation(2/2)

Cloud Rendering Engineon Linux, using KVM KSM daemon to share identical memory

pagesGuest OS : Debian GNU/Linux 6

Page 36: DocumentCT

36

Applications Online banking

Wells Fargorun Firefox in kiosk modeconfigure a whitelist for this proxy

Document viewingEvince, a Linux PDF viewer

Document editingAbiWord

Secure emailGmail

Page 37: DocumentCT

37

Performance Evaluation How responsive is the STT as a means for accessing remote

applications? How far can a CRE scale while providing a good user

experience?

CRE 16-core server with 2.0 GHz processors 64 GB RAM

STT 300 emulated clients replayed packet traces loop a 3–5 minute

23 ms network latency from Berkeley to Seattle

Page 38: DocumentCT

38

Performance Evaluation

Qualitative Usability Client-side Metrics Server-side Metrics

Page 39: DocumentCT

39

Qualitative Usability

Type paragraphs of text comfortably Scrolling the page is the slowest

Page 40: DocumentCT

40

Client-side Metrics

Page 41: DocumentCT

41

Server-side Metrics

Page 42: DocumentCT

42

Cost Analysis

CariNet 12core server with 40 GB RAM 100 Mbps connectivity for $1010/month Overall cost between 1.2 and 2.5 cents

per user-hour

Page 43: DocumentCT

43

Related Work Tahoma : browser OS IBOS : microkernel-based browser OS Proxos : partitions a system call interface Tboot : verified bootstrap of an OS or of a hypervisor TrustVisor : a hypervisor relies on hardware attestation Bumpy : type a secure attention sequence to encrypt

input Trusted Input Proxy (TIP) : a hypervisor and a separate

VM to pop up dialog boxes for sensitive input Building Verifiable

Trusted Path on Commodity x86 Computers protect trusted I/O paths from device-level attacks

Page 44: DocumentCT

44

Conclusion

A small secure thin terminal (STT) on the client

A cloud rendering engine (CRE) achieves a sweet-spot between security,

trusted code size, and generality Implementable on standard hardware At a low cost

Page 45: DocumentCT

45

End