US5729608A - Method and system for providing secure key distribution in a communication system - Google Patents

Method and system for providing secure key distribution in a communication system Download PDF

Info

Publication number
US5729608A
US5729608A US08591638 US59163896A US5729608A US 5729608 A US5729608 A US 5729608A US 08591638 US08591638 US 08591638 US 59163896 A US59163896 A US 59163896A US 5729608 A US5729608 A US 5729608A
Authority
US
Grant status
Grant
Patent type
Prior art keywords
key
ab
user
ba
function
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.)
Expired - Fee Related
Application number
US08591638
Inventor
Philippe Janson
Gene Tsudik
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
International Business Machines Corp
Original Assignee
International Business Machines Corp
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Grant date

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communication
    • H04L9/08Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0894Escrow, recovery or storing of secret information, e.g. secret key escrow or cryptographic key storage
    • H04L9/0897Escrow, recovery or storing of secret information, e.g. secret key escrow or cryptographic key storage involving additional devices, e.g. trusted platform module [TPM], smartcard or USB
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communication
    • H04L9/08Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/0827Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) involving distinctive intermediate devices or communication paths
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communication
    • H04L9/08Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/083Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) involving central third party, e.g. key distribution center [KDC] or trusted third party [TTP]
    • H04L9/0833Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) involving central third party, e.g. key distribution center [KDC] or trusted third party [TTP] involving conference or group key
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communication
    • H04L9/32Cryptographic mechanisms or cryptographic arrangements for secret or secure communication 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/321Cryptographic mechanisms or cryptographic arrangements for secret or secure communication 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 a third party or a trusted authority

Abstract

A method and system for providing secure authenticated cryptographic key distribution in a communication system having properties very similar to a Two-Party Authentication Protocol. A new group key is distributed by a server to a selected group of users in the system. A braided structure of the messages, sent by the server to each user, allows authentication and, at the same time, secure and secret key distribution. Moreover, the braided structure makes it possible to construct minimal-length protocol messages.

Description

TECHNICAL FIELD

The present invention relates in general to secure communication systems and in particular to secure cryptographic key distribution in a communication system. Still more particularly, this invention relates to secure authenticated key distribution in a communication system.

BACKGROUND OF THE INVENTION

Authentication protocols and key distribution protocols are known in the art.

A two-party authentication protocol (hereafter simply referred to as 2PAP) is described in R. Bird, I. Gopal, A. Herzberg, P. Janson, S. Kutten, R. Molva, M. Young: Systematic Design of Two-Party Authentication Protocols, Proceeding of Crypto '91, August 1991. In the described 2PAP, two users authenticate each other by transmitting challenges and using a shared secret key. This protocol has been shown to be secure against an important class of attacks known as interleaving attacks. Such attacks are based upon the adversary's ability to use either:

legitimate flows obtained from past executions of the protocol or

protocol flows elicited by the adversary from legitimate parties.

A family of key distribution protocols (hereinafter simply referred to as KDP) has been subsequently realized in an actual network security service, KryptoKnight, described in R. Molva, G. Tsudik, E. Van Herreweghen, S. Zatti: KriptoKnight Authentication and Key Distribution Service, Proceeding of ESORICS 92, October 1992, Toulouse, France.

In a two-party key distribution protocol (hereinafter simply referred to as 2PKDP) a user distributes to another user a new secret key, using an already previously secret shared key.

In a three-party key distribution protocol (hereinafter simply referred to as 3PKDP) and in a multi-party key distribution protocol (hereinafter simply referred to as MPKDP), as described in U.S. Pat. No. 4,649,233, there is a user (often called "server") that shares a corresponding master user key with each of the other users; each master user key is known only to the server and the corresponding user. When a group of users (two or more) want to exchange secrets, since they do not share a common key, they have to rely on collaboration with the server. On request, the server generates and distributes a new group key for two (or more) selected users.

Key distribution is particularly difficult--because of time constraints--in communication system that provide for dynamic routing functions, enabling the continuation of routing, broadcasting, and multicasting (sending a message to a sub-set of users along a path or a set of paths) in the presence of changes. Such dynamic routing functions are per se known in the art, see for example Bertsekas-Gallager: Data Networks, Prentice-Hall, 1987, section 5.3.

SUMMARY OF THE INVENTION

There are some drawbacks with this prior art. The key distribution protocols known in the art have not been shown sufficiently secure; at least not insofar as the 2PAP described by Bird et al., i.e., they are believed but have not been shown to resist any kind of attacks such as inlet leaving attacks or cut-and-splice attacks, for instance.

In addition, some do not guarantee integrity of the key being distributed, i.e. they do not guarantee that the key being distributed cannot be modified by an adversary. These limitations are particularly true of protocols with minimal-length messages for secure authenticated key distribution.

The above drawbacks of the prior art are overcome by the invention as claimed.

The present invention provides a method and system that have been mathematically demonstrated to be as secure as 2PAP, in particular against interleaving attacks, owing to a braided structure of the protocol messages. The basic two-party key distribution (and authentication) protocol can in turn be used as a basic building block for constructing more elaborate, e.g. three-party, multi-party or inter-domain, key distribution protocols. The braided structure, in addition, guarantees the integrity of the key being distributed. Besides, this authenticated key distribution protocol requires minimal length protocol messages, and it is as compact as possible in both the number and the size of messages exchanged.

All this can be achieved with minimal computational requirements and without the necessity of using encryption/decryption functions.

The foregoing and other objects, features, and advantages of the invention will be apparent from the following more particular description of a preferred embodiment of the invention, as illustrated in the accompanying drawing.

DESCRIPTION OF THE DRAWINGS AND NOTATIONS USED

The invention is described in detail below with reference to the following drawings:

FIG. 1 is a pictorial representation of a communication system which may be utilized for the implementation of the method and system of the present invention.

FIG. 2 depicts the 2PAP of the prior ad.

FIG. 3 is a high level logical flow chart illustrating an example of the two-party authentication key distribution protocol according to the present invention.

FIG. 4 depicts the message flow of an example of 2PKDP according to the present invention.

FIG. 5 is a high level logical flow chart illustrating an example of the three-party authentication key distribution protocol according to the present invention.

FIG. 6 depicts the message flow of an example of 3PKDP according to the present invention.

FIG. 7 depicts the message flow of an example of MPKDP according to the present invention.

FIG. 8 depicts the message flow of an example of an optimized 3PKDP according to the present invention.

The following terminology is adopted throughout the description:

A,B,C: full user names; all names are assumed to be distinct. These names are, for example, 64-bit values obtained either by directly coding the identity or by applying a hash function to reduce the original coding of the name into a 64-bit field.

S: full name of the authentication server; S is a user assumed to be universally trusted by all constituent users.

Nab : all symbols beginning with N are random challenges or nonces, i.e. unpredictable, used-only-once random numbers; created for that specific occasion unit of freshness information. The first letter of the subscript refers to the user that originated the nonce while the second letter in the subscript identifies the challenged target user (e.g., Nab is a nonce generated by A and sent to challenge B); Kab : all symbols beginning with K are keys. The subscript letters identify the users sharing that key (e.g., Kab is the key shared between A and B); +: exclusive OR or XOR function.

EK (X): encryption of plaintext block X under key K. We use the term encryption to refer to a single-block transformation of cleartext input. This includes traditional encryption functions such as DES (described in National Bureau of Standards, Federal Information Processing Standards, National Bureau of Standards, Publication 46, 1977) as well as strong one-way functions (no one can invert) such as MD5, when the key is used as a suffix and/or prefix (described in R. Rivest: The MD5 Message Digest Algorithm, Internet DRAFT, July 1991). In the case of DES, both K and X are assumed to be not longer than the basic block size of the underlying encryption function, i.e. 64 bits. (Such assumptions are irrelevant for many one-way hash functions such as MDS, which accommodate any parameter size by definition.)

FUNC(x,y,z): cryptographic function dependent upon arguments x,y,z; a function may depend on all or only some of its arguments. All functions generate results of a size equal to the basic block size of the underlying cryptographic algorithm, e.g. 64 bits for DES, 128 for MDS, etc.

A→B X: this notation captures a single protocol flow; it denotes that A sent a message X to B.

DETAILED DESCRIPTION

With reference now to the figures and in particular with reference to FIG. 1, a communication system (100) is represented. Users A(101), B(102), C(103) can reside in various locations which are computers, terminals, local area networks, connected by a set of links (104, 105, 106, 107, 108). One (or more) of these users may work as a server S (109) for secure key distribution. A common method is that a table of master user keys is kept in safe storage at the server (Kas is the master key shared by the server and a user whose identification is A; similarly Kbs is the key shared with B, and so on). Each user can also have his master user key stored in its safe storage device (encrypted file, special hardware, a smart card, etc.).

