Note: Descriptions are shown in the official language in which they were submitted.
CA 02530937 2005-12-20
1
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.
CA 02530937 2005-12-20
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,
CA 02530937 2005-12-20
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:
CA 02530937 2005-12-20
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
CA 02530937 2005-12-20
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.
CA 02530937 2005-12-20
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.
CA 02530937 2005-12-20
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
CA 02530937 2005-12-20
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
CA 02530937 2005-12-20
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
CA 02530937 2005-12-20
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
4 6
1 1 Encryption Decryption 9
S 2
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
CA 02530937 2005-12-20
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
CA 02530937 2005-12-20
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.
CA 02530937 2005-12-20
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
CA 02530937 2005-12-20
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
CA 02530937 2005-12-20
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.
