A Trusted Computing Base for Performing E-Commerce Transactions

Introduction

A browser is the most commonly used tool to carry out e-commerce transactions. However, current browsers such as Mozilla Firefox and Internet Explorer contain a large number of security vulnerabilities. Attackers have successfully exploited these vulnearbilities to obtain private information, install arbitrary code that modifies the browser's behavior or trick the user into providing sensitive information Secunia Vulnerability Report, Internet Explorer 6.0 Mozilla Firefox.

One of the main reasons for the large number of vulnerabilities is the large size and high complexity of current applications and systems software. For example, the Mozilla Firefox browser contains around 1 million lines of code. The browser requires X windows support and X11 server contains 1.25 million lines of code. Both pieces of software need the Linux kernel, which contains over 200,000 lines of code. The X11 server and the Linux kernel run at higher privilege level than the browser and vulnerabilities in them can be exploited to modify the behavior of the browser. Hence, we have to trust around 2.5 million lines of code whenever we use a browser.

One approach to alleviate this problem is to build small and simple security-sensitive applications that can be tested throughly. Such an approach provides two advantages: First, it results in a small code base that is more amenable to rigorous testing or modelling and secondly, it exposes a smaller profile to the attacker.

The aim of this project is to show that it is possible to build small trusted computing bases to perform security-sensitive operations without sacrificing performance and with minimal loss of functionality. This case study deals with the composition of a Trusted Computing Base (TCB) for an E-commerce transaction client.

E-Commerce Transaction Client

A browser is an example of an E-Commerce transaction client (ETC). A browser performs the following critical operations

• display content in a format determined by the merchant.

• Accept user input and pass them along to the merchant.

Similarly, we can break down an E-commerce transaction into the following stages

1. User browses the merchants website and build a shopping cart

2. User decides to check out

3. Webserver and Browser establish a secure session (SSL/TLS)

4. User provides private information (login-password, payment information)

5. Merchant authenticates the information and finalizes the transaction

We can see that while all stages involve some private user information being disclosed, stages 3-5 are more critical because subverting them would allow an attacker to cause monetary harm to the user. On the other hand, merchants would like to attract more users by improving user experience in all stages of the transaction. This is especially important in stages 1 and 2 as the user has not decided on a purchase yet. The merchant would prefer multimedia rich content like images and videos to attract the customer. In the later stages, such rich content is not really necessary to enhance user satisfaction.

One solution that satisfies both functionality and security is to use the functionally rich browser for stages 1 and 2 and use a small, trusted application called the ETC AppCore for stages 3 to 5. Since the webserver can determine the start of stage 3, we assume that when the user decides to check out, the webserver initiates an SSL connection with the trusted application rather than the browser.

Security Sensitive AppCore for an E-Commerce Transaction Client

Functionality-wise, the AppCore has to perform the following tasks

1. Establish SSL connection with the web server. Ensure that the certificate provided by the web server matches the URL and the merchant's name.

2. Get transaction details (e.g., shopping cart, payment information) from the web server

3. Get user's feedback regarding the transaction - Accept/Decline.

4. Send user response to server

5. Get confirmation from server and close SSL connection.

6. Store messages in the SSL connection is trusted storage.

We implement Steps 1-5 in our demo. Step 2 can be broken down into sub-steps, where the user provides payment information, rather than retrieving payment information from the web-server. This is a straightforward extension to our AppCore and it just involves one more round of messages.

Structure of the AppCore

Figure 1 shows the structure of the AppCore. We use the L4 microkernel and the L4 execution environment (L4Env) to support the AppCore. In this case, the GUI server, IO server, dynamic loader and name server are parts of L4env. The browser runs on top of a virtualized L4Linux kernel. The L4Linux kernel and the browser are untrusted entities. The AppCore uses the TCP/IP stack in the L4Linux kernel to communicate with the web server. We ensure confidentiality and integrity by executing the SSL protocol in the trusted portion of the application. Since we use L4's fast IPC to communicate with the TCP/IP stack, we do not expect a great degradation in performance. The AppCore consists of three main parts

• An SSL library to securely communicate with the webserver. We use a small SSL

library designed for use in embedded systems.

• A specialized parser that interprets the shopping cart. Instead of using

full-fledged HTML/XML, we use a limited number of tags to describe the shopping cart. Hence, we have a very small parser.

• User interface module, that display the cart and accepts user input.

The complexity of the resulting system is shown in Figure 2. MCC represents McCabe's complexity metric, which is calculated per function and it indicates the number of unique execution paths in the function. Intuitively, it gives a lower bound on the number of tests to be carried out to exhaustively test the control flow properties of the function. We can see that the AppCore is orders of magnitude simpler than a full browser. We feel that this will be an advantage in the testing phase.

Demonstration