FIG. 2 shows the basic secure 2PAP, described by Bird et al. in the prior art, between two users (A and B) sharing a common key Kab. The protocol execution begins at block 201 with the initiator party A transmitting its identity A and a nonce Nab to the second user B. Upon receiving the message from A, the value of an authentication function AUTH(Kab,Nab,Nba,B), based upon the shared key the nonce Nab, a new nonce Nba generated by B and the identity B of the message originator is computed by the second user B. Referring now to block 202, the value of this authentication function and the nonce Nba are transmitted from B to A. Upon receiving the message from B, the first user A re-computes the value of the authentication function AUTH(Kab,Nab,Nba,B) and compares it with its counterpart in the message sent by B; a match results in authentication of B. The first user A then computes the value of another authentication function ACK(Kab,Nab,Nba), based upon the shared key Kab, the nonce Nab and the nonce Nba, in order to complete two-way authentication. Referring now to block 203, the value of the authentication function ACK(Kab,Nab,Nba) is sent from A to B. Upon receiving the message from A, the user B re-computes the value of the authentication function ACK(Kab,Nab,Nba) and compares it with its counterpart in the message sent by A; a match results in authentication of A.

TWO-PARTY KEY DISTRIBUTION PROTOCOL (2PKDP)

FIG. 3 depicts an example of a secure two-party authenticated key distribution protocol between two users A and B according to the present invention. It is assumed that A and B share a common key Kab prior to protocol execution.

The protocol execution begins at block 301 with the initiator party A transmitting its identity A and a nonce Nab to the second user B, which can be considered as acting like a server to A. The second user B then generates a new key Kba at block 302, which is held in a secure fashion and meant only to be used by A and B. The value Nba of an authentication function AUTH(Kab,Nab,Kba,B), based upon at least the shared key Kab, the nonce Nab, the new key Kba and the identity of B is computed by the second user B at block 303. The function AUTH(Kab,Nab,Kba,B) can be an authentication expression based on the shared key Kab ; one example of AUTH is (where all encryption is performed with key Kab):

E(B+(E(N.sub.ba +E(N.sub.ab ))).

The same user B then computes at block 304 the value of a function BRAID(Kab,Nba,Kba), based upon at least the shared key Kab, the value Nba of the authentication function AUTH(Kab,Nab,Kba,B) and the new key Kba. The function BRAID can be an encryption function or a masking expression MASK=EK.sbsb.ab (Nba) computed by encryption of the value Nba under the shared key Kab, XOR-ed with the new key Kba :

E.sub.K.sbsb.ab (N.sub.ba)+K.sub.ba.

Referring now to block 305, the value of the authentication function AUTH(Kab,Nab,Kba,B) and the value of the function BRAID(Kab,Nba,Kba) are transmitted from B to A. Upon receiving the message from B, at block 306 the first user A can extract the new key Kba from the value of the function BRAID(Kab,Nba,Kba), using the shared key Kab and the value Nba. Assuming that the function BRAID is BRAID=EK.sbsb.ab (Nba)+Kba, A computes the value of the masking expression MASK=EK.sbsb.ab (Nba) and then extracts the new key Kba by XOR-ing the value of the function BRAID=EK.sbsb.ab (Nba)+Kba with the value of the masking expression:

K.sub.ba =E.sub.K.sbsb.ab (N.sub.ba)+K.sub.ba +MASK=E.sub.K.sbsb.ab (N.sub.ba)+K.sub.ba +E.sub.K.sbsb.ab (N.sub.ba)

If the user is indeed the user he claims to be by the identity sent to B in block 301, he has the key Kab and can obtain the new key Kba. If the user is impersonating the user A, he will not have the key Kab, and will not be able to obtain the new key Kba. Referring now to block 307, the first user A re-computes the value of the authentication function AUTH(Kab,Nab, Kba,B) and compares it with its counterpad in the message sent by B; a match results in successful, authenticated (and secret) distribution of the new key Kba. The process then passes to block 308, where the first user A computes the value of another authentication function ACK(Kab,Nab,Kba), based upon at least the shared key Kab, the nonce Nab and the new key Kba, in order to complete two-way authentication. The function ACK can be an authentication expression based on the shared key Kab ; one example of ACK is (where all encryption are performed with key Kab ):

E(K.sub.ba +E(N.sub.ab)).

Referring now to block 309, the value of the authentication function ACK(Kab,Nab,Kba) is sent from A to B. The process ends at block 310, where the user B re-computes the value of the authentication function ACK(Kab,Nab,Kba) and compares it with its counterpart in the message sent by A; a match results in authentication of A.

The distinctive feature of the braided structure of the BRAID function is important to achieve both authentication and, at the same time, key distribution. Moreover, the braided structure makes it possible to construct a minimal-length protocol message. This is because it is impossible to distribute an unpredictable random quantity (in secret) and simultaneously authenticate the quantity being distributed with a message of length less than two data units. The proposed two-party key distribution protocol is then extremely compact in both the number and the size of messages and this facilitates its application at any layer in the protocol hierarchy. Furthermore, as described in the following, the protocol is resistant to all interleaving attacks. All this is achieved with minimal computational requirements and without the necessity of using encryption/decryption functions (which are a stronger cryptographic tool, not always available).

DISCUSSION OF SECURITY

For simplicity and clarity of exposition, we will refer to the example of 2PKDP shown in FIG. 4.

Authentication

The first step in demonstrating the security of the proposed 2PKDP is to show equivalence between it and 2PAP. In other words, we need to support the statement that the proposed protocol provides a means for two-party authentication with security equal to that of 2PAP. If we can prove this equivalence, then it follows that the proposed protocol inherits the basic properties of 2PAP, namely, resistance to interleaving attacks. Of course, protocol goals other than authentication cannot be inherited from 2PAP. In particular, the proposed protocol will be shown to meet the additional requirement of non-disclosure of the key being distributed.

We begin with some initial assumptions about key distribution protocols at large:

A key is always generated by one party.

A key being distributed must be a random, unpredictable quantity. If A and B engage in a 2PKDP and B generates a key, then neither A nor any other party can predict this key.

Keys are never re-used.

These assumptions lead to an important observation that a freshly-generated key is very similar to a nonce; in fact, the only difference between a nonce Nba and a new key Kba is that Nba is communicated in the clear while Kba is kept secret.

We can observe now that the only difference between the two protocols is the so called `nonce` field of the second message. In 2PAP (202), the nonce field is simply Nba, while in 2PKDP (402) it is the more complex braid function expression EK.sbsb.ab (Nba)+Kba. The purpose of this expression is to conceal the key, i.e. Kba, which is used as a nonce (we consider the question of key confidentiality later). In order to demonstrate the equivalence of respective nonce fields, three issues must be addressed:

Is Kba a nonce?

If Kba is not a true nonce, then the equivalence does not hold. However, as noted earlier, nothing distinguishes a key from a nonce other than the fact that a key is kept secret. In particular, the rules and the procedures of generating keys and nonces are quite the same.

Is Nba a nonce?

Since Kba is a true nonce, Nba is a result of a strong one-way function of (among other variables) Kba, we conclude that Nba is also a nonce.

Is there a one-to-one relationship between EK.sbsb.ab (Nba)+Kba and Kba ?

Or, equivalently, does there exist a distinct value Nba such that: EK.sbsb.ab (Nba)=EK.sbsb.ab (Nba). Under the assumption that EK.sbsb.ab is a strong encryption function such as DES, this is clearly impossible since, otherwise, decryption would not be one-to-one. If, on the other hand, E is a strong one-way hash function (e.g. MD5) which produces a fixed-size digest of its input, different input values can be hashed into an identical digest. The issue is then the difficulty of computing Nba. In MD5, for example, the probability of any given input hashing into a known digest (in our case, even the digest is unknown) is ##EQU1## (impossible in practice).

Key-distribution

We now consider key distribution which is the added feature of the proposed 2PKDP. Strong authentication is not sufficient for achieving secure key distribution thus the results of the previous section are not applicable in this context.

The first issue is the definition of secure key distribution. For the purpose of key distribution, a protocol is considered secure if:

Non-disclosure:

The key being distributed cannot be obtained by the adversary (that is, without any assistance from either A or B).

Independence:

Knowledge of one key cannot be used to obtain other keys. Here we assume that the key being distributed will not be subsequently used as the encryption key in another 2PKDP. (The new key may, for example, be used for computing integrity checks on data messages exchanged between A and B).

Integrity:

The key being distributed cannot be modified by the adversary.

Non-disclosure

Assuming no collusion with a legitimate party, disclosure of a key is possible only if the adversary is somehow able to obtain the MASK value i.e., EK.sbsb.ab (Nba). However, this is impossible since each MASK is, in effect, a result of a one-way transformation of Nba. This implies that the adversary must either: 1) possess the encryption key, Kab, or, 2) somehow be able to elicit the desired MASK value from one of the legitimate parties. The former is assumed to be a non-issue while the latter deserves a closer look.

The adversary can try to obtain the MASK value by interrogating B and pretending to be A. However, no matter what value the adversary sends to B, B always generates a fresh key in message (402). It is the freshness of the new key that makes it impossible for the adversary to obtain any useful information. In fact, it is quite irrelevant what the adversary tries to send to B since Nba =AUTH (Kab,Nab,Kba,B) is strongly dependent on the freshly-generated Kba.

Alternatively, the adversary can try to elicit information from A. This is significantly harder because A responds with message (403) only if message (402) is authentic. Therefore, the adversary must be able to generate expressions of the type in message (402) which is impossible since both cryptographic operations in message (402) are computed over A's random challenge, Nab.

