Practical Uses of Virtual Machines for Protecting User Secrets

1
Practical Uses of Virtual Machines for Protecting
User Secrets

• Peter Kwan, Princeton University
• Glenn Durfee, Palo Alto Research Center

2
The vulnerabilities of commodity OSs

• Software vulnerability exploits
• Social engineering attacks
• Users inadvertently install malware

• Feature-rich OS APIs
• In Linux The XRecord extension allows a user
  process to monitor all X events.
• In Windows Admin-privileged processes can
  read/write other processes memory.

Viruses
Worms
Trojans/ Bots
Keystroke Loggers
Passwords, credit card numbers, private keys can
be easily harvested by malware
3
The rest of the talk

• Related work
• Hardened OS
• Multiple virtual machines for isolation
• Smartcards
• Our Design
• Separation based on data sensitivity
• Definition of legitimacy
• Use of virtual machines
• Prototype Implementation
• Setting up the architecture
• Online commerce using a browser
• SSH user authentication

4
Related work

• Hardening the platform
• (Daily) security patches
• Anti-virus software

• Smartcards
• Physical separation
• Cant tell whether the requests are legitimate

5
Threat model
6
Threat model
7
Related work

• Hardening the platform
• Security patches
• Anti-virus software

• Smartcards
• Physical separation
• Cant tell whether the requests are legitimate

• Multiple virtual machines
• Separate VMs for work, leisure, game, etc.
• Each VM still vulnerable individually
• Cant help if the secrets must be entered via
  some untrustworthy software, such as a web
  browser.

8
Separation based on the sensitivity of data

• Allow the user to use a commodity OS and
  configure it freely.
• Protect the secrets in a Vault
• Prevent misuse of the secrets
• Minimal user experience changes

9
Consider a victim system talking to a server
Server
Untrusted VM
Trusted VM (Vault)
Trojans
Vault
App1
App2
App3
Viruses
Keystroke Loggers
Worms
Commodity OS
Minimal OS
VMM
Hardware
10
Navigated to a login page in the commodity system
11
Normally, user inputs the secrets here
12
Switch to Vault using non-bypassable key seq
13
Enter secrets in Vault instead
14
Enter secrets in Vault instead
15
Enter secrets in Vault instead
16
Return to the commodity system authenticated
17
What does it mean by a legitimate request?

• Everything coming from the Untrusted VM can be
  malicious.
• Figuring out whether a request is malicious is
  undecidable in general! virus studies by Cohen
  (1987) and Chess (2002)
• But if we can be more precise, some progress can
  be made
• legitimate when it is explicitly approved by the
  user after he or she has been presented with all
  relevant information associated with the request.

18
Consider a victim system talking to a server
Server
Untrusted VM
Trusted VM (Vault)
Trojans
Vault
App1
App2
App3
Viruses
Keystroke Loggers
Worms
Commodity OS
Minimal OS
VMM
Hardware
19
What does it mean by a legitimate request?

• Everything coming from the Untrusted VM can be
  malicious.
• Figuring out whether a request is malicious is
  undecidable in general! virus studies by Cohen
  (1987) and Chess (2002)
• But if we can be more precise, some progress can
  be made
• legitimate when it is explicitly approved by the
  user after he or she has been presented with all
  relevant information associated with the request.

20
Enter secrets in Vault instead
21
How to get users approval?

• Trusted I/O
• Concern both input and display
• VM implementation allows a trusted interface
  (compared to smartcards)
• Transition to Vault
• Must be made non-spoofable
• A non-bypassable Password key?
• We use secure attention sequence (such as
  Ctrl-Alt-Del)

22
Session and server information embedded
23
Interactions between the entities
Application in Untrusted VM
Vault
Remote Server
1. User initiates session
4. sessionID
5. Server checks sessionID
5. Request for secrets (XML forms)
6-7. User checks servername, and input secrets
8. Secrets (XML forms)
9. Instruction for application
9. User switched back to Untrusted VM
10. Instruction for application
24
Session and server information embedded
ltinput typehidden namesession_id
valueh4GDbqKP5Ngt ltinput typehidden
nameserver_id valuehttps//techo.parc.xerox.
com/vault_auth.pygt
25
Interactions between the entities
Application in Untrusted VM
Vault
Remote Server
1. User initiates session
2. User switches to Vault
3. sessionID, servername
4. sessionID
5. Server checks sessionID
5. Request for secrets (XML forms)
6-7. User checks servername, and input secrets
8. Secrets (XML forms)
9. Instruction for application
9. User switched back to Untrusted VM
10. Instruction for application
26
Server
27
Prototype platform

• Hardware
• x86 PC
• Virtual Machine Monitor
• Xen, an open-source VMM, originally from
  Cambridge, now widely integrated with many Linux
  distributions.
• Configuration of Untrusted VM
• Linux with any application load
• Configuration of the Vault VM
• Minimal Linux installation, only runs the Vault
  application.

28
The Setup
Domain-0 VM
Trusted VM
Untrusted VM
Console 2
Console 1
X server
X server
App1
Vault
App2
App3
Virtual Network
Virtual Network
Virtual Network
Xen VMM
Hardware
NIC
Keyboard, Video, Mouse
29
SSH user authentication

• username/password based
• Public-private key based
• Private key stored locally on client computer
• Locked down by a password

30
SSH user authentication with ssh-agent
31
SSH user authentication
No direct connection between Vault and server
32
Server
Untrusted VM
Trusted VM (Vault)
Vault
App1
App2
App3
Commodity OS
Minimal OS
VMM
Hardware
33
Conclusion

• A design making use of virtual machine to protect
  sensitive data
• Prototypes show that it is practical
• Minimal change to user experience
• Future Work
• The UI in Vault how to encourage correct
  decisions?
• Transition to Vault more intuitive and seamless.

34

• Thank you