For purposes of demonstration, we use a linux application, that acts as a web-server. The task of the linux application is to read a text file containing a pre-determined shopping cart and user information. It then initiates an SSL connection to the AppCore. The AppCore authenticates the web-server and accepts the cart and displays it to the user. The user then has to look at the cart and decide whether to accept or decline the transaction. Based on the user's response the AppCore either sends an accept message and waits for a confirmation or sends a reject message and closes the SSL connection. Upon recieving the confirmation, the AppCore informs the user and closes the SSL connection.

Walkthrough for the Demo

First, select the Transaction Demo option in the boot menu. This will bring up a Dope window and a L4Linux window. The L4Linux system functions both as an untrusted application for the user and the host system for a web-server (which has to be trusted). It is quite easy to move the web-server to a different machine, but for purposes of the demo, we colocate the web-server with the untrusted applications.

Once the L4Linux window is ready, i.e., you see the Linux login prompt, type in root, to log into the console.

  L4Linux login: root

At the same time, you will also see a Dope window, which is the trusted application you will use to "commit" the transaction. You will also see a tab on the top of the window, that displays the name of the infocus application. This tab cannot be controlled by untrusted applications. Hence it acts as a trust indicator. We expect users to provide sensitive data only to trusted applications.

We assume that the user has already browsed a shopping website and has populated his shopping cart. The cart is maintained by the webserver, in its own internal format - xml, database or html format. When the webserver wants to commit the transaction, it generates an XML shopping cart. The file "tcart.xml" in the root directory of L4Linux is an example of the shopping cart, along with some profile information.

 > cat tcart.xml

To start the transaction, use the following command:

 > ./web_server tcart.xml

Now, if you activate the AppCore window, you will see the contents of the shopping cart. Moreover, you will also notice that the tab on the top of the screen reflects the name of the AppCore window, rather than that of L4Linux. The AppCore window provides 3 buttons - Accept, Reject and Exit. Reject and Exit will reject the transcation, whereas Accept will accept the transaction. You can select any one of them. Upon selecting a button, the trusted application executes a secure transaction protocol - a variation of the protocol presented in Steves et al. [ D.H. Steves, C. Edmondson-Yurkanan and M. Gouda, A Protocol for Secure Transactions, The Second USENIX Workshop on Electronic Commerce, November 1996]. Ideally, the messages from the protocol would be stored in a secure storage device for future reference. The webserver too executes the same protocol and the transaction is either committed or reject. A confirmation window pops up to inform you of the result of the transaction.

Discussion

Is the AppCore approach more secure than existing solutions?

AppCores rely on Trusted Computing Bases (TCB) to improve security. But more importantly AppCores reduce the size of code base that needs to be trusted. This is extremely important as you cannot expect a million line application like a browser to be completely free of vulnerabilities. Even with TCBs, applications can be compromised at runtime (e.g., using buffer overflow vulnerabilities). We also know that it is extremely difficult to write bug-free software. Hence, our goal should be building software with very low number of bugs. We can achieve this by building "manageable" software - software that can be exhaustively tested, software which can be modelled (at least partially) and software that is easy to maintain and modify. It is here that small and simple (in terms of software complexity) software provides the biggest advantage.

Eventually, it will be up to the user to correctly use the software. We expect the user to make minimum number of mistakes and be fully aware of the computing environment, e.g., look for trust indicators, not install malicious software.

Is this approach practical, as users will have to use two applications instead of one?

We have not carried out usability studies to analyze this issue. It is definitely cumbersome to use two applications to perform a task, that previously required just a single application. The flip side of this argument is the higher security provided with minimal loss of functionality. It is difficult to expect users to be satisfied with a spartan interface for large periods of time. We bridge this gap between functionality and security by using a functionally rich application for the security-insensitive phase and a separate, small, spartan application for the security-sensitive phase.

Overheads of the AppCore Approach

There will be some performance degradation due to the extra communication involved in the AppCore approach. However, in the case of E-commerce transactions, the performance degradation is minimal. Figure 3 compares the AppCore approach to a native Linux approach and we see that in absolute terms, the overhead is less than a few milliseconds, much less than user response times.

Execution Times for an E-commerce transaction in different scenarios

Future Challenges

The biggest challenge in the technical area is to provide a systematic approach to split applications. Ideally, in well-designed applications, this should not be much of a problem. However language features like function pointers, complicate simple data-flow analysis. Moreover, we also rely on data-structure simplification, which will be difficult to standardize and automate. Another technical challenge is to scale this approach for a large number of applications. Is it possible to identify a set of functions provided by "every" trusted application and encapsulate it in a library. This will greatly simplify the creation of trusted applications. The most important challenge, however, will be to convince end-users to adopt this approach.

Contact

Lenin Singaravelu (lenin@cc.gatech.edu)

Reboot the machine

Click here (in the Demo-CD version of this document) to reboot your machine.