A Class of Flexible and Efficient Key Management Protocols
`
`Colin Boyd
`Information Security Research Centre
`School of Data Communications
`Queensland University of Technology
`Brisbane Q4001
`Australia
`Emaik boyd@fit.qut.edu.au
`
`Abstract
`
`Cryptographic protocols for key establishment normally
`include some means to allow participants to ensure that a
`key is new and not replayed from an old protocol run. When
`the key is generated by a mutually trusted server this is usu-
`ally achieved by sending with the key a quantity known to
`be new. A different general method for achieving freshness
`in this context is proposed. A number of spec@ example
`protocols are given which have some practical advantages
`over previous published protocols.
`
`1. Introduction
`
`Protocols for authentication and key establishment are
`used to set up secure communications sessions. Protocols
`using symmetric cryptographic techniques usually involve
`a mutually trusted party who shares keys with the parties
`which will be involved in the session. The trusted party is
`often responsible for generation of the temporary session
`key. When a user receives a key from a trusted party what
`he needs to know, apart from the key’s value, is:
`
`0 which other users know that key.
`0 that the key is fresh for this session.
`
`The first of these properties is usually established by re-
`ceiving the names of the other recipients of the key in an
`authenticated message from a trusted server. The second
`is usually verified by checking the freshness of some item
`linked with the key. Typical methods are one of the follow-
`ing two.
`
`Challenge-Response The key recipient generates a ran-
`dom number and sends it to the server. This challenge
`
`is returned with the key. Since the recipient knows that
`the challenge is fresh he deduces that the key is also
`fresh.
`
`Timestamps When the key is sent by the server the current
`time is included. The recipient checks that the times-
`tamp is in a certain window of its current. clock time.
`
`Timestamps are problematic in applications involv-
`ing widely distributed systems because of the difficulties
`of clock synchronisation and so the challenge-response
`method is often preferred.
`Gong [7] has published a study of protocol efficiency
`concerns. The number of messages contained in a protocol
`is a measure of the number of separate events that must be
`initiated during a protocol execution. In many cases differ-
`ent messages may be sent in parallel. Gong defines a round
`to consist of all messages that can be sent and received in
`parallel within one time unit. The number of rounds re-
`quired by a protocol is a measure of the length of time that a
`protocol execution must take. Gong analysed and produced
`lower bounds for the number of messages and rounds that
`must be used in various types of secure protocols. In gen-
`eral, protocols that minimise the number of messages do not
`also minimise the number of rounds.
`In this paper a method of establishing key freshness is
`proposed which has largely been ignored in protocols of
`this type. General application of the method results in new
`protocols which have a number of potential advantages over
`previously published protocols; in particular it is possible to
`lower Gong’s lower bound for protocols in similar scenarios
`(although it should be emphasised that a different model for
`security is used). Another useful (and unusual) property is
`that it is possible to ‘cache’ replies from the server for use
`in later protocol executions.
`
`1063-6900/96 $5.00 0 1996 IEEE
`
`2
`
`Authorized licensed use limited to: Stevens Institute of Technology. Downloaded on December 15,2023 at 19:21:48 UTC from IEEE Xplore. Restrictions apply.
`
`UNIFIED PATENTS EXHIBIT 1023
`UNIFIED PATENTS, LLC v. DYNAPASS IP HOLDINGS LLC
`IPR2023-00425
`Page 1 of 7
`
`

`

