CS 736 - Spring 2007 - Paper Discussion

Summary
This paper outlines Bump in the Ether (BitE), along with the different types of input capturing it can defeat. The general approach taken is leveraging the split trust model to enable secure communication with a potentially compromised machine.

Problem
The problem addressed by BitE is quite simply preventing malicious people from capturing user input. There are a variety of ways that user input may be captured, including: networking sniffing and injection, "bad" user applications, and by hacking things like X or Windows.

BitE attempts to get around these traditional capture methods by introducing extensions to the kernel that allow a trusted mobile device to communicate directly with a target application.

Contributions
The idea of using a personal cell phone to form secure connections is conceptually interesting, though the foundations of the split trust model don't originate from this paper.

BitE is definitely appealing in that it works with legacy applications and the fact that if you were using BitE with a machine compromised by some of the typical methods outlined in the paper, you would still have secure communication.

Flaws
I think that BitE is fundamentally flawed; the authors assume that the state of a mobile device during association is not a compromised state.

Outside of fairly uncommon usage scenarios, I cannot imagine people willingly using BitE due to the inconveniences it introduces (maybe if you had a sort of dumb terminal laptop it would be ok).

Security
While it's nice to see work being done along these lines, BitE is simply too inconvenient to use outside of uncommon use cases and it seems as though it is flawed from the beginning.

Summary:
Malware and other software that captures private information without a users knowledge is becoming a greater problem today due to the wide spread use of the Internet. This work addresses this and presents an architecture for securely entering private information into webforms and other applications while being assured that the desired application is the only entity that is capturing the information.

Problems Addressed:
It is relatively easy these days to install a small program that can capture keystrokes, screen images and other private data from a personal computer and then ship it over the Internet to someone who can then use the information for their personal gain. A small lapse in the security of a system can be long enough for malicious software to be installed. Also the less computer savvy person can unknowingly install such software by clicking on the wrong thing while surfing the web. A method of entering private data with confidence that the data is not being sent to some third party is very necessary in this connected world where a person's identity is becoming easier to steal.

Contributions:
It is assumed the windows manager and for that manner parts of the OS kernel cannot be trusted and thus any secure communication channel must avoid them or only allow those modules to see encrypted data. The use of a separate mobile device is proposed for the secure interface. A secure architecture is developed that allows applications to register their state when they are installed. This state is examined when they are subsequently loaded and compared to the original state to verify that they have not been modified by some malware program. Any registered program can then request a secure channel with the mobile client. Once the mobile device accepts the secure connection the user can enter secure information into the mobile device which sends it through the secure channel right to the application. A lot of effort was put into making sure the user does not make simple mistakes in using the system that could compromise security while still making it relatively easy for the not so savvy computer user.

Flaw:
I found it difficult to understand how the programs would register securely since the architecture seems to utilizes some type of secure hardware that was not explained very well. Also it was assumed that when an application is registered no malware has already been installed, this is a fine assumption when the machine has been first loaded however many people install new programs much later on after the computer has been in use and could potentially be infected.

Summary
This paper presents a technique for allowing secure input to security sensitive applications using a "trusted tunnel" from an input device to the security sensitive application.

Problem
The main problem that the authors are trying to solve here is the problem that the user cannot necessarily trust what is seen on the screen and even when they can it is often possible for another user-space application to view key stroke events and and other user input data. These problems are largely the fault of doing computing in an environment in which a user is assumed to be safe from him/her self and the result is that if user-space malware is running the user cannot trust what is seen on the screen and some other secure method is needed to ensure that the user is not providing secure information to a malicious third-party.

Contributions
* Design paradigm of splitting trust which allows a more-trusted device to perform "security-sensitive" operations. In this case a secure mobile device is used to improve input security on a personal computer.
* Realization that it is impractical to expect commodity operating systems to provide a trusted portion of the screen due to the problems with using the screen in other ways.
* Threat model and assumptions
* Actual implementation and support for legacy as well as aware applications

Flaws
It seems to me that is is going a bit overboard and that most users will not tolerate this.
The assumption that the phone is secure seems to be likely incorrect.

Relevance
The concepts discussed are important and the authors raise several important issues but I do not believe their solution will catch on.

