U.S. patent application number 09/070794 was filed with the patent office on 2001-08-23 for authenticated key agreement protocol.
This patent application is currently assigned to CERTICOM CORP.. Invention is credited to BLAKE-WILSON, SIMON, JOHNSON, DONALD, MENEZES, ALFRED.
Application Number | 20010016908 09/070794 |
Document ID | / |
Family ID | 22097429 |
Filed Date | 2001-08-23 |
United States Patent
Application |
20010016908 |
Kind Code |
A1 |
BLAKE-WILSON, SIMON ; et
al. |
August 23, 2001 |
AUTHENTICATED KEY AGREEMENT PROTOCOL
Abstract
A key agreement method between a pair of entities i and j in a
digital data communication system, wherein each the entity has a
private and corresponding public key pair S.sub.i,P.sub.i and
S.sub.j,P.sub.j respectively and the system, having global
parameters for generating elements of a group, the method
comprising the steps of: (a) entity i selecting a random private
session value R.sub.i; (b) forwarding a public session value
corresponding to the private session value R.sub.i to the entity j;
(c) entity j computing a long term shared secret key k' derived
from entity i's public key and j's private key utilizing a first
function H.sub.1; (d) the entity j utilizing entity j utilizing the
key k' and computing an authenticated message on entity identities
i, j and entities public session keys and forwarding the
authenticated message to entity i; (e) the entity i verifying the
received authenticated message; (f) the entity i computing the long
term shared secret key k' derived from the entity j's public key
and i's private key in accordance with the first function H.sub.1;
(g) the entity i utilizing the long term shared secret key k' and
computing an authenticated message on the entities i and j identity
information and the entities public session keys and forwarding the
authenticated message to the entity j: (h) entity j verifying the
received authenticated message; and (i) upon both the entities i
and j verifying the authenticated message, computing a short term
shared secret key utilizing a respective entity's session public
and private keys.
Inventors: |
BLAKE-WILSON, SIMON; (ALTON
HANTS, GB) ; JOHNSON, DONALD; (MANASSAS, VA) ;
MENEZES, ALFRED; (MISSISSAUGA, CA) |
Correspondence
Address: |
FINNEGAN HENDERSON FARABOW GARRETT
AND DUNNER
1300 I STREET NW
WASHINGTON
DC
200053315
|
Assignee: |
CERTICOM CORP.
|
Family ID: |
22097429 |
Appl. No.: |
09/070794 |
Filed: |
May 1, 1998 |
Current U.S.
Class: |
713/171 ;
380/285; 380/30 |
Current CPC
Class: |
H04L 9/0841
20130101 |
Class at
Publication: |
713/171 ; 380/30;
380/285 |
International
Class: |
H04L 009/30 |
Claims
The embodiments of the invention in which an exclusive property or
privilege is claimed are defined as follows:
1. A key agreement method between a pair of entities i and j in a
digital data communication system, wherein each said entity has a
private and corresponding public key pairs S.sub.i, P.sub.i and
S.sub.j,P.sub.j respectively and the system, having global
parameters for generating elements of a group, said method
comprising the steps of: (a) entity i selecting a random private
session value R.sub.i; (b) forwarding a public session value
corresponding to said private session value R.sub.i to said entity
j; (c) entity j computing a long term shared secret key k' derived
from entity i's public key and j's private key utilizing a first
function H.sub.1; (d) said entity j utilizing entity j utilizing
said key k' and computing an authenticated message on entity
identities i, j and entities public session keys and forwarding
said authenticated message to entity i; (e) said entity i verifying
said received authenticated message; (f) said entity i computing
said long term shared secret key k' derived from said entity j's
public key and i's private key in accordance with said first
function H.sub.1; (g) said entity i utilizing said long term shared
secret key k' and computing an authenticated message on said
entities i and j identity information and said entities public
session keys and forwarding said authenticated message to said
entity j; (h) entity j verifying said received authenticated
message; and upon both said entities i and j verifying said
authenticated message, computing a short term shared secret key
utilizing a respective entity's session public and private keys.
Description
[0001] This invention relates to cryptographic systems and in
particular, to authenticated key agreement protocols used in the
cryptographic systems.
[0002] A key agreement problem exists when two entities wish to
agree on keying information in secret over a distributed network.
Solutions to the key agreement problem whose security is based on a
Diffie-Hellman problem in finite groups have been used
extensively.
[0003] Suppose however, that entity i wishes to agree on secret
keying information with entity j. Each party desires an assurance
that no party, other than i and j, can possibly compute the keying
information agreed upon. This may be termed the authenticated key
agreement (AK) problem. Clearly, this problem is harder than the
key agreement problem in which i does not care which entity it is
agreeing on a key with, for in this problem i stipulates that the
key may be shared with j and no other entity.
[0004] Several techniques related to the Diffie-Hellman problem
have been proposed to solve the AK problem. However, no practical
solutions have been provably demonstrated to achieve this goal and
this deficiency has led, in many cases, to the use of flawed
protocols.
[0005] Since in the AK problem, i merely desires that only j can
possibly compute the key and not that j has actually computed the
key, solutions are often said to provide implicit (key)
authentication. If i wants to make sure, in addition, that j really
has computed the agreed key, then key confirmation is incorporated
into the key agreement protocol leading to so-called explicit
authentication. The resulting goal is called authenticated key
agreement with key confirmation (AKC). It may be seen that key
confirmation essentially adds the assurance that i really is
communicating with j. Thus, the goal of key confirmation is similar
to the goal of entity authentication as defined in Diffie-Hellman.
More precisely however, the incorporation of entity authentication
into the AKA protocol provides i the additional assurance that j
can compute the key, rather than the stronger assurance that j has
actually computed the key.
[0006] A number of distinct types of attacks have been proposed
against previous schemes. There are two major attacks which a
protocol should withstand. The first is a passive attack, where an
adversary attempts to prevent a protocol from achieving its goal by
merely observing honest entities carrying out the protocol. The
second is an active attack where an adversary additionally subverts
the communication themselves in any way possible by injecting
messages, intercepting messages, replaying messages, altering
messages and the like.
[0007] It is thus essential for any secure protocol to withstand
both passive and active attacks since an adversary can reasonably
be assumed to have these capabilities in a distributed network.
[0008] It is therefore desirable to provide a key agreement
protocol that mitigates at least some of the above advantages.
SUMMARY OF THE INVENTION
[0009] A key agreement method between a pair of entities i and j in
a digital data communication system, wherein each said entity has a
private and corresponding public key pairs S.sub.i, P.sub.i and
S.sub.j,P.sub.j respectively and the system, having global
parameters for generating elements of a group, said method
comprising the steps of:
[0010] (a) entity i selecting a random private session value
R.sub.i;
[0011] (b) forwarding a public session value corresponding to said
private session value R.sub.i to said entity j;
[0012] (c) entity j computing a long term shared secret key k'
derived from entity i's public key and j's private key utilizing a
first function H.sub.1;
[0013] (d) said entity j utilizing entity j utilizing said key k'
and computing an authenticated message on entity identities i, j
and entities public session keys and forwarding said authenticated
message to entity i;
[0014] (e) said entity i verifying said received authenticated
message;
[0015] (f) said entity i computing said long term shared secret key
k' derived from said entity j's public key and i's private key in
accordance with said first function H.sub.1;
[0016] (g) said entity i utilizing said long term shared secret key
k' and computing an authenticated message on said entities i and j
identity information and said entities public session keys and
forwarding said authenticated message to said entity j;
[0017] (h) entity j verifying said received authenticated message;
and
[0018] (i) upon both said entities i and j verifying said
authenticated message, computing a short term shared secret key
utilizing a respective entity's session public and private
keys.
BRIEF DESCRIPTION OF THE DRAWINGS
[0019] These and other features of the preferred embodiments of the
invention will become more apparent in the following detailed
description in which reference is made to the appended drawings
wherein:
[0020] FIG. 1 is a schematic diagram of a digital data
communication system;
[0021] FIG. 2, 3, 4 and 5, are embodiments of a key agreement
protocol according to the present invention.
DESCRIPTION OF THE PREFERRED EMBODIMENTS
[0022] In the following discussion, the notation as outlined below
is utilized and described more filly in the Diffie-Hellman paper
entitled "New Directions in Cryptography", IEEE Transactions on
Information Theory, November 1976, and incorporated herein by
reference.
[0023] Referring to FIG. 1, a data communication system 10 includes
a pair of entities or correspondents, designated as a sender i and
a recipient j who are connected by a communication channel 16. Each
of the correspondents, i and j includes an encryption unit that may
process digital information and prepare it for transmission through
channel 16 as will be described below. Furthermore, the encryption
units may be either a dedicated processor or a general purpose
processor including software for programming the general purpose
computer to perform specific cryptographic functions.
[0024] In the following discussion, k.sub.ij is i's key pair
k.sub.i together with j's public value, tran is a transcript of the
ordered set of messages transmitted and received by i and j is the
agreed key.
[0025] The protocols are described in terms of arithmetic
operations in a subgroup generated by an element of prime order q
in the multiplicative group Z.sup.ol.sub.p={1,2, . . . ,p-1} where
p is a prime. In each case, an entity's private value is an element
S.sub.iofZ.sup.ol.sub.q={1,2, . . q-1}, and the corresponding
public value is P.sub.i=.alpha..sup.SlMOD.sub- .p.sup.2, so that
i's key pair is K.sub.i,=(S.sub.i,P.sub.i). It is to be noted that
the protocols can be described equally well in terms of the
arithmetic operations in any finite group and, of course, this
would require the conversion of the security assumptions on the
Diffie-Hellman problem to that group. Furthermore, any particular
run of a protocol is called a session. For example, the keying
information agreed in the course of a protocol run is referred to
as a session key. The individual messages that form a protocol run
are called flows.
[0026] The protocols as described below employ various primitives.
Of these primitives, the two primitives used are message
authentication codes (MAC) and Diffie-Hellman schemes (DHS). Of
course, some applications may wish to use another primitive to
achieve confirmation. For example, if the agreed session key is
later to be used for encryption, it seems sensible to employ an
encryption scheme to achieve key confirmation rather than waste
time implementing a MAC.
[0027] Referring now to FIG. 2, a graphical representation of a
first embodiment of an AKC protocol (Protocol 1) according to the
present invention is shown generally by the numeral 22. We use
.epsilon..sub.R to denote an element chosen independently at
random, and commas to denote a unique encoding through
concatenation (or any other unique encoding). Let H.sub.1 and
H.sub.2 represent independent random oracles and (p,q,) are global
parameters. The random oracles may be defined in terms of coin
tosses in the following way. It is assumed that all parties are
provided with a black-box random function
H(.multidot.):{0,1}.sup.k.fwdarw.{0,1.su- p.k}. When H is queried
for the first time, say on string x, it returns the string of
length k corresponding to its first k coin tosses as H(x). When
queried with a second string say x', first H compares x and x'. If
x'=n, H again returns its first k coin tosses H(n). Otherwise H
returns its second k tosses as H(x'). In instantiations, H is
generally modeled by a hash function H. When entity i wishes to
initiate a run of P with the entity j, i selects an element at
random R.sub.i .epsilon..sub.R Z.sup.ol.sub.q and sends
.alpha..sup.Rl to j. On receipt of this string, j checks that
2.ltoreq..alpha..sup.R.sup..sub.i.ltoreq.p-1 and
(.alpha..sup.R.sup..sub.i).sup.q=1, then j chooses R.sub.j
.epsilon..sub.R Z.sup.ol.sub.q, and computes .alpha..sup.Rj and
k'=H.sub.1(.alpha..sup.s.sup..sub.i.sup.s.sup..sub.j). Finally, j
uses k' to compute MAC.sub.k'(2, i, j, .alpha..sup.Rj,
.alpha..sup.Ri), and sends this authenticated message to i. (Recall
that MAC.sub.k'(m) represents the pair (m,.alpha.), not just the
tag .alpha.). On receipt of this string, i checks that the form of
this message is correct, and that
2.ltoreq..alpha..sup.R.sup..sub.i.ltoreq.p-1 and
(.alpha..sup.R.sup..sub.- j).sup.q=1. The entity i then computes
k'=H.sub.1(.alpha..sup.s.sup..sub.i- .sup.s.sup..sub.j), recall
that .alpha..sup.s.sup..sub.j is j's long term public key, and
verifies the authenticated message it received. If so, i accepts,
and sends back to j MAC.sub.k'(3, i, j, .alpha..sup.R.sup..sub.i-
,.alpha..sup.R.sup..sub.j). Upon receipt of this string, j checks
the form of the message, verifies the authenticated message, and
accepts. Both parties compute the agreed session key as
k=H.sub.2(.alpha..sup.R.sup..su- b.i.sup.R.sup..sub.j). If at any
stage, a check or verification performed by i or j fails, then that
party terminates the protocol run, and rejects.
[0028] In practice, entity i may wish to append its identity to the
first flow of Protocol 1. We omit this identity because certain
applications may desire to identify the entities involved at the
packet level rather than the message level--in this instance,
identifying i again is therefore superfluous.
[0029] Note that entities use two distinct keys in Protocol 1--one
key for confirmation and a different key as the session key for
subsequent use. In particular, the common practice of using the
same key for both confirmation and as the session key may be
disadvantageous if this means the same key is used by more than one
primitive.
[0030] Protocol 1 is different from most proposed AKC protocols in
the manner that entities employ their long-term secret values and
session-specific secret values. Most proposed protocols use both
long-term secrets and short-term secrets in the formation of all
keys. In Protocol 1, long-term secrets and short-term secrets are
used in quite independent ways. Long-term secrets are used only to
form a session-independent confirmation key and short-term secrets
only to form the agreed session key. Conceptually, this approach
has both advantages and disadvantages over more traditional
techniques. On the plus side, the use of long-term keys and
short-term keys is distinct, serving to clarify the effects of a
key compromise--compromise of a long-term secret is fatal to the
security of future sessions, and must be remedied immediately,
whereas compromise of a short-term secret effects only that
particular session. On the negative side, both entities must
maintain a long-term shared secret key k' in Protocol 1.
Protocol 2
[0031] Protocol 2 is an AKC protocol designed to deal with some of
the disadvantages of Protocol 1. It is represented graphically in
FIG. 3. The actions performed by entities i and j are similar to
those of Protocol 1, except that the entities use both their
short-term and long-term values in the computation of both the keys
they employ. Specifically, the entities use
k'=H.sub.2(.alpha..sup.R.sup..sub.i.sup.R.sup..sub.j,.alpha.-
.sup.S.sup..sub.i.sup.S.sup..sub.j) as their MAC key for this
session, and
k=H.sub.2(.alpha..sup.R.sup..sub.i.sup.R.sup..sub.j,.alpha..sup.S.sup..su-
b.i.sup.S.sup..sub.j) as the agreed session key. Unlike Protocol 1,
both long-term secrets and both short-term secrets are used in
Protocol 2 to form each key. While this makes the effect of a
compromise of one of these values less clear, it also means that
there is no long-term shared key used to MAC messages in every
session between i and j. However, the two entities do still share a
long-term secret value .alpha..sup.S.sup..sub.i.sup.S.sup..sub.j.
This value must therefore be carefully guarded against compromise,
along with S.sub.i and S.sub.j themselves. Conceptually, it is
possible to separate the AK phase and the key confirmation phase in
Protocol 2.
Protocol 3
[0032] An embodiment of a secure AK protocol is illustrated in FIG.
4 which shows a graphical representation of the actions taken by i
and j in a run of Protocol 3. To see that Protocol 3 is not a
secure AK protocol if an adversary can reveal unconfirmed session
keys, notice the following attack. E begins two runs of the
protocol, one with II.sup.3.sub.i,j, and one with II.sup.M.sub.i,j.
Suppose II.sup.3.sub.i,j sends .alpha..sup.R.sup..sub.i, and
II.sup.M.sub.i,j sends .alpha..sup.R'.sup..sub.i. E now forwards
.alpha..sup.R.sup..sub.i to II.sup.u.sub.i,j, and
.alpha..sup.R'.sup..sub.i to II.sup..alpha..sub.i,j. E can now
discover the session key
k=H.sub.2(.alpha..sup.R.sup..sub.i.sup.R.sup..sub.j,.alpha..sup.S.sup..su-
b.i.sup.S.sup..sub.j) held by II.sup.3.sub.i,j by revealing the
(same) key held by II.sup.u.sub.i,j.
[0033] In this protocol, care must be taken when separating
authenticated key agreement from key confirmation. Protocol 3 above
is not a secure AK protocol in the fill model of distributed
computing, but can nonetheless be turned into a secure AKC
protocol, as in Protocol 2. At issue here is whether it is
realistic to expect that an adversary can learn keys that have not
been confirmed.
[0034] Therefore, in this description we have tried to separate the
goals of AK and AKC. A reason we have endeavored to separate
authenticated key agreement from key confirmation is to allow
flexibility in how a particular implementation chooses to achieve
key confirmation. For example, architectural considerations may
require key agreement and key confirmation to be separated--some
systems may provide key confirmation during a `real-time` telephone
conversation subsequent to agreeing a session key over a computer
network, while others may instead prefer to carry out confirmation
implicitly by using the key to encrypt later communications.
[0035] The reason that we have specified the use of a subgroup of
prime order by the DHSs is to avoid various known session key
attacks on AK protocols that exploit the fact that a key may be
forced to lie in a small subgroup of Z.sup.o.sub.p. From the point
of view of the security proofs, we could equally well have made
assumptions about DHSs defined in Z.sup.o.sub.p rather than a
subgroup of Z.sup.o.sub.p.
[0036] It may be noted in particular that, as is the case with
Protocol 3, many previous AK protocols do not contain asymmetry in
the formation of the agreed key to distinguish which entity
involved is the protocol's initiator, and which is the protocol's
responder
Protocol 4
[0037] Again, in this protocol instead of describing the actions of
i and j verbally, we illustrate these actions in FIG. 5. While at
first glance, Protocol 4 may look almost identical to the
well-known MTI protocol, where the shared value computed is
.alpha..sup.S.sup..sub.i.sup.R.sup..su-
b.i.sup.+S.sup..sub.j.sup.R.sup..sub.i, notice the following
important distinction. Entity i calculates a different key in
Protocol 4 depending on whether i believes it is the initiator or
responder. In the first case, i computes
k=H.sub.2(.alpha..sup.S.sup..sub.i.sup.R.sup..sub.j,.alp-
ha..sup.S.sup..sub.j.sup.R.sup..sub.i), and in the second case
k=H.sub.2(.alpha..sup.S.sup..sub.j.sup.R.sup..sub.j,.alpha..sup.S.sup..su-
b.i.sup.R.sup..sub.j). As we noted above, such asymmetry is
desirable in a secure AK protocol. Of course, such asymmetry is not
always desirable--a particular environment may require that i
calculate the same key no matter whether i is the initiator or
responder.
[0038] If indeed it can be shown that Protocol 4 is a secure AK
protocol, then it can be turned into a secure AKC protocol in the
same spirit as Protocol 2.
[0039] One issue is how to instantiate the random oracles H.sub.1
and H.sub.2. A hash function such as SHA-1 should provide
sufficient security for most applications. It can be used in
various ways to provide instantiations of independent random
oracles. For example, an implementation of Protocol 1 may choose to
use:
H.sub.1(x):=SHA-1(01,x) and H.sub.2(x):=SHA-1(10,x).
[0040] A particularly efficient instantiation of the random oracles
used in Protocol 2 is possible using SHA-1 or RIPEMD-160. Suppose
80-bit session keys and MAC keys are required, Then the first 80
bits of
SHA-1(.alpha..sup.R.sup..sub.i.sup.R.sup..sub.j,.alpha..sup.S.sup..sub.i.-
sup.S.sup..sub.j) can be used as k' and the second 80 bits used as
k. Of course, such efficient implementations may not offer the
highest conceivable security assurance of any instantiation.
[0041] It is easy to make bandwidth savings in implementations of
the AKC protocols. Instead of sending the full authenticated
messages (m,.alpha.) in flows 2 or 3, in both cases the entity can
omit much of m, leaving the remainder of the message to be inferred
by its recipient.
[0042] In some applications, it may not be desirable to carry out a
protocol run each time a new session key is desired. Considering
specifically Protocol 2 by way of example, entities may wish to
compute the agreed key as:
H.sub.2(.alpha..sup.R.sup..sub.i.sup.R.sup..sub.j,.alpha..sup.S.sup..sub.i-
.sup.S.sup..sub.j,counter).
[0043] Then, instead of running the whole protocol each time a new
key is desired, most of the time the counter is simply incremented.
Entities need then only to resort to using the protocol itself
every now and then to gain some extra confidence in the `freshness`
of the session keys they're using.
[0044] In Protocols 1, 2, and 3, performance and security reasons
may make it desirable to use a larger (and presumably more secure)
group for the static. Diffie-Hellman number
(.alpha..sub.1.sup.S.sup..sub.i.sup.S.sup..- sub.j) than for the
ephemeral Diffie-Hellman number
(.alpha..sub.2.sup.R.sup..sub.i.sup.R.sup..sub.j) calculation. The
larger group is desirable because the static number will be used
more often. The static numbers may be cached to provide a speed up
in session key calculation.
[0045] Finally, note that a practical instantiation of G (assume G
generates key pairs for each entity) using certificates should
check knowledge of the secret value before issuing a certificate on
the corresponding public value. We believe that this is a sensible
precaution in any implementation of a Certification Hierarchy.
[0046] While the invention has been described in connection with
the specific embodiment thereof, and in a specific use, various
modifications thereof will occur to those skilled in the art
without departing from the spirit of the invention as set forth in
the appended claims. For example, each entity will usually generate
key pairs itself and then get them certified by a certification
authority.
[0047] The terms and expressions which have been employed in this
specification are used as terms of description and not of
limitations, there is no intention in the use of such terms and
expressions to exclude any equivalence of the features shown and
described or portions thereof, but it is recognized that various
modifications are possible within the scope of the claims to the
invention.
* * * * *