CA2530937A1 - System and method for end-to-end electronic mail encryption - Google Patents

Description

SYSTEM AND METHOD FOR END-TO-END ELECTRONIC
MAIL ENCRYPTION

Field of the Invention The present invention relates to data processing and, more particularly, to a method and apparatus for end-to-end encryption of electronic mail messages using mechanisms based on public key encryption and symmetric key encryption.

Background of the Invention Electronic mail (e-mail) has become a primary means of communication for a large number of organizations, businesses and individuals. Email, however, is an inherently insecure means of communication given that all messages sent between senders and recipients are transmitted in clear text over networks. In sum, sending email is like sending a postcard. This fact, nevertheless, does not deter a large portion of email users to continue using email as a conduit for sensitive, confidential data, and other users to avoid email altogether for any sort of sensitive transfers. While some email users, and/or the organizations they belong to, have started using encryption as a means to secure email data transfers, the vast majority of email users continue to transfer sensitive information using plaintext email. The fact of the matter is that none of the existing solutions for providing email encryption, and there are a great deal many of these, has been able to strike the right balance between security, ease-of-use and ease-of-deployment. While many attempts have been made to solve these issues, there has yet to be a single solution that has been widely adopted. The need for a powerful, yet simple end-to-end encryption mechanism is therefore very much still present.

2 Summary of the Invention The present invention provides a method and system for end-to-end electronic mail encryption. In one embodiment, the sender contacts an encryption server which identifies the sender as being authorized to use its services, receives the message the sender would like to encrypt for the recipient or recipients, generates a random symmetric key, encrypts the sender's message with the symmetric key, encrypts the symmetric key and other data items related to the message either using a public key associated with the recipient or the recipient's organization or using a mechanism based on a sender-chosen symmetric key (possibly a simple passphrase), for example if no public key is associated with the recipient, and returns the encrypted message and the encrypted randomly-generated symmetric key to the sender. The sender then uses his regular email infrastructure to transmit to the recipient the encrypted message and symmetric key. Upon receiving the sender's email, the recipient contacts a decryption server which has a copy of the recipient's private key and/or means for extracting the symmetric key used to encrypt the sender's message using, partly, the sender-chosen symmetric key.
The decryption server first identifies the recipient as being authorized to use its services - such identification could be very basic to the extent that no verification is carried out by the decryption server, or it could be very elaborate and require the use of passwords or the likes. Having been authorized to use the decryption server, the recipients sends it the encrypted symmetric key originally used by the encryption server to encrypt the sender's message. The decryption server then extracts the symmetric key and provides it back to the recipient which can then decrypt and read the sender's message.

As in co-pending "System and Method for Warranting Electronic Mail Using a Hybrid Public Key Encryption Scheme" assigned International Application Number PCT/CA2005/000173, the contents of which are expressly incorporated herein by reference, in this invention the participants, be they senders or recipients, do not have access to their private key, if one has been attributed to them, and cannot,

3 therefore, themselves decrypt messages encrypted for them using their matching public key. This is an important departure from most existing email encryption systems where participants possess their own public/private key pair and can themselves use their own private key to decrypt messages encrypted for them using their public key.

As in PCT/CA2005/000173, there is a trusted third party (TTP) managing public and private key databases, and the distribution and use of software implementing encryption and decryption servers. The TTP's involvement is key in ensuring that all parties obtain the functionality they expect with regards to end-to-end email encryption, in addition to providing other services such as sender authentication and certified proof of delivery (PoD).

Also, similarly to PCT/CA2005/000173, both senders and recipients would typically interact with the TTP, and the encryption, and decryption servers using a plugin to their email client software. This, therefore, allows users to continue using their email software without modifying their habits.

In addition to the basic functionality outlined above, the sender, or his organization, may choose to mark the message to be encrypted and sent to the recipient in such a way that upon requesting the symmetric key from the TTP's decryption server, the TTP will grant the recipient, and the recipient will thereupon receive, a one-time-use reply token or something similar allowing the recipient to log into the TTP's publicly-accessible encryption server and encrypt his reply back to the sender. This is especially interesting for senders who want to interact with recipients who are not recognized or otherwise known or identifiable to the TTP.
There are many advantages to the mechanisms embodied in this invention in comparison to existing email encryption systems. These advantages are best explained in the context of the participants' types, be they senders or recipients.
There are mainly four types of participants in this system:

