Cryptographic communication system

Description of equivalent WO 9802989 A1

CRYPTOGRAPHIC COMMUNICATION SYSTEM

BACKGROUND OF THE INVENTION

0003Field of the Invention

0004This invention relates to a cryptographic system for data transmission over a public

0005network, and more particularly to a system which allows parties to send encrypted data

0006messages to one another without key transfer between the parties and without reference to

0007the receiving parties' encryption/decryption protocol

0008Description of the Prior Art

0009There are a number of systems in use which encrypt and decrypt messages transmitted

0010over public networks, such as the internet. In each case some provision must be made for the

0011receiver to get a key to convert the encrypted data There are several prior art approaches

0012to providing a receiving party with a key necessary to decrypt the encrypted message

0013In some conventional cipher systems, both parties must share the same secret key

0014before communications begins; i.e. the sending party has to give his secret key to the receiving

0015party via a secure channel (e.g. a courier) This approach is practical in some situations,

0016particularly where the parties have an established relationship But it is not practical in many

0017other situations, particularly where there are a large number of potential receiving parties with whom the sender does not have an established relation and where the encryption algorithm of the potential receiving parties is unknown to the sender. Then, too, the security of a

0018cryptosystem relies on the secrecy the keys. The more a key is used, the greater the danger

0019of successful attack. For this reason, different session keys are often used for each job. Distribution of session keys is a complex matter. Session keys are usually transmitted encrypted by a master key and often come from a central key distribution center (KDC).

0020Public key, or asymmetric, cryptosystems provide an alternative prior art approach

0021to the key distribution problem. Through the use of public keys, a receiving party can

0022decipher a message without access to the sender's secret key. This allows parties without

0023prior contact to send encrypted messages over the internet, for example, provided both parties are using the same public key protocol. Compared to conventional cryptosystems, public key

0024cryptosystems use large keys and encryption and decryption tend to be slow. A book entitled "Firewalls and Internet Security " by William R. Cheswick and Steven M. Bellovin published

0025by Addison-Wesley Publishing Co., which is incorporated herein by reference, explains in

0026more detail prior art approaches to provide secure communications over insecure networks.

SUMMARY OF THE INVENTION

0028An object of this invention is the provision of a system which allows parties to

0029exchange encrypted messages over a public network, such as the internet, without a

0030requirement to exchange keys and without a requirement that either party know or use an

0031encryption algorithm which is compatible with that used by the other party.

0032Briefly, this invention contemplates the provision of system in which parties have

0033network access to a network secure communications gateway which stores the current encryption/ decryption algorithms and keys for parties registered with the network secure

0034communications gateway. For party A to send an encrypted message to party B, party A

0035encrypts the message using party A's secret key and encryption algorithm, copies of which

0036are stored at the network gateway. Party A sends the encrypted message, addressed to party

0037B, initially to the gateway. The gateway decrypts the message, using party A's secret key and

0038algorithm, and then encrypts the decrypted message using party B's secret key and algorithm.

0039Finally, the gateway forwards the re-encrypted message to party B, where B decodes it using

0040B's secret key and algorithm. The secure communications gateway periodically changes client

0041keys (or algorithms and keys) to provide additional system security.

BRIEF DESCRIPTION OF THE DRA INGS

0043The foregoing and other objects, aspects and advantages will be better understood

0044from the following detailed description of a preferred embodiment of the invention with

0045reference to the drawings, in which:

0046Figure 1 is a functional block diagram of an encryption gateway system in accordance

0047with the teachings of this invention,

0048Figure 2 is a flow chart of the steps for node A (e.g. party A) to send an encrypted

0049message to node B (e.g. party B) via the encryption gateway system of Figure 1.

0050Figure 3 is a flow chart of the operation of the secure communications gateway

0051manager in maintaining a periodically changing encryption/decryption algorithm and/or key

0052for each client. DETAILED DESCRIPTION OF A PREFERRED EMBODIMENT

0053Referring now to Figure 1, in one exemplary embodiment of a cryptographic

0054communications system in accordance with the invention, a node A computer processor,

0055indicated by the dashed box 10, includes application programs for encryption/decryption 12 and a suitable network interface program 14 for coupling the node to a network 16, such as

0056the internet network. As will be appreciated by those skilled in the art, suitable hardware and

0057software programs are available in the prior art to carry out these functions. An advantage

0058of this cryptographic communications system of this invention is that node A's choice of an

0059encryption algorithm is independent of the decryption algorithm used by the intended

0060recipients of node A's encrypted message and need not be known by the intended recipients.

0061In addition, in conventional prior art encryption systems the decryption algorithm is typically an inverse operation of the encryption process. In accordance with the teachings of this

0062invention, if desired, entirely different algorithms could be used by a given node respectively

0063for encoding messages to be placed on the network 16 and for decrypting messages received

0064from the network.

0065In the operation of node A sending an encrypted file to node B over the network 16,

0066A's encryption application program 12 encrypts a clear text file using node A's secret key 20.

0067The encrypted message includes an identifier of node B as the intended recipient, which may

0068be encrypted if desired, an identifier of node A, and the network address of a secure

0069communications encryption gateway 22. The node A identifier may be encrypted if the

