WO1999007104A1

WO1999007104A1 - Data security in multipoint publish/subscribe communications

Info

Publication number: WO1999007104A1
Application number: PCT/US1998/016365
Authority: WO
Inventors: Russell E. Selph; Dennis R. Page
Original assignee: Tibco Software, Inc.
Priority date: 1997-08-04
Filing date: 1998-08-04
Publication date: 1999-02-11
Also published as: AU8898698A; JP2001512923A; EP0998801A1; CA2299505A1; WO1999007104B1

Abstract

The method and program product are useful in a publish/subscribe communications system (30), such as one having a publisher (10) and at least one subscriber (20). In the method and program product the encrypted data is published to one or more subscribers (20', 20''). The subscriber attempts decryption but fails to decrypt the data. The method and the program product then initiate a key exchange between the subscriber (20', 20'') and the publisher (10). This results in passing the key and thereafter decrypting the published data.

Description

DATA SECURITY IN MULTIPOINT PUBLISH/SUBSCRIBE COMMUNICATIONS

BACKGROUND OF THE INVENTION

Technical Field

This invention relates to multipoint publish/subscribe communications and, more particularly, to secure encrypted communications between computer-based publisher and subscriber applications in a publish/subscribe communications system.

Background

It is well known that today's electronic communication environment needs secure communications. This need has led to the coding or encryption of electronic communications. Many encryption algorithms have been proposed and are in use. Probably one of the best known algorithms is the Diffie-Hellman key exchange protocol that allows two parties to establish a shared secret over a public channel. The Diffie-Hellman protocol is based on a "public key" technology relying on the difficulty of reversing an exponentiation function in modular arithmetic. A description of the Diffie-Hellman key exchange protocol can be found in numerous sources. See, for example, Applied Cryptography, Second Edition, by Bruce Schneier, section 22.1. (ISBN 0-471-11709-9).

One of the main problems with current encrypted (secret) electronic communications, however, is that these communications are all point-to-point. Point-to-point communications are basically single source to single receiver communications in which both parties (source and receiver) require advance knowledge of the other party. At a minimum, this is usually the address of the other party and some knowledge of the encryption key used by the other party. Thus, a sender "gives" one half of the key to the receiver and, at a later stage and independent of the giving of the key, encrypts a communication (electronic message) and sends that encrypted message to the receiver. The receiver then decrypts the received message by using the previously received key. This traditional, point-to-point communication has significant disadvantages. One of the primary being is that the advance knowledge of the parties make conventional encryption products technological solutions inappropriate in anonymous publish/subscribe environments.

In a typical anonymous publish/subscribe technologies ~ such as described in US patents 5,557,798; 5,339,392; 5,257,369 and 5,187,787 - a publisher application publishes information to requesting or subscriber applications without having any knowledge of the number, identity or address of any such subscriber applications. In fact, no subscriber applications may exist. Instead of knowing about subscribers, a publisher will merely publish information applying a context or subject "label" to the published message. A subscriber then identifies desired messages by the content label and receives only those messages relevant to the desired content.

Publish/subscribe interactions are event-driven rather than demand-driven. In this paradigm, producers (also called publishers) disseminate data to multiple consumers (also called subscribers). Publish/subscribe interactions are driven by events (usually the arrival or creation of data) in a producer. Consumers place a standing request for data by subscribing, but publishing events are independent of subscriptions. Communication is in one direction only, and is often one-to-many. Example applications include:

Securities data feed handlers publish the latest stock prices to hundreds of traders on a trading floor simultaneously; Materials movement systems distribute data to various materials handlers, controllers and tracking systems on a factory floor;

Inventory levels flow continuously to accounting, purchasing, marketing and other departments in a retail store;

A publish/subscribe interaction consists of only one broadcast message. A subscription is an implicit request for messages. In publish/subscribe interactions producers are decoupled from consumers-they do not coordinate data transmission with each other. Producers publish data to the network at large. Consumers can receive messages with any subject names. Any application can be both a producer and a consumer.

This event-driven paradigm is a natural and efficient style of computing for many applications, including data warehousing, Internet mirrors, incremental schedulers, just-in-time inventory management, real-time decision support, and data monitoring applications. Event-driven computing is emerging as a dominant paradigm for many business applications.