4 = Individual user: These are individuals who are known to and registered with the TTP. These users would typically interact with publicly-accessible encryption and decryption servers (PEDS) - typically encryption and decryption servers accessible through the public Internet.
= Local user: These are users located on a LAN and having access to privately-hosted local encryption and decryption servers (LEDS) - typically encryption and decryption servers located on an organization's LAN and likely protected by a local firewall, and therefore not being accessible to any other hosts than those on the LAN.
= Roaming user: These are users who belong to an organization that possesses LEDS but who, for a brief amount of time or for most of the time, are not connected to their organization's LAN.
Instead, these users are possibly traveling and must therefore use the TTP's PEDS.
= Non-member: These are individuals who are not registered with, identified to, or otherwise known by the trusted third-party (TTP). These users would typically only interact with the TTP's publicly-accessible decryption servers. If, and only if, they were granted a reply token by the sender, they could also use the TTP's publicly-accessible encryption servers to encrypt a reply back for the sender.

As senders, individual users benefit from using the TTP's PEDS firstly because they do not need to manage or grasp the underlying principles surrounding the use of private/public key pairs. Instead, they just need to follow the procedure required to use PEDS, such as providing a username/password pair. This also simplifies the overall system's usage should, for example, the private/public key pair associated with the user need to be regenerated. In addition, given that the message is encrypted on the TTP's servers, other services, such as PoD or sender authentication, can be offered in a simple, easy-to-use, integrated fashion.
Of course the underlying premise is that the user must trust the TTP since he will send it his original message unencrypted, but this is the essence of this scheme since other services provided by the TTP likely include content filtering and

5 certification, as per described in PCT/CA2005/000173. As a "trusted" third-party, the TTP must anyway provide assurances and possibly certification to the effect that it can and does honor users' privacy. Alternatively, individual users who would still prefer not to send content to be encrypted by PEDS may choose to enter in agreement with the TTP in order to obtain their own LEDS. In that case, they would become "local users" with regards to the above description.

As recipients, the individual users benefit from using the TTP's PEDS in that they don't need to manage their own private key for decrypting documents, instead they likely have a username/password that allows them to decrypt the symmetric they will need to decrypt a messages sent to them. In addition, contrary to the sending process, documents received by the user do not need to be submitted to the TTP
for decryption. Instead, only the encrypted symmetric key is submitted by the user to the TTP's decryption server. Also, it could be possible for the TTP to audit for the user his receiving of encrypted content. Such auditing could be used to detect whether the users' username/password pair may have been compromised and a malicious party is using them to read content sent encrypted to the user.

For an organization, having on-site LEDS has many benefits. First, for allowing its users to receive encrypted emails, the organization does not need to create, publish or manage a key pair for every single local user and, for both sending and receiving encrypted emails, there is no need for any user to grasp any of the concepts underlying the use of public-key encryption. Instead, as mentioned earlier, both the sending and receiving of encrypted emails relies on the hosting by the TTP of private/public key pairs.

6 Senders wishing to send encrypted email to a user belonging to an organization registered with the TTP, for example, would use the public key associated to the organization and hosted by the TTP on its public key servers. Upon receiving emails encrypted using this public key, local users would then use a designated method for authorizing with and using the organization's on-site decryption server.
This may involve using a username/password pair, but it could also be done using other means such as validating that the host from which the decryption server is contacted from is indeed on the LAN. Such a process guarantees that only recipients internal to the organization can read email encrypted for this organization. Additionally, the decryption server could be configured such that only recipients designated by the sender can obtain the decrypted symmetric key.
The net effect of this is that senders can interact with recipients part of an organization without requiring that a recipient take part in any special procedure or his organization to publish a key pair for him. Instead, the decision to allow an internal recipient to read an incoming message can be done at the decryption server, therefore allowing the organization to centralize the administration of decryption authorization - which, obviously, could be combined with the administration of the local users' rights to obtain other services, such as PoD request generation, message signatures for authentication, or encryption itself.
Much like for decryption, the requirement for local users to use an encryption server in order to encrypt outgoing email allows the organization to centralize the control to encryption capabilities. The encryption server can therefore be configured to first make sure senders are authorized to use its servers, and then could conduct a number of verifications on the message, some of which could be based on content, designated recipients, and sender's identity, before authorizing the encryption. Again, like for decryption, authorization could be granted based on a username/password pair, a network identifier such as an IP address, or something else.