Independence

We now suppose that the adversary has somehow managed to discover a key Kba i from one of the runs of 2PKDP. Furthermore, he has done so without any explicit cooperation with either A or B. The most important additional piece of information that the adversary can thereby obtain is: EK.sbsb.ab (Nba i)=MASKi.

Now, since MASKi is the encryption of Nba i under the long-term key, Kab, the adversary can discover a plaintext,ciphertext! block-pair which he can later use for trying to break Kab. This is, however, a danger commensurate with the presumed breach of security which resulted in the adversary's discovery of Kba i.

The remaining question is whether or not the adversary can use the newly-acquired information to attack the protocol by:

1. discovering a key Kba i (i≢j) from any other protocol run (either past or future);

2. successfully distributing Kba i to A in another protocol run while posing as B.

As stated earlier, MASK is a result of a one-way function of Nba. Recall also that Nba is, itself, a one-way function of Nab, Kba and B. This essentially precludes any possibility of type 1 attacks.

An attack of type 2 requires that the adversary be able to construct a message of the form (i≢j):

N.sub.ba.sup.i =AUTH(K.sub.ab,N.sub.ab.sup.j,K.sub.ba.sup.i,B), E.sub.K.sbsb.ab (N.sub.ba.sup.i)+K.sub.ba.sup.i where K.sub.ba.sup.j ≢K.sub.ba.sup.i.

This, in turn, is possible only if the adversary is able to produce a fresh value of Nba j which includes the computation of the AUTH expression over a fresh nonce Nab j. The adversary cannot obtain Nba i via oracle attacks since the party he chooses to interrogate will reply with a message implicitly re-freshed with its own nonce.

Integrity

The integrity of the key being distributed is not one of the foremost security features of a KDP. A pure key distribution protocol need not concern itself with the integrity of the key as long as the key cannot be modified to a particular value selected by the adversary. For example, some KDPs known in the art, as described in R. Bird at al. are vulnerable to key modification attacks since the key itself is not authenticated but, rather, only distributed. Nonetheless, this is not considered to be a bug in the protocol because the adversary cannot change the key to a known value; he can only offset a key by a known value.

On the other hand, attacks of this sod are not feasible with the present 2PKDP since key modification requires simultaneous modification of the authentication expression: AUTH(Kab,Nab,Kba,B).

THREE-PARTY KEY DISTRIBUTION PROTOCOL (3PKDP)

FIG. 5 depicts a high level logical flow chart of a three-party authenticated key distribution protocol according to the present invention. The objective of a 3PKDP is to distribute a fresh group key to a group of users (two parties in this case). It is assumed that there exists a mutually-trusted third party typically referred to as the authentication server (S). It is assumed that all the users of the group share a corresponding secret master user key prior to protocol execution (Kas for A-S and Kbs for B-S). Each of said user key is know only to the server and the corresponding user. In the protocol of this example there is an initiator, denoted as A, which starts the communication. It is assumed that the group is determined in such a way that A knows who takes part in it. The protocol is started by the initiator A who first identifies the other parties (users) in the group.

A secure 3PKDP must satisfy much the same conditions as a secure 2PKDP with one added requirement:

Neither party must be able to alter the group key being distributed.

More generally, we assume that one of the legitimate parties (A or B) may exhibit arbitrary `byzantine` behavior (that it could impersonate another party that is registered with S). Of course, not all types of such threats can be addressed within the protocol. For example, unauthorized disclosure of a session key cannot be prevented. However, a secure 3PKDP must be defended against attacks by a legitimate party. In fact, a legitimate party exhibiting byzantine behavior can be viewed as a special case of an adversary (one armed with additional knowledge).

We obtain a secure 3PKDP by combining two instances (runs) of 2PKDP and one instance of 2PAP. Two users A and B each engage in a 2PKDP with the authentication server S. A and B are each assumed to share a user secret key with S, i.e., Kas and Kbs. After the distribution of the new key Kab, A and B engage in a 2PAP in order to confirm each other's knowledge of Kab.

Referring now to block 501, the protocol execution begins with a first user A transmitting its identity A, a nonce Nas and the identity of the users (only B in this case) of the group other than A to the server S. The server then generates a new group key Kab at block 502, which is held in a secure fashion and meant only to be used by the users of the group (A and B in this example). The value Nsa of an authentication function AUTH(Kas,Nas,Kab,B), based upon at least the user's key Kas, the user's nonce Nas, the group key Kab and the identity of the users (B in this case) of the group other than A is computed by the server at block 503. The server S then computes at block 504 the value of a function BRAID(Kas,Nsa,Kab), based upon at least the user's kas, the value Nsa and the group key Kab.

Referring now to block 505, the value of the authentication function AUTH(Kas,Nas,Kab,B) and the value of the function BRAID(Kas,Nsa,Kab) are transmitted from S to A. Upon receiving the message from S, at block 506 the first user A can extract the group key Kab from the value of the user's function BRAID(Kas,Nsa,Kab), using the user's key Kas and the value Nsa.

Referring now to block 507, the first user A re-computes the value of the user's authentication function AUTH(Kas,Nas,Kab,B) and compares it with its counterpad in the message sent by S; a match results in successful, authenticated (and secret) distribution of the group key Kab. The process then passes to block 508, where the first user computes the value of another authentication function ACK(Kas,Nas,Kab), based upon at least the user's key Kas, the user's nonce Nas and the group key Kab, in order to complete two-way authentication.

Referring now to block 509, the value of the authentication function ACK(Kas,Nas,Kab) is sent from A to S. The first 2PKDP ends at block 510, where the server S re-computes the value of the authentication function ACK(Kas,Nas,Kab) and compares it with its counterpad in the message sent by A; a match results in authentication of A.

Similar steps are now performed between the second user B and the server S. Referring to block 511, the second user B transmits its identity B, a nonce Nbs and the identity of the users (only A in this case) of the group other than B to the server S. The value Nsb of an authentication function AUTH(Kbs,Nbs,Kab,A), based upon at least the user's key Kbs, the user's nonce Nbs, the group key Kab and the identity of the users (A in this case) of the group other than B is computed by the server at block 512. The server S then computes at block 513 the value of a function BRAID(Kbs,Nsb,Kab), based upon at least the user's key Kbs, the value Nsb and the group key Kab.

Referring now to block 514, the value of the authentication function AUTH(Kbs,Nbs,Kab,A) and the value of the function BRAID(Kbs,Nsb,Kab) are transmitted from S to B. Upon receiving the message from S, at block 515 the second user B can extract the group key Kab from the value of the user's function BRAID(Kbs,Nsb,Kab), using the user's key Kbs and the value Nsb.

Referring now to block 516, the second user B re-computes the value of the user's authentication function AUTH(Kbs,Nbs,Kab,A) and compares it with its counterpart in the message sent by S; a match results in successful, authenticated (and secret) distribution of the group key Kab. The process then passes to block 517, where the second user computes the value of another authentication function ACK(Kbs,Nbs,Kab), based upon at least the user's key Kbs, the user's nonce Nbs and the group key Kab, in order to complete two-way authentication.

Referring now to block 518, the value of the authentication function ACK(Kbs,Nbs,Kab) is sent from B to S. The second 2PKDP ends at block 519, where the server S re-computes the value of the authentication function ACK(Kbs,Nbs,Kab) and compares it with its counterpad in the message sent by B; a match results in authentication of B. The two users A and B then can authenticate each other by a 2PAP. Referring to block 520, the first user A transmits its identity A and a nonce Nab to the second user B. Upon receiving the message from A, the value of the authentication function AUTH(Kab,Nab,Nba,B), based upon at least the group key Kab, the nonce Nab, a new nonce Nba and the identity B of the message originator is computed by the second user B at block 521.

Referring now to block 522, the value of the authentication function AUTH(Kab,Nab,Nba,B) and the nonce Nba are transmitted from B to A. Upon receiving the message from B, at block 523 the first user A re-computes the value of the authentication function AUTH(Kab,Nab,Nba,B) and compare it with its counterpad in the message sent by B; a match results in authentication of B. The process then passes to block 524, where the first user computes the value of the authentication function ACK(Kab,Nab,Nba), based upon at least the group key Kab, the nonce Nab and the nonce Nba, in order to complete two-way authentication.

Referring now to block 525, the value of the authentication function ACK(Kab,Nab,Nba) is sent from A to B. The process ends at block 526, where the second user B re-computes the value of the authentication function ACK(Kab,Nab,Nba) and compare it with its counterpad in the message sent by A; a match results in authentication of A.

We note that the server can also play the role of a user (in addition to server). The server can use the protocol to share a key with a group which contains the server itself (as a member of the group), in which case the server can play both the role of the protocol server and the role of the user, omitting sending the group key and authentication verification to itself (which is not needed), but only to a sub-group of users consisting of the users of the group other than the server S. In particular, this can be used to refresh the keys shared by the server and a user in a reliable way that makes sure that only the server and the actual user can change the key they share. We note that if the group consists only of two users (e.g., A and S), the protocol becomes equal to the described 2PKDP.

DISCUSSION OF SECURITY