`2. Novel Method for Freshness
`
`2.1. Freshness by Random Input
`
`The usual methods for estal9ishing freshness of a key
`have been outlinedabove. These rely on checking the fresh-
`ness of an element received with the key. An alternative way
`to ensure freshness is for the k.ey user to generate a fresh
`input to the key generation process. Now this methad is
`not new, but has been used where the key users themselves
`are responsible for key generation (usually called key agree-
`ment [12]). The new idea is that this mechanism can still be
`used as a general method for obltaining freshness even when
`a server remains responsible for maintaining confidentiality
`of the key - that is, who may glet the key. (In general, it is
`possible to divide most protocols into one of four classes
`depending on whether the users establish freshness by input
`or receipt, and on whether they control who gets the key or
`not. This idea is explored further in a related paper [53.)
`To use the idea the session key generated must be a func-
`tion f of several inputs. This function must have the right
`properties to ensure that the security requirements are satis-
`fied.
`
`1. In order to maintain confidentiality of the session key
`at least one input off must be c
`col participants. f should then
`without knowledge of this input, the value of f cannot
`be calculated whatever the values of the other inputs.
`2. To achieve freshness for each participant f must have
`the property that if each participant's input is fresh then
`it is infeasible to choose {he other inputs so that the
`output of f is an old value.
`
`It is possible to proceed to design protocols by simply
`specifying that the function used should have the desired
`properties. Luckily it turns out that suitable practical func-
`tions exist on which to base concrete protocols. These base
`functions are variously called kt?yed hashfunctions or mes-
`sage authentication codes (MACS). There has been consid-
`erable interest lately in the design of such functions [3, 11
`but as yet there appears to be no consensus on the exact
`properties that they should have' and so it is useful to sum-
`marise here the properties required for the protocols of in-
`terest.
`A keyed hashfunction (KHF) is a mapping f : IS x M -+
`C where I( is a space of hashing keys of a fixed size, M is
`the space of all binary strings of any finite size, and C is
`the space of all strings of a fixed size (typically 128 or 160
`bits). In addition the following security properties hold.
`' ws may well be because the exacl properties required vaxy in differ-
`
`ent application scenarios.
`
`KHFl(Practica1ity) Given any k and m it is easy to calcu-
`late f(k, m).
`KMF2 (Confidentiality) Without knowledge of k it is in-
`feasible to calculate f ( k, m) for any m, even given the
`value of many f(k, mi) (with mi # m).
`KKF3 (Freshness) Given k it is infeasible to find any
`pair of messages ml and m2 such that f(k, m l ) =
`f (k, m2).
`Note that KHFl and KHF;! together imply that it is infea-
`sible to find the hashing key k given many f(k, mi) values.
`The names given to the above properties correspond to the
`security properties for which they will be used in protocols
`and are not the usual names given to them. In particular,
`KHF3 is usually called collision resistance, but the need for
`it in the protocols is that it should be infeasible ever to force
`an old key to be re-used - in other words, by ensuring that
`the input is different from before, any participant can ensure
`the key is fresh.
`The definition of KKF above is very similar to that of
`Bakhtiari, Safavi-Naini and Pieprzyk [l], and is strictly
`weaker than that of Berson, Gong and Lomas [3]. Of prac-
`tical importance it should be noted that both the papers
`cited give constructions to obtain concrete KHFs, which can
`equally be used to implement the protocols discussed in this
`paper.
`
`2.2. General Methodology
`The general design for protocols can now be simply ex-
`plained. The session key will be derived as the output of
`e hashing key for the KHF could be shared be-
`forehand but in general this will not be the case and con-
`fidentiality of the session key will be derived from secure
`Uansport of the hashing key to all participants. The hashing
`key could be chosen by any participant depending on the
`scenario; below the idea is illustrated with the conventional
`scenario of a trusted server who chooses the secret.
`The novel aspect is the method of ensuring freshness.
`The session key SK key will be defined as
`SK = f(k, N1 INZl.. . IN,.)
`where f is a KIQF and N1 I NZ I . . . IN,. is the concatenation
`of the inputs by each of the T participants. The definition of
`the KHF guarantees that SA' has the required properties as
`follows.
`
`1 guarantees that all participants can efficiently
`derive SI<.
`o As long as k is known to be shared by only the par-
`ticipants (possibly in addition to one or more trusted
`servers) then KHM. guarantees that SK is confidential
`to the participants.
`
`3
`
`Authorized licensed use limited to: Stevens Institute of Technology. Downloaded on December 15,2023 at 19:21:48 UTC from IEEE Xplore. Restrictions apply.
`
`UNIFIED PATENTS EXHIBIT 1023
`UNIFIED PATENTS, LLC v. DYNAPASS IP HOLDINGS LLC
`IPR2023-00425
`Page 2 of 7
`
`

`

`o As long as each participant knows that at least one
`of NI, N2, . . . , N, is new then KHF3 guarantees the
`freshness of SI{.
`
`A distinctive aspect of this general design is that session
`key confidentiality and session key freshness are derived in-
`dependently. This leads to considerable flexibility in using
`such protocols and a number of useful properties not shared
`by other published protocols. This point is discussed further
`below.
`
`The following protocol presents a typical example of the
`methodology. The general format is typical for key manage-
`ment protocols using symmetric cryptography and a trusted
`server S. The two protocol users A and B initially share
`keys, K A S and KSS respeetively, with S. The aim of the
`is to allow A and B to establish a key K A B which
`p ~ o ~ o c o ~
`they are confident is a new key only known to themselves
`and S.
`
`A and B need to calculate the value of K A B by
`I ~ A B = f( Iis, N A I N E )
`where f is a previously agreed KHF. In this description dis-
`tinction is made between the cases where the encryption
`function used is needed to provide confidentiality and when
`it is needed to provide information integrity. The notation
`{ M } K denotes that the message M is encrypted using key
`I< and the encryption function used provides both confiden-
`tiality (to prevent the value lis from being discovered by an
`eavesdropper) and integrity (to prevent the identities of the
`users being altered). The notation [ M ] K , by contrast, de-
`notes that M is transformed only to provide integrity, but
`since M may sometimes contain information that should
`not be revealed it is also assumed that it is not feasible to
`obtain M from [MI,<. In other words, [M]lc may be re-
`garded as an integrity check value on M .
`
`3.1. Security
`
`The general form for the protocol has been designed to
`ensure that the chosen security requirements are achieved.
`Nevertheless it is worthwhile to consider carefully whether
`is is really the case for the concrete protocol reached.
`
`4
`
`This is especially true because the protocol appears, super-
`ficially, to be very similar to some protocols with known
`flaws.
`The first thing to note is that security may be considered
`with respect to each user separately; indeed the protocol is
`essentially symmetric with respect to A and B. Consider
`A’s viewpoint. She receives the message { A , B , K s ) K ~ ~
`from S (its physical routing via B is of no relevance). As
`long as the encryption provides integrity of data (an as-
`sumption it is important to make explicit) A can be sure
`that S intended Iis to be shared between A and B. The
`encryption must also provide confidentiality so that other
`users cannot gain access to this value.
`Since the message from the server carries no informa-
`tion to show that it is new, an obvious method of possible
`attack is to exploit the possibility of replaying an old ses-
`sion key KAB which has been compromised. It is a normal
`assumption in protocol analysis that such an attack is pos-
`sible. Let us consider what an attacker may gain from this.
`Since each user is able to gain independent assurance that
`each key used is fresh there is no chance €or the attacker to
`force the use of an old key. The only benefit he may be able
`to gain is to use knowledge of an old key to aid a cryptan-
`alytic attack. If the attacker could gain knowledge of KS
`this would be sufficient for him to be able to obtain the new
`keys shared by A and B . Thus Ks must remain as secure
`as the shared keys K A S and K s s 2 . Furthermore, the cryp-
`tographic strength of the KHF f should be equal to that of
`the encryption function used by the server.
`The security properties of the protocol can be sum-
`marised in the following result, subject to the assumption
`(normal for cryptographic protocols) that the cryptographic
`algorithms used are not subject to cryptanalysis.
`
`Claim 1 At the end ofa successful protocol run Alice and
`Bob can both be sure that the session key is new and shared
`only with the other and the trusted servel:
`
`3.2. Protocol Properties
`
`The protocol given above could be claimed as of inter-
`est in its own right as the product of a new design method.
`However it turns out to have some remarkable properties
`which give it distinct advantages over previously known ex-
`amples in a variety of situations.
`
`3.2.1
`Number of messages and rounds
`The protocol above has four messages. Since each message
`after the first relies on information received in the previ-
`2Note that at no time is h’s used to encrypt any value. Furthermore,
`if K s is stored for future use it may be safely left in the encrypted form
`as received from S so that there is no additional requirement for secure
`storage over more conventional schemes.
`
`Authorized licensed use limited to: Stevens Institute of Technology. Downloaded on December 15,2023 at 19:21:48 UTC from IEEE Xplore. Restrictions apply.
`
`UNIFIED PATENTS EXHIBIT 1023
`UNIFIED PATENTS, LLC v. DYNAPASS IP HOLDINGS LLC
`IPR2023-00425
`Page 3 of 7
`
`

`

`ous message it follows that the protocol also requires four
`rounds. However, it is possiblle to re-route some of the in-
`formation to form a related protocol with more messages
`but fewer rounds as follows.
`
`of using timestamps without introducing the problems of
`clock synchronisation. Further advantages are now consid-
`ered.
`
`1. A - t S : A , B
`2. A + B : A , N A
`3. S -t B : { A , B , I < s } K ~ ~
`4. S -t A : ( A , B , I < s } K ~ ~
`5. B + A : B , N g
`6. B -t A : [ N A ] K ~ ~
`7. A -t B : [ N B ] K ~ ~
`
`As before A and B calculate the value of KAB by
`KAB = f(Ks, NA I NB). Although this variant has an ex-
`tra three messages it is now possible to send messages 1 and
`2 in parallel, 3,4, and 5 in paridlel, and 6 and 7 in parallel
`thus reducing the number of rounds to three.
`Gong [7] has derived tight lower bounds for the number
`of messages and rounds for protocols in a variety of classes.
`One criterion used for classification is who generates the
`session key. Gong considers situations where the server
`alone chooses it, and where one or both users generate it.
`He does not consider that all three might take part.
`The other criterion used by Gong is whether freshness is
`achieved by timestamps or by nonces (random challenges).
`Of course the new protocol does not properly fall into either
`category but is much nearer to the second in that both rely
`on the generation of random numbers and do not rely on
`clock synchronisation.
`Gong’s lower bounds for protocols in which nonces are
`used, and where a handshake is included, are 5 messages
`and 4 rounds if the server chooses the key, or 6 messages
`and 5 rounds if the two users choose the key. Since we have
`demonstrated protocols lowering these bounds we arrive at
`the following result.
`
`Claim 2 Protocols using the new method for freshness can
`be designed to be more eficient in the number of rounds
`and the number of messages rhan any protocol using the
`conventional challenge-response method.
`
`It is not difficult to see that the reason this efficiency is
`achieved is that the server does not have to wait for nonces
`from both users before generating and distributing the ‘key’.
`This feature is common with protocols that rely on times-
`tamps for freshness and so it is not surprising that the lower
`bounds for this new class of protocols are the same as Gong
`has found for protocols using timestamps. In a sense it is
`reasonable to say that the new method gives the convenience
`
`3.2.2 Re-use of keying material
`
`To the reader familiar with similar protocols, one of the
`most striking features of the protocol above will be that the
`messages received from S by A and B are independent of
`the input from A and B. Of course the whole point is that
`freshness does not come from the server’s input, but an un-
`expected consequence is that users may save much compu-
`tation.
`Certain authors [lo, 91 have noted that it may some-
`times be desirable to renew authentication during a ses-
`sion without contacting the server again; those same authors
`have given protocols to achieve this. With the new proto-
`col above re-authentication can be achieved in an obvious
`and simple manner. A and B simply choose new random
`values NA and NA and use these to define the new key
`I<;, = f(Ks, N i l N L ) . This may then be followed by
`a handshake to establish that the other has the key.
`This feature may also be exploited to delay authentica-
`tion and key exchange until a later time without using the
`server. Consider the following variant protocol.
`
`1. A + S : A , B
`
`3. A + B : A, B , { A , B, K s } I < ~ ~ ,
`N A
`
`Here messages 1 and 2 may be exchanged at any time be-
`fore the other messages and without knowledge of B. This
`means that A may cache messages from S to use at any later
`time. A may also use these cached messages multiple times.
`Note that there is no security problem with this since A and
`B insert new inputs each time to give key freshness. We can
`as
`
`regard the values { A , B , K s } I c ~ ~ and { A , B , K s } K ~ ~
`renewable tokens for A and B.
`As long as f is a good KHF, there is no reason to suppose
`that KS will become any more vulnerable than the long-
`term keys K A S and KBS even with repeated use. Of course
`eventually K A S and I<BS will be changed, at which time
`the cached keys will become invalid. Notice that there is no
`necessity to store the renewable tokens securely as long as
`they remain in their encrypted state and only decrypted at
`their time of use.
`
`5
`
`Authorized licensed use limited to: Stevens Institute of Technology. Downloaded on December 15,2023 at 19:21:48 UTC from IEEE Xplore. Restrictions apply.
`
`UNIFIED PATENTS EXHIBIT 1023
`UNIFIED PATENTS, LLC v. DYNAPASS IP HOLDINGS LLC
`IPR2023-00425
`Page 4 of 7
`
`

`

`4. Discussion
`
`4.1. Comparison with Previous Protocols
`
`As already mentioned, the general structure of the new
`protocols has many similarities with well known protocols
`but the fundamentally different method to obtain freshess
`has far-reaching consequences. One noteable protocol with
`similarities is due to Gong from 1989 [6]; in that proto-
`col one of the principals obtains freshness by input while
`the other receives a nonce with the session key. It is also
`worthwhile to compare a recent protocol of Kao and Chow
`[9]. They employ a novel method to obtain freshness which
`involves using a short-term key just for this purpose. The
`following is a successful run of their protocol.
`
`As above, { M } K denotes the message M encrypted
`with key IC where (presumably) the encryption provides
`both message confidentiality and integrity. The short-term
`key Kt is used only for the duration of the protocol run and
`is then destroyed by both parties. This means that it is un-
`reasonable to assume that the key Kt will be found by an
`attacker and so used in a replay attack. This enables the
`protocol also to lower Gong’s bound for nonce-based pro-
`tocols (again within a different security model). However,
`there are other security implications of their method; in par-
`ticular user A is able to force use of an old key - a curious
`property not discussed by the authors. Furthermore, it does
`not obtain the flexibility of key caching or re-use since the
`nonce chosen by A is included in the reply from the server.
`There is also a certain similarity between the methods
`advocated here and the 3 party EKE protocol described by
`Steiner, Tsudik and Waidner [1313. In their 3-party EKE
`protocol principals A and B both contribute to the key value
`and thus obtain freshness by input to the key. A trusted
`server shares secret passwords with A and B and uses these
`to transfer authentication between them. An advantage of
`the 3-party EKE over the protocols presented above is that
`it providesforward secrecy; that is, compromise of secrets
`does not compromise previously agreed session keys. How-
`ever, because both A and B need to contribute their values
`to the server before getting their reply, the number of rounds
`
`31 am grateful to one of the anonymous referees for pointing out this
`similarity.
`
`6
`
`remains the same as for conventional uses of nones. Also,
`because the server responses depend on the user input, key
`caching and re-use are not possible.
`The comparison with 3-party EKE suggests the follow-
`ing novel protocol which may be viewed as a combination
`of 3-party EKE with the ideas presented in this paper. In the
`following g is the generator of an appropriate multiplicative
`group such as the integers modulo some large prime. The
`other notation is the same as elsewhere in the paper.
`
`2. A - B : A,gNA
`
`1. A - + S : A , B
`
`3. S + B : {A, B , K ~ } I < , ,
`4. S + A : ( A , B , I C S } K ~ ~
`5. B - A : B,gNE
`6. B + A : [ g N A ] ~ a s
`7. A ---t B : [ g N B ] ~ c A B
`Here the session key is calculated by A as KAB =
`(gNB)NAICs and by B as ICAB = (gNA)NBKs. This pro-
`tocol has the advantages of the protocols examined ear-
`lier and also has the forward secrecy property of 3-party
`EKE. Notice that it is necessary here that the function
`f(k, N A , N B ) = g k N A N B has the required security prop-
`erties as described in section 2.1. Also it should be noted
`that one feature of 3-party EKE has been lost, namely that
`the shared keys could be passwords (indeed this was the
`whole motivation for the original EKE protocols [2]); in the
`protocol above the shared keys KAS and ICBS must be full
`length keys not vulnerable to dictionary attacks
`
`4.2. Vulnerability after Key Compromise
`
`The security analysis given above makes the assumption
`that the key ICs has not been compromised. Since it is
`never used as a session key, or indeed to encrypt any in-
`formation at all, this is a reasonable assumption in normal
`operation of the protocol. However, the possibility that at
`sometime a key ICs becomes compromised cannot be dis-
`counted. Now this may just as likely happen to a long term
`key such as KAS in any protocol using shared keys, and the
`expected consequence would be that the key would be re-
`placed. However, it was pointed out by Gong [8] that there
`is a significant difference here from protocols which gain
`freshness from an element received with the message.
`Suppose, for example, that K A S is compromised. Then
`A should ensure that it is replaced with a new value. Then
`any renewable tokens { KS , A, B}lcAS previously used with
`any B are also compromised. However, the corresponding
`token { ICs, A , B } I ~ , , remains valid for B whether ICAS is
`
`Authorized licensed use limited to: Stevens Institute of Technology. Downloaded on December 15,2023 at 19:21:48 UTC from IEEE Xplore. Restrictions apply.
`
`UNIFIED PATENTS EXHIBIT 1023
`UNIFIED PATENTS, LLC v. DYNAPASS IP HOLDINGS LLC
`IPR2023-00425
`Page 5 of 7
`
`

`

`replaced or not, allowing an attacker who knows the com-
`promised Ks value to masquecade as A to B . At first sight
`it seems as though all the lon,g-term keys must therefore
`be replaced. This is a very prclblematic conclusion partic-
`ularly since a malicious A could deliberately compromise
`KAS and thereby inconvenience all other users (effectively
`mounting a denial of service attack). Further thought re-
`veals that the situation is not (quite so bad as is now ex-
`plained.
`The tokens { K s , A , B } K ~ : ; bear considerable resem-
`blance to public key certificates which provide signed
`copies of public keys [ll]. Like certificates, the renew-
`able tokens provide a ‘certifiedl’ copy of the keying mate-
`rial Ks, although they can only be used with a single other
`user. Compromise of a private key leaves the certificate of
`the corresponding public key still valid even after the pub-
`lic key itself has been changed. For this reason manage-
`ment of public keys usually involved a revocation list of
`public key certificates that are known to be compromised
`and have been revoked [ 111 (analogous to a ‘black list’ of
`stolen credit cards).
`A practical implementation of the technique suggested
`in this paper would require a mechanism for revocation of
`tokens if there is any possibility of a long-term key or a
`token being compromised. It w,as also pointed out by Gong
`[8] that the same property also applies to the protocol of Kao
`and Chow mentioned in sectiaa 4.1. Therefore a similar
`countermeasure must be taken in their protocol too. The
`view may be taken that use of a renewable token has many
`of the advantages of public key!;, since they may be re-used
`and thus in many cases allow key exchange without an on-
`line server. (It should be emphasised that the analogy does
`not extend beyond this.) The price to be paid appears to be
`the need for key revocation lists.
`
`4.3. Design of Other Protocols
`
`It is easy to design other protocols with the same method
`for freshness using the design principles explained else-
`where [4]. For example the message from S may be sent
`in two messages as a ‘split channel’ protocol as follows. In
`this protocol the confidentiality and integrity properties are
`provided separately.
`
`provides confidentiality whereas, as above, [MI K denotes
`an integrity check value of M protected by I<. The ar-
`guments supporting the security of the protocol still hold,
`while much flexibility in choosing the crypto-algorithms is
`achieved.
`Another example is the following conference key pro-
`tocol which has the same advantages explained above over
`the similar nonce-based protocol. In this protocol the set
`of users is U = { U1, U,, . . .} and for convenience it is as-
`sumed that U1 initiates the protocol. In step 2 the server S
`sends the value I<s together with the identities in U to each
`user Ui using the shared key I<ui S. In the third step the no-
`tation Ui + * denotes that each user broadcasts a random
`number. The shared conference key will be the value
`
`1. U 1 + S : U
`
`3. Ui - + * : Ni
`
`4.4. Conclusion
`
`In this paper a novel method for obtaining key freshness
`in server-based protocols has been introduced. An example
`protocol using this method has been given, together with
`several variants, which appear to consitute new and pre-
`viously unpublished protocol examples. There are several
`benefits of using this method.
`
`The number of messages and rounds used is reduced to
`the same as when using timestamps. (An example pro-
`tocol given in this paper appears to be more efficient
`in the number of rounds obtained than any previously
`published protocol which uses nones.)
`
`Server messages may be cached to be used, or re-used,
`at a later time.
`
`It may be used as a general purpose replacement for
`challenge-response mechanism in a wide variety of
`scenarios.
`
`Acknowledgements
`
`I am very grateful to Wenbo Mao of Hewlett Packard
`Laboratories for helpful discussions regarding the ideas ex-
`pressed in this paper. Li Gong of SRI pointed out the diffi-
`culties of key compromise and made a number of other very
`helpful comments.
`
`7
`
`Authorized licensed use limited to: Stevens Institute of Technology. Downloaded on December 15,2023 at 19:21:48 UTC from IEEE Xplore. Restrictions apply.
`
`UNIFIED PATENTS EXHIBIT 1023
`UNIFIED PATENTS, LLC v. DYNAPASS IP HOLDINGS LLC
`IPR2023-00425
`Page 6 of 7
`
`

`

`References
`
`[l] S. Bakhtiari, R. Safavi-Naini and J. Pieprzyk, “Keyed
`Hash Functions”, Cryptography: Policy and Algo-
`rithm, Springer-Verlag, 1996, pp.201-214.
`[2] S. Bellovin and M. Memtt, “Encrypted Key Ex-
`change: Password-based Protocols Secure against
`Dictionary Attacks”, Proceedings IEEE Symposium
`on Security and privacy, May 1992, pp.72-84.
`[3] T.A. Berson, L. Gong and T.M.A. Lomas, “Secure,
`Keyed and Collisionful Hash Functions”, Technical
`Report, SRI International, September 1994.
`[4] C. Boyd, “Desiging Secure Key Exchange Protocols”,
`ESORICS ’94, Springer-Verlag, 1994, pp.93-105.
`[5] C. Boyd, “A Framework for Design of Key Establish-
`ment Protocols”, Australian Conference on Inform-
`tion Security and Privacy, Wollongong, June 1996, to
`appear.
`[6] L. Gong, “Using One-way Functions for Authenti-
`cation”, Computer Communications Review, Vo1.19,
`pp.8-11, October 1989.
`[7] L. Gong, “Efficient Network Authentication Proto-
`cols: Lower Bounds and Optimal Implementations”,
`Distributed Computing, 9(3), 1995.
`[8] L. Gong, Private Communication, September 1995.
`[9] I-L. Kao and R. Chow, “An Efficient and Secure Au-
`thentication Protocol using Certified Keys” Operating
`Systems Review 29,3, July 1995, pp.14-21.
`[lo] A. Kehne et. al., “A Nonce-Based Protocol for Multi-
`ple Authentication”, ACM Operating Systems Review,
`26,4, October 1992, pp.84-89.
`[ll] S. Kent,“Privacy Enhancement for Internet Electronic
`Mail: Part 11: Certificate-Based Key Management”,
`RFC 1422.02/10/1993.
`[12] R. Rueppel and P.C. van Oorschot “Modem Key
`Agreement Techniques”, Computer Communications,
`17,7, July 1994, pp.458-465.
`[13] M. Steiner, G. Tsudik and M. Waidner, “Refinement
`and Extension of Encrypted Key Exchange”, ACM Op-
`erating Systems Review, 29,3, July 1995, pp.22-30.
`
`8
`
`Authorized licensed use limited to: Stevens Institute of Technology. Downloaded on December 15,2023 at 19:21:48 UTC from IEEE Xplore. Restrictions apply.
`
`UNIFIED PATENTS EXHIBIT 1023
`UNIFIED PATENTS, LLC v. DYNAPASS IP HOLDINGS LLC
`IPR2023-00425
`Page 7 of 7
`
`