7 For a local user to be able to decrypt incoming messages or encrypt outgoing messages, the LEDS administrator would likely add him to the list of users recognized by the LEDS. In order to remove the authorization of a user to encrypt/decrypt, the administrator would, conversely, remove him from the list of users recognized by the LEDS. Also, it could be possible for the LEDS to automatically deactivate users' ability to use its services should any abnormality be detected with regards to a user's behavior, such as attempts to process messages which are determined to contain spam. In that case, a user's account could be quarantined and notification given to the administrator.
Generally, the use of LEDS allows an organization to centralize auditing, activity logging, key event notification, policy enforcement, standards-compliance, and all such similar tasks.

In addition, organizations could choose to create their own private/public key pairs.
In that case, while the public key could be disseminated at large, possibly using the TTP's public key server, only the organization's decryption server would be able to decrypt emails sent to local users by outside senders since it would be the only location hosting the corresponding private key. This also means that roaming users would not be able to use PEDS to decrypt messages, but would instead need to use some form of VPN for accessing their organizations' decryption servers. Such cases of organizations wishing to maintain their own key pair is likely to be limited only to those organizations requiring the highest degree of security such as financial institutions and the likes.
Generally, roaming users have much of the same advantages as individual users except that they don't have a separate private/public key pair attributed to them.
Instead, they use the same pair attributed to their organization and can therefore encrypt and decrypt messages that, typically, could have been processed only by their organization's LEDS. The ability for roaming users to use PEDS allows organizations to have users traveling yet having the same advantages of local

8 users without the organization having to set up any sort of VPN for these roaming users to log into the organization's LAN.

It could be possible to set up roaming users with their own key pair should organizations prefer such users not being able to use the organization's keys through PEDS. In that case, for a roaming user to receive an encrypted message, it could be made that the symmetric key generated by the sender's encryption server be encrypted twice, once with the recipient's organization's public key and once with the public key attributed to the roaming user, both encryption results being returned to the sender for sending to the recipient. Upon receipt, the roaming user would then either use the receiving organization's decryption server, if he is locally connected, or his account on PEDS to decrypt the received message.

It should be possible for organizations' system administrators to administer accounts for roaming users using, for example, a web interface on PEDS or something similar provided by the TTP.

As recipients, non-members can receive encrypted content without being a participant in any way with the TTP. This is a major departure from existing encryption schemes where sender and recipient must both be participants to the same encryption infrastructure. Since no public key is associated with the recipient, emails sent to the non-member recipients may be encrypted using the public key associated with the sender and a passphrase chosen by the sender.
Upon receipt, the non-member recipient would contact the TTP's decryption server and provide it with both the encrypted symmetric key and the passphrase provided by or agreed upon with the sender. The TTP's decryption server would then use the sender's private key and the passphrase to decrypt the encrypted symmetric key and provide it to the recipient. Given that the symmetric key was encrypted with the sender's public key, it would be practically impossible for an intercepting party to decrypt the emails using brute-force techniques, as could have been

9 simpler would the email been only encrypted using a passphrase. As an extra precaution, the TTP's decryption server could be configured to not allow more than a handful of decryption attempts on any given message by non-member recipients.
To facilitate interaction with non-member recipients, senders could be provided with facilities for storing recipient-specific passphrases either on the designated encryption server or locally on their machine. This would allow senders to interact with non-member recipients without having to provide a passphrase every time.
In other circumstances, such as for banks providing online access to customer accounts, it may be desirable for allowing non-member recipients to select their own passphrases using a web interface. In that case, the non-member recipient would be able to select his own passphrase without the actual sender having to select one for or agree upon one with the non-member recipient. Capabilities would be provided for the sender's system or the encryption server to automatically retrieve the passphrase for a given non-member recipient.

