A Secure Email Infrastructure for Computationally Weak Clients J. Robert von Behren jrvb@cs.berkeley.edu and ByungHoon Kang hoon@cs.berkeley.edu Abstract: Security in email systems involves computationally expensive public key cryptography operations. This makes it difficult to deploy secure email systems for computationally weak environments, such as personal digital assistants. To solve this problem, we have developed a secure framework in which computationally weak clients can use a trusted server to perform difficult cryptographic operations on their behalf. As an added benefit, slight modifications to our scheme make it simple to add email security on top of older systems that do not support security. 1 Introduction 1.1 Problem Security in email communication is generally achieved through public key cryptography. Unfortunately, public key operations are computationally expensive, and hence inappropriate for some computing environments. In particular, personal digital assistants (PDAs) are too slow to make wide use of public key cryptography feasible. This is an increasingly important problem, as small computing devices are becoming more widespread. Moreover, the disparity in computing resources between PDAs and workstation or server machines is fundamental. In order to be convenient and appeal to a mass market, PDAs must be small and inexpensive. Hence they will never have as much computational power as larger, more expensive machines, and won t be able to "catch up" to the cryptographic capabilities of their larger counterparts. 1.2 Current State of Email Security Current secure email systems (PGP and S/MIME, for example) place the responsibility for security in the hands of the sender and the recipient. This means that while the software and machines of the end users must be completely trusted, none of the remaining infrastructure need be trusted at all. Additionally, current systems have relatively good failure modes. Although the end-user machine stores the private key used by the user for decrypting and signing messages, this key is stored encrypted with a pass phrase known only to the user. The key itself is decrypted only when it is used. This limits the damage potential if the user s machine is compromised. 1.3 Our Approach To allow PDA software to take advantage of secure email, we have created a proxy server that the PDA can use to perform cryptographic operations on its behalf. This extends the trust perimeter to include not only the PDA but the proxy server as well. Our primary goal was to minimize the amount of trust an end user would need to place in the proxy server, and hence carry as much of the current trust semantics for secure email systems over to the PDA environment. 1.4 Organization of This Paper This paper is organized into seven additional sections. Section two details the motivation for this work, as well as our initial goals. Section three describes our design and four our specific implementation decisions. In section five, we evaluate the security implications of our work, and in eight we summarize some of the important things we learned and suggest possible future directions. Finally, we conclude in section seven and list our references in section eight.
2 Motivation and Goals 2.1 The Problem Why cryptographic email? Email is an extremely important means of communication for an increasingly large population. Compared with traditional paper communications such as letters or faxes, email has the tremendous advantages that it is almost instantaneous (barring backlogged email servers, network outages, etc.) and that it allows easy communication both between pairs of individuals and larger groups. In its most basic incarnation, however, it provides no good mechanism for ensuring the privacy of the contents of messages or for proving their authenticity. Cryptographic email systems such as PGP and S/MIME overcome these shortcomings by allowing users to encrypt and/or digitally sign the text of their messages before they are sent out. This provides end-to-end security between the sender and receiver. As email becomes increasingly used for business transactions, the authenticity and privacy guarantees that cryptographic email systems provide will become increasingly attractive. Public key cryptography in email systems Public key cryptography is an essential technology for allowing the widespread use of email encryption. One of the primary advantages of communication via email is its convenience - email makes it very simple to communicate with people all over the world without ever meeting them. Hence, it is important for any technology that secures email communication to preserve this ease of use. Public key cryptography is essential for this, because it allows individuals who have never communicated before to send each other private messages. This would not be possible with shared-key cryptography, since they would first have to have some out of band mechanism for exchanging cryptographic keys. Enter the Personal Digital Assistant Unfortunately, current public key cryptosystems are not well suited to certain application environments. Public key cryptography relies on mathematical functions that are difficult to invert without some special piece of knowledge. Since the numbers involved in this are typically of a particular form, a would-be attacker could easily rule out a large fraction of possibilities when trying to guess for the private key. This means that a k-digit pubic key will always be less secure than a k-digit key in a shared key cryptosystem. The end result is that keys used in public key systems must be much larger than the keys used in shared key systems to achieve the same level of security. This poses a significant problem for computationally weak platforms such as Personal Digital Assistants (PDAs). For example, while manipulating 128-bit shared keys using the blowfish shared key cryptosystem is quite easy on the 3COM PalmPilot, performing operations on 1024-bit RSA public keys is very time consuming. Hence, using secure email on PDAs requires an unreasonable time investment on the part of the user, while they wait for their mail to be decrypted. A fundamental problem? The seemingly natural solution to this problem would be to wait for technology to improve a little, and provide more computational power for small devices. In a couple of years, it may not be unreasonable to have an inexpensive hand-held device that can quickly perform operations on 1024-bit numbers. At the same time, however, the more expensive machines attackers would use to find a user s private key would have also become more powerful. The fundamental question is whether or not the computational power of PDAs will increase quickly enough to allow them to perform public key operations on numbers that are large enough that an attacker cannot break them. Fortunately, mathematics is somewhat on the side of the PDA in this case, since as key size increases the difficulty of breaking the key grows much faster than the difficulty of using it. It is not clear that this alone will be enough, however, since there are a number of factors that tend to limit the increased computational power available to PDAs:
1. Cost. PDAs are designed to appeal to a wide consumer audience. Hence, to succeed, manufactures must try to deliver acceptable performance for the lowest possible cost. Since the common PDA tasks such as appointment scheduling are not CPU intensive, it seems likely that manufacturers will not want to increase the cost of their devices by using microprocessors that are faster than required for most applications. 2. Size. For convenient integration into day to day life, PDAs must be very small. In fact, the trend seems to be toward adding computation capabilities to smaller and smaller devices, such as cellular phones and watches. Given this strong requirement for smaller and more easily portable devices, it is likely that processor speed and sophistication may be compromised in favor of smaller size. Furthermore, small size precludes many of the advantages of newer workstations, such as the option of multiple CPUs or special-function chipsets to increase computation power. 3. Power requirements. Because PDAs are battery operated, they must also be very conservative with their power consumption. Hence, manufacturers may choose energy efficiency over computation power when deciding on microprocessors for the next generation of PDAs. 4. Increased resources for attackers. With networked computation becoming more and more feasible, attackers may well be able to use not only their own machines but potentially a huge number of unused CPU cycles on other machines in order to break someone s private key. This will make it even more difficult for an unaided PDA to compete with the computational resources available to a would-be attacker. 2.2 Design Objective The approach we have taken to solve this disparity in force between potential attackers and PDA users is to find a secure mechanism through which a PDA user could harness the computing resources of a trusted server machine. Our fundamental goal was to design a system in such a way that its trust perimeter would match that of existing secure email systems as closely as possible. Hence, users would be just as safe using our system as they would be using existing secure email systems. 2.3 Background on Email Systems Email security In order to understand the implications of our desire to mimic the trust boundaries of current secure email systems, we first must clearly understand the properties we are trying to emulate. Current secure email systems place the responsibility for all of the privacy decisions in the user s hands. For example, with the commonly used Pretty Good Privacy (PGP) system, users use shell commands to perform cryptographic operations on both incoming and outgoing messages. To send a secure message, the user goes through the following steps: Create a file with the plaintext of the message to be encrypted Invoke PGP to do the encryption and/or signing Insert the encrypted text into an email message The steps for receiving cryptographic messages are similar: Save the encrypted text to a file Invoke PGP to do decryption and/or signature verification Read the decrypted output file Naturally, many mail readers have been modified to do these steps automatically, which makes using the system more convenient. PGP stores the user s private key in a file on the file system, but encrypts it with a pass phrase chosen by the user. When the privileged actions of decryption and signing are required, the user is prompted for the pass phrase to unlock the private key. Since other secure email systems such as S/MIME and PEM are structured similarly, we focus on the use of PGP in our examples and in our implementation. The threat model There are two things that any secure email system tries to guarantee:
The contents of messages that are deemed private by the user (via encryption). The authenticity of messages that come from the user (via digital signatures). Any compromise to either of these is a serious breach in the system s security. Since knowledge of the user s private key would allow an attacker to break both of the above guarantees, security of the private key is one of the most important aspects of email cryptography. Although there may be unknown flaws in the cryptographic aspects of an email security system, our design simply allows a PDA user to make use of an existing cryptographic email system on a proxy server. Hence, the cryptographic security of the decryption and signing activities are identical between our system and the existing system on which it is deployed. Similarly, encryption and signature verification rely on being able to learn the correct public key for the person with whom we are communicating. Since this issue also does not change for our system, we do not deal with it here. In analyzing the differences between our system and the status quo, we are therefore primarily interested in attacks on the infrastructure, rather than attacks on the cryptographic algorithms themselves. Potential points of failure are as follows: 1. Attacks on individual messages or signatures. An attacker with access to the user s account could read or modify the plaintext before it is signed, or after it is decrypted (depending on whether the user is sending or receiving the message). 2. Attacks on pre-installed software. An attacker with administrator access to the user s machine could install a rogue mail or PGP program on the system. (This could probably also be done with just user-level access, by modifying the user s PATH environment variable.) 3. Attacks on running software. An attacker with access to the user s account could use debugging tools to attach to a running copy of the PGP binary, and read the user s private key from memory. 4. Attacks on the PGP pass phrase. An attacker with access to the user s account could use a brute-force attack to try to break the pass phrase encryption of the user s private key. Since pass phrases are usually meaningful natural language phrases (or slight variations thereof) they may be susceptible to dictionary attacks. Additionally, pass phrases are often much shorter than the private keys they protect, so a brute force attack may be feasible. Trusted computing base Since we are not concerned with the cryptographic security issues of PGP, it is not surprising that all of the attacks above require access to the user s account. This allows us to easily define the trusted computing base for secure email: 1. Cryptography and email software. These must be trusted not to divulge the user s private key (or equivalently the user s pass phrase), as well as to sign only the messages requested by the user and to not divulge the contents of any decrypted messages. To trust this software means that the user feels reasonably confident that they know enough about the software to know that it should perform only appropriate actions and that it has not been tampered with - either before or after installation. 2. The user s machine. Clearly, the user must be able to trust that her machine has not been compromised in some way, as otherwise all of the above attacks will be possible. Although it might be possible to limit the trust in the user s machine in some way, in practice it is probably better to err on the side of being overly suspicious. Hence, as long as the user can ensure both that their software does not intentionally violate their privacy and that no untrustworthy parties have access to their account. 3 Design - the Secure Email Proxy 3.1 Overall System Architecture
As shown in Figures 1 and 2, our Secure Email Proxy (SEProxy) is located between the client email program and the existing email server. The client connects to the proxy and provides it with the information it needs to retrieve email messages from the user s mail server. Additionally, the client provides the proxy with the capability to both decrypt and sign messages on her behalf by sending the proxy the user s PGP pass phrase. To retrieve messages, the client software first fetches a list of available messages from the proxy. The client checks to see if any are new, and if so requests them. When the proxy receives a request for a specific message, it downloads it from the mail server, decrypts and verifies signatures (if necessary), and then sends it off to the client. N e tw o r k D ia g ra m IM A P I M A P S e rv e r SE P protocol SE P protocol S e c u re E m a il P ro x y L egacy protocol e.g ) P O P L e g a c y E m a il S e rv e r e.g ) P O P S e rv e r C o m p u ta tio n a lly w e a k C lie n t F u t u re p ro to c o l F u tu re E m a il S e rv e r : E n c ry p te d L in k : U n E n c ry p t e d L in k Figure 1 3.2 Secure Email Proxy Protocol To control the communication between the client and the proxy, we have developed a Secure Email Proxy Protocol (SEPprotocol). SEPprotocol provides a very simple mechanism for allowing the client to send the proxy the information it requires for retrieving mail from the server and for performing message decryption and signing on behalf of the user. SEPprotocol also defines some simple mechanisms for sending email messages between the client and the proxy, and for requesting specific messages. The typical data flow for downloading a message is shown in Figure 2. S ecure E mail P roxy Protocol Example 1. Retr hint Cache Hit 2. Check Cache Secure Email Proxy 5. Decrypt PGP message and Encrypt with shared-key Cache Miss 3. Request message 4. PGP message Legacy Email Server 6. Message Data : Encrypted Link : UnEncrypted Link Figure 2
The following is the command set currently used in SEProxy. Authorization process 1. USER <username>: username is passed followed by command word USER 2. PASS password : password of user s email access is passed followed by command word PASS 3. SECR pass_phrase_to_private_key: pass-phrase to access the user s private key is passed followed by command word SECR (SECR can be unnecessary where pass-phrase is stored on the proxy as in firewall example) After authorization 4. LIDX message-number : last message number the client has retrieved recently is passed followed by command word LIDX (this is typical for optimization and it depend on the client application needs) 5. RETR message-number : the requested message id number is passed followed by command word RETR 6. SEND message-data : the message-data is passed to SEProxy to be PGP processed and sent out 4 Implementation 4.1 SEProxy The SEProxy server is intended to run on a user s workstation, and serve only one user. This assumption has very nice implications for the security of the system, which are discussed in 5. Additionally, this allowed us to take advantage of the existing PGP setup of the host machine. For example, we assume that the user has configured PGP to behave as they would like, in terms of finding public keys from a key server or from the user s key ring, etc. The single user model also simplified the performance requirements of the proxy, and allowed us to focus on the security aspects of the system. The code for the proxy consists of approximately 2300 lines of JAVA code (including copious comments). This makes security analysis of the code extremely simple. The proxy communicates to POP and IMAP servers through the interfaces provided in the javamail package, available from SUN Microsystems [JAVAMAIL]. At present, our implementation uses the existing PGP software for all encryption and decryption functionality [MITPGP]. This presents an additional potential for security holes, since SEProxy must spawn another process and pipe messages through it. This flaw is not intrinsic to our design, however. It should be easy to replace the cryptographic functionality of PGP with internal code by using the JAVA Cryptography package, which should be released in the near future. Configuration of the proxy is handled through an external configuration file. Configurable items include the type (POP or IMAP) and host name of the mail server, the port on which the proxy should listen for connections, and the location of the log file. The log file is particularly important, since it provides an audit trail in the case of a security breach. In order to provide fail-safe default behavior (from the cryptographic sense), the proxy is particularly draconian in its handling of unexpected events. Rather than retrying resources, any failure (for example to write to the log file, or to download a message from the mail server) results in immediate termination of the connection, and the destruction of any secure information stored on the proxy. Although this may make the proxy less friendly in some circumstances, it also makes it much easier to understand and predict its behavior. This simplifies the security analysis. Additionally, since exceptional situations should only happen occasionally, this overreaction should not effect normal usage. 4.2 PDA Client Software To demonstrate our system, we have developed a simple client application for the 3COM PalmPilot platform. Computational resources on the PalmPilot are scarce, which makes it a perfect candidate for outside help with secure email functionality. At present, the user interface for the Pilot client is quite rudimentary. Users are given the ability to choose an appropriate SEProxy server and port, as well as to specify their email user name and password. When the client connects to SEProxy, the user is asked to provide their PGP pass phrase, which is then sent to the proxy. Finally, the client finds out which messages are new since its last check, and downloads them.
Developing secure software for the Pilot is difficult for several reasons. The most important problem is that there is no way to prevent another application from stopping the client software, and reading its memory. As a result, we are forced to consider the entire Pilot to be part of the trusted computing base. (See 5.1) There are a number of improvements to the client interface we hope to implement in the near future. Among them, we would like to offer the user the ability to select which messages to download as well as to control whether or not to truncate or otherwise filter messages as they come in. Additionally, we would like to add some improvements to the SEPprotocol to allow for more efficient decisions as to which messages should be downloaded, etc. These features are tangential to our security concerns, so we do not discuss them further here. 4.3 Secure Email Service for Multivalent Document Browser As an example of another possible use of the SEProxy architecture, we have modified the email client available with the Multivalent Document (MVD) Browser 1 to speak the SEPprotocol. On the whole, these changes took only a few days to implement. The ease with which this was achieved demonstrates the flexibility of the proxy architecture. By redirecting the MVD email client s pop address to our proxy server address, we have added security to this client almost for free. A demonstration of this can be found at http://www.cs.berkeley.edu/~hoon/seproxy.html As an expansion on this idea, it would also be possible to modify SEProxy to act as a trusted mail server for legacy email clients that could not be modified. To accomplish this, the proxy would have to be trusted with permanent access to the user s private key, rather than requesting the PGP pass phrase from the client. The SEPprotocol would also have to be replaced by the protocol understood by the legacy email client (such as POP or IMAP). Given these changes, however, email security could easily be added to legacy clients. This arrangement might be reasonable as a part of a firewall mail proxy, since the firewall machine already must be heavily trusted. Additionally, since the network communication between the firewall and the client is safe from outside snooping, it is not necessary to otherwise secure the communication link between the two. 4.4 Communication The communication between the client and the proxy is handled with standard TCP/IP routines in JAVA and C. At present, we have not implemented any security for this communication link. Hence, for the purposes of our security analysis we simply assume that the link is secure. Fortunately, securing this link should not be difficult. Current work at UC Berkeley should provide a simple mechanism for creating secure connections between computationally weak clients and existing SSL services. This will allow us to easily add security to the PDA client communications. For SEProxy and the MVD email client, the SSL implementation in the upcoming JAVA security package will provide the necessary secure communication support. 5 Evaluation - Security Analysis 5.1 Trusted Computing Base for SEProxy As mentioned in 2.2, the goal of SEProxy was to provide a secure email environment for PDAs and other computationally weak clients that had security properties equivalent to those of current email security systems. While our design does increase the trust boundary, we believe these increases are quite acceptable. Our design comes very close to this goal, as the trust a user would have to place in the SEProxy system is very similar to the trust that current users place in PGP. 1 The Multivalent Document Browser was developed as part of the Berkeley Digital Library project. MVD allows users to put an open-ended variety of annotations, such as executable copyeditor marks, Post-it style notes, or highlights, on other individuals plain text, HTML, or scanned image documents. The resulting composite documents can then be shared. The documents themselves may be accessed via different network services, including HTTP (i.e., the web) and email. The MVD email client sends an HTML wrapper which the client uses to invoke the sender s MVD document. The MVD email client can also bring his/her email into MVD window for annotation or copy-edit-marking with various MVD features.
With the design of SEProxy in mind, we revisit the potential failure points discussed earlier for PGP: 1. Attacks on individual messages or signatures. (reading a message after it is decrypted or modifying a message before it is signed) The only place where the plaintext of a message is intentionally stored unencrypted is on the PDA. However, it is also possible that the operating system on the proxy may temporarily store information to disk by writing it out to the swap file. Hence, this point of failure exists on both the proxy and the PDA. 2. Attacks on pre-installed software. (Installing bogus PGP or email software) This also could effect both the PDA and the proxy, since either could divulge important information if they were running rogue software. 3. Attacks on running software. (Reading private data from program memory) These would be possible for both the PDA and the proxy. 4. Attacks on the PGP pass phrase. (Attempting to recover the user s private key by guessing the pass phrase.) The encrypted private key is stored only on the proxy server, so this attack is only possible if the attacker gains access to the proxy machine. The SEProxy architecture also makes the following attack possible: 5. Attacks on network communication. SEProxy introduces the need for the client to communicate securely with the proxy server. If an attacker can somehow subvert the encryption of this communication, they could read not only the contents of private messages but the PGP pass phrase itself. Alternatively, if the authentication step of the communication handshake could be subverted, the PDA user could be tricked into starting a session with a bogus proxy. Based on these attack models, we can now describe the trusted computing base for SEProxy: 1. Cryptography and email software on the PDA. These must be trusted not to divulge the user s private key (or equivalently the user s pass phrase), as well as to sign only the messages requested by the user and to not divulge the contents of any decrypted messages. To trust this software means that the user feels reasonably confident that they know enough about the software to know that it should perform only appropriate actions and that it has not been tampered with - either before or after installation. 2. The PDA. The PDA must be trusted not to have other rogue software that attempts to read the memory of an active SEProxy session. 3. The proxy software. The proxy software must be trusted not to permanently store private information or to intentionally divulge it to some third party. 4. The proxy machine. The proxy machine must be trusted to prevent outsiders from accessing the user s account on the machine. 5. The network. The network communications protocol between the PDA and the proxy must be trusted to correctly protect private information sent between the proxy and the PDA. If the user were only interested in reading email on the PDA and did not use the proxy server machine for reading mail, this would make the security situation worse than at present, since the user would be required to trust twice as many machines, twice as much software, and a network connection. In most cases, however, we expect the PDA email client to be a supplement to the user s email activity on their workstation. In this case, the user is already forced to trust the security of the workstation. Hence, it is reasonable that in order to use email security on another machine, that machine must also be trusted. In this case, the only additional trust the user must place is in the network connection. Since secure network communications are relatively well understood, we feel that this addition is reasonable, given added convenience of reading secure email from a very portable client such as a PDA. 5.2 Security Principles To justify the trust a user would have to place in the SEProxy system, we now analyze the system according to the security principles laid out in Jerome Saltzer and Michael Schroeder s paper The Protection of Information in Computer Systems. [SALTZER] Although many of these themes are mentioned in various places throughout this paper, we feel it is useful to make them explicit here, as they help to clarify the behavior of the SEProxy system.
Economy of mechanism Wherever possible, the code design of both the proxy server and the PDA client has been kept small and modular. At present our server software (including copious comments) is only a few thousand lines of Java code. The proxy architecture also contributes significantly to economy of mechanism. Because the proxy implementation is completely orthogonal to the rest of the email system, we needn t worry about the safety of other parts of the email system causing problems with the proxy service. Fail-safe defaults The proxy server never has the capability to decode messages on its own - it is completely reliant on the client to provide it with enough information to decode private messages. Additionally, if any error is detected in any part of the proxy s functionality, it exits immediately and closes the connection to the client. This prevents any unexpected inputs from tripping up the proxy software, and reducing security. Complete mediation Complete mediation for SEProxy would mean that every access to the user s private key is checked, to make sure the requestor is a valid user. Because complete mediation would require the user to re-enter her pass phrase for every message downloaded from the server, this would quickly become cumbersome. Instead, we chose to compromise, and require each session to be authenticated. Hence, when the user first connects to the proxy, she will be asked for her PGP pass phrase. After this, the Proxy server software stores the pass phrase until the end of the session. Open design Our source code is readily available to all who would like to peruse it. Moreover, the security-critical portions are small, which should make them easier to scrutinize. Separation of privilege SEProxy does not provide separation of privilege, since only one key is required to perform security-critical tasks. We do not consider this a deficiency in our design, however, since the purpose of current secure email systems is to allow an individual user to control the privacy of her email communications. Hence, separation of privilege is not a meaningful metric in this case, since by definition all privilege should rest with the end user. Least privilege All processes in our system operate at user level, on behalf of only one user. Hence, there is never a chance of privilege leaking from one part of the system to another. Least common mechanism Because the proxy server is intended to be run on behalf of one user, it does not create the risk that a subverted proxy could betray the security of more than one user. This would be much more difficult to assure with a centralized mail proxy service. 6 Advantages of the Proxy Approach for Secure Systems 6.1 Why Choose the Proxy Design? In our original work on this project, we considered augmenting an existing IMAP server to process PGP-based email messages on behalf of the PDA. After looking more carefully at the IMAP implementation, however, we realized that implementing a modified IMAP server would be a tremendous amount of work, and would also require large changes to existing infrastructure. Instead, we decided to construct a proxy that could be used without modifying existing infrastructure. While this decision was originally motivated by a desire to reduce the time required to prototype our design, we soon realized that there were a number of other significant advantages to the proxy design. 6.2 Orthogonality One of the key issues is that the proxy server is completely orthogonal to the existing email infrastructure. As long as the existing infrastructure includes a POP or IMAP server, our current proxy will be able to fetch email from it without difficulty. Furthermore, the proxy design allows the simple addition of new types of email servers without requiring changes to the client software. Alternatively, the proxy approach makes it relatively simple to add new
types of clients. The MVD email client is an excellent example of this, as it was added as an example for the system in only a few days, with very little complicated coding. This flexibility makes it relatively simple to add secure email capabilities to existing software. The separation of functionality afforded by the proxy design also means that no security-critical functionality is trusted to the main email server. Since email servers tend to be large and complex, separating out the securitycritical aspects makes them much easier to verify and understand. 6.3 Flexibility in Changing Trusted Computing Base The proxy architecture also provides an interesting opportunity to flexibly change the trusted computing base to gain additional functionality. For example, by trusting the proxy server with the user s private key (rather than requiring the user to explicitly send the pass phrase to the proxy), the proxy could proactively download and decrypt messages while the user was away. This would reduce the latency when the user actually connected to the proxy to download her messages. Alternatively, with this same addition of trust in the proxy, you could easily have the proxy speak POP to existing mail clients. Such a scheme might make sense on a firewall, where you already assume the firewall machine must be trusted. The advantage of such a system would be that you could set up an organization-wide security policy for outgoing messages as well as correctly read encrypted incoming messages. All of this could be done without requiring the client software to be aware of the security system at all. 6.4 Easy Customization The current SEProxy implementation is simple and easy to understand. This can allow users to easily modify it to suit any peculiarities in their operating environment. For example, some users might want to filter out junk mail before sending it to the PDA. Alternatively, others might want to compose the mail proxy with a more sophisticated mail protocol such as IMAP, to allow PDA clients to selectively download only parts of the messages. Finally, the proxy architecture makes it easy to modify the communication between client and server to accommodate structural features such as available bandwidth or to truncate messages as they are downloaded. 7 Conclusion SEProxy plays an important roll in providing secure email services to computationally weak clients. By placing a trusted proxy server between the client and the email server, we can perform cryptographic operations on behalf of the user in a safe environment. Significantly, this additional functionality can be achieved with reasonable extensions to the user s trusted computing base. We feel that understanding the trust implications of relying on an outside server for cryptographic functionality is particularly important, since it is possible that small devices may never perform sufficiently large public key operations quickly. As an added benefit, the proxy architecture allows a good deal of unexpected flexibility. Among other things, this could allow users fine-grained control over where they place their trust, and how they choose to trade additional trust for additional functionality in the infrastructure. Following this approach, SEProxy could be easily expanded to provide secure email not only to PDAs, but to legacy email systems as well. 8 References [1] [UKERNA96] Report of the UKERNA Secure Email Project, May1996, http://www.ac.uk.pgp.net/pgpnet/secemail/q4.html [2] [MITPGP] MIT distribution site for PGP, http://web.mit.edu/network/pgp.html [3] [PGPNEWS] News articles about PGP, http://www.news.com/news/item/0,4,13493,00.html [4] [BSCHNEIER] Bruce Schneier, Applied Cryptology (second edition), John Wiley & Sons, Inc, 1996. [5] [SALTZER] Saltzer and Schroeder, The protection of information in computer systems, [6] [JAVAG] J. Gosling, H. McGilton, The Java language environment: A white paper, 1995, http://www.javasoft.com/whitepaper/javawhitepaper1.html [7] [JAVAMAIL] JavaMail API Design Specification, 1998 [8] [RSA1] http://www.rsa.com/rsalabs/faq/html/3-1-2.html [9] [RSA2] http://www.rsa.com/rsalabs/faq/html/2-3-4.html