For simplicity and clarity of exposition, we will refer to the example of 3PKDP shown in FIG. 6.

Authentication

As with 2PKDP, the first issue we must address is the strength of 3PKDP as an authentication protocol. In other words, does the protocol achieve pairwise authentication of (A,S), (B,S) and, finally, (A,B)?

Starting from the end of the protocol, it can be easily seen that, assuming secure distribution of Kab, the authentication protocol between A and B is as secure as the underlying 2PAP (in fact, it is 2PAP.)

Viewed in isolation, 2PKDP between A and S is secure and so is 2PKDP between B and S. However, one important difference between 3PKDP and two unrelated runs of 2PKDP is that the nonce generated by S is the same in both runs of 2PKDP (i.e., Kab). This is not a problem as long as it can be shown that the respective AUTH expressions remain uniquely `tied` to the particular run of 3PKDP. We address this issue by explicitly including the name of the peer party in the calculation of each AUTH expression, i.e., B is included in AUTH with Kas and A in AUTH with Kbs. While this argument is not particularly crisp, we note that one simple method for complete conformance with 2PKDP is to use Kab +A instead of Kab in AUTH with Kas and, similarly, Kab +B instead of Kab in AUTH with Kbs.

Key distribution

The non-disclosure and independence properties in 3PKDP are inherited directly from 2PKDP. The integrity of the new key is a different matter. The side-effect of the same key being distributed to both parties, is that an `insider` adversary, say B, can obtain the expression used to mask the key in the message from S to A. MASKa =EK.sbsb.as (Nsa)=EK as (AUTH(Kas,Nas,Kba,B)).

At the first glance, it appears that knowledge of this expression allows B to modify Kab to any selected Kab with impunity. Nonetheless, the AUTH with Kas expression (enclosed in the same message) precludes this attack since B cannot alter AUTH(Kas,Nas,Kab,B) to be AUTH(Kas,Nas,Kab,B)

On a related note, one advantage that B does gain as a result of 3PKDP is the knowledge of the cleartext-ciphertext pair of the form: Nsa, EK.sbsb.as (Nsa). This poses a threat insofar as B is able to discover Kas by means of a brute-force attack. However, the amount of work required on the average remains considerable, certainly commensurate with what would be required to crack an AUTH expression in the first place.

MULTI-PARTY KEY DISTRIBUTION PROTOCOL

FIG. 7 depicts the list of the messages exchanged in an example of a secure multi-party authenticated key distribution protocol from a server S to a group of selected users (A, B and C in the example) according to the present invention. In the protocol of this example there is an initiator, denoted as A, which starts the communication. It is assumed that the group is determined in such a way that A knows who is pad of it. It is also assumed that all users of the group share a corresponding secret user key prior to protocol execution (Kas for A-S, Kbs for B-S and Kcs for C-S). Each of said user keys is known only to the server and a corresponding one of the users. The protocol is started by the initiator A who first identifies the other parties (users) in the group.

The actual process flow implementing the above protocol messages can be plainly derived from FIG. 7.

In FIG. 7, the Multi-Party Key Distribution Protocol (MPKDP) is obtained by combining three runs of 2PKDP: A-S, B-S, and C-S with three runs of 2PAP: A-B, A-C, B-C. The goal of the MPKDP is to distribute to all parties the new key Kabc. After receiving Kabc, A-B, A-C, and B-C engage in a 2PAP to confirm each other's knowledge of Kabc.

Referring to blocks 701,704 and 707, each of A, B and C, sends to server S its identity, its own nonce (Nas, Nbs, Ncs), and the identities of other group members: (B,C) for A, (A,C) for B and (A,B) for C.

Referring to blocks 702,705 and 708, server S generates a new key Kabc which is held in a secure fashion and is meant only to be used by the members of the group (A, B, and C in this example.) The values of Nsa, Nsb, and Nsc are: AUTH(Kas,Nas,Kabc,B,C), AUTH(Kbs,Nbs,Kabc,A,C) and AUTH(Kcs,Ncs Kabc,A,B), respectively. Each is based upon at least the user's key (Kas, Kbs or Kcs), the user's nonce (Nas, Nbs, or Ncs), the group key Kabc, and the identities of other group members ((B,C), (A,C) or (A,B)).

Server S also computes the value of the functions: BRAID(Kas,Nsa,Kabc), BRAID(Kbs,Nsb,Kabc), and BRAID(Kcs,Nsc,Kabc). Each of these functions is computed as in the description of 3PKDP.

Finally, server S sends out to A: AUTH(Kas,Nas,Kabc,B,C) and BRAID(Kas,Nsa,Kabc); to B: AUTH(Kbs,Nbs,Kabc,A,C) and BRAID(Kbs,Nsb,Kabc); to C: AUTH(Kcs,Ncs Kabc,A,B) and BRAID(Kcs,Nsc,Kabc). Each of A, B, and C verifies its respective message and extracts the new key Kabc.

Referring to blocks 702, 705 and 709, each user A, B, and C computes and sends to server S, respectively, the value of ACK(Kas,Nas,Kabc), ACK(Kbs,Nbs,Kabc) and ACK(Kcs,Ncs,Kabc) whereof each is based upon at least the user's key (Kas, Kbs, Kcs), the user's nonce (Nas, Nbs or Ncs), and the group key Kabc. Upon receipt of all three messages, S verifies each one using the corresponding values. This completes the authenticated key distribution.

The remainder of the protocols (blocks 710 through 718) is devoted to three runs of 2PAP to confirm to each of the three group members that the other members hold the new key Kabc. Each of the 2PAP runs A-B, A-C, and B-C is identical to that in FIG. 2.

OPTIMIZATION

The protocol shown in FIG. 6 (similar considerations can be made about the protocol of FIG. 7) was obtained by a straightforward combination of 2PKDPs and 2PAPs. It requires a total of 9 messages and 3 bi-directional communication flows (A-B, A-S, B-S). In order to reduce the number of messages and optimize the protocol some of the messages can be interleaved. Moreover, it is not necessary for both A and B to communicate with S directly. A more realistic scenario would be such that all communication with S is either through A or B.

Referring now to FIG. 8, there is depicted a compacted version of a 3PKDP. In this example A starts the execution, then passes its information to B which passes A's information to S together with B's information. In a counter-move, the server S sends all the information to B, that distributes its piece of information to A. In order to make the protocol insensitive to the order of communication inside the group of users communicating with each other, tags are used so that a particular user knows which particular piece of information it is to use in a stream of data.

Referring now to block 801, the protocol execution begins with an initiating user, A, transmitting his identity, his nonce for S (Nas), his nonce for B (Nab) and the name of the other user (B) to that user B.

At block 802, upon receipt of the information from user A, user B transmits to S his own identity, the identity of the other use (A), his nonce for S (Nbs) and A's nonce for S (Nas).

Referring now to block 803, server S generates a new key Kab which is held in a secure fashion and meant only to be used by A and B. The value Nsa of an authentication function AUTH(Kas,Nas,Kab,B) based upon at least the user's key Kas, the user's nonce Nas, the new key Kab, and the identity of the other user B is computed. Server S then computes the value of a function BRAID(Kas,Nsa,Kab), based upon at least the user's key Kas, the value Nsa, and the new key Kab.

Referring still to block 803, server S also computes the value authentication function AUTH(Kbs,Nbs,Kab,A) based upon at least the user's key Kbs, the user's nonce Nbs, the new key Kab, and the identity of the other user A. Server S then computes the value of a function BRAID(Kbs,Nsb,Kab), based upon at least the user's key Kbs, the value Nsb, and the new key Kab. Finally, server S transmits AUTH(Kas,Nas,Kab,B), BRAID(Kas,Nsa,Kab), AUTH(Kbs,Nbs,Kab,A) and BRAID(Kbs,Nsb,Kab) to B.

Referring now to block 804, user B receives the above message and extracts the new key Kab from the value of the user's function BRAID(Kbs,Nsb,Kab) using the key Kbs and the value AUTH(Kbs,Nbs,Kab,A). Then, B authenticates the new key Kab by verifying the authentication function AUTH(Kbs,Nbs,Kab,A) based upon at least the user's key Kbs, the value Nbs, the new key Kab, and the identity of the other user A.

Then, B computes the value AUTH(Kab,Nab,Nba,B) based upon at least the new key Kab, A's nonce Nab, B's nonce Nba and the identity of B. At the end of block 804, B transmits AUTH(Kas,Nas,Kab,B), BRAID(Kas,Nsa,Kab) to A. At block 805, B transmits AUTH(Kab,Nab,Nba,B) and its nonce Nba to A. Referring to block 806, user A receives the above message and extracts the new key Kab from the value of the user's function BRAID(Kas,Nab,Kab) using the key Kas and the value AUTH(Kas,Nas,Kab,B). Then, A authenticates the new key Kab by verifying the authentication function AUTH(Kas,Nas,Kab,B) based upon at least the user's key Kas, the value Nas, the new key Kab, and the identity of the other user B.

Then, A verifies the received value AUTH(Kab,Nab,Nba,B) based upon at least the new key Kab, A's nonce Nab, B's nonce Nba, and the identity of B.