The advantages of such a publish subscribe, content-based addressing systems are well known and include the ability to totally decouple subscribers and publishers from one another. This decoupling allows publishers and subscribers to operate without having any knowledge of the identity, location or address, or communication protocols of each other. The flexibility that this offers is enormous and, accordingly, such content/subject-based addressing communication-environments are becoming increasingly popular. Unfortunately, the very advantages (such as anonymous decoupling) of these systems, precludes the use of conventional "knowledge based" encrypted messaging protocols; protocols that require advanced knowledge between applications. Thus, a very real need exits for having both the advantage of encrypted messaging and the advantages of content-based, anonymous publish/subscribe environments.

Similar comments apply to "broadcast" and "bulletin-board" communication environments. In "broadcast" environments all applications receive every message published by every application. Thus, it is not necessary for publishers to know the identity of subscribers. In "bulletin-board" environments, subscribers access or join a "bulletin-board" type of environment to which messages are posted by a publisher. In these environments, the publisher does not necessarily know individual subscribers' addresses but, at a minimum, must know the address and/or other details of the bulletin-board. Moreover, it is frequently necessary or desirable to send encrypted data from publisher to subscriber, especially in the case of personal and privileged information, as well as financial information.

Whatever the case, however, both the broadcast and bulletin approaches to messaging do not readily lend themselves to encrypting messaging primarily because of a degree of anonymity between publisher and subscriber (sender or receiver). Thus, these environments also present a obstacle to the implementation of encrypted messaging.

SUMMARY OF THE INVENTION

Briefly, therefore, this invention provides for secure/encrypted messaging that is applicable to point-to-point as well as other environments such as anonymous content-based, publish/subscribe, broadcast and bulletin board environments.

Generally, our invention is a method of and a program product for publishing encrypted data in a publish/subscribe communications system having a publisher and at least one subscriber (and preferably more). The method includes the steps of initiating a key exchange between the subscriber and the publisher, publishing encrypted data to a subscriber; and thereafter decrypting the published data.

In one embodiment, a publisher publishes an encrypted message with an identifying "tag" or "label" and the address of a publisher-side encrypting/decrypting "responder." This message is sent over conventional data communications channels in a computer network and is received by a subscriber — having identified the message by its "tag" or "label" — who then attempts to read the message.

As the message is encrypted, the subscriber cannot read it, so the unread, encrypted message is sent to a subscriber-side encrypting/decrypting responder associated with the subscriber. The subscriber responder realizes that the message is encrypted and, using the publisher responder address attached to the encrypted message, sends a message to the publisher-side responder. As will be described more fully herein below, when a subscriber receives it's first message from a given publisher, it will attempt to decrypt it, but will get a "not enough info" error. In response to this error, the subscriber will initiate a key exchange with the responder specified in the message. Once the key exchange is complete, the subscriber will be able to decrypt incoming data from the publisher, and can optionally now decrypt the original message that initiated the exchange. Once a key exchange has taken place, all subsequent messages from the publisher can be decrypted as they are received.

According to a still further embodiment, our invention can be used for authentication only. When used only to authenticate messages, and not to encrypt them, many parts of the protocol are simplified. For instance, a full key-exchange requires two complete turn-arounds on the network (four messages). When authenticating a message only, it may only be required to get a certificate from the sender. This is accomplished in one turnaround (two messages). Similarly, if a publisher decides to publish its certificate along with the data stream, then subscribers can verify the identity of the sender without any interactions at all.

The encrypted message can be sent along non-data communication paths, using instead a more secure path. The subscriber responder acknowledges receipt of the originally encrypted message and starts the process of confirmed and verified message exchanges using and receiving/checking a series of digital signatures. This process leads to the subscriber receiving the key to decipher the originally encrypted message and, in most cases, subsequent messages from the same publisher.

Advantages of the Invention

This inventive process has a number of advantages. It provides secure communications in multipoint environments by allowing communicating applications to authenticate messages by creating and checking digital signatures. It does this through two major functions:

(i) using message encryption and decryption functions; functions that operate on messages and create and verify signatures; and (ii) using key and certificate exchange protocol; a protocol that employs messaging to securely exchange key information between publishers and subscribers.

