CA2299505A1 - Data security in multipoint publish/subscribe communications - Google Patents
Data security in multipoint publish/subscribe communications Download PDFInfo
- Publication number
- CA2299505A1 CA2299505A1 CA002299505A CA2299505A CA2299505A1 CA 2299505 A1 CA2299505 A1 CA 2299505A1 CA 002299505 A CA002299505 A CA 002299505A CA 2299505 A CA2299505 A CA 2299505A CA 2299505 A1 CA2299505 A1 CA 2299505A1
- Authority
- CA
- Canada
- Prior art keywords
- subscriber
- publisher
- message
- key
- article
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
- 238000004891 communication Methods 0.000 title claims abstract description 39
- 238000000034 method Methods 0.000 claims abstract description 38
- 230000004044 response Effects 0.000 claims description 7
- 230000000977 initiatory effect Effects 0.000 claims description 5
- 238000004519 manufacturing process Methods 0.000 claims 25
- 230000000694 effects Effects 0.000 claims 8
- 230000008901 benefit Effects 0.000 description 7
- 230000003993 interaction Effects 0.000 description 6
- 230000008569 process Effects 0.000 description 5
- 230000005540 biological transmission Effects 0.000 description 2
- 238000005516 engineering process Methods 0.000 description 2
- 239000000463 material Substances 0.000 description 2
- 101150105133 RRAD gene Proteins 0.000 description 1
- 238000013459 approach Methods 0.000 description 1
- 238000002592 echocardiography Methods 0.000 description 1
- 239000006260 foam Substances 0.000 description 1
- 238000007726 management method Methods 0.000 description 1
- 238000013507 mapping Methods 0.000 description 1
- 230000007246 mechanism Effects 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 238000012544 monitoring process Methods 0.000 description 1
- 238000000638 solvent extraction Methods 0.000 description 1
- 230000001360 synchronised effect Effects 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
- H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
- H04L9/0838—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these
- H04L9/0841—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these involving Diffie-Hellman or related key agreement protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer And Data Communications (AREA)
- Mobile Radio Communication Systems (AREA)
- Telephonic Communication Services (AREA)
- Storage Device Security (AREA)
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
wo 99romo4 pcTius~t~s DATA SECURITY IN MULTIPOINT PUBLISH/SUBSCRIBE
- COMMUNICATIONS
BACKGROUND OF THE INVENTION
S
Technical Field -This invention relates to multipoiat publish/subscribe communications and, more particularly, to secure encrypted communications between computer-based publisher and subscriber applications in a publish/subscribe communications system.
IO
Backgrnaad 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.
15 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 exponrntiation function in modular arithmetic. A
description of the Lie-Hellman key exchange protocol can be found in numerous 20 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 25 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 sander "gives" one half of the key to the receiver and, at a later stage and independent of the giving of the 30 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 publishlsubscribe environments.
In a typical anonymous publishlsubscribe 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/subseribe 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.
- COMMUNICATIONS
BACKGROUND OF THE INVENTION
S
Technical Field -This invention relates to multipoiat publish/subscribe communications and, more particularly, to secure encrypted communications between computer-based publisher and subscriber applications in a publish/subscribe communications system.
IO
Backgrnaad 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.
15 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 exponrntiation function in modular arithmetic. A
description of the Lie-Hellman key exchange protocol can be found in numerous 20 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 25 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 sander "gives" one half of the key to the receiver and, at a later stage and independent of the giving of the 30 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 publishlsubscribe environments.
In a typical anonymous publishlsubscribe 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/subseribe 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 effrcient 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 s~h 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 enonmous 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.
This event-driven paradigm is a natural and effrcient 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 s~h 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 enonmous 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.
Briefly, therefore, this invention provides for securelencrypted 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 rrad 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.
WO 9910'1104 PCTNS98It6365 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-grounds 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.
Advantstges of the Invention This inventive process has a number of advantages. It provides secure ' communications in rriultipoint 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 5.
WO y9~p71p4 PCTNS98/16365 (ii) using key and certificate exchange protocol; a protocol that employs messaging to securely- exchange key information between publishers and subscribers.
S 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 sumrnaty, 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:
Asyrurnetric Encryption WO 99/07101 PCf/US98/16365 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 7.
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 subscribers) are soRwate applications based on one or more computers interconnected by a network providing a data path among the applications. 'The publisher 10 aad subscribers) 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 subscribers) 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 conresponding 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 reveaiing 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 Dike-Hellman key exchange protocol.
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.
Briefly, therefore, this invention provides for securelencrypted 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 rrad 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.
WO 9910'1104 PCTNS98It6365 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-grounds 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.
Advantstges of the Invention This inventive process has a number of advantages. It provides secure ' communications in rriultipoint 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 5.
WO y9~p71p4 PCTNS98/16365 (ii) using key and certificate exchange protocol; a protocol that employs messaging to securely- exchange key information between publishers and subscribers.
S 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 sumrnaty, 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:
Asyrurnetric Encryption WO 99/07101 PCf/US98/16365 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 7.
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 subscribers) are soRwate applications based on one or more computers interconnected by a network providing a data path among the applications. 'The publisher 10 aad subscribers) 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 subscribers) 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 conresponding 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 reveaiing 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 Dike-Hellman key exchange protocol.
8.
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 Diffe-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= gx mod n (2) B chooses a random large integer y and sends A
Y=g''modn (3) A computes k = Y' mod n (4) B computes k' = X'' mod 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 y, 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 -1 ~2 should also be a prime. And most important, n should be large:
The security of the system is based on the diff culty 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 aad 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 ~x~J
in which subj indicates the contentlsubject of the message;
resp indicates the encrypting respondent 12 address; and (x~aiooicJ is the now-unreadable, encrypted message.
Also, the encrypted message 30 would include the responder 12's Diffe-Hellman half value DH-x and generically include information of the foam Ex (M, MIC) in which E,r is an encryption key;
M is the encrypted message; and MIC is a message internal code typically including a hash function as follows:
h (M, Source, Seguence #, delivery information) , CA 02299505 2000-02-04 W O 99/0? 104 PCTNS98/16365 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 contentlsubject 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:
S,,t,,~ (sub resp; DH y; E,~ (r~; signature injo)) in which sub resp is the subscriber-side responder 22's address;
DH y is responder 22's Diffie-Hellman half value;
r, is a first random number, and signature info is a request for signature informationlsigned message.
The publisher side responder 12 responds with a fully signed message 36 of the form:
SF~Ly (pub resp; E,~ (r1; r~; signature; signature in, fo)) in which pub resp is the publisher-side responder 12's address;
r~ is an echo of the first random number;
r1 is a second random number;
signature is responder 12's signature; and signature info is a request for signature informationla 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:
SFUU (sub resp; ExE /r?; r3; signature; key request)) in which sub resp is the subscriber-side responder 22's address;
r1 is an echo of the second random number;
r j is a third random number;
signature is responder 22's signature; and Arey 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 bank to responder 22 with MAC
message 44 incorporating the encryption key as follows:
S,,u~ (pub resp; E~ (r,; rj; keyJgrant)) ' in which pub resp is the publisher-side responder 12's address;
r3 is an echo of the third random number;
r, is a fourth random number; and ~Eey~rant 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-Helhnan 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 WO 9910'f104 PC'fNS98116365 cases the entire exchange, including the transmission of key values, is accomplished in two turn-grounds (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 tn~de-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 E1-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 tharis used for publishing. As long as-xhe 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-grounds 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.
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 Diffe-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= gx mod n (2) B chooses a random large integer y and sends A
Y=g''modn (3) A computes k = Y' mod n (4) B computes k' = X'' mod 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 y, 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 -1 ~2 should also be a prime. And most important, n should be large:
The security of the system is based on the diff culty 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 aad 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 ~x~J
in which subj indicates the contentlsubject of the message;
resp indicates the encrypting respondent 12 address; and (x~aiooicJ is the now-unreadable, encrypted message.
Also, the encrypted message 30 would include the responder 12's Diffe-Hellman half value DH-x and generically include information of the foam Ex (M, MIC) in which E,r is an encryption key;
M is the encrypted message; and MIC is a message internal code typically including a hash function as follows:
h (M, Source, Seguence #, delivery information) , CA 02299505 2000-02-04 W O 99/0? 104 PCTNS98/16365 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 contentlsubject 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:
S,,t,,~ (sub resp; DH y; E,~ (r~; signature injo)) in which sub resp is the subscriber-side responder 22's address;
DH y is responder 22's Diffie-Hellman half value;
r, is a first random number, and signature info is a request for signature informationlsigned message.
The publisher side responder 12 responds with a fully signed message 36 of the form:
SF~Ly (pub resp; E,~ (r1; r~; signature; signature in, fo)) in which pub resp is the publisher-side responder 12's address;
r~ is an echo of the first random number;
r1 is a second random number;
signature is responder 12's signature; and signature info is a request for signature informationla 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:
SFUU (sub resp; ExE /r?; r3; signature; key request)) in which sub resp is the subscriber-side responder 22's address;
r1 is an echo of the second random number;
r j is a third random number;
signature is responder 22's signature; and Arey 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 bank to responder 22 with MAC
message 44 incorporating the encryption key as follows:
S,,u~ (pub resp; E~ (r,; rj; keyJgrant)) ' in which pub resp is the publisher-side responder 12's address;
r3 is an echo of the third random number;
r, is a fourth random number; and ~Eey~rant 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-Helhnan 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 WO 9910'f104 PC'fNS98116365 cases the entire exchange, including the transmission of key values, is accomplished in two turn-grounds (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 tn~de-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 E1-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 tharis used for publishing. As long as-xhe 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-grounds 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 (46)
1. A method of publishing encrypted data between a plurality of computers interconnected by a network providing a datapath therebetween in a publish/subscribe communications system comprising a publisher and at least one subscriber interconnected by said network, said method comprising the steps of:
a) publishing encrypted data over said network 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 across the network using a Diffie-Hellmann key exchange protocol; and e) thereafter decrypting the published data at the subscriber.
a) publishing encrypted data over said network 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 across the network using a Diffie-Hellmann key exchange protocol; and e) thereafter decrypting the published data at the subscriber.
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 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 the publisher publishing a message to be encrypted, encrypting the message using an encryption key, and signing the data with a private key.
10. The method of claim 9 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.
11. The method of claim 10 wherein the second message further includes a challenge value.
12. The method of claim 10 wherein the second message further includes a request for signature information.
13. The method of claim 11 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.
14. The method of claim 13 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.
15. The method of claim 14 wherein the publisher responds with a fifth message including the key.
16. The method of claim 15 wherein the fifth message further includes the publisher's address, an echo of the third random number, and a fourth random number.
17. An article of manufacture comprising:
computer readable program code for publishing encrypted data between a plurality of computers interconnected by a network providing a datapath therebetween 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 over the network 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 Diffie-Hellmann key exchange protocol over the network 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.
computer readable program code for publishing encrypted data between a plurality of computers interconnected by a network providing a datapath therebetween 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 over the network 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 Diffie-Hellmann key exchange protocol over the network 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.
18. The article of manufacture of claim 17 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.
19. The article of manufacture of claim 18 further comprising communications daemons to establish communications between said publisher software program and said subscriber program software programs running on said computers.
20. The article of manufacture of claim 18 wherein said publisher software program and said subscriber program each further contain a software object responder.
21. The article of manufacture of claim 20 wherein said software object responder is a single cryptographic entity keeping a cryptographic key and a signature key.
22. The article of manufacture of claim 21 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.
23. The article of manufacture of claim 17 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.
24. The article of manufacture of claim 23 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.
25. The article of manufacture of claim 24 further comprising program code incorporating a challenge value into the second message.
26. The article of manufacture of claim 22 further comprising program code for incorporating a request for signature information into the second message.
27. The article of manufacture of claim 25 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.
28. The article of manufacture of claim 27 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.
29. The article of manufacture of claim 28 further comprising program code for effecting the publisher responding with a fifth message including the key.
30. The article of manufacture of claim 29 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.
31. A method of publishing encrypted data between a plurality of computers interconnected by a network providing a datapath therebetween in a publish/subscribe communications system comprising a publisher and at least one subscriber, said method comprising the steps of:
a) initiating a Diffie-Hellmann key exchange over the network between the subscriber and the publisher;
b) publishing encrypted data to a subscriber over the network; and c) thereafter decrypting the published data at the subscriber.
a) initiating a Diffie-Hellmann key exchange over the network between the subscriber and the publisher;
b) publishing encrypted data to a subscriber over the network; and c) thereafter decrypting the published data at the subscriber.
32. The method of claim 31 wherein said publisher is a software application program.
33. The method of claim 32 wherein said subscriber is a software application program.
34. The method of claim 33 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.
35. The method of claim 34 comprising using communications daemons to establish communications between said publisher software program and said subscriber program software programs running on said computers.
36. The method of claim 34 wherein said publisher software program and said subscriber program each further contain a software object responder.
37. The method of claim 36 wherein said software object responder is a single cryptographic entity keeping a cryptographic key and a signature key.
38. The method of claim 36 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.
39. The method of claim 31 comprising the publisher publishing a message to be encrypted, encrypting the message using an encryption key, and signing the data with a private key.
40. An article of manufacture comprising:
computer readable program code for publishing encrypted data between a plurality of computers interconnected by a network providing a datapath therebetween in a publish/subscribe communications system comprising a publisher and at least one subscriber, the computer readable program code in said article of manufacture comprising:
a) computer readable program code for causing a computer to effect initiating a Diffie-Hellmann key exchange over the network between the subscriber and the publisher;
b) computer readable medium having computer readable program code for causing a computer to effect publishing encrypted data to a subscriber over the network; and c) computer readable program code for causing a computer to effect decryption of the published data at the subscriber.
computer readable program code for publishing encrypted data between a plurality of computers interconnected by a network providing a datapath therebetween in a publish/subscribe communications system comprising a publisher and at least one subscriber, the computer readable program code in said article of manufacture comprising:
a) computer readable program code for causing a computer to effect initiating a Diffie-Hellmann key exchange over the network between the subscriber and the publisher;
b) computer readable medium having computer readable program code for causing a computer to effect publishing encrypted data to a subscriber over the network; and c) computer readable program code for causing a computer to effect decryption of the published data at the subscriber.
41. The article of manufacture of claim 40 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.
42. The article of manufacture of claim 41 further comprising communications daemons to establish communications between said publisher software program and said subscriber program software programs running on said computers.
43. The article of manufacture of claim 41 wherein said publisher software program and said subscriber program each further contain a software object responder.
44. The article of manufacture of claim 43 wherein said software object responder is a single cryptographic entity keeping a cryptographic key and a signature key.
45. The article of manufacture of claim 44 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.
46. The article of manufacture of claim 41 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.
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US5463697P | 1997-08-04 | 1997-08-04 | |
| US60/054,636 | 1997-08-04 | ||
| PCT/US1998/016365 WO1999007104A1 (en) | 1997-08-04 | 1998-08-04 | Data security in multipoint publish/subscribe communications |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CA2299505A1 true CA2299505A1 (en) | 1999-02-11 |
Family
ID=21992475
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA002299505A Abandoned CA2299505A1 (en) | 1997-08-04 | 1998-08-04 | Data security in multipoint publish/subscribe communications |
Country Status (5)
| Country | Link |
|---|---|
| EP (1) | EP0998801A1 (en) |
| JP (1) | JP2001512923A (en) |
| AU (1) | AU8898698A (en) |
| CA (1) | CA2299505A1 (en) |
| WO (1) | WO1999007104A1 (en) |
Families Citing this family (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6980658B1 (en) | 1999-09-30 | 2005-12-27 | Qualcomm Incorporated | Method and apparatus for encrypting transmissions in a communication system |
| US20050021836A1 (en) | 2003-05-01 | 2005-01-27 | Reed Carl J. | System and method for message processing and routing |
| CN110740150B (en) * | 2018-07-20 | 2022-12-23 | 阿里巴巴集团控股有限公司 | Message interaction method and device |
Family Cites Families (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5677953A (en) * | 1993-09-14 | 1997-10-14 | Spyrus, Inc. | System and method for access control for portable data storage media |
| US5539828A (en) * | 1994-05-31 | 1996-07-23 | Intel Corporation | Apparatus and method for providing secured communications |
-
1998
- 1998-08-04 WO PCT/US1998/016365 patent/WO1999007104A1/en not_active Application Discontinuation
- 1998-08-04 EP EP98940794A patent/EP0998801A1/en not_active Withdrawn
- 1998-08-04 JP JP2000505708A patent/JP2001512923A/en active Pending
- 1998-08-04 AU AU88986/98A patent/AU8898698A/en not_active Abandoned
- 1998-08-04 CA CA002299505A patent/CA2299505A1/en not_active Abandoned
Also Published As
| Publication number | Publication date |
|---|---|
| AU8898698A (en) | 1999-02-22 |
| WO1999007104B1 (en) | 1999-04-15 |
| JP2001512923A (en) | 2001-08-28 |
| WO1999007104A1 (en) | 1999-02-11 |
| EP0998801A1 (en) | 2000-05-10 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US7415606B2 (en) | Method and apparatus for managing secure collaborative transactions | |
| AU2003202511B2 (en) | Methods for authenticating potential members invited to join a group | |
| EP1043864B1 (en) | System and method for document distribution | |
| US6941457B1 (en) | Establishing a new shared secret key over a broadcast channel for a multicast group based on an old shared secret key | |
| US6937726B1 (en) | System and method for protecting data files by periodically refreshing a decryption key | |
| US7181014B1 (en) | Processing method for key exchange among broadcast or multicast groups that provides a more efficient substitute for Diffie-Hellman key exchange | |
| US6859533B1 (en) | System and method for transferring the right to decode messages in a symmetric encoding scheme | |
| US6987855B1 (en) | Operational optimization of a shared secret Diffie-Hellman key exchange among broadcast or multicast groups | |
| US7346171B2 (en) | Network system, terminal, and method for encryption and decryption | |
| US20020106085A1 (en) | Security breach management | |
| CN109905229B (en) | Anti-quantum computing Elgamal encryption and decryption method and system based on group asymmetric key pool | |
| EP1113617A2 (en) | System and method for transferring the right to decode messages | |
| US7286665B1 (en) | System and method for transferring the right to decode messages | |
| Khurana et al. | Sels: a secure e-mail list service | |
| WO2001069843A2 (en) | Method and system for coordinating secure transmission of information | |
| WO1996029795A1 (en) | Simultaneous electronic transactions | |
| CA2299505A1 (en) | Data security in multipoint publish/subscribe communications | |
| EP1130843B1 (en) | System and method for transferring the right to decode messages in a symmetric encoding scheme | |
| Chen et al. | Key distribution without individual trusted authentification servers | |
| EP1111838B1 (en) | System and method for cryptographically protecting data | |
| EP1699162A2 (en) | Method for document distribution | |
| Trevathan et al. | A private and anonymous data repository service |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| EEER | Examination request | ||
| FZDE | Discontinued |