Still referring to block 806, user A computes the value of another authentication function ACK(Kas,Nas Kab) based at least on the user's key Kas, the user's nonce for S (Nas), and the new key Kab in order to complete two-way authentication between A and S. User A also computes yet another authentication function ACK(Kab,Nab,Nba) based upon at least the new key Kab, A's nonce for B Nab, and B's nonce for A Nba. At the end of block 806, user A transmits to B ACK(Kas,Nas,Kab) and ACK(Kab,Nab,Nba).

Referring now to block 807, user B receives ACK(Kas,Nas,Nab) and ACK(Kab,Nab,Nba). First, user B recomputes the value of the function ACK(Kab,Nab,Nba) and compares it with its counterpad in the messages received from A; a match results in the authentication of A.

User B now computes the value of another authentication function ACK(Kbs,Nbs,Kab) based at least on the user's key Kbs, the user's nonce for S (Nbs), and the new key Kab in order to complete two-way authentication between B and S. Then, user B transmits to S ACK(Kas,Nas,Kab) and ACK(Kbs,Nbs,Kab).

Referring still to block 807, server S receives ACK(Kas,Nas,Kab) and ACK(Kbs,Nbs,Kab) sent by B. Server S first recomputes the value of the authentication function ACK(Kas,Nas,Kab) and compares it with its counterpad in the message received from B; a match results in the authentication of A. Next, server S first recomputes the value of the authentication function ACK(Kbs,Nbs,Kab) and compares it with its counterpad in the message received from B; a match results in the authentication of B. This completes the protocol.

Claims (22)

We claim:
1. A method for providing secure, authenticated distribution in a communication system of a key to be used by a group of selected users, the key being distributed from a server to a sub-group consisting of the users of said group other than said server, each user of said sub-group sharing a secret user key with said server, said method comprising the steps of:
transmitting (501,511) the user's identification (A), a user's nonce (Nas) and an identification (B) of a user of said sub-group other than said transmitting user from each user of said sub-group to said server through an available path of said system;
generating (502) a new, common group key (Kab) for all users of said group by said server;
computing (503,512) the value of a first function for each user of said sub-group by said server, said first function depending upon at least said user's key (Kas), said user's nonce (Nas), said group key (Kab) and the identification (B) of the user of said group other than said user;
computing (504,513) the value of a second function for each user of said sub-group by said server, said second function depending upon at least said user's key (Kas), the value of said user's first function and said group key (Kab);
transmitting (505,514) the values of said user's first and second functions from said server to each user of said sub-group through an available path of said system;
extracting (506,515) said group key, by each user of said sub-group, from the value of said user's second function, employing said user's key and the value of said user's first function; and
re-computing (507,516) the value of said user's first function by each user of said sub-group and considering authenticated said extracted group key (Kab) if said re-computed value is equal to the value of said user's first function received by said server.
2. The method according to claim 1, further comprising the steps of:
computing (508,517) the value of a third function by each user of said sub-group, said user's third function depending upon at least said user's key (Kas), said user's nonce (Nas) and said group key (Kab);
transmitting (509,518) the value of said user's third function from each user of said sub-group to said server through an available path of said system; and
re-computing (510,519) the value of said user's third function for each user of said sub-group by said server and authenticating each user of said sub-group if said re-computed value if equal to the value of said user's third function received by said user.
3. The method according to claims 1 or 2, further comprising the step of:
each user of said sub-group authenticating (520 to 526) itself to any other user of said sub-group by encrypting and exchanging information with said group key (Kab) between said users.
4. The method according to claims 1 or 2, wherein said first, second and third functions are encryption functions under said user's key (Kas).
5. The method according to claims 1 or 2, wherein said second function is an encryption function under said user's key (Kas) of at least said user's first function, exclusively OR-ed with said group key (Kab).
6. The method according to claim 5, wherein said group key (Kab) is extracted by each user of said sub-group by re-computing the value of said user's encryption function and XOR-ing said result with the value of said user's second function.
7. The method according to claims 1 or 2, further characterized in that:
the information to be transmitted from each user of said sub-group to the server is collected by one of the users of the system and then transmitted from said one user to said server.
8. The method according to claims 1 or 2, further characterized in that:
the information to be transmitted over the system is identified by a tag identifying the addressed user or server.
9. A communication system (100) for providing secure, authenticated distribution of a key to be used by a group of selected users (101,102,103,109), the key being distributed from a server (109) to a sub-group of users (101,102,103) consisting of the users of said group other than said server, each user of said sub-group sharing a corresponding secret user key with said server, said system comprising:
means for transmitting (501,511) the user's identification, a user's nonce and an identification of a user of said sub-group other than said user from each user of said sub-group to said server through an available path of said system;
means for generating (502) a new, common group key for all users of said group by said server;
means for computing (503,512) the value of a first function for each user of said sub-group by said server, said first function depending upon at least said user's key, said user's nonce, said group key and the identification of the user of said group other than said user;
means for computing (504,513) the value of a second function for each user of said sub-group by said server, said second function depending upon at least said user's key, the value of said user's first function and said group key;
means for transmitting (505,514) the values of said user's first and second functions from said server to each user of said sub-group through an available path of said system;
means for extracting (506,515) said group key, by each user of said sub-group, from the value of said user's second function, employing said user's key and the value of said user's first function; and
means for re-computing (507,516) the value of said user's first function by each user of said sub-group and considering authenticated said extracted group key if said re-computed value is equal to the value of said user's first function received by said server.
10. The communication system according to claim 9, further comprising:
means for computing (508,517) the value of a third function by each user of said sub-group, said user's third function depending upon at least said user's key, said user's nonce and said group key;
means for transmitting (509,518) the value of said user's third function from each user of said sub-group to said server through an available path of said system; and
means for re-computing (510,519) the value of said user's third function for each user of said sub-group by said server and authenticating each user of said sub-group if said re-computed value is equal to the value of said user's third function received by said user.
11. The method according to claim 3, wherein said first, second and third functions are encryption functions under said user's key (Kas).
12. The method according to claim 3, wherein said second function is an encryption function under said user's key (Kas) of at least said user's first function, exclusively OR-ed with said group key (Kab).
13. The method according to claim 4, wherein said second function is an encryption function under said user's key (Kas) of at least said user's first function, exclusively OR-ed with said group key (Kab).
14. The method according to claim 3, further characterized in that:
the information to be transmitted from each user of said sub-group to the server is collected by one of the users of the system and then transmitted from said one user to said server.
15. The method according to claim 4, further characterized in that:
the information to be transmitted from each user of said sub-group to the server is collected by one of the users of the system and then transmitted from said one user to said server.
16. The method according to claim 5, further characterized in that:
the information to be transmitted from each user of said sub-group to the server is collected by one of the users of the system and then transmitted from said one user to said server.
17. The method according to claim 6, further characterized in that:
the information to be transmitted from each user of said sub-group to the server is collected by one of the users of the system and then transmitted from said one user to said server.
18. The method according to claim 3, further characterized in that:
the information to be transmitted over the system is identified by a tag identifying the addressed user or server.
19. The method according to claim 4, further characterized in that:
the information to be transmitted over the system is identified by a tag identifying the addressed user or server.
20. The method according to claim 5, further characterized in that:
the information to be transmitted over the system is identified by a tag identifying the addressed user or server.
21. The method according to claim 6, further characterized in that:
the information to be transmitted over the system is identified by a tag identifying the addressed user or server.
22. The method according to claim 7, further characterized in that:
the information to be transmitted over the system is identified by a tag identifying the addressed user or server.
US08591638 1993-07-27 1993-07-27 Method and system for providing secure key distribution in a communication system Expired - Fee Related US5729608A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/EP1993/001989 WO1995004416A1 (en) 1993-07-27 1993-07-27 Method and system for authenticated secure key distribution in a communication system

Publications (1)

Publication Number Publication Date
US5729608A true US5729608A (en) 1998-03-17

Family

ID=8165749

Family Applications (1)

Application Number Title Priority Date Filing Date
US08591638 Expired - Fee Related US5729608A (en) 1993-07-27 1993-07-27 Method and system for providing secure key distribution in a communication system

Country Status (5)

Country Link
US (1) US5729608A (en)
EP (1) EP0711480B1 (en)
JP (1) JP3078841B2 (en)
DE (2) DE69311581D1 (en)
WO (1) WO1995004416A1 (en)

