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
2
Outline
Introduction Overview Secure Thin Terminal Cloud Rendering Engine Setup and Session Protocols Implementation and Evaluation Related Work Conclusion
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
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
5
Introduction(3/3)
Introduce the Cloud Terminal architecture
Evaluate this architecture with realistic applications
6
Overview
Use Cases Goals and Threat Model Existing Approaches and Comparison Architecture
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)
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
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
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
11
Existing Approaches and Comparison(1/3)
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
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
14
Architecture
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
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
17
Architecture(Cloud Terminal Protocol) Extends an existing RBP protocol (VNC) Adding additional levels of security Using end-to-end encryption
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
19
Secure Thin Terminal
Microvisor Cloud Terminal Client Securing the Execution of the Client Untrusted User-Space Helper
20
Screenshot of the STT
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
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
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
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
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
26
Cloud Rendering Engine
CRE Scalability CRE Security
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
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)
29
Setup and Session Protocols Cloud Terminal Installation Session Protocol
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
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
32
Session Protocol(2/2)
33
Implementation and Evaluation
Implementation Applications Performance Evaluation Cost Analysis
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
35
Implementation(2/2)
Cloud Rendering Engineon Linux, using KVM KSM daemon to share identical memory
pagesGuest OS : Debian GNU/Linux 6
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
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
38
Performance Evaluation
Qualitative Usability Client-side Metrics Server-side Metrics
39
Qualitative Usability
Type paragraphs of text comfortably Scrolling the page is the slowest
40
Client-side Metrics
41
Server-side Metrics
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
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
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
45
End