Summary:
The paper talks about 'Bump in the Ether' - a mechanism that protects user from malicious user-space software that eavesdrop keyboard inputs and misdirect user by controlling the display.

Problem:
With more and more computers connecting to the net and people using their computers to do more sensitive work such as banking, online purchases, tax preparation etc, malicious software have been on the rise. These software log keystrokes or read/overwrite screen area using window manager APIs in order to get sensitive information. BitE prevents this bu bypassing window managers and sending inputs from user directly to the intended application in a secure way.

Contributions:
* Splitting trust to achieve better security - a smaller, trusted device handles more sensitive information while a larger device performs all other application. This was a novel idea by the paper, but re-used from elsewhere.
* Support for legacy applications, though the ideas and technology itself are new
* Use of mobile devices for security - built mostly on capability of the device - like network security was easy to achieve when networks were too few.

Flaws:
- "Splitting trust" was a good idea, but using a mobile to input everything and see the output would be annoying. If the mobile was small enough, it would be really annoying to input/output using it. If it is large enough, typically the device is quite powerful (running Linux, Windows Mobile, etc inside), making it vulnerable to malware attack (and useless for BitE - mobile device is 'trusted')
- Many malware attacks are based on altering (or extending through scripts) of running programs (like Internet Explorer). The IMA (and BitE) fails to handle this scenario.
- The assumption that 'mobile device' is not compromized.. Today, this assumption is naive.
- The biggest assumption that the 'system state can be trusted during application registration' is also farfetched for a paper that talks about malware prevention.
- BitE says it works on commodity systems, but TPM is not widely available in commodity systems today (Vista might drive it with its Bitlocker)

Relevance:
I think the paper talked about some nice ideas, but made too many assumptions it shouldnt have. Frankly, I dont see the idea getting anywhere.

Summary
Bump in the Ether allows a user to setup a trusted tunnel between the device driver and the application intended to use the information. By using a separate display (mobile device) both systems need to be compromised in order to compromise the system (sort of).

Problem
Malware and keyloggers are becoming increasingly prevalent. These applications can collect sensitive input by watching system keyboard events. There is a need for a way to enter trusted information on a potentially compromised system.

Contributions
Bump in the Ether leverages the idea that most users will have a fairly capable cell phone. This cell phone is used as a trusted source. Due to the thinking that viruses and malware are not as common on cell phones. By having critical decisions, such as which application to setup a secure tunnel with, made by input to the cell phone the user's trust that the correct thing will happen is split over both machines. The end result of setting up a secure tunnel is that any malware application installed on the main computer will not be able to log any keystrokes because they are encrypted.

The verification of software is managed by "measurements", typically hashes of files computed at install or boot. By securely storing the measurement of all applications on the system a mobile device has the ability to check to see if an application has been modified. Currently this check is only done at application load-time.

Possible Improvements
I can see this being an extremely worthwhile solution for limited situations, such as a banking website where a 1% decrease in fraud would save millions, but it is far from a general solution. The approach relies on an untainted kernel on the desktop machine. Any compromised machine where the attacker escalated their privileges to root would be able to bypass Bump in the Ether. Granted escalation of privileges might not be an easy task, but there is the possibility that it would happen. People might be given a false sense of security from the system.

