Bump in the Ether

 

1. Questions from reviews
2. Problem:
1. User’s can trust that input gets to the desired application without

                                              i.     being logged

                                             ii.     being changed

                                           iii.     being inserted

2. QUESTION: Why?

                                              i.     APIs: pretty easy to hook input with windows or X

                                             ii.     UI: hard to create a trusted location on screen without subversion

1.   e.g. draw app. UI convincingly

a.    E.g. web sites make frame with no status bar / title bar / buttons and draw in everything

2.   draw whole screen convincingly

3.   Users dramatically bad at noticing things (even if it was available)

a.    E.g. how many people have typed password into wrong window because they weren’t looking?

b.   E.g. NSA has 2 computers > arms reach apart to prevent accidents

3. Solution:

                                              i.     Remove user input from computer to a trusted device (e.g. cell phone)

1.   Users can trust phone to do the right thing – get key strokes from mechanical form to electronic signals

                                             ii.     Problem becomes: how do you:

1.   Get input to application

2.   Verify that it is the right application

3.   Verify that nobody is subverting the application

4. QUESTION: why not rely on OS support?

                                              i.     A: when you walk up to a computer, you can’t tell what OS it is running

3. Hardware support: TPM (Trusted Platform Module)
1. Key goal: provide a way to verify that you are running the right software

                                              i.     2 modes: authentication and security

1.   Authentication: can verify what is running external to the computer

2.   Security: can ensure only trusted code runs with a white list

2. Attestation:

                                              i.     Each chip has a unique public/private key pair

                                             ii.     Chip will sign tings with its private key

                                           iii.     Chip will give out its public key

3. Measurement:

                                              i.     Each chip has a set of PCRs: platform configuration registers

1.   Initialized to zero

2.   Computed by hashing in hardware contents with a new buffer

3.   HW does hashing, SW chooses what to hash

                                             ii.     Software chooses what to measure

1.   e.g. bios, boot loader, os, kernel modules

2.   Software records individual measurements, hardware records cumulative measurements

                                           iii.     Generate a PCR quote: list of PCR values signed by chips private key

                                           iv.     Key idea: induction

1.   HW computes hash of initial SW

2.   Each piece of SW computes hash of the piece it loads

4. Sealed Storage

                                              i.     Place to store keys for authentication

                                             ii.     Effectively encrypted with a PCR quote: signed list of PCR values

1.   Ensures that can only be decrypted if same set of hashes can be regenerated.

2.   E.g. an app can save things, only the same app (with SW support) can get them out. Without app. bits, can’t get to them

5. Use:

                                              i.     Remote attestation

1.   Set up a channel using HW attestation key

2.   Communicate PCR quotes + measurement hashes to other side

3.   Other side (1) verifies hashes are correct / expected values and (2) PCR quote contains only hashed values

4.   Other side can verify, decide whether to trust

                                             ii.     PROBLEM:

1.   Software changes; hard to store hashes for every possible piece of software, including all versions

                                           iii.     NOTE:

1.   Can’t do local; can lie to someone local (e.g. manipulate the data they see, result of comparison instructions)

6. QUESTION

                                              i.     What does all this provide?

1.   Validation of bits set executing

                                             ii.     What does it not provide?

1.   Assurance an app has not been compromised

a.    e.g. buffer overflow

4. Bump-in-the-Ether
1. Goal: secure user input
2. Approach: prevent other user-level applications from seeing input

                                              i.     Encrypt data from mobile device into application

                                             ii.     Keystroke loggers at system call level (e.g. see messages to app) can’t decrypt

3. Assumptions:

                                              i.     Can verify (and then trust) kernel and all low-level SW + system services

                                             ii.     Can have a stable trusted platform to do setup without attacks

4. Design

                                              i.     HW setup

1.   Attack keyboard to mobile phone

2.   App contacts mobile phone to do input

3.   Mobile phone verifies:

a.    kernel + system services

b.   application hash (as compute by BitE kernel module)

4.   Create secure tunnel for phone input

5. Issues:

                                              i.     Set up: how establish data for trust?

1.   Set up channel between device / computer (device association)

a.    Record hashes for all system services + kernel on device

b.   Exchange certificates (using standard protocol e.g. SSL) for later mutual authentication

2.   Set up application

a.    Load once, measure it (all binaries, sensitive inputs such as config), create a key and store it in sealed storage (or elsewhere with key protected by sealed storage)

                                                                                                    i.     Ensures that a modified App. can’t get access to the key

b.   Send key / measurement to mobile device

c.     

                                             ii.     UI: how make sure users don’t screw it up?

1.   A: don’t allow any security-relevant choices without “seeing” the data

a.    e.g. to select which app to communication, user must select from a list (not prompted by application)

b.   e.g. no multitasking

5. Key ideas:
1. Can’t trust a computer in front of you – can’t see what it is running
2. Can trust something you carry (perhaps – see next lecture)
3. Use remote attestation to verify SW running