A further advantage is that either or both endpoints can be anonymous ~ an endpoint that does not have a private key corresponding to a certificate is considered anonymous ~ although for maximum security this may not be appropriate.

Yet another advantage is that the invention imposes very little policy as to the actual encryption and signing algorithms used, or the key lengths employed. Thus algorithms can be added without changing any of the message formats.

In summary, the invention goes beyond the functionality of SSL (the Secure Socket Layer protocol originally proposed by Netscape). Whereas SSL implements the semantics of a TCP socket, with two endpoints and a continuous byte stream of data, this invention allows publish/subscribe semantics to be implemented, with many endpoints and discrete messages.

The invention will be described in greater detail below with reference to the accompanying drawing.

DESCRIPTION OF THE DRAWING

In the attached drawing:

Figure 1 is a schematic representation of a typical publish subscribe environment illustrating the messages flow in the protocol of the invention.

DEFINITIONS

Before describing the invention in greater detail, it is necessary to define certain terms used in this application:

Asymmetric Encryption Asymmetric encryption involves the use of two keys, one public and one private. The public key is derived from the private key, and can be distributed to anyone. Data encrypted with the public key can only be decrypted with the private key, and vice versa. This is especially useful for applications like secure e-mail: a message is encrypted with the recipients public key, and no one (except the owner of the private key) can decrypt it.

Digital Signatures

Digital signatures are a special application of asymmetric encryption. A hash or 'fingerprint' of the message is calculated using a one-way hash function. The signer then encrypts this hash with a private key. This encrypted hash value is the signature. Any one can verify the signature by decrypting the signature with the signer's public key, and comparing it with a hash of the message that they calculated themselves.

Identity and Certificates

Certificates provide a reasonably secure mechanism for verifying identity in a distributed and scaleable way. A Certificate Authority signs copies of everyone's public keys, and makes these signed keys publicly available. The CA also makes available a copy of its own public key. Client programs need only keep a copy of the CA's public key in order to verify any certificate they receive.

Message Authentication Codes (MACs)

Message Authentication Codes (MACs) are often used in lieu of true digital signatures. It requires much less computation to generate them, so they are preferred in any protocol that may need to support a high data rate. The disadvantage of MACs is that they require the sender and receiver to have a shared secret (the MAC key or MAC code).

One-way Hash Functions A one-way hash function is much like a check-sum. The difference is that it is very difficult to 'invent' two messages that hash to the same value.

Symmetric Encryption Symmetric encryption is the most basic form of encryption. A secret key is used to obscure data in such a way that it cannot be recovered without knowing the secret key. This form of encryption is generally faster to perform on a large block of data than asymmetric encryption.

SPECIFIC DESCRIPTION

In Figure 1 a publisher application 10 and a plurality of subscriber applications 20, 20' and 20" are shown. In the preferred embodiment of this invention the publisher and subscriber(s) are software applications based on one or more computers interconnected by a network providing a data path among the applications. The publisher 10 and subscriber(s) 20 preferably implement a content-based communications protocol whereby a publisher publishes a message indicating only the content of the message and without knowing the identity or protocols used by the subscriber(s) 20. These inter-application communications are established by communications daemons not shown in Fig. 1, but are well known in the art and described in many publications including the patents referred to above.

Associated with both the publisher 10 and the subscriber 20 is a software object or data structure called a responder, 12 and 22 respectively. Each responder 12, 22 is a single encrypting or decrypting entity. Each responder also is responsible for keeping one key for data encryption and one key for signature creation.

Responders can have a definite identity, or they can be anonymous. In order to have an identity, the responder must have both a certificate, and the private key corresponding to that certificate's public key. In contrast, anonymous responders are useful for situations in which it is impractical for the endpoint code to obtain a private key without revealing it to adversaries.

As will be explained in more detail below, the responders 12, 22 send messages to each other in order to accomplish key exchanges. These messages are encrypted using keys established via the Diffie-Hellman key exchange protocol. The Diffie-Hellman key exchange protocol is described by Schneier, above. As described by Schneier, Diffie-Hellman gets its security from the difficulty of calculating discrete logarithms in a finite field, as compared with the ease of calculating exponentiation in the same field. Diffie-Hellman can be used for key distribution — For example, A and B can use this algorithm to generate a secret key — but it cannot be used to encrypt and decrypt messages.

