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
library designed for use in embedded systems.
full-fledged HTML/XML, we use a limited number of tags to describe the shopping cart. Hence, we have a very small parser.
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.
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.
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.
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.
Lenin Singaravelu (firstname.lastname@example.org)
Reboot the machine
Click here (in the Demo-CD version of this document) to reboot your machine.