It's just my representation after reading the paper.

1. 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
2

3. Introduction(1/3)
 Poor of end-to-end information
protection
 Multiple tiers have many vulnerability
 Complexity leads to vulnerabilities
 VM for protect sensitive applications
 Strong isolation
 Heavyweight
 TCB(trusted computing base) is too large
3

4. Introduction(2/3)
 Cloud Terminal
 STT : Simple client side software
 Microvisor : a small hypervisor-like layer
 Cloud Rendering Engine(CRE) : executes
an application, produce/send bitmap to the
STT
4

5. Introduction(3/3)
 Introduce the Cloud Terminal
architecture
 Evaluate this architecture with realistic
applications
5

6. Overview
 Use Cases
 Goals and Threat Model
 Existing Approaches and Comparison
 Architecture
6

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)
7

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
8

9. Goals and Threat model(2/3)
 Adversary can …
 controls the OS
 intercept all its network traffic
 not have physical access (example)
 not infer the user’s input
9

10. Goals and Threat model(3/3)
 Prevent viewing and modifying
 Protects against some social
engineering attacks
 A shared secret between the user and STT
 use the user’s TPM
 Not designed to prevent DoS
10

11. Existing Approaches and
Comparison(1/3)
11

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
12

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
13

14. Architecture
14

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
15

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
16

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

18. Architecture
(Public Infrastructure Services)
 For public service, rather than
corporation
 Directory service
 Provide a list of CREs
 Verification service
 Check that users installed a genuine STT
18

19. Secure Thin Terminal
 Microvisor
 Cloud Terminal Client
 Securing the Execution of the Client
 Untrusted User-Space Helper
19

20. Screenshot of the STT
20

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
21

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 trust
 use code from the Flicker
 Ensure 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
22

23. Cloud Terminal Client
 A process
 Runs in the context of the microvisor
 Interacts 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 key
 store persistently in the TPM using sealed
storage
23

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
24

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
25

26. Cloud Rendering Engine
 CRE Scalability
 CRE Security
26

27. CRE Scalability
 Spend most of their time waiting for
input
 Share a high fraction of memory
 Key optimizations
 Memory sharing
 Disk sharing
 Stripped-down OS
 Reduced timer interrupts
27

28. CRE Security
 Accepts only sessions from attested
STTs
 Network isolation
 separate 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)
28

29. Setup and Session
Protocols
 Cloud Terminal Installation
 Session Protocol
29

30. Cloud Terminal Installation
 Certifying to the user that installing a genuine
STT
 verification service
 Verify through a secondary channel (a phone)
 Stablishing a shared secret between the STT
and the user
 user select a background image as reverse
password
 TPM’s private key as a second authentication
factor
30

31. Session Protocol(1/2)
 UI displays a list of available
applications
 obtains from a directory service
 Store a master public key in STT and
application public key for each application
 Using TLS-like protocol
31

32. Session Protocol(2/2)
32

33. Implementation and Evaluation
 Implementation
 Applications
 Performance Evaluation
 Cost Analysis
33

34. Implementation(1/2)
 Secure Thin Terminal
 All components are available for Linux
 not yet support to protect STT from malicious
DMAs or SMI handlers
 Implement on a Lenovo W510 laptop
34

35. Implementation(2/2)
 Cloud Rendering Engine
 on Linux, using KVM
 KSM daemon to share identical memory
pages
 Guest OS : Debian GNU/Linux 6
35

36. Applications
 Online banking
 Wells Fargo
 run Firefox in kiosk mode
 configure a whitelist for this proxy
 Document viewing
 Evince, a Linux PDF viewer
 Document editing
 AbiWord
 Secure email
 Gmail
36

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
37

38. Performance Evaluation
 Qualitative Usability
 Client-side Metrics
 Server-side Metrics
38

39. Qualitative Usability
 Type paragraphs of text comfortably
 Scrolling the page is the slowest
39

40. Client-side Metrics
40

41. Server-side Metrics
41

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
42

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
43

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
44

45. End
45