0070encryption method for the node A identifier does not require that the identity of node A be

0071known prior to decrypting the identifier. That is, the node A identity may be clear text or may be encoded using a public key algorithm shared by Node A and the gateway 22, for example.

0072The encryption gateway 22 includes a network interface 24, a decryption server 26, an encryption server 28, and an encryption decryption manager 30. The encryption/ decryption program for implementing the encryption/decryption algorithm for each node and

0073the current key for each node recognized by the encryption gateway are stored in files 32 and

007434, respectively, which are accessed by the manager 30. Thus, if nodes A and B are both recognized by the encryption gateway 22, the encryption/decryption algorithm and the key for each node will be stored in files 32 and 34. In response to an incoming encoded data file

0075from node A, the manager 30 will fetch node A's decryption algorithm from file store 32 and

0076the then current key from store 34. The manager 30 loads these files into the decryption server 26, which de-encrypts the incoming encrypted data file, including, if necessary, the

0077identity of the intended recipient, node B. Manager 30 fetches the encryption algorithm and

0078the key for node B, and loads them into the encryption server 28. Decryption server 26

0079decrypts the encrypted message from node A using node A's algorithm and key, and the plain

0080text file is conveniently buffer stored in buffer 36. Encryption server 28 encrypts the plain

0081text file output of server 26 using node B's algorithm and key. The encrypted message file is then launched on to network 16 via the encryption gateway's network interface 24,

0082addressed to node B.

0083Node B, as it pertains to this invention, is functionally equivalent to node A, and includes a network interface server 44, an encryption/decryption server 42 and a current key

0084and algorithm file 48. Different reference numbers have been used for the components of node B to emphasize the fact that, while functionally equivalent, the specific encryption/decryption algorithm(s) and the key may be different as between sending and

0085receiving nodes. As will be appreciated by those skilled in the art, a large number of nodes

0086on the network 16 may be recognized by the encryption gateway 22; these additional nodes are represented in the drawing by the block labeled node n.

0087Figure 2 illustrates as a flow chart the operation of the system described in connection

0088with Figure 1. Node A (a k.a. user A) composes a file for transfer to node B (a.k.a. user B),

0089block 50. The file is transferred to A's network server interface, where a decision (block 51)

0090can be executed to send the file encrypted or plain text, based on A's input. If the result of

0091decision block 51 is not to encrypt, the plain text file is launched on the network (e.g. internet) directly addressed to B, block 52.

0092If the result of decision block 51 is to encrypt, the file is encrypted, block 53, and the

0093encrypted file is launched on the network addressed to the encryption gateway, block 54. At

0094the encryption gateway, the encrypted message is received, and the sender (A) identified,

0095block 56. A's algorithm and current key are loaded into the decryption server (block 57), and

0096the intended recipient (B) of A's message is identified, block 58. The status of B as a client of the encryption gateway is determined in decision block 60.

0097If B is not a client, an error message is sent to A (block 62), preferably an encrypted error. If B is a client, B's algorithm and key are loaded into the encryption server (block 64),

0098the encrypted file is decrypted using A's algorithm and key (block 66) and the decrypted file is re-encrypted using B's algorithm and key, block 68. At block 70, the re-encrypted message

0099is addressed to B and launched on the network. At B, the encrypted file is identified as a file

0100having been sent from the encryption gateway, and the appropriate decryption algorithm and key are used to decrypt the file, block 74. Here it should be noted, a node may have more

0101than one encryption/decryption algorithm and/or more than one key. For example, one algorithm and/or key may be used for exchanging encrypted files with a party or parties with

0102whom the node has a prior relation, and another algorithm and/or key for exchanging

0103encrypted files with the encryption gateway.

0104As will be appreciated by those skilled in the art, the ability of someone to successfully attack a cypher may increase as the number of times the cypher or a particular key for that

0105cypher is used increases. This is particularly true where the encrypted data is transmitted on

0106a public network, such as the internet, to parties with whom the sender may have little or no

0107prior contact. For this reason, the encryption manager 30 is provided with a software routine,

0108as illustrated in Figure 3, which periodically and automatically changes the client encryption key or the client encryption algorithm itself which would, of course, include a new key. The

0109routine starts at decision box 80, which essentially waits for a time when the encryption gateway 22 is idle (free of incoming traffic). If the encryption gateway 22 is idle, the

0110encryption manager 30 selects a client (block 82) from the stored list of clients, preferably

0111using a selection algorithm which makes a more or less random client selection. A new key

0112for the selected client algorithm is generated in block 84, preferably again using a process which randomizes the key generation. Here, it should be noted that if desired, an algorithm different from the selected client's current algorithm could be selected. In the next step 86,

0113the client's current algorithm and key are fetched, and used to encrypt the new key (or

0114algorithm), step 88. The encrypted new key is transmitted to the selected client in step 90, where it is used by the client as a replacement for the client's then currently used key. In block 92, the key store 34 (and algorithm store 32 if desired) is updated by replacing the existing key for the selected client with the new key.

0115While the invention has been described in terms of a single preferred embodiment, those skilled in the art will recognize that the invention can be practiced with modification within the spirit and scope of the appended claims.