throbber
Optimal Authentication Protocols
`Resistant to Password Guessing Attacks
`
`Li Gong
`
`SRI International
`Computer Science Laboratory
`Menlo Park, California 94025, U.S.A.
`(gong@csl.sri. com)
`
`Abstract
`
`Users are typically authenticated b y their pass-
`words. Because people are known to choose convenient
`passwords, which tend to be easy to guess, authenti-
`cation protocols have been developed that protect user
`passwords from guessing attacks. These proposed pro-
`tocols, however, use more messages and rounds than
`those protocols that are not resistant to guessing at-
`tacks. This paper gives new protocols that are resis-
`tant to guessing attacks and also optimal in both mes-
`sages and rounds, thus refuting the previous belief that
`protection against guessing attacks makes an authen-
`tication protocol inherently more expensive.
`
`1 Introduction
`
`Identifying users is an indispensable element of
`computer security and, because auxiliary devices such
`as smart-card are not likely to be ubiquitous in the
`foreseeable future, users have to be authenticated
`through their passwords. (We do not discuss authen-
`tication methods based on physical or biological tech-
`nologies.) People are known to use poorly chosen
`passwords that are vulnerable to dictionary attacks
`or guessing attacks [9], while all available evidence
`suggests that forcing people t o choose and remember
`good passwords - those that tend to be long charac-
`ter strings including both Roman letters and digits -
`is unworkable because such well-chosen passwords are
`also quite unmemorable [3, 71.
`Authentication protocols have been proposed that
`are resistant to password guessing attacks [8, 6, 1, 21,
`although they are more expensive in terms of the num-
`bers of messages and rounds than those authentication
`protocols without the additional requirement to pro-
`
`tect weak passwords [4, 51. For example, it is proven
`that the optimal mutual authentication (with hand-
`shake and using nonces for challenge and response)
`uses five messages [4], while the Nonce Protocol uses
`seven messages [6]. It was thought that such increased
`cost is inherent, and in particular, is because the server
`must decide if a client request is fresh before giving a
`reply - otherwise, guessing attack can materialize [6].
`In this paper, we show that this constraint is inci-
`dental to the techniques used in those protocols, and
`by a different design, we can develop authentication
`protocols that are resistant to password guessing at-
`tacks while at the same time being optimal both in
`the number of messages and in that of rounds.
`In the rest of this paper, we first review the tech-
`niques and protocols for protecting passwords from
`guessing attacks. Readers familiar with existing liter-
`ature on this subject can skip Section 2. Then we show
`how to design protocols that are optimal in messages
`and rounds. We also discuss extensions of the proto-
`cols to other scenarios, such as direct authentication.
`We finally conclude with a summary and a discussion
`as to why synchronized clocks may not help in further
`reducing the numbers of messages and rounds.
`
`2 Defeating Guessing Attacks
`
`We use the following notation throughout the pa-
`per. The notation {m}k denotes the result of en-
`crypting message m using key k , “,” denotes concate-
`nation ( m , n represents the concatenation of m and
`n ) , and
`denotes the bit-wise exclusive-or operation.
`“ A --.f B : m” represents A sending a message m to B .
`We now summarize the basic techniques for protect-
`ing passwords from guessing attacks. (More technical
`details can be found in an earlier paper [6].) Suppose
`
`1063-6900/95 $4.00 0 1995 IEEE
`
`24
`
`Authorized licensed use limited to: Stevens Institute of Technology. Downloaded on December 13,2022 at 20:20:29 UTC from IEEE Xplore. Restrictions apply.
`
`UNIFIED PATENTS EXHIBIT 1009
`Page 1 of 6
`
`

`

`A registers a password k2 at server S , and A knows
`the public key of S , k l . (The case of A not knowing
`S’s public key can be handled easily by a simple ex-
`tension [6].) Then, suppose that A asks S a question
`represented by the number n, and expects to get an
`answer in the form of f ( n ) , where f() can be a well
`known function. The protocol is shown in Table 1.
`
`tamps [6]. The modification is to let A (and also B )
`obtain al freshness identifier n s (a nonce in this case)
`from the server S (messages 1 and 2). After that, the
`protocol is the same as the Compact Protocol except
`that the timestamlp in messages 3 and 4 are substi-
`tuted by the nonce n s .
`
`1.
`2.
`
`A * S: { c l , ~ 2 , ~ 3 , n , k2}kl
`
`S * A: ( ~ 2 , ~3 @ f(n)}k;!
`
`Table 1: An illustration of basic techniques
`
`In step 1, A selects three sufficiently large random
`numbers c l , c2, and c3, encrypts them (together with
`the question n and the password k 2 ) under S’s public
`key k l , and sends the ciphertext to S. In step 2 , S de-
`crypts message l using his private key, checks the pass-
`word, uses c3 to mask the answer f(n), encrypts withi
`A’s password k2, and replies with message 2. Upon
`receiving message 2, A decrypts it using his password1
`and checks the result. If the first part of message f!
`is indeed c2, then the reply must be fresh (i.e., after
`receiving message 1) and has not been tampered eni
`route (assuming encryption also provides integrity).
`Now A can use c3 to unmask the second part of the
`reply and obtain the answer to his question.
`To mount a guessing attack, the attacker wlho has
`recorded all the exchanges over the network can guess
`k2 and try to decrypt message 2. But all he can see in
`the decrypted text is a random string, which gives no
`indication as to whether his guess of k2 is correct or
`not. Furthermore, k l is a public key and thus its cor-.
`responding private key is commonly assumed too long
`to guess in a computationally feasible way. Therefore,
`the attacker cannot decrypt message 1, and can only
`hope to reconstruct it in order to verify if a guess iri
`correct. This reconstruction is infeasible because he
`does not know c l . In other words, to attack password1
`k2 by guessing, the attacker effectively has to guess;
`both the password and c l (or S’s private key), but
`the latter is too long to guess. Therefore, the attacker
`cannot know whether a guess is correct or not, andl
`guessing attack is rendered impotent. If the attacker
`attempts to use a guessed password in an online trans-
`action, then a failed guess can be detected and logged.
`Based on these basic techniques, a protocol using
`nonces has been developed [6], as shown in Table 2.
`Here, K a and Kb are A’s and B’s passwords respec-
`tively. K s is server’s public key. This protocol irr
`adapted from the Compact Protocol that uses times-
`
`1. A - + S : A , B
`S -+ A : A , B , n s
`2.
`3.
`A -+ B : { A , 81, n u l , nu2, ca, { n s } K a } K s , n s , ru
`B --+ S: { A , B , n u l , na2, ca, { ~ s } K ~ } K ~ ,
`4.
`{ B , A , n b l , nb2, cb, {ns}Kb}Ks
`5.
`S -+ B : { n u l , k €8 n a 2 } g a , { n b l , k @ n b 2 ) ~ b
`6.
`B -+ A : { n u l , k @ na2}jya, {fl(ra), rb}k
`7. A --+ B : { f 2 ( ~ . b ) } k
`
`Table f!: The Nonce Protocol
`
`This protocol works as follows. A first obtains a
`nonce n s from the server, composes a fresh request
`message, and sends it to S via B (and at the same
`time passes along S’s nonce). B composes a simi-
`lar request message. The server checks, by examining
`that both parts of message 4 are
`
`{ n s } ~ ~ and { n s } ~ ~ ) ,
`fresh and they originate from A and B. S then se-
`lects a session key k and replies with message 5. B
`decrypts the second part of message 5 using his pass-
`word, finds n b l , and thus is satisfied that the message
`is from S, is fresh, and has not been tampered with
`during transmission. A does a similar check, before
`they complete a handshake. Here f l ( ) and f 2 ( ) are
`predefined functions.
`In this protocol, we protect the passwords not only
`from an outside attacker, but also from insiders, who
`can be either malicious or merely incompetent. For ex-
`ample, .4 cannot guess B’s password, and vice versa,
`even with the aid of the residue of a successful authen-
`tication. A safeguard that works under these circum-
`stances also ensures that neither party can cause the
`compromise of the other’s password by compromising
`their own.
`The reason for requiring the initial nonce acquisi-
`tion is that, if message 3 (or 4) is not fresh, then the
`attacker can reuse it and obtain two different versions
`of messa,ge 6: { n u l , k@na2}jya and { n u l , k ’ @ n ~ 2 } ~ a .
`The two session keys, k and k‘, are different because S
`chooses a new session key each time. However, because
`both messages contain the same value for n u l , the at-
`tacker ciin guess 1 - a and decrypt both messages to see
`if the same value nail emerges. A match indicates that
`the guess is correct with very high probability.
`
`25
`
`Authorized licensed use limited to: Stevens Institute of Technology. Downloaded on December 13,2022 at 20:20:29 UTC from IEEE Xplore. Restrictions apply.
`
`UNIFIED PATENTS EXHIBIT 1009
`Page 2 of 6
`
`