Cited By (60)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6038322A (en) * 1998-10-20 2000-03-14 Cisco Technology, Inc. Group key distribution
US6041408A (en) * 1996-06-28 2000-03-21 Hitachi, Ltd. Key distribution method and system in secure broadcast communication
US6064736A (en) * 1997-09-15 2000-05-16 International Business Machines Corporation Systems, methods and computer program products that use an encrypted session for additional password verification
WO2000069113A1 (en) * 1999-05-07 2000-11-16 Telefonaktiebolaget Lm Ericsson Secure distribution and protection of encryption key information
US20010019614A1 (en) * 2000-10-20 2001-09-06 Medna, Llc Hidden Link Dynamic Key Manager for use in Computer Systems with Database Structure for Storage and Retrieval of Encrypted Data
US6330671B1 (en) * 1997-06-23 2001-12-11 Sun Microsystems, Inc. Method and system for secure distribution of cryptographic keys on multicast networks
US20020026414A1 (en) * 2000-08-25 2002-02-28 Mitsuru Nakajima Authentication method, authentication system, payment system, user apparatus and recording medium containing program for conducting authentication
US20020055989A1 (en) * 2000-11-08 2002-05-09 Stringer-Calvert David W.J. Methods and apparatus for scalable, distributed management of virtual private networks
WO2002039658A1 (en) * 2000-11-08 2002-05-16 Sri International Methods and protocols for intrusion-tolerant management of collaborative network groups
US20020152380A1 (en) * 2001-04-12 2002-10-17 Microsoft Corporation Methods and systems for unilateral authentication of messages
US20020150097A1 (en) * 2001-02-21 2002-10-17 Wei Yen Method and apparatus for secured multicasting
US6483921B1 (en) 1997-12-04 2002-11-19 Cisco Technology, Inc. Method and apparatus for regenerating secret keys in Diffie-Hellman communication sessions
US20030005300A1 (en) * 2001-04-12 2003-01-02 Noble Brian D. Method and system to maintain portable computer data secure and authentication token for use therein
US20030018893A1 (en) * 2000-02-08 2003-01-23 Erwin Hess Method and configuration for mutual authentication of two data processing units
US20030021417A1 (en) * 2000-10-20 2003-01-30 Ognjen Vasic Hidden link dynamic key manager for use in computer systems with database structure for storage of encrypted data and method for storage and retrieval of encrypted data
US20030076955A1 (en) * 2001-10-18 2003-04-24 Jukka Alve System and method for controlled copying and moving of content between devices and domains based on conditional encryption of content key depending on usage state
US20030212911A1 (en) * 2002-05-13 2003-11-13 International Business Machines Corporation Secure control of access to data stored on a storage device of a computer system
US20030217288A1 (en) * 2002-05-15 2003-11-20 Microsoft Corporation Session key secruity protocol
US20030226013A1 (en) * 2002-05-31 2003-12-04 Sri International Methods and apparatus for scalable distributed management of wireless virtual private networks
US20040010683A1 (en) * 2002-07-12 2004-01-15 Microsoft Corporation Method and system for authenticating messages
US20040049676A1 (en) * 2001-04-26 2004-03-11 Bruno Dutertre Methods and protocols for intrusion-tolerant management of collaborative network groups
US20040073792A1 (en) * 2002-04-09 2004-04-15 Noble Brian D. Method and system to maintain application data secure and authentication token for use therein
US20040193875A1 (en) * 2003-03-27 2004-09-30 Microsoft Corporation Methods and systems for authenticating messages
US20050025172A1 (en) * 2003-07-30 2005-02-03 Justin Frankel Method and apparatus for secure distributed collaboration and communication
US6892308B1 (en) * 1999-04-09 2005-05-10 General Instrument Corporation Internet protocol telephony security architecture
US20050102513A1 (en) * 2003-11-10 2005-05-12 Nokia Corporation Enforcing authorized domains with domain membership vouchers
US20050125684A1 (en) * 2002-03-18 2005-06-09 Schmidt Colin M. Session key distribution methods using a hierarchy of key servers
US6912656B1 (en) * 1999-11-30 2005-06-28 Sun Microsystems, Inc. Method and apparatus for sending encrypted electronic mail through a distribution list exploder
US20050149758A1 (en) * 2004-01-06 2005-07-07 Samsung Electronics Co., Ltd. Authentication apparatus and method for home network devices
US6959089B1 (en) * 2000-04-07 2005-10-25 General Instrument Corporation Method and apparatus for secure transmission of data
US20050283620A1 (en) * 2004-06-17 2005-12-22 Bassam Khulusi System and method for dis-identifying sensitive information and associated records
US20060005013A1 (en) * 2004-06-30 2006-01-05 Microsoft Corporation Call signs
US20060018483A1 (en) * 2004-07-23 2006-01-26 Hewlett-Packard Development Company, L.P. Delegation protocol
US20060020807A1 (en) * 2003-03-27 2006-01-26 Microsoft Corporation Non-cryptographic addressing
US7111172B1 (en) * 1999-07-19 2006-09-19 Rsa Security Inc. System and methods for maintaining and distributing personal security devices
US7149895B1 (en) * 1999-02-01 2006-12-12 International Business Machines Corporation Personal device, terminal, server and methods for establishing a trustworthy connection between a user and a terminal
US7203834B1 (en) * 1999-12-02 2007-04-10 International Business Machines Corporation Method of updating encryption keys in a data communication system
US7234058B1 (en) * 2002-08-27 2007-06-19 Cisco Technology, Inc. Method and apparatus for generating pairwise cryptographic transforms based on group keys
US7236597B2 (en) 2002-12-20 2007-06-26 Bbn Technologies Corp. Key transport in quantum cryptographic networks
US20070192600A1 (en) * 2005-05-27 2007-08-16 Samsung Electronics Co., Ltd. Key handshaking method and system for wireless local area networks
US20070250700A1 (en) * 2006-04-21 2007-10-25 Microsoft Corporation Peer-to-peer contact exchange
US7324647B1 (en) 2000-10-23 2008-01-29 Bbn Technologies Corp. Quantum cryptographic key distribution networks with untrusted switches
US7424615B1 (en) * 2001-07-30 2008-09-09 Apple Inc. Mutually authenticated secure key exchange (MASKE)
US7428749B2 (en) 2001-08-03 2008-09-23 International Business Machines Corporation Secure delegation using public key authorization
US7430295B1 (en) 2003-03-21 2008-09-30 Bbn Technologies Corp. Simple untrusted network for quantum cryptography
US7457416B1 (en) * 2002-07-17 2008-11-25 Bbn Technologies Corp. Key distribution center for quantum cryptographic key distribution networks
US7460670B1 (en) 2002-12-20 2008-12-02 Bbn Technologies Corp. Systems and methods for managing quantum cryptographic networks
US7515716B1 (en) 2004-02-26 2009-04-07 Bbn Technologies Corp. Systems and methods for reserving cryptographic key material
US20090161919A1 (en) * 2007-12-21 2009-06-25 General Instrument Corporation Device Detection with Secure Identity Authentication
US7610487B2 (en) 2003-03-27 2009-10-27 Microsoft Corporation Human input security codes
US7624264B2 (en) 2003-03-27 2009-11-24 Microsoft Corporation Using time to determine a hash extension
US7627126B1 (en) 2002-10-15 2009-12-01 Bbn Technologies Corp. Systems and methods for implementing path length control for quantum cryptographic systems
US7697693B1 (en) 2004-03-09 2010-04-13 Bbn Technologies Corp. Quantum cryptography with multi-party randomness
US7706535B1 (en) 2003-03-21 2010-04-27 Bbn Technologies Corp. Systems and methods for implementing routing protocols and algorithms for quantum cryptographic key transport
US8001605B2 (en) 2002-09-18 2011-08-16 Microsoft Corporation Method and system for detecting a communication problem in a computer network
CN102804676A (en) * 2009-06-23 2012-11-28 松下电器产业株式会社 Cryptogram-key distribution system
US8656164B2 (en) 2009-06-23 2014-02-18 Panasonic Corporation Authentication system
US20140245398A1 (en) * 2013-02-27 2014-08-28 Kt Corporation M2m data management
EP2890074A1 (en) * 2013-12-31 2015-07-01 Gemalto SA Method for transmitting push messages
US9722803B1 (en) * 2016-09-12 2017-08-01 InfoSci, LLC Systems and methods for device authentication

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5953420A (en) * 1996-10-25 1999-09-14 International Business Machines Corporation Method and apparatus for establishing an authenticated shared secret value between a pair of users
US6292896B1 (en) 1997-01-22 2001-09-18 International Business Machines Corporation Method and apparatus for entity authentication and session key generation
CN102143491B (en) * 2010-01-29 2013-10-09 华为技术有限公司 MTC (machine type communication) equipment authentication method, MTC gateway and relevant equipment
EP3110066A4 (en) * 2014-02-18 2017-03-01 Panasonic Ip Corp America Authentication method and authentication system

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0197392A2 (en) * 1985-04-11 1986-10-15 International Business Machines Corporation Improvements in cryptographic communication
US5124117A (en) * 1989-08-07 1992-06-23 Matsushita Electric Industrial Co., Ltd. Cryptographic key distribution method and system
US5222140A (en) * 1991-11-08 1993-06-22 Bell Communications Research, Inc. Cryptographic method for key agreement and user authentication
US5251258A (en) * 1991-03-05 1993-10-05 Nec Corporation Key distribution system for distributing a cipher key between two subsystems by one-way communication
US5369705A (en) * 1992-06-03 1994-11-29 International Business Machines Corporation Multi-party secure session/conference

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0197392A2 (en) * 1985-04-11 1986-10-15 International Business Machines Corporation Improvements in cryptographic communication
US4649233A (en) * 1985-04-11 1987-03-10 International Business Machines Corporation Method for establishing user authenication with composite session keys among cryptographically communicating nodes
US5124117A (en) * 1989-08-07 1992-06-23 Matsushita Electric Industrial Co., Ltd. Cryptographic key distribution method and system
US5251258A (en) * 1991-03-05 1993-10-05 Nec Corporation Key distribution system for distributing a cipher key between two subsystems by one-way communication
US5222140A (en) * 1991-11-08 1993-06-22 Bell Communications Research, Inc. Cryptographic method for key agreement and user authentication
US5369705A (en) * 1992-06-03 1994-11-29 International Business Machines Corporation Multi-party secure session/conference