In implementing Diffie-Hellman, A and B and Bob agree on a large prime, n and g, such that g is primitive mod n. These two integers don't have to be secret; thus, A and B can agree to them over some insecure channel. They can even be common among a group of users. Then, the protocol goes as follows:

(1) A chooses a random large integer x and sends B X- g^x XΑoά n (2) B chooses a random large integer y and sends A

Y= g! mod n

(3) A computes k = T mod n

(4) B computes k' =X od. n

Both k and k' are equal to g ³' mod n. No one listening on the channel can compute that value; they only know n, g, X, and Y. Unless they can compute the discrete logarithm and recover x or , they do not solve the problem. So, k is the secret key that both A and B computed independently.

The choice of g and n can have a substantial impact on the security of this system. The number (n - l)/2 should also be a prime. And most important, n should be large: The security of the system is based on the difficulty of factoring numbers the same size as n. You can choose any g, such that g is primitive mod n; there's no reason not to choose the smallest g you can — generally a one-digit number. (And actually, g does not have to be primitive; it just has to generate a large subgroup of the multiplicitive group mod n.) As a first step in the overall process, the publisher 10 has a message to be encrypted. To encrypt a message for publishing, an encrypt function is called with the message and the responder 12 as parameters. The responder 12's encryption key is used to encrypt the data and its private key to sign the data.

It should be noted that a publisher 10 has great flexibility to assign responders to published subjects. A single responder can be used for all messages published by the publisher 10, or a responder can be created for each subject published. As one responder corresponds to one encryption key, partitioning of security is determined by the mapping of responders to subjects. The best choice will vary according to the security needs of the publisher 10.