`

`It is this constraint - that the server must respond
`only to fresh requests - that makes the nonce-based
`protocol use two messages more than the optimal case.
`In the next section, we show how to remove this con-
`straint and thus to derive optimal protocols.
`
`3 An Optimal Protocol
`
`The central idea is to let A choose an additional
`random number nu3 that is to be used by S as the en-
`cryption key in the reply message. The idea of user-
`generated encryption key is not new, but the typi-
`cal objection is that the authentication server is much
`better at selecting high-quality keys. In our circum-
`stances, however, the alternative key is a user-chosen
`password, which is unlikely to be cryptographically
`stronger than the random number nu3. (Of course
`nu3 should not be weak keys specific to the cryptosys-
`tems used.) Moreover, nu3 is a one-time key such that
`cryptographically breaking its encryption does not en-
`danger the password and subsequent authentication
`sessions. The optimal protocol is shown in Table 3.
`
`is maintained, then it must have come from the server,
`and thus the key k must be the session key chosen
`by the server. Moreover, if the attacker attempts to
`mount a guessing attack on a password (say K u ) , then
`he needs to reconstruct message 1 because a guessed
`value of K u does not lead to any other information
`related to subsequent messages (i.e., no verifiable texts
`in later messages). However, to reconstruct message
`1, he must also guess the value of ca (the confounder
`[SI), which is assumed t o be chosen at random from a
`large space and thus infeasible to guess by exhaustive
`search.
`Although the attacker can replay an old message 1
`- because the server cannot decide its freshness - all
`the attacker can get is a pair (or more) messages in
`and { n u l , k’$ n ~ 2 } , , ~ .
`the form of { n u l , k $ nu2},,3
`These do not help him in compromising a future ses-
`sion key k” or in guessing the password K u .
`The optimality of the protocol is easier to see - it
`uses five messages, reaching the proven lower bound
`[4]. (More detailed definitions and terminologies re-
`lated to optimality can be found in our previous pub-
`lications [4, 51.) It is also simple to re-arrange the
`messages so that it uses four rounds, again a proven
`lower bound, as shown in Table 4.
`A -+ B : { A , B , n u l , nu2,cu, nu3, { n u 3 } ~ ~ } ~ ~ ,
`
`TU
`B -+ S: { A , B , n u l , nu2, cu, nu3, { n u 3 } ~ , } ~ ~ ,
`{ B , A, nbl, nb2, cb, nb3, { n b 3 } ~ b } ~ ,
`S --+ B : { n u l , k @ n ~ 2 } , , ~ , {nbl, k @ nb2},b3
`3 .
`B -+ A : { n u l , k @ n ~ 2 } , , ~ , { f l ( r u ) , r b } k
`4.
`5. A -+ B : { f 2 ( ~ b ) } k
`
`1.
`2.
`
`Table 3: An optimal, five-message nonce protocol
`
`This protocol works as follows. A selects ran-
`dom numbers ( n u l , nu2, cu, nu3, T U ) and composes
`and sends message 1. B does the same by sending
`message 2. The server S checks that the pair nu3
`and { n u 3 } ~ , matches with A’s password ICu, which
`proves that the original sender is A. S does the same
`check for B. Then the server selects a session key k
`for A and B to share and replies with message 3.
`In message 3, the inclusion of nul and n b l demon-
`strates that the reply is fresh, while n u l and nbl hide
`the value of the session key. The message is encrypted,
`in two parts, under keys nu3 and nb3. After that, A
`and B complete a handshake exchange, the same as is
`done in the earlier Nonce Protocol.
`The security of the protocol can be argued similarly
`as that of the Nonce Protocol. Basically, because ICs is
`the server’s public key, only the server can obtain nu3
`and nb3. Since message 3 is also fresh and its integrity
`
`1. A 3 B : { A , B , n u l , nu2, cu, nu3, { n u 3 } ~ , } ~ , ,
`TU
`
`2. B + S : { A , B , n u l , nu2, cu, nu3, { n u 3 } ~ , } ~ , ,
`{ B , A, nbl, nb2, cb, nb3, { n b 3 } ~ b } ~ , ,
`rb
`3. S + A : { n u l , IC
`n ~ 2 } , , ~ , rb
`4. s
`-f B : { n b l , k @ nb2},b3
`
`5.
`6 .
`
`A + B : { f 2 ( ~ b ) } k
`B + A : { f l ( ~ ~ ) } k
`
`Table 4: An optimal, four-round nonce protocol
`
`Here, messages 3 and 4, and 5 and 6, can be sent
`in the same round. Note that the server relays B’s
`nonce r b to A in message 3. An earlier proof (Case
`8, NB+AH+SO [5]) applies, which shows that it is
`impossible to design a protocol with five messages and
`four rounds.
`Note that a lot of replayed messages may overload
`the authentication server. This does not necessarily
`pose a security threat, unless we consider cryptanal-
`ysis (on the server’s responses) a significant problem.
`Techniques are available to make such attacks more
`difficult.
`
`26
`
`Authorized licensed use limited to: Stevens Institute of Technology. Downloaded on December 13,2022 at 20:20:29 UTC from IEEE Xplore. Restrictions apply.
`
`UNIFIED PATENTS EXHIBIT 1009
`Page 3 of 6
`
`

`

`4 Beware of Subtle Attacks
`
`5 Two-Party Direct Authentication
`
`As we have shown, it is not important if the server
`cannot decide the freshness of the request messages,
`which is the main reason why we have been aLble to
`develop optimal protocols. It is vital, however, that
`the server can identify the senders of those request
`messages because otherwise S may be cheated into
`telling B that A is at the other end of the connection
`when in fact it is an attacker C. In our protocol,
`identification is done through two pairs of texts, nu3
`
`and { n u 3 } ~ ~ , and nb3 and { n b 3 } ~ b , because only the
`holders of the passwords ( K u and Kb) can generate:
`such pairs.
`Such explicit identification may be necessary, as we
`now show how to break a variation of the protocoll
`where identification is inexplicit. Suppose we remove
`nu3 from the pair, as shown in Table 5 (the case for
`B is identical). Because { n u 3 } ~ , is still present, intu-
`itively only S knows Ku and can obtain nu3 to com-
`pose a reply message.
`
`1.
`2.
`
`3.
`4.
`5.
`
`A -+ B : { A , B , nul, nu2, cu, { ~ u ~ } K ~ } K ~ ,
`IW
`B --+ S : { A , B , nul, na2, cu, { ~ U ~ } K , } K ~ ,
`{ B , A , nbl, n b 2 , 4 { n b 3 } ~ b } ~ ~
`S 4 B : {nul, k
`1262}na3, {nbl, k CB nb2},nb3
`B -+ A : {nul, k CB n ~ 2 } ~ ~ 3 ,
`rb}k
`{ f l ( ~ ~ ) ,
`A -+ B : { f 2 ( ~ b ) } k
`
`
`
`Table 5: A variation that is insecure
`
`In this case, the attacker can take the following
`line of actions. He selects random numbers (nul,
`nu2, cu, and E ) and compose a message of the form
`{ A , B , n u l , n u 2 , c ~ , x } ~ ~ . He sends this in place of
`message 1, claiming that it originates from A . The
`server then treats x as { n u 3 } ~ , for some vatlue of
`nu3, and in due course the attacker receives y =:
`{nul, k @ n ~ 2 } , , ~ . Now the attacker guesses a. value
`of Ku, uses it to decrypt x to obtain nu3, and uses
`that to further decrypt y. If nul emerges from the de-.
`cryption, the attacker knows that he has guessled KGI
`correctly with very high probability.
`Note that even if message 3 is modified to be
`{ k n ~ 2 } , , ~ so that the evidence nul is rernoved,
`the same attack can still succeed. Now, the attacker
`himself also takes the role of B , through which he
`(quite legitimately) obtains the session key IC. After
`decrypting y, he only need to see if the plaintext is
`identical to k @ nu2 (he knows both k and na2). A,
`match indicates a successful guess of Ku.
`
`27
`
`A and B sometimes may already share a poorly cho-
`sen secret (say Kubf and wish to establish, in a secure
`way, a well-chosen session key. In the following direct
`authentication prot,ocol, k l is a public key chosen by
`A, and IC is the session key chosen by B.
`
`A -+ B : nu, { E ; l } K a b
`1.
`2. B -+ A : { B , A , nb, cb, kj { n a } l i a b } k l
`A --+ B : {nb}k
`3.
`
`Table 6: An optimal direct authentication protocol
`
`In this protocol, A selects public key k l , encrypts
`it with the shared password Kub, and sends it and a
`nonce n(z to B. B decrypts to get kl, selects three ran-
`dom numbers (nb, cb, k ) , and sends message 2. A then
`uses the private key corresponding to k l to decrypt
`this message and obtain the session key k . The pres-
`ence of (nu}Kab proves to A that the message is sent
`by B and is fresh. Finally, A completes the handshake
`by sending message 3.
`The security argument is similar to those for the
`three-pa.rty protocol in Section 3. This protocol is
`more efficient than those previously proposed that use
`five messages [l, 611. Our protocol is in fact optimal
`because three messages and three rounds are lower
`bounds proven for nonce-based protocols that carry
`out only handshakes [4].
`It is easy to modify the protocol so that both clients
`contribute to the selection of the session key. For ex-
`ample, .4 can propose another key k‘, and then they
`use h(k, k’) as the session key, where h ( ) is a one-way
`hash function, as follows.
`
`6 Using “Secret Public Keys”
`
`In th’e optimal protocol in Section 3, the clients A
`and B must know the server’s public key before pro-
`tocol invocation. If the clients cannot be assumed to
`have this knowledge, we can add an extra round of ini-
`tial exchange to obtain a “secret public key” protocol
`PI.
`1. A - + S : A , B
`2. S -+ A : {KS}Ka
`
`Authorized licensed use limited to: Stevens Institute of Technology. Downloaded on December 13,2022 at 20:20:29 UTC from IEEE Xplore. Restrictions apply.
`
`UNIFIED PATENTS EXHIBIT 1009
`Page 4 of 6
`
`

`

`Alternatively, if the clients can generate public keys
`in real time, then we can use the technique in Section 5
`to obtain a more efficient “secret public key” protocol,
`as shown in Table 7.
`
`Table 7: An optimal “secret public key” protocol
`
`In this protocol, k l and k 2 are public keys chosen
`by A and B , and nu and nb are their nonces. Numbers
`csl and cs2 are confounders chosen by S. They must
`be independently chosen because otherwise A and B
`may be able to guess each other’s password if a secret
`public key is later revealed.
`Rearranging the messages can yield a four-round
`protocol, as done in Section 3. These protocols are
`thus optimal because they meet the lower bounds of
`the numbers of messages and rounds [4].
`
`7 Do Timestamps Improve Protocol
`Efficiency?
`
`In this section, we discuss why the use of times-
`tamps may not help to make the protocols more ef-
`ficient.
`In general, the availability of synchronized
`clocks and the use of timestamps often can reduce the
`numbers of messages and rounds for authentication
`protocols. For example, an optimal mutual authenti-
`cation protocol assuming synchronized clocks uses four
`messages or three rounds, cheaper than nonce-based
`protocols [4]. Thus, a question remains as to whether
`the efficiency of the protocols in Sections 3 , 5, and 6
`can be further improved if timestamps are used.
`Clearly the use of timestamps will enable the server
`(or a client, in a situation of direct authentication) to
`check if an initial request message is fresh and thus to
`respond only to fresh requests. However, as we have
`shown, the security of the protocol does not depend
`on the server knowing whether the request messages
`are fresh, even with fhe additional requirement that
`protocols be resistan? to password guessing attacks.
`To use timestamps in later stages of the protocol does
`not increase protocol efficiency either, because by then
`all parties will have the chance to exchange nonces
`
`28
`
`(piggybacked on earlier messages).
`Moreover, current techniques for protecting pass-
`words [l, 61 all require that a client, before receiving
`the session key, must either generate and send a pub-
`lic key (to the other client) or send a message to the
`server encrypted with the server’s public key. This
`is equivalent, in terms of efficiency, to requiring that
`each client send a nonce before receiving the session
`key, which is in fact a security requirement for nonce-
`based protocols. Therefore, we conjecture that pro-
`tocols resistant to password guessing attacks cannot
`be more efficient than nonce-based protocols, even if
`synchronized clocks can be assumed.
`We can further argue for this conjecture from an-
`other angle. Suppose timestamps do help, and because
`the difference in lower bounds between timestamp-
`based and nonce-based protocols is only one message
`OF one round [4, 51, then we can deduce that three
`messages are sufficient for both A and B to receive the
`session key from the server. In this case, because A has
`to initiate the protocol, a little analysis will show that
`B must receive the key in his first contact with the
`server. We know of no technique that achieves this
`goal - note that guessing attacks must not become
`possible after the session key is later used for hand-
`shaking or for encrypting traffic - unless we assume
`that S knows about a trap-door function on B’s side
`(e.g., B’s public key). An impossibility proof along
`this line of reasoning will be very useful.
`Nevertheless, in the case with a trusted third party,
`if either (or both) client, instead of the server, chooses
`the session key, then it is not difficult to check that
`using timestamps can reduce the numbers of messages
`and rounds to the theoretical lower bounds [4].
`
`8 Related Work
`
`Gong et al. [6, 81 and Bellovin and Merritt [l, 21
`developed the first authentication protocols that are
`resistant t o password guessing attacks. Gong [4, 51
`and Yahalom [ll], among others, have investigated
`the design of optimal authentication protocols.
`Tsudik and Van Herreweghen suggested protocol
`modifications in order to reduce the amount of en-
`cryption [lo]. Their techniques, including their use of
`user-generated encryption keys, potentially can also
`reduce the number of messages. However, in their
`protocols, a client cannot know if the session key he
`receives from the server is correct (i.e., has not been
`tampered with) until he later uses it. This deficiency
`is nevertheless compensated by their use of extremely
`short messages. This trade-off appears to be intrinsic.
`
`Authorized licensed use limited to: Stevens Institute of Technology. Downloaded on December 13,2022 at 20:20:29 UTC from IEEE Xplore. Restrictions apply.
`
`UNIFIED PATENTS EXHIBIT 1009
`Page 5 of 6
`
`

`

`and Communications Security, pages 26-37, Fair-
`fax, Virginia, November 1993.
`[5] L. Gong. Efficient Network Authentication Pro-
`tocols: Lower Bounds and Optimal Implemen-
`tations. Technical Report SRI-CSL-94-15, Com-
`puter Science Laboratory, SRI International,
`Menlo Park, California, October 1994.
`[6] L. Gong, T.M.A. Lomas, R.M. Needham, and
`J.H. Saltzer. Protecting Poorly Chosen Secrets
`IEEE Journal on Se-
`froim Guessing Attacks.
`lected Areas in Communications, 11(5):648-656,
`June 1993.
`[7] D.V. Klein. Foiling the Cracker: A Survey of, and
`Improvements to Password Security. In Proceed-
`ings of the 2nd‘ USENIX Unix Security Workshop,
`pages 5-14, August 1990.
`[8] T.M.A. Lomas, L. Gong, J.H. Saltzer, and R.M.
`Needham. Reducing Risks from Poorly Chosen
`In Proceedings of the 12th ACM Sym-
`Ke:ys.
`posaum on Operating System Principles, volume
`23(5) of ACM Operating Systems Review, pages
`14-18, Litchfield Park, Arizona, December 1989.
`
`[9] R. Morris and K. Thompson. Password Security:
`A Case History. Communications of the ACM,
`22(11):594-597, November 1979.
`[lo] G. Tsudik and E. Van Herreweghen. Some Re-
`marks on Protecting Weak Keys and Poorly-
`Chosen Secrets from Guessing Attacks. In Pro-
`ceedings of the 12th IEEE Symposium on Reliable
`Distributed Systems, pages 136-141, Princeton,
`New Jersey, October 1993.
`
`[ll] R. Yahalom. Optimality of Multi-Domain Pro-
`tocols. In Proceedings of the 1st ACM Confer-
`ence on Computer and Communications Security,
`pages 38-48, Fairfax, Virginia, November 1993.
`
`9 Summary
`
`Users are typically authenticated to a computer sys-
`tem or to each other by the use of their passwords.
`Because people are known to prefer convenient pass-
`words, which are easy to guess, researchers have dlevel-
`oped authentication protocols that protect user pass-
`words from guessing attacks, even if the attacker can
`monitor and record all messages exchanged duriing au-
`thentication. These proposed protocols, however, use
`more messages and rounds than those protocols that
`are not resistant to guessing attacks.
`In this paper, we have described new protocols that
`are resistant to guessing attacks and are also opti-
`mal in both messages and rounds, thus refuting the
`previously held belief that the additional requirement
`of protecting passwords from guessing attacks makes
`an authentication protocol inherently more expensive.
`Our protocols use the simple idea of letting the user
`choose a temporary key that is used by the seirver to
`encrypt its response message. We also show why some
`naive variations of the protocols are not secure, how
`to extend the basic idea to direct authentication and
`to the use of “secret” public keys, and why the use of
`timestamps may not make the protocols more efhcient.
`
`References
`
`S. Bellovin and M. Merritt. Encrypted Key
`Exchange:
`Password-Based Protocols Secure
`In Proceedrings of
`Against Dictionary Attacks.
`the IEEE Symposium on Research in Security and
`Privacy, pages 72-84, Oakland, California, May
`1992.
`
`[2] S. Bellovin and M. Merritt. Augmented En-
`crypted Key Exchange: A Password-Based Pro-
`tocol Secure Against Dictionary Attacks and
`Password File Compromise. In Proceedings cif thle
`1st ACM Conference on Computer and Cfmmu-
`nzcations Security, pages 244-250, Fairfax, Vir-
`ginia, November 1993.
`
`[3] D.C. Feldmeier and P.R. Karn. UNIX Pass-
`word Security - Ten Years Later.
`In Proceed-
`ings of Crypto’89, volume 435 of Lecture Notes in
`Computer Science, pages 44-63. Springer-’Verlag ,
`1989.
`
`[4] L. Gong. Lower Bounds on Messages and FLoundis
`for Network Authentication Protocols. In Pro-
`ceedings of the 1st ACM Conference on Computer
`
`29
`
`Authorized licensed use limited to: Stevens Institute of Technology. Downloaded on December 13,2022 at 20:20:29 UTC from IEEE Xplore. Restrictions apply.
`
`UNIFIED PATENTS EXHIBIT 1009
`Page 6 of 6
`
`

This document is available on Docket Alarm but you must sign up to view it.


Or .

Accessing this document will incur an additional charge of $.

After purchase, you can access this document again without charge.

Accept $ Charge
throbber

Still Working On It

This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.

Give it another minute or two to complete, and then try the refresh button.

throbber

A few More Minutes ... Still Working

It can take up to 5 minutes for us to download a document if the court servers are running slowly.

Thank you for your continued patience.

This document could not be displayed.

We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.

Your account does not support viewing this document.

You need a Paid Account to view this document. Click here to change your account type.

Your account does not support viewing this document.

Set your membership status to view this document.

With a Docket Alarm membership, you'll get a whole lot more, including:

  • Up-to-date information for this case.
  • Email alerts whenever there is an update.
  • Full text search for other cases.
  • Get email alerts whenever a new case matches your search.

Become a Member

One Moment Please

The filing “” is large (MB) and is being downloaded.

Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.

Your document is on its way!

If you do not receive the document in five minutes, contact support at support@docketalarm.com.

Sealed Document

We are unable to display this document, it may be under a court ordered seal.

If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.


Access Government Site

We are redirecting you
to a mobile optimized page.





Document Unreadable or Corrupt

Refresh this Document
Go to the Docket

We are unable to display this document.

Refresh this Document
Go to the Docket