As mentioned earlier, it would be possible to send non-members specially-marked encrypted emails that upon being decrypted by the TTP's decryption servers would result in the non-member recipient being able to log into the TTP's encryption servers and encrypt a reply back to the original sender. Again, this is a major departure from existing encryption schemes where non-members are typically directed to a web site for reading encrypted content and replying back to the original sender. The system presented in this invention therefore allows non-member recipients to continue using their existing email client software while still being able to entertain a secure email exchange with a sender recognized by the TTP.

In sum, this invention is thus composed of the encryption server, the decryption server, the software used by the sender and the recipient to interact with the encryption and decryption servers, and all additional software and hardware required to implement this invention.

5 Detailed Description of the Invention The following drawing illustrates the invention's main components.
5ender's 5 Recipient's mail server mail server Encryption public key server/ DB

1 1 Encryption Decryption 9 erver Server a Sender 3 7 Recipient

10 Figure 1 In 1, the sender contacts the encryption server in order to encrypt the message to his recipient. First, the sender must provide the proper information in order to obtain the authorization to use the encryption server. This information may be a username/password pair, or it may be a function of the network layout, such as an IP address or a MAC address, or both, or something else. The encryption server may also be configured to accept connections from any sender with access to it. In the case of a non-member having received a one-time-use reply token, the authorization procedure would require providing the token to the encryption server, thereby typically using it up and rendering it unusable for future reuse.
Having been authorized to use the encryption server's services, the sender transmits the messages he wishes to encrypt to his recipient or recipients to the encryption server. Note that the encryption server could be located on a sender's

11 organization's LAN or it could be remotely accessible through another network such as the Internet. The functionality of the encryption server should be fairly similar whether it is on the local LAN or on a remote network.

In 2, the encryption server first receives the sender's message and likely stores it in a temporary buffer in RAM for further processing. The encryption server could then conduct a series of analysis on the sender's message, including verifying compliance to corporate guidelines and spam detection, amongst other possibilities. Having done so, the encryption server generates a random key and encrypts the sender's message with this key.

The encryption server then conducts a series of operations to locate and select a public key or a set of public keys for encrypting the symmetric key for the recipient or recipients. First, the server checks whether a public key has been published for the actual recipient and then checks whether a public key has been published for the recipient's organization (possibly based on the domain name found in the recipient's email address). The order and extent of these checks could be configurable. For example, the encryption server could be made to first look in a local cache, which could contain entries with a time-to-live, or it could be made to look in a statically-populated database, or even required to retrieve the.public key every time an encryption request is made. Whenever the encryption server would need to locate a key for a recipient it does not have a key for locally, it would typically contact a public key server, possibly the one hosted by the TTP. It is also possible that the encryption server could be configured to permit the sender to designate which public key to use for the recipients or in which way the recipient's can be determined or retrieved.

Should no key be located for the recipient, the encryption server may interact with the sender to encrypt the message using the public key attributed to the sender along with a designated symmetric key, such as the passphrase mentioned earlier, which would typically be provided by the sender. The selection, storage, and

12 retrieval of this designated symmetric key could, of course, be automated and the non-member recipient could, as explained earlier, be made to participate in the selection of an associated passphrase. At this stage, the sender could typically be prompted whether he wants the non-member recipient to receive a one-time-use reply token for being able to reply back in an encrypted fashion, as described earlier.

Having found the relevant public key or keys, or having determined that the recipient is a non-member and that a designated symmetric key will be used in addition to the sender's public key, the encryption server encrypts the randomly-generated symmetric key appropriately, possibly multiple times, possibly once for each sender.