The encrypted message is then published (shown schematically as 30) on the normal data communications channel of the network. Typically, the message will take the form of subj,resp [xxxxxj in which subj indicates the content/subject of the message; resp indicates the encrypting respondent 12 address; and [xxxxxj is the now-unreadable, encrypted message.

Also, the encrypted message 30 would include the responder 12's Diffie-Hellman half- value DH-x and generically include information of the form E_κ {M, MIC} in which

E_K is an encryption key;

Mis the encrypted message; and

MIC is a message internal code typically including a hash function as follows:

h (M, Source, Sequence #, delivery information) This hash function will include a "signature" if authentication is required. Thus all hash functions are signed in authenticated communications.

Each subscriber 20, 20', 20" listens for and accesses messages based on the message its content/subject in the normal way. When the message is received, however, it is unreadable and is therefore passed to the appropriate subscriber-side responder 22.

The subscriber-side responder 22 then responds by communicating with the publisher- side responder 12 by way of a MAC-based message 32 to the address (resp) identified in the original message 30. This message 32, amongst other things, is the start of a message decrypt function and typically takes the format:

SMAC (sub_ resp; DH-y; E_KE fri; signature Jnfo}) in which sub resp is the subscriber-side responder 22's address; DH-y is responder 22's Diffie-Hellman half- value; rj is a first random number; and signature Jnfo is a request for signature information/signed message.

The publisher side responder 12 responds with a fully signed message 36 of the form: SFULL (pub resp; EKE {^2,' r;; signature; signature Jnfo}) in which pub_resp is the publisher-side responder 12's address; r_/ is an echo of the first random number; r₂ is a second random number; signature is responder 12's signature; and signature Jnfo is a request for signature information/a signed message from responder 22.

When the subscriber-side responder 22 receives this message 36, it calls back to the subscriber 20 (shown by arrow 38) to get the subscriber 20's approval. Once this approval is received, the responder 22 calls back to responder 12 with a fully signed message 40 of the form:

S_FULL (sub resp; E_KE {^2,' r^, signature; key request}) in which sub_resp is the subscriber-side responder 22's address; r₂ is an echo of the second random number; r₃ is a third random number; signature is responder 22's signature; and key request is a request for the key to decipher the encrypted message and it could include a data payload from the subscriber.

When the publisher-side responder 12 receives this message 40, it responds to the publisher 10 (shown by arrow 42) to get publisher 10 approval to transmit the key. Once this approval is received, the responder 12 calls back to responder 22 with MAC message 44 incorporating the encryption key as follows:

SMAC (pubjesp; E_KE {r₄; r₃; key_grant}) in which pub resp is the publisher-side responder 12's address; r₃ is an echo of the third random number; r₄ is a fourth random number; and key grant is the requested decryption key and could include a datapayload from the publisher.

For all these communications when a challenge value, that is, a random number, is sent by a responder 12, 22, it must be returned with additional information and a signature before the identity of the remote end is trusted. It is for similar reasons that the random numbers are echoed except that challenge values require signatures (at a minimum) in response while random number echoes are not always accompanied by signatures. Thus, only when identity of both parties has been established securely, a key request can be sent.

Thus responders 12 and 22 communicate with each other to accomplish key exchanges. The Diffie-Hellman protocol is used to establish a secure channel between the responders for the duration of the negotiation. The actual protocol used is similar to the station-to-station protocol which is based on Diffie-Hellman. In most cases the entire exchange, including the transmission of key values, is accomplished in two turn-arounds (a total of four messages).

When satisfying a key request, the default behavior is to supply the most current key value. However, responders may cache old key values, and if asked for the key corresponding to a message with an old sequence number, will send the older key value.

The protocol of the invention allows the publisher to choose algorithms for both encrypting and signing data and a algorithms can be "plugged in" to any API incorporating this invention. The choice of algorithm is usually a trade-off between efficiency and security.

For encryption, a publisher can use any symmetric algorithm. Furthermore, many algorithms exist, offering varying key lengths and encryption speeds. For signing, the publisher must choose between an asymmetric algorithm, such as RSA or El-Gamal encryption, or using a MAC for authentication. The most secure choice is to use an asymmetric algorithm, with a certified copy of the public key. This allows recipients of the message to definitely verify the origin of the message.

However, for some applications this level of security may be burdensome in terms of compute time or inconvenience. In these cases a MAC is more appropriate, since it is quick to compute and imposes no administrative overhead. However, since the publisher must share its MAC secret with all subscribers, each subscriber will then be able to impersonate the publisher.

Although not illustrated in the above message formats, all messages contain a sequence number in order to prevent replay attacks. If a message is received with an old sequence number it is flagged to the application as a potential replay. This is to prevent adversaries from grabbing whole, encrypted packets from the network and simply 'replaying' them at a later time. There is nothing built into the protocol that requires the responder that satisfies a key request to be the same one that is used for publishing. As long as the two responders have the same key data, everything works fine. What this means is that it is possible to set up "key servers" which deal with key requests in a more distributed fashion. Of course, the key server must be synchronized with the key information used by the publisher.

The above describes a publish/subscribe scenario. In this scenario subscribers typically receive the first message from a given publisher before they can begin the key exchange protocol. This is because the responder address is embedded in the message stream itself.

As described above, when a subscriber receives it's first message from a given publisher, it will attempt to decrypt it, but will get a "not enough info" error. In response to this error, the subscriber will initiate a key exchange with the responder specified in the message. Once the key exchange is complete, the subscriber will be able to decrypt incoming data from the publisher, and can optionally now decrypt the original message that initiated the exchange. Once a key exchange has taken place, all subsequent messages from the publisher can be decrypted as they are received.

This invention does, however, have broader implementation. For example, when the invention is used in a remote procedure call scenario, the request is usually published to a broadcast subject, and the reply information is returned to the publisher. In this situation, the servers are acting as subscribers in the previous scenario. The first time a message is received from a given client, the server must initiate a key exchange with that client. Once the key exchange is complete, the server can process the client message.

In addition, as far as the invention is concerned, point to point messages behave exactly as published messages.

Finally, this invention can be used for authentication only. When used only to authenticate messages, and not to encrypt them, many parts of the protocol are simplified. For instance, a full key-exchange requires two complete turn-arounds on the network (four messages). When authenticating a message only, it may only be required to get a certificate from the sender. This is accomplished in one turnaround (two messages). Similarly, if a publisher decides to publish its certificate along with the data stream, then subscribers can verify the identity of the sender without any interactions at all.

All publications and patent applications mentioned in this specification are herein incorporated by reference to the same extent as if each individual publication or patent application was specifically and individually indicated to be incorporated by reference.

The invention now being fully described, it will be apparent to one of ordinary skill in the art that many changes and modifications can be made thereto without departing from its spirit or scope.

Claims

We claim:

1. A method of publishing encrypted data in a publish/subscribe communications system comprising a publisher and at least one subscriber, said method comprising the steps of: a) publishing encrypted data to a subscriber; b) attempting decryption at the subscriber; c) failing to decrypt the data at the subscriber; d) initiating a key exchange between the subscriber and the publisher; and e) thereafter decrypting the published data.

2. The method of claim 1 wherein said publisher is a software application program.

3. The method of claim 2 wherein said subscriber is a software application program.

4. The method of claim 3 wherein said publisher software program and said subscriber program are software programs running on computers interconnected by a network providing a datapath among the software programs.

5. The method of claim 4 comprising using communications daemons to establish communications between between said publisher software program and said subscriber program software programs running on said computers.

6. The method of claim 4 wherein said publisher software program and said subscriber program each further contain a software object responder.

7. The method of claim 6 wherein said software object responder is a single cryptographic entity keeping a cryptographic key and a signature key.

8. The method of claim 6 wherein at least one of said software object responders has an identity, a certificate, and a private key, said private key corresponding to a public key of the certificate.

9. The method of claim 1 comprising exchanging keys between the publisher and the subscriber using keys established using a Diffie-Hellmann key exchange protocol..

10. The method of claim 9 comprising the publisher publishing a message to be encrypted, encrypting the message using an encryption key, and signing the data with a private key.

11. The method of claim 10 wherein the subscriber receives an encrypted message from the publisher, and responds thereto by sending a second message addressed to the publisher, said second message including the subscriber's address, a Diffie-Hellmann half value, and a first random number.

12. The method of claim 11 wherein the second message further includes a challenge value.

13. The method of claim 11 wherein the second message further includes a request for signature information.

14. The method of claim 12 wherein said publisher responds to the said second message with a third message, said third message including an echo of the first random number, a second random number, a response to the challenge value, the challenge number, the responder' s signature, and a request for signature information from the subscriber.

15. The method of claim 14 wherein the subscriber responds to the third message with a fourth message including the subscriber's address, an echo of the second random number, a third random number, a challenge response to the publisher's challenge, the subscriber's signature, and a key request.

16. The method of claim 15 wherein the publisher responds with a fifth message including the key.

17. The method of claim 16 wherein the fifth message further includes the publisher's address, an echo of the third random number, and a fourth random number.

18. An article of manufacture comprising: computer readable program code for publishing encrypted data in a publish/subscribe communications system having a publisher and a subscriber, the computer readable program in said article of manufacture comprising: a) a computer readable medium having computer readable program code embodied therein for causing a computer to effect publishing encrypted data to a subscriber; b) computer readable program code for causing a computer to effect attempting decryption at the subscriber; c) computer readable program code for causing a computer to effect failing to decrypt the encrypted data at the subscriber; d) computer readable program code for causing a computer to effect initiating a key exchange between the subscriber and the publisher; and e) computer readable program code for causing a computer to effect decryption of the published data at the subscriber.

