"A secure email delivery system'
INTRODUCTION
Field of the Invention
The invention relates to delivery of secure email messages
Prior Art Discussion
It is well known that a major barrier to use of email for delivery of business and legal documents is the problem of ensuring security of messages and attached documents This problem remains despite the fact that major advances m cryptography have been made m recent years It appears that many people have not used the available key pair and digital signature systems because there is a perception that they require excessive processor time and are difficult to use
The invention addresses this problem
SUMMARY OF THE INVENTION
According to the invention, there is provided a secure email delivery system comprising
a client-side interface comprising means for receiving outgoing messages from client devices operated by registered subscribers and for transmitting incoming messages to said client devices,
a policy database storing a security policy for each of a plurality of registered subscribers,
a policy manager comprising means for accessing the policy database to determine a registered subscriber policy in real time and for delivering policy data to a requesting function m real time,
a secure key database securely storing keys of registered subscribers and their addressees and a secure certificate database securely storing certificates of registered subscribers and their addressees,
a signing function comprising means for receiving policy data from the policy manager and a registered subscriber private key from the key database and for dynamically signing an outgoing message received at the client-side interface,
an encryption function compπsmg means for receiving policy data from the policy manager and for dynamically encrypting an outgomg message m real time usmg an addressee public key retrieved from the certificate database,
a decryption function compπsmg means for automatically decrypting an incoming message in real time using the private key of the addressee registered subscriber retrieved from the key database, and
a server-side interface comprising means for transmitting outgoing messages to a mail server after being processed, and for receiving incoming messages
In one embodiment, the policy database stores a policy for non-registered users who are addressees of mail from registered users, and the policy manager comprises means for determining policv data according to both a sender and a recipient of a message
In one embodiment, the signing function comprises means for automatically signing an outgoing message in the absence of policy data for an addressee
In one embodiment, the client-side interface comprises an API for linking with hooks on a server
In one embodiment, the API comprises means for linking with hooks on an external mail server for generating Web mail under client instructions
In one embodiment, the policy manager is linked with the signing function, the encryption function, and with the decryption function by a cryptography API providing a real time bi-directional link and allowing modularity of the functions of
In another embodiment, the signing function, the encryption function, and the decryption function comprise means for operating with use of a cryptography library of low-level cryptography processes.
In one embodiment, the system further comprises a certificate manager and a key manager residing on the same side of the cryptography API as the signing, encryption and decryption functions
In another embodiment, the signing function, the encryption function, the decryption function, the certificate manager, and the key manager provide a programmed wrapper around the cryptography library
In one embodiment, the key database stores a policy as an instance of a plurality of datatype classes
In one embodiment, the datatype classes include signing algorithm, encryption algorithm, signing policy, and decryption policy classes
In one embodiment, the key database stores a key pool m a directory having a configurable size with a threshold, and the database comprises means for replenishing keys when the level falls below the threshold
In another embodiment, a management console comprises means for editing data in the policy database
In one embodiment, the management console comprises means for retrieving a policy from the policy database as a model and for retπevmg a certificate from the key database as a model
In one embodiment, the management console comprises a controller compnsmg means for treating each business operation as an object-orientated class mstance
In another embodiment, the controller comprises means for receivmg a command string, parsing the string into a hash table, instantiating a class instance and setting properties and a name for the mstance, and initialising the instance
In one embodiment, the policy database stores group policies, each associated with a group of registered subscribers
In another embodiment, the policy database stores default policies
In one embodiment, the certificate manager comprises means for automatically stripping certificates from incoming messages and storing them in the certificate database for subsequent use
According to another aspect, the mvention provides a secure email delivery system comprising
a client-side interface comprising means for receiving outgoing messages from client devices operated by registered subscribers and for transmitting incoming messages to said client devices,
a policy database storing a security policy for each of a plurality of registered subscribers,
a policy manager comprising means for accessmg the policy database to determine a subscriber policy in real time and for delivering policy data to a requesting function in real time,
a secure key database securely storing keys of registered subscribers and their addressees and a secure certificate database securely storing certificates of registered subscribers and their addressees,
a signing function comprising means for receiving policy data from the policy manager and a subscriber private key from the key database and for dynamically signing an outgoing message received at the client-side interface,
an encryption function compnsmg means for receiving policy data from the policy manager and for dynamically encrypting an outgoing message in real time usmg an addressee public key retrieved from the certificate database,
a decryption function comprising means for automatically decrypting an incoming message in real time using the private key of the addressee retrieved from the key database, and
a server-side interface compnsmg means for transmitting outgoing messages to a mail server after being processed, and for receivmg incoming messages, and wherem
the policy manager is linked with the signing function, the encryption function, and with the decryption function by a cryptography API providing a real time bi-directional link and allowing modularity of the functions on each
the signing function, the encryption function, and the decryption function comprises means for operating with use of a cryptography library of low-level cryptography processes, and
the system further comprises a key manager and a certificate manager residing on the same side of the API as said signing, encryption, and decryption functions, and said functions, the key manger, and the certificate manager together provide a wrapper around said cryptography library
DETAILED DESCRIPTION OF THE INVENTION
Brief Description of the Drawings
The mvention will be more clearly understood from the following description of some embodiments thereof given by way of example only with reference to the accompanying drawings, in which
Fig 1 is a high level diagram showing interaction of a security relay of the invention with a client computer and with a mail server,
Fig. 2 is a diagram showing mteraction between the client computer and the security relay m more detail;
Fig. 3 is a diagram showing the security relay in more detail,
Figs. 4 and 5 are diagrams showing parts of the relay m more detail, and
Fig. 6 is a flow diagram illustrating operation of the relay in more detail.
Description of the Embodiments
Referring to Fig. 1 , a secure email delivery system 1 interfaces with a client computer 2 over a secure HTTP socket layer (SSL) connection 3. It also interfaces with a local mail server 4 via APIs using a HTTP SSL lmk 5. The mail server 4 sends and receives messages over the Internet 6. Because the system 1 effectively operates as a relay between the client and server, it is henceforth called a" security relay" or "relay".
The client computer 2 is conventional insofar as it only needs to have a messaging application or browser which supports a portable code environment such as a Java Virtual Machine™ environment. The computer 2 is operated by a registered subscriber, also referred to as a "user" The mail server is a conventional mail server for an ISP In this embodiment, the relay 1 resides on the same platform as the mail server 4
Referring to Fig. 2, the client computer 2 interfaces with a Web server 10 hosting the mail server 4 and the relay 1. The client computer 2 runs a browser 11 having a portable code interpreter which allows execution of plug-ms 12. The Web server 10 allows the client computer 2 to communicate with the mail server 4 to create "Web mail" messages while on-lme. The server 4 then sends the messages to the recipients
and receives the incoming messages m a mailbox for the user The user then subsequently retrieves the messages The security relay transparently to the user performs a set of desired security operations for both incoming and outgoing messages and so it may be regarded as conceptually residing between the client computer 2 and the mail server 4 However, the physical interconnection is via APIs between the mail server 4 and the relay 1 , this channel transmittmg
(a) outgoing messages from the mail server 4 to the relay 1 and security- processed outgoing messages back to the mail server 4 for onward transmission to the recipient, and
(b) incoming messages from the mail server 4 and security-processed incoming messages back to the mail server 4 for onward transmission to the client computer 2
A key feature is that the relay 1 handles all cryptography and digital signature operations for the client 2 These operations are carried out transparently to the user and require no input from him or her Thus a user only needs to subscribe to the security service provided by an organisation hosting the relay 1 Such an organisation may be any ISP or ASP, as the Internet is of course the major insecure network m use Thus the (real or perceived) problem of setting up encryption /decryption functionality is taken from the user He or she only needs to send and receive email messages in the usual manner The following is a typical message sequence
User X (of computer 2) sends a message to a remote user Y This is created over the secure socket 3 by the client computer 2 and the mail server 4
The message is routed to Y via the relay 1 This is not encrypted, but is signed automatically by the relay 1 on behalf of X
If Y responds, the relay 1 captures Y's certificate on the return path From then on the relay 1 will automatically encrypt and sign all outgoing messages to Y, and also decrypt all incoming messages
Thus, the user X has a secure bi-directional link with Y without the need to bother with any cryptography operations.
Because the relay 1 interfaces with an existing mail server 4, it is particularly convenient for the ISP or ASP hosting it The relay 1 can be added in a modular manner
Referring now to Fig 3 the relay 1 is shown m more detail It interfaces on the server side with (a) an SMTP delivery module 20 and an SMTP server 21 for sending messages, and (b) with an IMAP/POP3 mail server 22 and an IMAP/POP3 retriever 23 for receiving messages. This interfacing is via APIs executing on the platform which hosts the relay 1 and the mail server 4 as applications.
A security policy database 30 allows the relay 1 to provide the security required by users according to policies set by a system administrator This database is managed by a management console function 31.
A user authentication module 35 uses the database 30 to dynamically perform authentication of subscribed users A client side interface API function block 41 receives messages via the client plug-ms 12
The messages are passed to encryption functions 37 which perform encryption and digital signing according to the policies for the users and addressees retrieved from the database 30. As described above, if the addressee is being addressed for the first time there is digital signmg by default, however the outgoing message can not be
encrypted However, once a reply is received from the addressee his or her certificate is stored m the database 30 and there will be encryption /decryption from then on
Messages are retrieved from the retriever 23 and are decrypted where applicable and the signature is authenticated by functions 38 using the database 30 The headei (sender, subject, date) is passed to the client computer 2 for display (after decryption) if it is selected by the user
In more detail, referring to Fig 4 the policy database 30 and the management console 31 are illustrated They may be together referred to as an administrative framework The framework follows the MVC (Model-View-Controller) design pattern, allowing the management presentation interface to be completely decoupled from the logic Each retrieved policy is represented as a JavaBean model 53 and each retrieved certificate is represented as a model 54 A certificate interface 56 is lmked with a certificate /key database 90, shown in Fig 5 A view interface 50 uses HTML with embedded JSP tags 51 Post/get control is implemented by a set of Java servlets 52
Referring to Fig 5, the functions 37 and 38 are illustrated in detail A Java cryptography API 75 is linked with a policy manager 74 and it has a HTTP client 76 linked with
a fast Common Gateway Interface (CGI) cryptography server 77 programmed in C++ a S/MIME C++ cryptography function 78 a certificate manager 79 programmed ln C-f — , a key manager 80 programmed m C++, and a cryptography library 81 having access to a certificate /key database 90
The interface 41 comprises
an API 71, a HTTP client 72 programmed m native Java, and an API servlet 73, and
In more detail, the management console 31 provides graphical user interfaces foi input and display of user information, security policies, and certification management The view interface 50 is the console front end and the screens are displayed using HTML and JSP The JSP tags 51 are used to interface between the screens and Java ode for the purposes of displaying derived data that is calculated or changes during the lifetime of the relay 1 The controller servlets provide the derived data to the JSP tags The security policy model 53 is a Javabean which drives the data for the security policy screens Likewise, the certificate model 54 is a Java bean which drives data for certificate management screens The function 55 provides access to the database 30 for persistent data on policies using the Java standard JDBC The certificate interface interacts with the key database 90 to retrieve certificate data for the management console 31 Access to the database 90 is via the cryptography library 81 , described in more detail below
Referring again to Fig 5, the functions which perform the core cryptography operations are now described in detail The mail server 4 shown m Fig 1 includes a client 70 which accesses the relay 1 via the client interface 10 In this example the client of the server 4 is written in Perl/PHP The client of the server calls the API 71 of the block 41 and the HTTP client 72 provides a mechanism for the client hooks 70 to communicate with the relay 1 This mechanism involves use of the API servlet 73 for server-side processing
The policy manager 74 determines what security policies should be applied to an email being received or sent It does this by communicating with the function 55 which extracts information from the database 30
The cryptography API 75 is an mterface which provides a real time bi-directional link and allows Java code to call C++ cryptography code The cryptography API client 76 allows the cryptography library 81 to be distributed on a different hardware platform for fault tolerance versatility, and performance The Fast CGI server 77 is the server side of the cryptography API 75
The component 78 provides S/MIME cryptography functionality for signing, encryption, and decryption The component 79 provides certificate management functionality, and the component 80 provides key pool management functionality These components interact with the key database 90, and use cryptography processes of the library 81 The library 81 implements low-level cryptography algorithms and key generation routines The components 78, 79, and 80 provide a C++ wrapper around the low-level C library 81
In the architecture illustrated m Fig 4, the controller 52 manages the flow of control for its operations by receiving a CGI command for instantiating business logic, and each business logic instance is a Java bean class instance The control flow is as follows
Taking the command string from the CGI variables,
Parsing the string into a hash table,
Instantiating a bean using introspection and the command string,
Setting the bean properties from the name, value pairs m the hash table,
Calling inttQ on the bean, and Pushing the data mto the view for display
The policy database 30 stores policies m which a policy consists of one instance of each of the following data type classes
Security policy scope,
Signmg algorithm, Encryption algorithm, Signing policy, Encryption policy
The relay 1 automatically captures security data for non-registered users when they reply to an outgoing message from a registered user This is achieved by the certificate cryptography function 78 stripping off the certificate from a signed message and storing the certificates in the database 90
The key pool database 90 is structured to have minimal impact on performance of the relay 1 as generation of key pairs is processor-intensive The key pool directory size is configurable by the user, and a threshold is set for the directory and when the number of keys falls below that level they are replenished The key pool is replenished with anonymous key pairs, but these are still fully usable keys sets The key sets are made usable by the generation of certificates and this happens on demand A daemon is used to monitor key pool threshold levels, and message queues are used to communicate between the controller and the key pool code
Referring now to Fig 6 operation of the relay 1 is described The client computer 2 generates an email using Web server functions 10 and this is processed by the module 37 The plug-ins 12 allow the client computer 2 to route the email to the relay 1 via the mail server Web mail functionality This is a very effective mechanism for integration of the relay 1 with a mail server 4 in a modular manner With an open API any subscriber or administrative user can interface with the relay 1 by implementing a plug-m 12 so that its code interacts with the API 41
In the module 37, the security policy is determined based on the "from" and "to' addresses m the message The security policy consists of
Digital Signature Policy
Clear-sign Opaque sign
Digest Algorithm
Encryption policy
Do not encrypt Encrypt
(Symmetric) encryption algorithm
The policy manager 74 accesses the policy database 30 to get policies for the senders and receivers of messages Each policy contains a "from" and a "to" field Some policies contain wildcards to allow setting of policies for groups The relay 1 has default policies, and these can be changed by the system administrator The policies contain the signing and encryption polices and algorithms
The key manager 80 then obtains access to the sender's private key from the database 90 This is secure because the keys are stored m the pkc #15 secure storage format
The S/MIME component 78 then constructs an S/MIME signed message including the digital certificate chain associated with the signing key m the message Encryption is of course by-passed if the policy does not indicate a requirement for encryption
If the policy requires encryption, the certificate manager 79 retrieves the recipient certificate from the certificate database The S/MIME component 78 then constructs an S/MIME encrypted message The message is encrypted usmg a randomly-
generated symmetric session key, and the session key is encrypted using the recipient's public key These cryptography operations are performed by an algorithm selected from the library 81 The structure of the library is as follows -
key and certificate generation key and certificate management, and
S/MIME capabilities
The S/MIME message is then transmitted
An incoming message is received by the functions 71, 72, 75, 76, 77, and 78 There is no involvement of policies for incoming messages and the messages are decrypted by the S/MIME component 78 and the library 81
It will be appreciated that the invention provides for very effective security processing of messages m a manner which is modular on the Web server hosted by the ISP or ASP and is transparent to the subscriber. Also, the policy database allows excellent versatility in choice of options by subscribers The structure of the functions allows excellent versatility for deployment of resources such as the low-level cryptography algorithms Also, the administrative framework comprising the management console 31 and the policy database 31 allows simple and effective real time configuration by administrative personnel of the host organisation
The invention is not limited to the embodiments described but may be varied in construction and detail