I am not entirely convinced the separate hardware is needed. Would it be possible to use a set sequence of keys (such as window's ctrl+alt+del) to bring up a secure window? The system already relies on an unmodified kernel so it does not seem like this extra logic in the kernel would decrease the security of the system. Without the need for a separate device Bump in the Ether would require much less resources to implement.

Summary:

The paper presents an approach for securing user input to applications by creating a trusted tunnel (using encryption) between the user input device and the authenticated application. A mobile device sits between the input device and the application; it presents a secure interface to enable choosing of the application to which a sensitive input should go. This prevents user level malware from reading user input of another application.

Problem addressed:

User level malware can gain access to user input meant for a different application. The lack of a secure mechanism to transfer user input to the intended application is very serious.

Contributions:

The use of mobile devices in general to provide a secure platform in general is an interesting idea, since the amount of code running on such a device can be audited carefully.

The trusted computing primitives are a powerful resource for providing credentials and ensuring authenticity. Their use here enables such a "split" architecture.

The questions of user interactions are well thought of, I may not agree with the solution space but the questions posed are an important concern.

Flaws:

I am not a big fan of the paper:

The whole idea seems a bit outlandish to me. Since we cannot write good code (That is secure X11 or other window managers) let us create fairly complicated hardware solutions with more code and complex encryption etc involved to solve the problem. I am not sure how difficult it would be to fix the buggy window managers but changing every keyboard and adding a mobile device seems a tall order. A simpler solution can be proposed.

The targeted malware space is small - the user space malware which do keylogging. Also there is a very strong assumption of the kernel not being subverted.

The boot order limitations are mentioned by the authors, also the application "signing" is problematic with the time to check, time to use vulnerability which is quite strong for big applications with dynamically loadable modules.
Also the simplication with the initial key exchange (though fixable) is still quite complicated.

The input is secured, but what of the output? The output is still going to the windowing system. The X11 system might still be buggy enough for the output to be read by malware.

The usability discussion clearly brings out the problem with deployment. People switch off the checks in Vista as soon as they install it. Switching between applications should not be so cumbersome.

Malware consistently tricks users into believing they are legitimate (spyware, etc). The user may have this system and still be compromised.

The application attestation is a good idea and it can be incorporated in general systems since the kernel can perform the integrity checks.

Security:

The paper presents an approach to prevent user input from being read by malicious applications from the window manager in user space. Overall the approach is interesting but it is not compelling enough to be added to newer systems.

SUMMARY
In "Bump in the Ether: A framework for securing sensitive user input", McCune et al. present a way guarding user input from malware using a separate device.

PROBLEM
In today's OSes it is easy to intercept user input and users have no guarantees about which applications actually receive the input.

CONTRIBUTIONS
* a technique to prevent keystrokes from being intercepted

* the idea of using a separate device to improve security is interesting and strangely appealing on some level

* ability to use a known-compromised machine with a bit less of a risk of exposing sensitive data

* a BitE prototype

* the techniques in themselves seem to deliver what authors promised

FLAWS
Maybe it's the lack of sleep but I just don't understand how anybody could think that this would be a good idea. I am not disputing author's technique; it's just looks like they are using the wrong tool for the problem.

* the authors took their idea a little too seriously. While BitE is interesting from an abstract point of view, I cannot imagine somebody actually being interested in the prototype.

* who are the target users? It's too weird and complicated for my mom and too insecure for people who are serious about security.

* fundamentally ineffective. Users give away quite a bit of information willingly.

* the system is a complex work-around that cannot guarantee effectiveness because it relies on too many other things being secure (e.g. the kernel, TMP-enables OS and BIOS, etc).

* there are better, simpler ways of providing the same level of insecurity as BitE.

* wrong place to attempt to secure a system. Needing a computer in order to use your computer is just silly.

SECURITY IMPACT
The idea of using a special device to enhance security properties of the underlying system is interesting.

As I post this I realize my flaws section is as lange as the rest of the review, but I guess I have a lot to say.

Summary:
The paper presents BitE, which is a method for protecting user input from snooping by other applications/spyware by using a separate device to verify the integrity of the computer.

Problem:
It's currently easy for programs to intercept messages meant for other programs, which allows them to snoop on passwords and other sensitive information the user is entering.

Contributions:
A method of creating a secure tunnel between keyboard and application so that keystrokes can't be intercepted.

The idea of using a second device to provide two things: verification of the software running on the computer and a trusted display.

I thought the idea of randomizing the list of applications to make the user look at it was clever (though as a user I would probably not like it).

Flaws:
The solution strikes me as being complicated for the benefit it gives you. Specifically, I think a pure software solution would give a great deal of the benefit. For instance, on Windows the keystroke ctrl-alt-del will always go to the system; it would be possible to make that keystroke transition to a secure desktop. Reserving, say, 5 pixels at the edge of the screen would allow the system to indicate (by turning them red or similar) that it was in the secure desktop.

There are only two things lost I can find. The biggest is the ability to have the TPM verify the running OS. This is admittedly a loss, but I'm not sure how big of one against snooping malware. Second, BitE allows the user to use his own device for input, which provides protection against HW keyloggers. In return, a SW-only solution would remove the possibility of the mobile device being compromised. Looking at the defensed attacks, a pure SW solution would still protect against three of the attacks, obviate one (bluetooth sniffing), and fail to one (kernel modification); looking BitE's failure modes a SW solution would fix one possibility (compromised mobile device) and fail at one that BitE actually succeeds at (small amount of input past a HW logger). It's not clear that what you gain from BitE is worth the added complexity.

Even if you think that verifying the OS is important enough, a simple $10 device with a screen stuck in the case of the computer could do the same task without the mobility, allowing you to continue to use your computer if you forgot/lost/had your phone stolen. It wouldn't let you move the device from computer to computer, but I have little idea why you would want to (especially for a home user -- maybe if you were carrying out sensitive operations on a public computer...).

I don't want to say it's a solution in search of a problem (it's the same sort of problem that inspired Vista's secure desktop, though even that's different from even my proposed SW solution in a couple important ways), but to be honest I'm not convinced.

Summary

This paper presents an approach to prevent malicious user-space applications from accessing sensitive user input. The authors' main approach is to use an external mobile device to communicate the security-sensitive information between the client and server.

Problem Description

Various user-level programs like key-loggers and spy-ware etc. can intercept security-sensitive information of a user. X-windows allows any application to register a callback function for keyboard events destined for any application. The authors' suggest reducing the involvement of window manager involvement in sensitive data transmission activities.

Summary of Contributions

The main contribution of this paper is to utilize the 'splitting trust' approach to secure the security-sensitive information being transmitted between the client and the server. Using this approach the authors suggest that very minimal modifications to the operating system are required. Secondly, this approach also helps the author to provide backwards compatibility as not modifications to the actual application or the operating system are required.

Flaws

The major flaw of the approach presented by the authors is its huge reliability on external hardware. A mobile device is required to communicate security sensitive information between client and server. Secondly, the system also requires a wireless keyboard in order to send security-sensitive data directly to the mobile device.

Security Impact

The authors' main goal in providing security is to provide a separate secure channel transmitting for security-sensitive information between the client and the server. By doing so, this information is routed to the mobile device directly without the intervention of windows manager. As a result mal-ware cannot affect the data being transmitted.

Paper Review: Bump in the Ether: A Framework for Securing Sensitive User Input [McCune, et al.]

Summary:

This paper describes BitE, a combined hardware and software approach to
secure user input to trusted applications from being observed by other
user-space programs. BitE employs a user's trusted mobile device, such
as a cell phone, as secure user input and output device that negotiates
an encrypted secure tunnel to a trusted application on a somewhat
untrusted host.

Problem:

The problem is that window managers in operating systems such Unix and
Windows, in some circumstances, allow malicious user programs to
intercept communications from the keyboard and to the display
unbeknownst to the user that is running them while issuing sensitive
user input, such as passwords. There is no way for a user or secure
application to verify that the communication can't be observed.

Contributions:

* BitE uses a "splitting trust" paradigm where a trusted personal
computing device performs security-sensitive operations while another,
presumably more powerful computer workstation runs the user application.
The personal device provides a private channel to both send and receive
information hidden from other, untrusted, workstations applications.

* Probably the largest benefit is for use to perform a secure
connection, perhaps for work, from a workstation that may contain
various malware programs running as that same user - such as those that
arrive as viruses or trojans.

Flaws:

* The user interface is very inconvenient and clunky. I couldn't
imagine using a cell phone keypad and devicing beeping at me to
determine why my input was or wasn't being received by a secure
application. They even proprose intentionally incoveniencing the user
by randomly ordering an application menu to prevent the user from
"clicking through" based on past experience! I'd rather just trust my
laptop as secure.

* BitE relies on the Trusted Computing Group's to secure the OS and a
set of applications. Their integrity is tested at boottime or program
load time, so is open to Time-of-Check and Time-of-Use attacks - as the
authors admin.

Security Impact:

There are a number of attacks that BitE might prevent, *if* we were
using the requisite Trusted Platform Model on common operating systems.
These include some software-based keystroke captures and modification of
secured applications or kernel modifications. Still, in each case,
there are some loopholes. I just don't understand where this would be
useful - you can't use it at kiosk computers unless you trust a portion
of the kiosk computer already, and it's a major inconvenience if used to
protect yourself from malware you may be unknowingly running.