Non-Patent Citations (4)

* Cited by examiner, † Cited by third party
Title
Computer Security Esorics 92.Second European Symposium on Research in Computer Security Proceedings, Nov. 23 25, 1992, Toulouse, France; Kryptoknight Authentication and Key Distribution System , R. Molva et al, pp. 155 174. *
Computer Security--Esorics 92.Second European Symposium on Research in Computer Security Proceedings, Nov. 23-25, 1992, Toulouse, France; ▪Kryptoknight Authentication and Key Distribution System▪, R. Molva et al, pp. 155-174.
IEEE Journal on Selected Areas in Communication, vol. 11, No. 5, Jun. 1993, New York, ▪Systematic Design of a Family of Attack-Resistant Authentication Protocols▪, R. Bird et al, pp. 679-693.
IEEE Journal on Selected Areas in Communication, vol. 11, No. 5, Jun. 1993, New York, Systematic Design of a Family of Attack Resistant Authentication Protocols , R. Bird et al, pp. 679 693. *

Cited By (102)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6041408A (en) * 1996-06-28 2000-03-21 Hitachi, Ltd. Key distribution method and system in secure broadcast communication
US6512829B1 (en) 1996-06-28 2003-01-28 Hitach, Ltd. Key distribution method and system in secure broadcast communication
US6330671B1 (en) * 1997-06-23 2001-12-11 Sun Microsystems, Inc. Method and system for secure distribution of cryptographic keys on multicast networks
US6064736A (en) * 1997-09-15 2000-05-16 International Business Machines Corporation Systems, methods and computer program products that use an encrypted session for additional password verification
US6483921B1 (en) 1997-12-04 2002-11-19 Cisco Technology, Inc. Method and apparatus for regenerating secret keys in Diffie-Hellman communication sessions
US6215878B1 (en) 1998-10-20 2001-04-10 Cisco Technology, Inc. Group key distribution
US6038322A (en) * 1998-10-20 2000-03-14 Cisco Technology, Inc. Group key distribution
US7149895B1 (en) * 1999-02-01 2006-12-12 International Business Machines Corporation Personal device, terminal, server and methods for establishing a trustworthy connection between a user and a terminal
US6892308B1 (en) * 1999-04-09 2005-05-10 General Instrument Corporation Internet protocol telephony security architecture
WO2000069113A1 (en) * 1999-05-07 2000-11-16 Telefonaktiebolaget Lm Ericsson Secure distribution and protection of encryption key information
US6711263B1 (en) 1999-05-07 2004-03-23 Telefonaktiebolaget Lm Ericsson (Publ) Secure distribution and protection of encryption key information
US7111172B1 (en) * 1999-07-19 2006-09-19 Rsa Security Inc. System and methods for maintaining and distributing personal security devices
US6912656B1 (en) * 1999-11-30 2005-06-28 Sun Microsystems, Inc. Method and apparatus for sending encrypted electronic mail through a distribution list exploder
US7203834B1 (en) * 1999-12-02 2007-04-10 International Business Machines Corporation Method of updating encryption keys in a data communication system
US7353392B2 (en) * 2000-02-08 2008-04-01 Infineon Technologies Ag Method and configuration for mutual authentication of two data processing units
US20030018893A1 (en) * 2000-02-08 2003-01-23 Erwin Hess Method and configuration for mutual authentication of two data processing units
US6959089B1 (en) * 2000-04-07 2005-10-25 General Instrument Corporation Method and apparatus for secure transmission of data
US7310608B2 (en) 2000-08-25 2007-12-18 Fujitsu Limited Authentication method, authentication system, payment system, user apparatus and recording medium containing program for conducting authentication
US20020026414A1 (en) * 2000-08-25 2002-02-28 Mitsuru Nakajima Authentication method, authentication system, payment system, user apparatus and recording medium containing program for conducting authentication
EP1189184A3 (en) * 2000-08-25 2004-05-26 Fujitsu Limited Authentication method, authentication system, payment system, user apparatus and recording medium containing program for conducting authentication
US20010019614A1 (en) * 2000-10-20 2001-09-06 Medna, Llc Hidden Link Dynamic Key Manager for use in Computer Systems with Database Structure for Storage and Retrieval of Encrypted Data
US7885413B2 (en) 2000-10-20 2011-02-08 Eruces, Inc. Hidden link dynamic key manager for use in computer systems with database structure for storage of encrypted data and method for storage and retrieval of encrypted data
US7362868B2 (en) 2000-10-20 2008-04-22 Eruces, Inc. Hidden link dynamic key manager for use in computer systems with database structure for storage of encrypted data and method for storage and retrieval of encrypted data
US20030021417A1 (en) * 2000-10-20 2003-01-30 Ognjen Vasic Hidden link dynamic key manager for use in computer systems with database structure for storage of encrypted data and method for storage and retrieval of encrypted data
US7324647B1 (en) 2000-10-23 2008-01-29 Bbn Technologies Corp. Quantum cryptographic key distribution networks with untrusted switches
US20020055989A1 (en) * 2000-11-08 2002-05-09 Stringer-Calvert David W.J. Methods and apparatus for scalable, distributed management of virtual private networks
WO2002039658A1 (en) * 2000-11-08 2002-05-16 Sri International Methods and protocols for intrusion-tolerant management of collaborative network groups
US7403980B2 (en) 2000-11-08 2008-07-22 Sri International Methods and apparatus for scalable, distributed management of virtual private networks
US20020150097A1 (en) * 2001-02-21 2002-10-17 Wei Yen Method and apparatus for secured multicasting
US20020152384A1 (en) * 2001-04-12 2002-10-17 Microsoft Corporation Methods and systems for unilateral authentication of messages
US20020152380A1 (en) * 2001-04-12 2002-10-17 Microsoft Corporation Methods and systems for unilateral authentication of messages
US7203837B2 (en) 2001-04-12 2007-04-10 Microsoft Corporation Methods and systems for unilateral authentication of messages
US8473744B2 (en) 2001-04-12 2013-06-25 Microsoft Corporation Methods and systems for unilateral authentication of messages
US7134019B2 (en) 2001-04-12 2006-11-07 Microsoft Corporation Methods and systems for unilateral authentication of messages
US20030005300A1 (en) * 2001-04-12 2003-01-02 Noble Brian D. Method and system to maintain portable computer data secure and authentication token for use therein
US7302571B2 (en) * 2001-04-12 2007-11-27 The Regents Of The University Of Michigan Method and system to maintain portable computer data secure and authentication token for use therein
US20040049676A1 (en) * 2001-04-26 2004-03-11 Bruno Dutertre Methods and protocols for intrusion-tolerant management of collaborative network groups
US7424615B1 (en) * 2001-07-30 2008-09-09 Apple Inc. Mutually authenticated secure key exchange (MASKE)
US7698736B2 (en) 2001-08-03 2010-04-13 International Business Machines Corporation Secure delegation using public key authentication
US20090055916A1 (en) * 2001-08-03 2009-02-26 International Business Machines Corporation Secure delegation using public key authentication
US20090055902A1 (en) * 2001-08-03 2009-02-26 International Business Machines Corporation Secure delegation using public key authentication
US7694329B2 (en) 2001-08-03 2010-04-06 International Business Machines Corporation Secure delegation using public key authentication
US7428749B2 (en) 2001-08-03 2008-09-23 International Business Machines Corporation Secure delegation using public key authorization
US20080313741A1 (en) * 2001-10-18 2008-12-18 Nokia Corporation System and method for controlled copying and moving of content between devices and domains based on conditional encryption of content key depending on usage state
US7844821B2 (en) 2001-10-18 2010-11-30 Nokia Corporation System and method for controlled copying and moving of content between devices and domains based on conditional encryption of content key depending on usage state
US8549304B2 (en) 2001-10-18 2013-10-01 Nokia Corporation System and method for controlled copying and moving of content between devices and domains based on conditional encryption of content key depending on usage state
US20030076955A1 (en) * 2001-10-18 2003-04-24 Jukka Alve System and method for controlled copying and moving of content between devices and domains based on conditional encryption of content key depending on usage state
US20110040975A1 (en) * 2001-10-18 2011-02-17 Nokia Corporation System and method for controlled copying and moving of content between devices and domains based on conditional encryption of content key depending on usage state
US7487363B2 (en) 2001-10-18 2009-02-03 Nokia Corporation System and method for controlled copying and moving of content between devices and domains based on conditional encryption of content key depending on usage
US7477748B2 (en) 2002-03-18 2009-01-13 Colin Martin Schmidt Session key distribution methods using a hierarchy of key servers
US20050125684A1 (en) * 2002-03-18 2005-06-09 Schmidt Colin M. Session key distribution methods using a hierarchy of key servers
US7299364B2 (en) 2002-04-09 2007-11-20 The Regents Of The University Of Michigan Method and system to maintain application data secure and authentication token for use therein
US20040073792A1 (en) * 2002-04-09 2004-04-15 Noble Brian D. Method and system to maintain application data secure and authentication token for use therein
US20030212911A1 (en) * 2002-05-13 2003-11-13 International Business Machines Corporation Secure control of access to data stored on a storage device of a computer system
US7523490B2 (en) 2002-05-15 2009-04-21 Microsoft Corporation Session key security protocol
US20030217288A1 (en) * 2002-05-15 2003-11-20 Microsoft Corporation Session key secruity protocol
US7971240B2 (en) 2002-05-15 2011-06-28 Microsoft Corporation Session key security protocol
US20030226013A1 (en) * 2002-05-31 2003-12-04 Sri International Methods and apparatus for scalable distributed management of wireless virtual private networks
US7246232B2 (en) 2002-05-31 2007-07-17 Sri International Methods and apparatus for scalable distributed management of wireless virtual private networks
US7370197B2 (en) 2002-07-12 2008-05-06 Microsoft Corporation Method and system for authenticating messages
US20040010683A1 (en) * 2002-07-12 2004-01-15 Microsoft Corporation Method and system for authenticating messages
US7457416B1 (en) * 2002-07-17 2008-11-25 Bbn Technologies Corp. Key distribution center for quantum cryptographic key distribution networks
US7234063B1 (en) * 2002-08-27 2007-06-19 Cisco Technology, Inc. Method and apparatus for generating pairwise cryptographic transforms based on group keys
US7234058B1 (en) * 2002-08-27 2007-06-19 Cisco Technology, Inc. Method and apparatus for generating pairwise cryptographic transforms based on group keys
US8001605B2 (en) 2002-09-18 2011-08-16 Microsoft Corporation Method and system for detecting a communication problem in a computer network
US7627126B1 (en) 2002-10-15 2009-12-01 Bbn Technologies Corp. Systems and methods for implementing path length control for quantum cryptographic systems
US7236597B2 (en) 2002-12-20 2007-06-26 Bbn Technologies Corp. Key transport in quantum cryptographic networks
US7460670B1 (en) 2002-12-20 2008-12-02 Bbn Technologies Corp. Systems and methods for managing quantum cryptographic networks
US7430295B1 (en) 2003-03-21 2008-09-30 Bbn Technologies Corp. Simple untrusted network for quantum cryptography
US7706535B1 (en) 2003-03-21 2010-04-27 Bbn Technologies Corp. Systems and methods for implementing routing protocols and algorithms for quantum cryptographic key transport
US7610487B2 (en) 2003-03-27 2009-10-27 Microsoft Corporation Human input security codes
US8261062B2 (en) 2003-03-27 2012-09-04 Microsoft Corporation Non-cryptographic addressing
US20040193875A1 (en) * 2003-03-27 2004-09-30 Microsoft Corporation Methods and systems for authenticating messages
US7624264B2 (en) 2003-03-27 2009-11-24 Microsoft Corporation Using time to determine a hash extension
US20060020807A1 (en) * 2003-03-27 2006-01-26 Microsoft Corporation Non-cryptographic addressing
US7409544B2 (en) 2003-03-27 2008-08-05 Microsoft Corporation Methods and systems for authenticating messages
US20050025172A1 (en) * 2003-07-30 2005-02-03 Justin Frankel Method and apparatus for secure distributed collaboration and communication
US20050102513A1 (en) * 2003-11-10 2005-05-12 Nokia Corporation Enforcing authorized domains with domain membership vouchers
US20050149758A1 (en) * 2004-01-06 2005-07-07 Samsung Electronics Co., Ltd. Authentication apparatus and method for home network devices
US7844818B2 (en) * 2004-01-06 2010-11-30 Samsung Electronics Co., Ltd. Authentication apparatus and method for home network devices
US7515716B1 (en) 2004-02-26 2009-04-07 Bbn Technologies Corp. Systems and methods for reserving cryptographic key material
US7697693B1 (en) 2004-03-09 2010-04-13 Bbn Technologies Corp. Quantum cryptography with multi-party randomness
US7681042B2 (en) 2004-06-17 2010-03-16 Eruces, Inc. System and method for dis-identifying sensitive information and associated records
US20050283620A1 (en) * 2004-06-17 2005-12-22 Bassam Khulusi System and method for dis-identifying sensitive information and associated records
US20060005013A1 (en) * 2004-06-30 2006-01-05 Microsoft Corporation Call signs
US7929689B2 (en) 2004-06-30 2011-04-19 Microsoft Corporation Call signs
US20060018483A1 (en) * 2004-07-23 2006-01-26 Hewlett-Packard Development Company, L.P. Delegation protocol
US20070192600A1 (en) * 2005-05-27 2007-08-16 Samsung Electronics Co., Ltd. Key handshaking method and system for wireless local area networks
US8000478B2 (en) * 2005-05-27 2011-08-16 Samsung Electronics Co., Ltd. Key handshaking method and system for wireless local area networks
US20070250700A1 (en) * 2006-04-21 2007-10-25 Microsoft Corporation Peer-to-peer contact exchange
US8086842B2 (en) 2006-04-21 2011-12-27 Microsoft Corporation Peer-to-peer contact exchange
US20090161919A1 (en) * 2007-12-21 2009-06-25 General Instrument Corporation Device Detection with Secure Identity Authentication
US8401244B2 (en) * 2007-12-21 2013-03-19 General Instrument Corporation Method and system for securely authenticating user identity information
CN102804676A (en) * 2009-06-23 2012-11-28 松下电器产业株式会社 Cryptogram-key distribution system
US8656164B2 (en) 2009-06-23 2014-02-18 Panasonic Corporation Authentication system
US8817985B2 (en) 2009-06-23 2014-08-26 Panasonic Corporation Encryption key distribution system
EP2448170A4 (en) * 2009-06-23 2015-06-24 Panasonic Ip Man Co Ltd Cryptogram-key distribution system
US20140245398A1 (en) * 2013-02-27 2014-08-28 Kt Corporation M2m data management
US9888002B2 (en) * 2013-02-27 2018-02-06 Kt Corporation M2M data management
EP2890074A1 (en) * 2013-12-31 2015-07-01 Gemalto SA Method for transmitting push messages
WO2015101544A1 (en) * 2013-12-31 2015-07-09 Gemalto Sa Method for transmitting push messages
US9722803B1 (en) * 2016-09-12 2017-08-01 InfoSci, LLC Systems and methods for device authentication