19. The article of manufacture of claim 18 wherein said article of manufacture further comprises said publisher software program and said subscriber program are software programs running on computers interconnected by a network providing a datapath among the software programs.

20. The article of manufacture of claim 19 further comprising communications daemons to establish communications between said publisher software program and said subscriber program software programs running on said computers.

21. The article of manufacture of claim 19 wherein said publisher software program and said subscriber program each further contain a software object responder.

22. The article of manufacture of claim 21 wherein said software object responder is a single cryptographic entity keeping a cryptographic key and a signature key.

23. The article of manufacture of claim 22 wherein at least one of said software object responders has an identity, a certificate, and a private key, said private key corresponding to a public key of the certificate.

24. The article of manufacture of claim 18 further comprising computer readable program code for effecting exchanging keys between the publisher and the subscriber using keys established using a Diffie-Hellmann key exchange protocol..

25. The article of manufacture of claim 24 further comprising computer readable program code for effecting the publisher publishing a message to be encrypted, encrypting the message using an encryption key, and signing the data with a private key.

26. The article of manufacture of claim 25 further comprising program code for effecting the subscriber receiving an encrypted message from the publisher, and responding thereto by sending a second message addressed to the publisher, said second message including the subscriber's address, a Diffie- Hellmann half value, and a first random number.