The encryption server could also conduct a number of other operations on the message, such as generating a signature for the sender akin to the description found in co-pending PCT/CA2005/000173, or it may create a PoD request for the message so that the recipient would not be able to read the message's content without confirming receipt back to the sender. With regards to encryption, PoD
and signature, the preferred order would typically be: create PoD request, encrypt for recipient, and sign. This would allow recipients to first validate the origin (which is the least expensive of operations in terms of required computational power), then proceed with the other operations. This is unique to this invention as encryption and signature can be atomically conducted on the encryption server. In other encryption systems, content certification can only be done on non-encrypted content, and therefore signing is conducted before encryption, which requires recipients to conduct the more expensive operation (decryption) first before being able to verify the email's origin. Additionally, given that recipients must first decrypt before taking care of PoD, senders can be sure that recipients do indeed have a readable message after the processing of the PoD, instead of possibly a message for which a PoD was triggered but that the recipient may turn out to be unable to decrypt.

13 The encryption server could also be made to conduct a number of auditing procedures as described above.

In 3, the encryption server returns the encrypted message along with the encrypted copies of the randomly-generated symmetric key back to the sender.
Both steps 1 and 3 are automated using software on the sender's station. Said software could possibly be a plugin to the sender's existing email client software.

In 4, the sender transmits the encrypted message and the encrypted symmetric key as a regular email to his existing mail server.

In 5, the sender's mail server transmits the sender's mail to the recipient's mail server.
In 6, the recipient retrieves messages stored for him by his mail server. It is at this stage that software located on the recipient's station, possibly a plugin to his email client software, which could possibly be the same one originally used by the sender to encrypt the message for the recipient, would detect emails encrypted and act appropriately. The encrypted email generated by the encryption server would likely contain plaintext messages so that recipients that lack the software required to decrypt messages encrypted using the above-described process could still be informed of the functionality and how they could obtain the software required to deal with such emails.
In 7, the recipient (or, more specifically, the software on the recipient's station) contacts a decryption server in order to obtain a decrypted copy of the symmetric key used to encrypt the email he has received. If he is recognized by the decryption and, therefore, a public key associated with him was used by the sender's encryption server to encrypt the designated symmetric key, the recipient would typically have to first be authorized by the decryption server to use its

14 server, typically using the methods described above such as using a username/password pair. If the recipient is a non-member and is, therefore, not recognized by or know to the decryption server, the recipient would likely need to provide the decryption server with the designated symmetric key (likely a passphrase) used by the sender's encryption server to encrypt the randomly-generated symmetric key. This request could possibly be in the form of a pop-up to the user, or, if the non-member recipient often interacts with the same sender, the agreed-upon symmetric key could be stored locally on the recipient's system and retrieved as needed for decrypting incoming messages from the given sender.
In 8, the decryption server processes the decryption request obtained from the recipient. If the recipient is registered with or otherwise known to the decryption server, the decryption server retrieves the private key associated with the recipient from a database and uses the retrieved key to decrypt the encrypted symmetric key. If the recipient is a non-member, the decryption identifies the private key associated with the sender, retrieves this key from a database, and uses this key along with the designated symmetric key provided by the recipient for decrypting the randomly-generated symmetric key originally used by the sender's encryption server to encrypt the sender's message. Should the encrypted randomly-generated symmetric key used by the sender's encryption server to encrypt the sender's message be specially-marked, the decryption server would generate a one-time-use reply token that the non-member recipient could later use to log into an encryption server and encrypt a reply back to the sender.

The decryption server could, of course, be made to conduct various operations in reaction to decryption requests. For example, as alluded to earlier, it could check to make sure that the recipient requesting the decryption is indeed part of the list of recipients originally designated by the sender. In addition, the decryption server could be made to conduct many tasks related to auditing, report generation, incident reporting and the likes such as recording recipients' decryption requests along with who is sending encrypted content to them. Much of the decryption server's behavior could of course be configurable.

It is possible that the encryption server and the decryption server could be hosted 5 on the same system. This would especially be the case for organizations having LEDS.

In 9, the encryption server transfers the decrypted symmetric key to the recipient.
Having received the decrypted symmetric key, the recipient can then decrypt the 10 sender's message and read it. Should the sender have marked his message for allowing the recipient to reply back in an encrypted fashion, the recipient would also receive a one-time-use token for logging into an encryption server for encrypting his reply back to the sender.

15 While embodiments of this invention have been illustrated and described above, it will be evident to those skilled in the art that changes and modifications may be made therein without departing from the essence of this invention.

Claims