Also Published As

Publication number Publication date Type
JPH08511928A (en) 1996-12-10 application
JP3078841B2 (en) 2000-08-21 grant
DE69311581T2 (en) 1997-12-11 grant
EP0711480B1 (en) 1997-06-11 grant
WO1995004416A1 (en) 1995-02-09 application
EP0711480A1 (en) 1996-05-15 application
DE69311581D1 (en) 1997-07-17 grant

Similar Documents

Publication Publication Date Title
Desmedt Threshold cryptography
William Cryptography and network security: principles and practices
Kremer et al. An intensive survey of fair non-repudiation protocols
Blake-Wilson et al. Authenticated Diffe-Hellman key agreement protocols
Otway et al. Efficient and timely mutual authentication
Holt et al. Hidden credentials
US4881264A (en) Digital signature system and method based on a conventional encryption function
Boyd et al. Protocols for authentication and key establishment
Burmester et al. Provably secure ubiquitous systems: Universally composable RFID authentication protocols
Abdalla et al. Password-based authenticated key exchange in the three-party setting
MacKenzie et al. Networked cryptographic devices resilient to capture
US5666415A (en) Method and apparatus for cryptographic authentication
US6535607B1 (en) Method and apparatus for providing interoperability between key recovery and non-key recovery systems
Lin et al. Three-party encrypted key exchange: attacks and a solution
Canetti et al. Security analysis of IKE’s signature-based key-exchange protocol
Van Le et al. Universally composable and forward-secure RFID authentication and authenticated key exchange
Krawczyk SIGMA: The ‘SIGn-and-MAc’approach to authenticated Diffie-Hellman and its use in the IKE protocols
Bird et al. The kryptoknight family of light-weight protocols for authentication and key distribution
US4649233A (en) Method for establishing user authenication with composite session keys among cryptographically communicating nodes
US5440635A (en) Cryptographic protocol for remote authentication
US20020087862A1 (en) Trusted intermediary
Anderson et al. A new family of authentication protocols
US5953424A (en) Cryptographic system and protocol for establishing secure authenticated remote access
US6038322A (en) Group key distribution
Chung et al. Three weaknesses in a simple three-party key exchange protocol

Legal Events

Date Code Title Description
AS Assignment

Owner name: IBM CORPORATION, NEW YORK

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:PHILIPPE, JANSON;TSUDIK, GENE;REEL/FRAME:007993/0217;SIGNING DATES FROM 19951121 TO 19951127

FPAY Fee payment

Year of fee payment: 4

REMI Maintenance fee reminder mailed
LAPS Lapse for failure to pay maintenance fees
FP Expired due to failure to pay maintenance fee

Effective date: 20060317