WO2002021793A2

WO2002021793A2 - System and method for encrypted message interchange

Info

Publication number: WO2002021793A2
Application number: PCT/US2001/020812
Authority: WO
Inventors: Matthew Hausken; Paul Ivsin; Abdou Touray
Original assignee: Rivenet.Com, Inc.
Priority date: 2000-09-08
Filing date: 2001-06-29
Publication date: 2002-03-14
Also published as: CA2391049A1; WO2002021793A3; AU2001273089A1

Abstract

A system and method for encrypted message interchange between an administrator and a subscriber that are connected via a network. The system and method utilizes a session key 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 key is signed with a private key of the administrator and transmitted to the subscriber in a message that is encrypted with a public key of the subscriber. The session key 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 key is a one-time key and is used only to encrypt and decrypt messages during the current interchange session.

Description

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 network are 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 environment, they do suffer drawbacks. In this regard, 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 clear 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 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 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 utilizes a session key 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 key is signed with a private key of the administrator and transmitted to the subscriber in a message that is encrypted with a public key of the subscriber. The session key 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 key is a one-time key and is used only to encrypt and decrypt messages during the current interchange session. 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 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 block diagram illustrating an exemplary network on which the system and method for encrypted message interchange may be practiced;

Figure 2 is a data flow diagram illustrating an exemplary messaging architecture for 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 and method for encrypted message interchange; 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 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 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 network. As illustrated in Fig. 1, the public network 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 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 regard to the underlying 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 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 "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 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 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 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 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 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 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" 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 "Subscriptions" AMI may also be used to request additional publication(s) 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 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 only 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 network 10. 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 key 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 key pairs and to make their public key available to anyone sending a public key request message. Expired or compromised keys should be revoked and replaced immediately. Furthermore, it is the responsibility of the administrator to generate and transmit session keys upon request. Expired session keys should be destroyed, not archived, by both subscribers and administrators. The private/public key pairs can be generated using 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 key and the public key of the administrator. If the subscriber has the current session key 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 key 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 key 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 key in the public key message. At this time, the administrator should also request the public key of the requesting subscriber to which the subscriber should respond with its public key 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 key ring of the receiving party. If the administrator 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 key message; (c) wait for an acknowledge message with a status of "ok;" (d) respond with the public key request message; (e) wait for the public key message from the subscriber; (f) respond as usual to the public key 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 normal. 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 key sent in step (b) should be revoked). Again, during this process the ID of the 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 keys 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 key corresponding to the 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 key has been performed. This verification may take place offline. Once verified, the administrator may sign the public key with its private key to indicate that it is considered to be valid. If the subscriber does not have the current session key, the subscriber sends to the administrator a session key request message. If the sender ID is valid and the public key for that sender ID exists, the administrator generates the session key, persists the session key/sender ID pair, and responds to the subscriber with a session key message containing the generated session key. The session key is signed with the private key of the administrator and the signed session key 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 key was generated by the administrator. If the session key is determined to be valid, i.e., the signature of administrator was verified and the sender ID is determined to be valid, the session key 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 key for the requester does not exist, the administrator may respond with the public key request message. If the sender ID is not valid, the administrator should respond with an acknowledge message with a status of "bad senderlD." If the request 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 key 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 the session key 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 key for that sender ID does exist, the administrator should respond with a session key message. If the sender ID is valid, no session key for that sender ID exists, and no public key 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." To further ensure the security of the system and method for encrypted message interchange, it is preferred that the session key be revoked 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 revoke session key request to the administrator. If the sender ID is determined by the administrator to be valid, the administrator should also de-persist the session key/sender ID pair. It will be appreciated that the administrator may also perform the same steps to request that the subscriber revoke the current session key. Accordingly, session keys can be destroyed by either party of the conversation at any point although an automated key-revocation schedule would be preferred. 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 network. 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 key 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.

Claims

CLAIMS What is claimed is:

