Note: Descriptions are shown in the official language in which they were submitted.
CA 02391049 2002-05-08
WO 02/21793 PCT/USO1/20812
SYSTEM AND METHOD FOR ENCRYPTED MESSAGE INTERCHANGE
BACKGROUND OF THE INVENTION
This invention relates generally to systems and methods for facilitating
secure
communications over a public network such as the Internet and, more
particularly, relates to a
system and method for encrypted message interchange.
Various mechanisms for facilitating the exchange of information between
clients and
servers over a public networlc axe known in the art. For example, the exchange
of
information between clients and servers can be performed using the File
Transfer Protocol
("FTP"). A more sophisticated mechanism for exchanging information is found in
the use of
the Secure Sockets Layer ("SSL") protocol. In the Internet environment, the
SSL protocol is
presently the protocol of choice to exchange confidential information, i.e.,
information that is
desired to be secured from outside observers.
While these known mechanisms do facilitate the exchange of information between
clients and servers in a network enviromnent, they do suffer drawbacks. In
this regaxd, the
FTP protocol is inherently insecure and data transferred between two endpoints
can be seen
by persons outside of the intended recipient. Since traditional authentication
schemes
employed using the FTP protocol are based upon cleax text passwords and the
data that
travels across the network is typically unencrypted, the data can be readily
accessed by
outsiders. While the SSL protocol does provide a higher level of security than
is found in the
2o use of the FTP protocol, the SSL protocol is inappropriate for use in
transferring data files or
logic states. This shortcoming arises from the fact that the SSL protocol is a
directive-
centered protocol that is useful primarily for securing messages sent using
the HyperText
Transfer Protocol ("HTTP")
As a result of these drawbacks, a need exists for an improved system and
method for
transferring confidential messages between clients and servers over a public
network. More
specifically, a need exists for a system and method for transferring
confidential messages
between business partners such that the messages cannot be easily viewed by
unwanted third
parties. In this manner, business partners would be able to confidently and
securely share
financial information, performance data, financial instruments, demographic
and personal
3 o data over the public network.
SUMMARY OF THE INVENTION
In accordance with these need, the present invention is realized in a system
and
method for encrypted message interchange. The interchange takes place between
an
administrator and a subscriber that are connected via a network. The system
and method
-1-
CA 02391049 2002-05-08
WO 02/21793 PCT/USO1/20812
utilizes a session lcey that is generated by the administrator in response to
each request from
the subscriber to establish an interchange session. During the interchange
session, the
subscriber will receive confidential information from the administrator. The
session lcey is
signed with a private lcey of the administrator and transmitted to the
subscriber in a message
that is encrypted with a public lcey of the subscriber. The session lcey is
used by the
administrator to encrypt messages that contain the confidential information
and by the
subscriber to decrypt the messages to gain access to the confidential
information. The
session lcey is a one-time lcey and is used only to encrypt and decrypt
messages during the
current interchange session.
1o A better understanding of the objects, advantages, features, properties and
relationships of the invention will be obtained from the following detailed
description and
accompanying drawings which set forth an illustrative embodiment and which are
indicative
of the various ways in which the principles of the invention may be employed.
BREIF DESCRIPTION OF THE DRAWINGS
15 For a better understanding of the invention, reference may be had to a
preferred
embodiment shown in the following drawings in which:
Figure 1 is a bloclc diagram illustrating an exemplary network on wluch the
system
and method for encrypted message interchange may be practiced;
Figure 2 is a data flow diagram illustrating an exemplary messaging
architecture for
2o use in connection with the system and method for encrypted message
interchange;
Figure 3 is a table illustrating exemplary data tables for use in connection
with the
system and method for encrypted message interchange;
Figure 4 is a table illustrating exemplary messages that may be exchanged in
the
system aald method for encrypted message interchange;
25 Figure 5 is a flow chart illustrating an exemplary method of sending
confidential data
in the system and method for encrypted message interchange; and
Figure 6 is a table illustrating exemplary messages that may be exchanged in
the
practice of the method illustrated in Figure 5.
DETAILED DESCRIPTION
3o Turning now to the figures, wherein like reference numerals refer to like
elements,
there is illustrated a system and method for encrypted message interchange. In
particular, the
system and method is particularly adapted to allow partners to exchange
messages that
include confidential financial and personal information over a public network.
By way of
example only, the information may relate to values of annuities, applications
for life
-2-
CA 02391049 2002-05-08
WO 02/21793 PCT/USO1/20812
insurance coverage, program data structures, etc. To prevent access of the
confidential
information by third parties, the system and method for encrypted message
interchange
utilizes public/private keys and session keys to ensure that the confidential
information is
securely transmitted and accessible by only the desired, target party.
For facilitating the.transmission of the confidential information, the system
and
method for encrypted message interchange utilizes various components that
reside on
computers in a public networlc. As illustrated in Fig. 1, the public networlc
10 may be the
Internet or a Virtual Private Network to which are connected one or more
client computers 12
and one or more data and/or application servers 14. As will be appreciated by
those of skill
to in the art, one or more routers 16 are provided for routing communications
between the
computers 12 and servers 14 over the network 10. The routers 16 may be
connected to the
computers 12 and servers 14 by means of firewalls or any other open ports 18.
The
computers 12 and servers 14 each include a Java Virtual Machine such that the
system and
method for encrypted message interchange may be utilized without regaxd to the
underlying
15 platforms of the computers 12 and servers 14. According to this preferred
embodiment, the
programs on the computers 12 and servers 14 that implement the system and
method for
encrypted message interchange are also preferably implemented in the JAVA
language.
According to an important aspect of the system and method for encrypted
message
interchange, the system and method for encrypted message interchange can be
described as
2o having two main components, namely, a publish/subscribe umbrella and an
encryption layer.
The publish/subscribe umbrella is used for managing the servers 14 that
transmit and receive
messages from the computers 12. The encryption layer is used for the actual
transmission of
data files from the servers 14 to the computers 12.
Under the publish/subscribe umbrella, providers of data are referred to as
25 "administrators" while receivers of data are known as "subscribers." A
subscription is
considered to be a series of files that are updated over time, for example, a
transmission of
AUV data would be considered to be a subscription. The subscriptions may be
updated with
new daily files. Subscribers can request subscriptions to some or all of the
available
subscriptions maintained on the servers 14. The administrators can approve or
deny any
3o subscription request as they see fit. The actual transmission of a
subscription to a subscriber
is performed utilizing the encryption layer.
For use in transferring subscriptions to subscribers, the messaging
architecture
illustrated in Fig. 2 may be utilized. As illustrated, the transport layer
defines the actual
mode of the data transmission. For example, the transport layer may be used to
specify the
-3-
CA 02391049 2002-05-08
WO 02/21793 PCT/USO1/20812
transmission of data via HTTP, JMC, or sockets. The message protocol layer
defines the
business logic of the messaging conversation and contains a listing of valid
message formats
and their corresponding valid responses. The message protocol layer is also
used to
determine the level of security required for any given message. The security
layer is an
optional wrapper around the content being sent. The security layer contains
the algorithms
necessary to encrypt and decrypt confidential information. In the preferred
embodiment, the
security layer consists of a server-side JAVA package available to all users.
Finally, the
content layer defines the syntactic structure of all valid messages in the
system, for example,
the form of data file definitions or Document Type Definitions ("DTDs").
to To manage the publish/subscribe umbrella, a number of Application
Management
Interfaces ("AMIs") may be provided. Examples of AMIs that may be used in the
system
include "Create/Modify/Remove Subscriber," "Create/Remove Publication,"
"Publish File,"
"Manage Subscriptions," and "Subscription Requests." The "Create/Modify/Remove
Subscriber" AMI is an interface for maintaining the subscriber information
table data. The
15 data included in the subscriber information table may be collected offline.
As illustrated in
Fig. 4, entries into the subscriber information table preferably trigger the
"notify subscriber
created" and "notify subscriber removed" messages. The "Create/Remove
Publication" AMI
is an interface for maintaining the publication information table data.
Entries into the
publication information table preferably trigger the "notify new publication"
and "notify
2o publication canceled" messages. The "Publish File" AMI is an interface to
load new files to
be published. Use of the "Publish File" AMI preferably triggers the issuing of
the "notify
published," "file request," and "file" message sequence. The "Manage
Subscriptions" AMI
is an interface to view all publications and the subscriber of each
publication. The "Manage
Subscriptions" AMI can be used by administrators to add and drop subscribers
to each
25 publication. Use of the "Manage Subscriptions" AMI preferably triggers the
issuing of the
"allow subscription" message and the "notify subscription canceled" message.
Finally, the
"Subscription Requests" AMI is an interface to view the request of the
subscriber for new
publications. This interface allows the administrator to grant or deny
subscriptions. Use of
the "Subscription Requests" AMI preferably triggers the issuing of the "deny
subscription"
3o and "allow subscription" messages.
In addition to the AMIs noted above, various subscriber AMIs may also be
provided.
For example, the system and method for encrypted message interchange may
provide a
"Subscriptions" AMI. The "Subscriptions" AMI is an interface for the
subscriber to view all
current subscriptions and each publications most recent publication date. The
-4-
CA 02391049 2002-05-08
WO 02/21793 PCT/USO1/20812
"Subscriptions" AMI may also be used to request additional publications) or to
cancel
current subscription(s). Use of the "Subscriptions" AMI preferably triggers
the "available
publications," "request subscription" and "cancel subscription" messages.
Turning to Fig. 3, the various database tables that are preferably utilized in
connection
with the system and method for encrypted message interchange are illustrated.
As illustrated,
the system and method for encrypted message interchange preferably maintains a
subscriber
table, a publication table, a file table and a subscription table for use in
managing the
transmission of subscriptions to their appropriate subscribers. It will be
appreciated that the
data fields illustrated in the tables shown in Fig. 3 are meant to be
exemplary only and that
to the actual data fields used should be tailored to meet the particular needs
of the envisioned
usage of the system.
For communicating status information between administrators and subscribers
using
the system and method for encrypted message interchange, the messages
illustrated in Fig. 4
may be transmitted between the servers 14 and computers 12. Again, it will be
appreciated
that the status messages shown in Fig. 4 are meant to be exemplary oily and
that the actual
messages used should be tailored to meet the particular needs of the
envisioned usage of the
system. It will also be appreciated that these status messages may not be
deemed to include
confidential information and, therefore, may not be required to be encrypted
when
transmitted over the public networlc 10.
2o To transmit the files that include the confidential information for which a
secure
transmission is sought, the method illustrated in Fig. 5 is preferably
utilized. In accordance
with this method, the messages illustrated in Fig. 6 are preferably exchanged
to facilitate the
transfer of any requested files. However, before any files are transmitted
from the
administrator to the subscriber, it is the responsibility of the subscriber to
determine if all of
the necessary public and session keys exist. Thus, prior to sending the file
request message,
the subscriber should verify that: 1) the subscriber has a current copy of the
public lcey of the
administrator; and 2) the subscriber has a current session key. In this
regard, it is the
responsibility of both the subscriber and the administrator to maintain
current, valid
public/private lcey pairs and to make their public lcey available to anyone
sending a public
3o key request message. Expired or compromised keys should be revoked and
replaced
immediately. Furthermore, it is the responsibility of the adminstrator to
generate and
transmit session keys upon request. Expired session lceys should be destroyed,
not archived,
by both subscribers and achninistrators. The private/public key pairs can be
generated using
-5-
CA 02391049 2002-05-08
WO 02/21793 PCT/USO1/20812
encryption modules that are part of the system while the session keys are
preferably
generated indirectly by calling a build session key method resident on the
servers 14.
Before receiving any requested files, as noted above, the subscriber
determines if it
has the current session lcey and the public lcey of the administrator. If the
subscriber has the
current session lcey and the public key of the administrator, the subscriber
can issue the file
request message to which the administrator responds with the requested file
that is encrypted
with the current session key. The subscriber can then use the current session
lcey to decrypt
the file and retrieve the requested information.
If the subscriber determines that it does not have the public key, the
subscriber should
send a public lcey request message to the administrator. In this regard, it is
preferred that all
messages sent between parties include the ID of the sender. If the public key
request
message is malformed, the administrator may respond with an acknowledge
message with a
status of "bad message." If the administrator determines that the sender ID is
a valid ID and
that the public key request message is in an acceptable format, the
administrator should
respond with the public lcey in the public key message. At this time, the
administrator should
also request the public lcey of the requesting subscriber to which the
subscriber should
respond with its public lcey in a public key message. During this process, the
ID of the party
sending the message is continually checked to see if it is valid. If the IDs
are valid, the public
keys are stored to the local public lcey ring of the receiving party.
2o If the admiizistrator determines that the ID of the requester is a not a
valid ID, the
administrator may: (a) hang on to the public key request message; (b) respond
with the public
lcey message; (c) wait for an acknowledge message with a status of "ok;" (d)
respond with the
public lcey request message; (e) wait for the public key message from the
subscriber; (f)
respond as usual to the public lcey message; and (g) verify that (i) the
sender ID in step (e) is
valid and (ii) the sender ID in step (a) matches the requester in step (e). If
the sender ID is
valid and matches, the procedure has succeeded and everything may proceed as
noi~rnal. If the
step (e) requester is bad or the sender ID from steps (a) and (e) do not
match, the procedure
has failed, and the remote sender should not be trusted unless/until it
explains itself (ideally,
the public lcey sent in step (b) should be revoked). Again, during this
process the ID of the
3o party sending a message is continually checked to see if it is valid. If
the IDs are valid and
procedure is deemed to be successful, the public lceys are stored to the local
public key ring
of the receiving party.
Once this procedure is complete, it is known that the message is internally
consistent
(i.e., that the user ID and the sender ID is signed with the private lcey
corresponding to the
-6-
CA 02391049 2002-05-08
WO 02/21793 PCT/USO1/20812
public key in the message.) Ideally, the administrator should not respond to
any session key
or file request messages until a verification of the public lcey has been
performed. This
verification may talce place offline. Once verified, the administrator may
sign the public lcey
with its private lcey to indicate that it is considered to be valid.
If the subscriber does not have the current session lcey, the subscriber sends
to the
administrator a session lcey request message. If the sender ID is valid and
the public lcey for
that sender ID exists, the administrator generates the session lcey, persists
the session
key/sender ID pair, and responds to the subscriber with a session key message
containing the
generated session lcey. The session lcey is signed with the private lcey of
the administrator
to and the signed session lcey is encrpyted with the public key of the
subscriber. Upon receipt
of the session key message by the subscriber, the session key is decrypted by
the subscriber at
which time the subscriber will validate the signature of the session key to
ensure that the
session lcey was generated by the administrator. If the session lcey is
determined to be valid,
i.e., the signature of administrator was verified and the sender ID is
determined to be valid,
15 the session lcey and sender ID pair is persisted by the subscriber.
Returning to the administrator, if the sender ID in the request session key
message is
valid and the public lcey for the requester does not exist, the administrator
may respond with
the public lcey request message. If the sender ID is not valid, the
administrator should
respond with an acknowledge message with a status of "bad senderID." If the
request
2o message is malformed, the administrator should respond with an acknowledge
message with
a status of "bad message."
Once the subscriber has both the current session lcey and the public key for
the
administrator, the file request message may be sent from the subscriber to the
administrator.
Again, the file request message will have the ID of the sender. If the sender
ID is valid and
25 the session lcey for that sender ID exists, the administrator responds with
the requested file.
As noted previously, the requested file is encrypted with the current session
key which the
subscriber uses to decrypt and read the file. If the sender ID is valid and no
session key for
that sender ID exists, but the public lcey for that sender ID does exist, the
administrator
should respond with a session key message. If the sender ID is valid, no
session lcey for that
3o sender ID exists, and no public lcey for the sender ID exists, the
administrator may respond
with a public key request message. If the sender ID is not valid, the
administrator should
respond with an acknowledge message with a status of "bad sender ID." If the
message is
malformed, the administrator should respond with an acknowledge message with a
status of
"bad message."
_7_
CA 02391049 2002-05-08
WO 02/21793 PCT/USO1/20812
To fiu-ther ensure the security of the system and method for encrypted message
interchange, it is preferred that the session lcey be revolted once the
current session for
transferring confidential information is complete. Upon completion of the
current session,
the subscriber should de-persist the session key/sender ID pair and send a
revolve session lcey
request to the administrator. If the sender ID is determined by the
administrator to be valid,
the administrator should also de-persist the session lcey/sender ID pair. It
will be appreciated
that the administrator may also perform the same steps to request that the
subscriber revolve
the current session lcey. Accordingly, session keys can be destroyed by either
party of the
conversation at any point although an automated lcey-revocation schedule would
be preferred.
to From the foregoing it will be appreciated that the described system and
method for
encrypted message interchange provides an improved system and method for
transferring
confidential information between clients and servers over a public networlc.
This security
arises, in particular, from the use of signed, one-time only keys, i.e., the
signed session keys
that are revoked on a session by session basis. Thus, even in the unlikely
event that an
unauthorized, third party viewer was able to decipher an encrypted file
containing
confidential information, the unauthorized, third party viewer would
nevertheless be limited
to that one instance since the encrypting lcey changes on a session by session
basis.
While specific embodiments of the invention have been described in detail, it
will be
appreciated by those skilled in the art that various modifications and
alternatives to those
details could be developed in light of the overall teachings of the
disclosure. For example,
the described system may also be used for the secure transport of serialized
program data
structures such as Java Beans or Classes to allow for the transfer of logic
between two
interconnected systems. Furthermore, the programs that perform the operations
that allow for
the encrypted message interchange may be distributed across a plurality of
servers and
computers attached to the network. Accordingly, the particular arrangement
disclosed is
meant to be illustrative only and not limiting as to the scope of the
invention which is to be
given the full breadth of the appended claims and any equivalents thereof.
_g_