27. The article of manufacture of claim 26 further comprising program code incorporating a challenge value into the second message.

28. The article of manufacture of claim 23 further comprising program code for incorporating a request for signature information into the second message.

29. The article of manufacture of claim 27 further comprising program code for effecting said publisher responding to the said second message with a third message, said third message including an echo of the first random number, a second random number, a response to the challenge value, the challenge number, the responder' s signature, and a request for signature information from the subscriber.

30. The article of manufacture of claim 29 further comprising program code for the subscriber responding to the third message with a fourth message including the subscriber's address, an echo of the second random number, a third random number, a challenge response to the publisher's challenge, the subscriber's signature, and a key request.

31. The article of manufacture of claim 30 further comprising program code for effecting the publisher responding with a fifth message including the key.

32. The article of manufacture of claim 31 further comprising program code for effecting the fifth message further including the publisher's address, an echo of the third random number, and a fourth random number.

33. A method of publishing encrypted data in a publish/subscribe communications system comprising a publisher and at least one subscriber, said method comprising the steps of: a) initiating a key exchange between the subscriber and the publisher; b) publishing encrypted data to a subscriber; and c) thereafter decrypting the published data.

34. The method of claim 33 wherein said publisher is a software application program.

35. The method of claim 34 wherein said subscriber is a software application program.

36. The method of claim 35 wherein said publisher software program and said subscriber program are software programs running on computers interconnected by a network providing a datapath among the software programs.

37. The method of claim 36 comprising using communications daemons to establish communications between said publisher software program and said subscriber program software programs running on said computers.

38. The method of claim 36 wherein said publisher software program and said subscriber program each further contain a software object responder.

39. The method of claim 38 wherein said software object responder is a single cryptographic entity keeping a cryptographic key and a signature key.

40. The method of claim 38 wherein at least one of said software object responders has an identity, a certificate, and a private key, said private key corresponding to a public key of the certificate.

41. The method of claim 33 comprising exchanging keys between the publisher and the subscriber using keys established using a Diffie-Hellmann key exchange protocol.

42. The method of claim 41 comprising the publisher publishing a message to be encrypted, encrypting the message using an encryption key, and signing the data with a private key.

43. An article of manufacture comprising: computer readable program code for publishing encrypted data in a publish/subscribe communications system having a publisher and a subscriber, the computer readable program in said article of manufacture comprising: a) computer readable program code for causing a computer to effect initiating a key exchange between the subscriber and the publisher; b) a computer readable medium having computer readable program code embodied therein for causing a computer to effect publishing encrypted data to a subscriber; and c) computer readable program code for causing a computer to effect decryption of the published data at the subscriber.

44. The article of manufacture of claim 43 wherein said article of manufacture further comprises said publisher software program and said subscriber program are software programs running on computers interconnected by a network providing a datapath among the software programs.

45. The article of manufacture of claim 44 further comprising communications daemons to establish communications between said publisher software program and said subscriber program software programs running on said computers.

46. The article of manufacture of claim 44 wherein said publisher software program and said subscriber program each further contain a software object responder.

47. The article of manufacture of claim 46 wherein said software object responder is a single cryptographic entity keeping a cryptographic key and a signature key.

48. The article of manufacture of claim 47 wherein at least one of said software object responders has an identity, a certificate, and a private key, said private key corresponding to a public key of the certificate.

49. The article of manufacture of claim 43 further comprising computer readable program code for effecting, exchanging keys between the publisher and the subscriber using keys established using a Diffie-Hellmann key exchange protocol..

50. The article of manufacture of claim 49 further comprising computer readable program code for effecting the publisher publishing a message to be encrypted, encrypting the message using an encryption key, and signing the data with a private key.