1. In an administrator, a method for encrypted message interchange between the administrator and a subscriber connected via a network, the method comprising: generating a session key in response to each request from the subscriber to establish a session during which the subscriber desires to receive confidential information from the administrator; signing the session key with a private key of the administrator; encrypting the signed session key with a public key of the subscriber; transmitting to the subscriber the encrypted, signed session key; and in response to a request from the subscriber to receive the confidential information, encrypting a message containing the confidential information with the session key and transmitting the encrypted message to the subscriber where the subscriber will use the transmitted, signed session key to decrypt the message and gain access to the confidential information.

2. The method as recited in claim 1, further comprising the step of checking a sender ID that is transmitted in a request message from the subscriber and persisting the sender ID and session key pair.

3. The method as recited in claim 1, further comprising the step of requesting the subscriber to transmit the public key of the subscriber.

4. The method as recited in claim 1, wherein the confidential information comprises state information.

5. In a subscriber, a method for encrypted message interchange between an administrator and a subscriber connected via a network, the method comprising: requesting the administrator to establish a session during which the subscriber desires to receive confidential information from the administrator; receiving from the administrator a session key that is unique to the requested session, the session key being signed with a private key of the administrator and contained in a message encrypted using a public key of the subscriber; decrypting the message to access the session key; validating the signature of the session key; requesting the administrator to transmit the confidential information; receiving a message from the administrator containing the confidential information, the message being encrypted with the session key; and decrypting the message using the decrypted, validated session key to gain access to the confidential information.

6. The method as recited in claim 5, further comprising the step of requesting from the administrator the public key of the administrator.

7. The method as recited in claim 5, further comprising the step of receiving from the administrator an administrator ID and persisting the administrator ID and session key pair.

8. The method as recited in claim 7, further comprising the step of de-persisting the administrator ID and session key pair at the end of the requested session.

9. The method as recited in claim 5, wherein the confidential information comprises financial information.

10. The method as recited in claim 5, wherein the confidential information comprises state information.

11. The method as recited in claim 5, wherein the confidential information comprises a JAVA program.

12. A computer-readable medium in an administrator for use in an encrypted message interchange between the administrator and a subscriber connected via a network, the computer-readable medium having instructions for performing the steps comprising: generating a session key in response to each request from the subscriber for a session during which the subscriber desires to receive confidential information from the administrator; signing the session key with a private key of the administrator; encrypting the signed session key with a public key of the subscriber; transmitting to the subscriber the encrypted, signed session key; and in response to a request from the subscriber to receive the confidential information, encrypting a message containing the confidential information with the session key and transmitting the encrypted message to the subscriber where the subscriber will use the transmitted, signed session key to decrypt the message and gain access to the confidential information.

13. The computer-readable medium as recited in claim 12, wherein the instructions are adapted to be run in connection with a Java Virtual Machine.

14. A computer-readable medium in a subscriber for use in an encrypted message interchange between an administrator and a subscriber connected via a network, the computer-readable medium having instructions for performing the steps comprising: requesting the administrator to establish a session during which the subscriber desires to receive confidential information from the administrator; receiving from the administrator a session key that is unique to the requested session, the session key being signed with a private key of the administrator and contained in a message encrypted using a public key of the subscriber; decrypting the message to access the session key; validating the signature of the session key; requesting the administrator to transmit the confidential information; receiving a message from the administrator containing the confidential information, the message being encrypted with the session key; and decrypting the message using the decrypted, validated session key to gain access to the confidential information.

15. The computer-readable medium as recited in claim 14, wherein the instructions are adapted to be run in connection with a Java Virtual Machine.

16. The computer-readable medium as recited in claim 14, further comprising the step of determining if the subscriber has the public key of the administrator and the session key prior to sending the request to receive the confidential information from the administrator.

17. A system for encrypted message interchange between an administrator and a subscriber connected via a network, the system comprising: means for generating a session key in response to each request from the subscriber to establish a session with the administrator during which the subscriber desires to receive confidential information from the administrator; means for signing the session key with a private key of the administrator; means for encrypting the signed session key with a public key of the subscriber; means for transmitting the encrypted, signed session key from the administrator to the subscriber; means for encrypting a message containing the confidential information with the session key and for transmitting the encrypted message from the administrator to the subscriber; and means for decrypting the message transmitted from the administrator to the subscriber using the session key whereby the subscriber gains access to the confidential information.