CN101116281A - Challenge-response signatures and secure diffie-hellman protocols - Google Patents

Abstract

A method (and structure) of exchange between two parties interconnected by a device or network. A recipient party (verifier) chooses a secret value x for computing a value X=F1(x), where F1 comprises a first predetermined function having at least one argument, the value x being one of the at least one argument of F1. A signing party (signer) chooses a secret value y for computing a value Y=F2(y), where F2 comprises a second predetermined function having at least one argument, the value y being one of the at least one argument of F2. The signer obtains the value X, and the signer has a private key b and a public key B. The signer computes a value s=F3(y,b,X), where F3 comprises a third predetermined function having at least three arguments: the value y, the private key b, and the value X being three arguments of the at least three arguments of F3. There exists a fourth predetermined function F4(x,Y,B) to calculate a value s', F4 having at least three arguments: the value x, the value Y, and the public key B being three arguments of the at least three arguments of F4, but the value s is not an argument of F4. There exists no secret shared between the verifier and the signer that serves as a basis for any argument in any of the functions F1, F2, F3, and F4. The verifier can consider the values s and s' as valid authenticators if value s' is determined to be related in a predetermined manner to value s.

Description

Challenge-response signature and secure diffie-hellman protocol

Technical Field

Aspects of the invention generally relate to signatures that are provably secure for both the sending and receiving parties of an information exchange. More specifically, the challenge-response (challenge-response) signature scheme possesses the property that both a verifier and a signer can compute the same or related signatures, the former by knowing the challenge and the latter by knowing the secret signature key (private signature key), thereby permitting, in exemplary embodiments, variants of the provably secure, conventional key exchange protocols, including variants of the well-known MQV protocol.

Background

As originally suggested, the Diffie-Hellman (DH) key exchange protocol 100 shown in fig. 1 is considered secure against eavesdropping-only attackers. The search for "authenticated Diffie-Hellman" protocols to combat effective, man-in-the-middle attacks has led to numerous ad-hoc proposals, many of which have been compromised or shown to be disadvantageous. With the recent development of a rigorous security model for key exchange, those skilled in the art are now in a much better position to judge the security of these protocols and to develop designs that can prove resistant to realistic effective attacks.

As expected, adding safeguards against valid attacks results in increased complexity, both in terms of additional communications and in terms of additional computations. The latter is particularly important in protocols that utilize public key technology authentication, which typically requires additional expensive group exponentiation. In addition to the need for reliable security, many practical applications for key exchange have prompted designers to improve the performance costs associated with authentication mechanisms, especially those based on public keys.

One line of inquiry (PK) was initiated by Matsumoto, takashima and Imai in 1986 to authenticate Public Keys (PKs) that would add minimal complexity to the protocolSearch of the DH protocol. Theoretically, the communication of a protocol is expected to be entirely considered a basic DH exchange until the exchange of the authentication public key. In the case of the technique, it is preferable that,authentication of the protocol must be obtained through the key derivation process: all parties will be in harmony with g ^x 、g ^y Agreeing on the key combined with the public/private key of the parties, rather than on the basic Diffie-Hellman key g ^xy A agreement is reached.

Partly because of the practical advantages such protocols will provide, and partly because of mathematical challenges after such design, many protocols have been developed under this approach, often referred to as "authenticatable Diffie-Hellman protocols". Not only can this approach generate a protocol that is a very efficient communication-wise (communication-wise), but authentication in conjunction with the key derivation process can potentially result in significant computational savings. For these reasons, several of these "implicitly certified" protocols have been standardized by major national and international security standards.

Among these protocols, the MQV protocol appears to have been widely standardized. This protocol has been standardized by many organizations and recently has been announced by the National Security Agency (NSA) as a key exchange mechanism underlying "next generation cryptography to protect U.S. government information" that includes protection of "classified" or mission critical national security information ".

In addition, MQV appears to have been designed to meet a range of security goals. The basic version of the MQV protocol is explained, for example, in U.S. patent No. 5,761,305 to Vanstone et al.

However, despite its attractiveness and success, MQV has so far circumvented any formal analysis in a well-defined model of key exchange. The present invention motivates the desire to provide such an analysis. In conducting research, the inventors observed that virtually none of the stated MQV goals could be shown to hold, as implemented in the computational key exchange model of Canetti and Krawczyk, and as described in the above-identified provisional application.

This result has led the inventors to focus on the security of this conventional protocol. Thus, based on this analysis that conventional MQV protocols cannot be proven to be secure, there is a need for increased security for MQV while preferably maintaining its existing performance and versatility.

Disclosure of Invention

In view of the foregoing and other exemplary problems, drawbacks, and disadvantages of the conventional systems, an exemplary feature of the present invention is to provide a method and structure for a new variant of MQV (referred to herein as HMQV) that achieves the security goals of the MQV protocol in a demonstrable manner.

Another exemplary feature of the present invention is to demonstrate a new digital signature scheme, referred to herein as a "challenge-response signature".

Another exemplary feature of the present invention is that the challenge-response signature scheme is demonstrated as including a version of what is referred to herein as an "exponential challenge-response" (XCR) signature scheme derived from the Schnorr identification scheme, as providing a protocol mechanism having the property that both the challenger and the signer can compute the same or related signatures, the former computed by having selected challenges and the latter computed by knowing a secret signature key.

It is therefore an exemplary object of the present invention to provide a structure and method for improving security for authenticated Diffie-Hellman protocols, wherein security can be demonstrable by implementing therein the concept of an XCR signature scheme.

In a first exemplary aspect of the present invention, to achieve the above features and objects, there is described herein a method of exchange between two parties interconnected by a device or network, comprising a recipient (verifier) selecting a secret value X for calculating a value X = F1 (X), wherein F1 comprises a first predetermined function having at least one argument, said value X being one of said at least one argument of F1. The signer (signer) selects a secret value Y for calculating a value Y = F2 (Y), where F2 comprises a second predetermined function having at least one argument, the value Y being one of the at least one argument of F2. The signer obtains the value X, the signer also having a private key B and a public key B. The signer computed value s = F3 (y, b, X), wherein F3 comprises a third predetermined function having at least three arguments, the value y, the private key b and the value X being three of the at least three arguments of F3. There is a fourth predetermined function F4 (x, Y, B) to calculate a value s', F4 having at least three arguments, the value x, the value Y and the public key B being three of the at least three arguments of F4, but the value s not being an argument of F4. There is no shared secret between the verifier and the signer that is used as a basis for any argument in any of the functions F1, F2, F3 and F4. If it is determined that the value s 'is related to the value s in a predetermined manner, the verifier may consider the values s and s' as valid certifiers.

In second and third exemplary aspects of the invention, there is also described herein an apparatus implementing the method described in the preceding paragraph, and a signal-bearing medium tangibly embodying a program of machine-readable instructions executable by a digital processing apparatus to implement the method.

In a fourth exemplary aspect of the invention, a method for establishing an authentication key between two parties interconnected by a device or network is also described herein. The first party has a private key a and a public key A, the private key a being an integer such that 0 ≦ a ≦ q-1, q being a positive integer, g being a generator of a finite group of order q, and A being an element in a group generated by the value g and calculated as A = g ^a . The second party has a private key B and a public key B = g ^b The private key b is an integer such that b is greater than or equal to 0 and less than or equal to q-1. The first party chooses to calculate a value of X = g ^x Is an integer such that 0 ≦ X ≦ q-1, and the value X is communicated to the second party. The second party selects to calculate a value of Y = g ^y Y is an integer such that 0. Ltoreq. Y.ltoreq.q-1, andthe value Y is communicated to the first party. The first calculated value

Where m, m' comprise messages known or exchanged between the parties and the second party calculates a value

The function f ₂ And f ₄ Comprises a function H having at least one argument, one such argument being at least one of said messages m and m', wherein H comprises a cryptographic function, an encryption function and a cryptographic hash function being one of the one-way functions. The first and second parties derive a shared key from the values s and s', respectively.

Drawings

The foregoing and other objects, aspects and advantages will be better understood from the following detailed description of a preferred embodiment of the invention with reference to the drawings, in which:

FIG. 1 illustrates a basic (unauthenticated) Diffie-Hellman protocol 100;

FIG. 2 illustrates a two-message Diffie-Hellman protocol 200 authenticated through the use of digital signatures;

FIG. 3 shows a comparison 300 of the computation of the session key K in the conventional MQV protocol versus the computation of the session key of the HMQV protocol of the present invention, demonstrating in one exemplary embodiment how HMQV utilizes a hash that is appended to the hash used in MQV;

FIG. 4 shows a diagram 400 that differs from the HMQV protocol shown in FIG. 3;

fig. 5 exemplarily shows a calculation 500 of XCR;

fig. 6 shows an example of the calculation 600 of a non-interactive XCR signature;

FIG. 7 illustrates the computation 700 of dual XCR signatures for both parties;

FIG. 8 shows an HMQV as exemplarily embodied in a three message Key validation (HMQV-C) protocol 800;

FIG. 9 shows an HMQV as exemplary embodied in a one-way (one-pass) key exchange 900;

FIG. 10 illustrates an exemplary hardware/information handling system 1000 for incorporating the present invention therein; and

fig. 11 illustrates a signal-bearing medium 1100 (e.g., storage medium) for storing steps of a program of a method according to the invention.

Detailed Description

Referring now to the drawings, and more particularly to FIGS. 1-11, there are shown exemplary embodiments of methods and structures according to the present invention.

As a preliminary note for clusters and tokens, all protocols and operations discussed herein assume a cyclic cluster G of order q (typically a prime number) generated by a generator G. The bit length of q is represented by | q | (e.g.Meaning the logarithm of q with a base of 2, rounded up to the nearest integer) and this quantity is used as the implied security parameter. For simplicity, as is common in practice, it is assumed that the parameters G, G and q are fixed and known in advance by the parties. Alternatively, these values may be included in a certificate or the like.

The multiplicative representation of a group operation is used herein, but the process is equally applicable to additive groups, such as elliptic curves or any other algebraic or specific group, finite field, complex mode, etc. In the protocol, the public key represented by a capital letter (e.g., a, B) is an element in group G, and the private key represented by a corresponding lower case letter (e.g., a, B) is Z _q An element of (1), wherein Z _q Represents the set of integers 0, 1.

For example, public key a = g ^a Corresponding to private key a. The party with A as its public key will use

To denote, by convention, is considered "Alice" (the second party)

Conventionally considered as "Bob"). In general, "annotation notation" (hatnotation) "is used to denote the logical or" distinguishing "identity of parties in a protocol, such as names, email addresses, roles, and the like. In some cases, these identities may be supplemented with digital certificates. For the more complete mathematical analysis provided in the provisional application, which is not repeated here, consider the implementation of the parties to the protocol, including the attacker, by means of a probabilistic polynomial time machine. AttackThe hitter is also represented by M, where M may represent "malicious (malicious)".

Thus, as shown in FIG. 1, the computation of the session key for the basic unauthenticated Diffie-Hellman protocol 100 involves the inclusion of two parties

Is exchanged therebetween, wherein

In the first direction

The party sends its key X = g ^x And is and

the party then passes its key Y = g ^y Is transmitted back to

Party to respond, and wherein x and y are each independently selected from

And

from the set Z _q A randomly selected secret, and wherein the shared session key is calculated as g ^xy 。

Note that in the description herein, the symbol ∈ _R Sometimes used to denote random selection. For example, x ∈ _R Z _q Meaning from the integer set Z _q The value x is chosen randomly, typically by using a random or pseudo-random number generator.

MQV protocol:

in addition to identity

Additional information such as public key certificates may be included or these identities may be omitted altogether, with the communications in the MQV protocol being the same as the basic unauthenticated DH protocol 100 depicted in fig. 1.

The first challenge in designing a two-message authenticated key exchange protocol is to prevent a successful attack based on the replay of the first protocol messages. This is problematic because the first message cannot include any form of session-specific "freshness assurance" (e.g., like a nonce or a fresh DH value) contributed by the responder. One solution to this problem is to provide freshness by computing session keys.

The two-message Diffie-Hellman protocol 200 shown in figure 2 is authenticated using digital signatures, for example, as employed by the ISO (international standards organization) 9793 protocol. Albeit atUnder the signature of (2) comprises g ^x Provides the freshness of authentication, but in

The protection measure is not present in the message(s) of (1). And a session key g ^xy Is guaranteed to be fresh (and independent of other session keys) because it is randomized by fresh y. However, if an attacker can find it

In and with

The single (x, g ^x ) In pair, the security of the protocol is broken, in which case the attacker also knowsThis allows an attacker to use the same message and his knowledge of x to be undirected

False capAnd need not ever have to knowThe long-term secret signing key.

This is a serious weakness that violates the rationale that information specific to short (ephemeral) sessions (e.g., (x, g) ^x ) To) should not leak other sessions. In view ofMultiple applications will compute the (x, g) offline ^x ) This is especially true for and keeps them in less protected memory than, say, long-term private keys.

How can one design a two-message protocol that is resistant to replay attacks (replay attack) even when transient information is leaked? The usual answer is to include the long-term private key into the calculation of the session key. This is a method that has been proposed by Matsumoto, takashima and Ima in 1986, which motivates many so-called "implicitly certified" variants of Diffie-Hellman, including MQV. In this approach, each party has a long-term DH public key and its corresponding secret component, and a session is generated by combining a session-specific ephemeral DH value with the public and private keys of the parties. The security of such a protocol thus depends entirely on the exact details of this combination of keys. Notably, this seemingly simple idea is difficult to implement safely with all previous protocols having several drawbacks.

Now consider the following general solution to the problem of combining ephemeral and long-term keys in session key computation, when

And

when they want to exchange keys, they do the basic Diffie-Hellman protocol and calculate the session key as K = g ^(x+a)(y+b) ＝(YB) ^x+a ＝(XA) ^y+b . In this case, if an attacker learns x but not a, it cannot compute K.

However, the protocol is still insecure, as demonstrated by the following simple attack: m selects the value x ^* ∈ _R Z _q Calculating

And to

Transmitting X as a pair from

Counterfeiting of the initial message.

Transmitting Y = g ^y And calculates the session key K = (X a) ^y+b . Unfortunately, M can also calculate K as (BY) ^x* . Thus, the protocol is not secure.

Further, even if the calculation of K becomes K = g for the constants d, e ^(x+da)(y+eb) Then attacks are still possible. On the other hand, if the constants d, e are allowed to vary with X and Y in such a way that an attacker cannot control e and Y, respectively, the above simple attack may not work. This idea takes us back to the design of MQV, where

And is

The calculation 301, 302 of the session key K in MQV is shown in FIG. 3, where

Party has long-term private key a E Z _q And the corresponding public key a = g ^a . Similarly, the private/public key pair of B is (B, B = g) ^b ) And the transient DH value is X = g ^x 、Y＝g ^y Wherein x and y are selected from A and B, respectively. The calculation of the session key also uses the valueAnd

wherein for l = | q |/2,

and

it is noted that

The calculation of the session key involves calculating X = g ^x One of the two fastenersMachine exponentiation for calculating B ^e Is used for an on-line exponentiation, and is used for (YB) ^e ) ^x+da Additional online exponentiation of. However, it is also noted that the second exponentiation uses an exponent e of length | q |/2, and thus it counts as "half exponentiation" (e.g., half the number of modular multiplications relative to the normal exponentiation of g). Same count of operation to

This is true.

In summary, the performance of MQV is truly impressive: the same communication as the basic unauthenticated DH protocol (except for possible transmission of certificates that are part of the identity of the parties) and only half more exponentiation than the basic protocol, which is only computationally increased by 25% to obtain an authentication exchange. This is significantly better than any of the proven DH protocols that rely on digital signatures for authentication or public key encryption, which involve more expensive operations and increased bandwidth. It is also the most efficient implicitly certified DH protocol, closest to the "Unified Model" protocol that requires three full exponentiations but provides fairly few security features.

This extraordinary performance and commitment to security make MQV an attractive candidate when choosing an authenticated DH protocol. For these reasons, this protocol has been adopted for many standards and is widely discussed in the literature. However, since any formal analysis of the MQV protocol has not been successfully performed in any formal model of key exchange security, one question that has not been answered so far is how secure the MQV protocol is indeed.

On the other hand, MQV designers have defined security goals behind the design. These include basic security against impersonation and known-key attacks, including against "Unknown Key Sharing (UKS)" attacks, and more specific features such as complete forward secrecy (PFS) and resistance to KCI (key leakage impersonation) attacks. Resistance to known key attacks represents the principle that disclosure of ephemeral session-specific secret information should not compromise the security of other sessions.

The PFS and KCI properties relate to the limitation of security compromise in case a private key of a party is revealed to an attacker M. More specifically, PFS means that any session key established between two uncorrupted parties cannot be known by M even if both parties are corrupted after the session key is cleared from both parties' memories. Knowledge of anti-KCI attack requirements

The long-term key of a party and can therefore obviously be counterfeited to other parties

Is unable to attack

And impersonating other uncorrupted parties.

Unfortunately, as further described in the above-referenced provisional application, the results of the analysis by the present inventors indicate that the MQV protocol does not satisfy any of these characteristics when formally studied. In particular, it is demonstrated in the security model of Canetti and Krawczyk that this protocol is open to a range of attacks, which contradicts the above-mentioned security properties that are claimed to be satisfied by MQV.

HMQV protocol:

the HMQV protocol (which may be considered "H" to mean "Hash") is a simple but powerful variant of MQV, which in various exemplary embodiments may include a Hash (hashing), such as that shown at step 303 in fig. 3, in addition to the conventional MQV protocol for comparison shown at step 302. It is further noted, however, that as an initial matter, the hashing steps of these exemplary embodiments are not a prerequisite of the present invention, as alternative embodiments that do not require hashing and use different techniques than hashing are discussed herein and are also included in the concepts of the present invention. The more basic concept of the invention relates to a challenge-response signature scheme, from which a number of applications and embodiments are derived, including exemplary hashed versions of the MQV protocol.

Hashing, as is well known in the art, involves the use of a hash function to convert a string of characters into a number, a fixed length string (e.g., hash or message digest) or the like as output. The basic functionality of a hash function in cryptography is to have a "one-way" or "irreversible" transformation, meaning that it should not be feasible to retrieve the original data, and also to construct a block of data that matches a given hash value. Hash functions can range from simple "mixing" functions to transformations like pure random scrambling (scrambling). The latter is referred to as a "strong cryptographic hash function" and is often modeled in cryptographic analysis by a notional random function (or "random oracles").

Several hash functions are widely used for strong cryptographic hashes. For example, MD5 takes a data block of arbitrary size as input and generates a 128-bit (16-byte) hash by using a bit-by-bit operation, an addition, and a table of values based on a sine function that processes data in a 64-byte block. Another major hashing function is the NIST (national institute of standards and technology) Secure Hashing Algorithm (SHA) which provides 160-bit hashes.

Typically, hash functions are not used directly for encryption, but encryption functions provide one-way transformations and are therefore applicable to some hashing purposes, including some exemplary embodiments of the present invention. Hash functions are also well suited for data authentication and are used for such purposes in conjunction with secret keys (in these settings they are often referred to as message authentication codes MAC or pseudo-random functions PRF) or signature schemes (where hash values are used for "message digests").

Various exemplary embodiments of the present invention use at least one hash function, H, that is extracted as the ideal random oracle in the security analysis described in more detail in the provisional application referenced above. The two tasks for which function H is used in these exemplary embodiments are as follows: firstly, calculating indexes d and e; and second, derive the session key itself.

The first task illustratively uses two arguments for H and outputs a string of length | q |/2, while the second task applies H to a single argument and outputs a key of specified length (e.g., 128 bits). To simplify notation, the same symbol H is used to denote both applications of the hash function. Indeed, a single H may be used, say SHA-1, which may process variable length inputs and may adjust its output size to accommodate both tasks, possibly using some combination of truncation/expansion (truncation/expansion) in generating the hash result.

However, it is also noted that if hashing is used as in the first task, it will not necessarily be limited to two arguments, as additional arguments such as timestamps, nonces, etc. may be included as inputs into the hash function, rather than just hashing the message or the identity of a party.

When hashing is used, the hash function used to generate the exponents d, e (typically with an output of l = | q |/2 bits) is often used

And the hash function applied to the sigma value with a k-bit output is denoted by H. In fact, the same hash function may be used with different output lengths, and therefore sometimes the symbol H is used instead of

As a result of the memory symbol,

the cross bar in (1) indicates that the output of the function is used as an index.

As in MQV, the communication of the HMQV protocol is the same as the basic DH exchange shown earlier in FIG. 1, with possible additional credentialsA book. As illustrated in fig. 3, in the calculation of the values d and e, the calculation of the session key K is different from the calculation of MQV, which involves a hash of one party's own DH value and the identity of the peer. The typical output of this hash is l = | q |/2 bits. Additionally, in one exemplary embodiment, HMQV will take on values

Is assigned to a k-bit key, where k is the length of the desired session key. In alternative embodiments, one or both sigma functions are not hashed.

From the present description, it can be seen that HMQV maintains the significant performance of MQV in both communication and computation. At the same time, HMQV overcomes to the greatest extent possible all of the security shortcomings of MQV discussed in the above-referenced provisional patent application, as discussed and demonstrated further herein. A more complete description of the safety features and advantages of HMQV and its variants will be given later in this application.

Challenge-response signature:

although it should now be clear how the HMQV protocol differs from the MQV protocol, the invention has on the other hand an even more important in some sense: the main technical tool as a core design and analysis element behind HMQV is a new form of interactive signature, called "challenge-response signature", which is implemented using a new variant of the Fiat-Shamir method based on the recognition scheme of Schnorr. Thus, the "exponential challenge-response" (XCR) signature of the present invention is obtained. The relationship between the Schnorr and Fiat-Shamir methods and XCR signatures is discussed below.

These XCR signatures are secure in the random oracle model (under the computational Diffie-Hellman or CDH assumption-see below) and have the property, by way of example, that both the verifier and signer can compute the same signature. The former achieves the computation by knowing the challenge, and the latter can achieve the computation by knowing the secret signature key. Variations on computing the same signature include the computation of different but related signatures by the signer and the verifier.

For example, a signature value computed by one person may be a hashed variant of a signature computed by another person, or they may be related by some particular algebraic property, or the like. The various HMQV protocols of the present invention are one exemplary mechanism for using these XCR signatures, where they provide authentication (of DH values and peer identities) and session key computation.

Thus, XCR signatures and their "double versions" (e.g., DCR), which will be discussed briefly, provide a natural explanation of the ideas underlying HMQV design and analysis from both technical and conceptual standpoints.

In addition, it is noted that XCR signatures can also be used in applications other than the HMQV protocol. In its basic form, XCR signatures do not provide the typical functionality of digital signatures, as they are interactive, challenge specific, and non-transferable. That is, it cannot be used for non-repudiation (non-repudiation) purposes.

XCR signatures, on the other hand, provide a property important for certain applications (including key exchange) — denial of authentication (denying), whereby the recipient of the XCR signature can be confident of the origin and integrity of the message or key, but cannot prove this origin to any third party. In particular, these signature and synthetic key exchange protocols are ideally suited for "off-the-record" communications and privacy protection. Additionally, as discussed below, non-interactive versions of XCR exist, and in some cases they provide an alternative to establishing a signature scheme, such as the well-known Digital Signature Algorithm (DSA).

As in conventional digital signature schemes, in a challenge-response signature scheme, a signer has a pair of private and public keys for generation and verification of a signature, respectively, and it is assumed that the verifier obtains the signer's authentic public key. In particular, it is not assumed that the parties share a secret prior to initiating the signing protocol, nor is such a shared secret involved in the calculation of the signature. However, in contrast to conventional signatures, in its basic form, a challenge-response signature is interactive and requires that the recipient of the signature (e.g., a verifier) issue a challenge to the signer before the signer can generate the signature on a given message. A secure challenge-response signature scheme requires assurance: anyone but a legitimate signer cannot generate a signature that would persuade a challenger to accept the signature as valid. In particular, the signature is not only message-specific but also challenge-specific.

On the other hand, ensuring the verifiability of the signature by the challenger is also of interest, and thus no assumptions or requirements are made about the transferability or verifiability of the signature by the third party. Furthermore, the specific scheme described below has the property that the party selecting the challenge can always generate a signature on any message, which signature is valid in relation to that particular challenge. Of even greater importance to the present application and distinguishing this scheme from other interactive signatures is the fact that the verifier can use the challenge to compute the same (or related) signature string as the signer.

As previously mentioned, G is the generator of a group G of order q (usually a prime number). Further, H is the output | q |/2 bits

But again using the "prime order" and the particular output length of H are merely exemplary design details of the exemplary embodiment and are not required by the invention.

Definition of XCR signature scheme:

the exponential challenge-response (XCR) signature scheme 500 illustrated in fig. 4 is defined as follows: XCRIn the scheme are composed ofThe represented signer owns the private key b e _R Z _q And public key B = g ^b . By

Verifier (or challenger) provision of a representationCalculated as X = g ^x (x∈ _R Z _q ) Of the initial query X, wherein

Select x and keep secret. Using a challenge X to place a given message m on

Is defined as

Pair, where Y = g ^y And is composed of

Selecting y e _R Z _q And decreasing the exponent modulo q

If and only if

In term of erection, examiner

Accept signature pair (Y, σ) as valid (X = g for message m and challenge) ^x )。

We use the following notation: for a given message m, a challenge X and a value Y, we defineNamely, it is

Representing the second element in an XCR signature pair. As a general remark, it is worth observing the above usage table for the word "message"Data or information in any form, including transmission data, files, media, etc., that may be represented by a bitstream, and may itself be a hashed version of a longer message. The message may be entered into the parties, as shown in fig. 5, or it may be transmitted from one party to another, or it may be provided by a third party (an external source), and so on.

As described in this application, the advantages of XCR signatures include: analysis robustness (provability), computability by both verifier and prover, duality (a single computation representing a combination of signatures of two or more parties), "hashability" (i.e., the ability to act on and verify a hashed signature), derivation of a key or public value, non-transferability and repudiation, convertibility (from a repudiatable signature to a conventional non-repudiatable signature), offering a more robust alternative to DSS (especially in an interactive environment), and the presence of non-interactive variants.

The motivation for designing XCR schemes may be illustrated by the relationship with the identification scheme of Schnorr from which the XCR signature is derived. Schnorr's (interactive) recognition scheme involves at a given input B = g ^b Proof of knowledge of the discrete logarithm b. Order to

Represents a prover in the scheme (who owns b) andrepresenting the verifier (who is given input B). The basic Schnorr identification consists of three messages:

(i)selecting y e _R Z _q And Y = g ^y Is sent to

(ii)

Using a random value e _R Z _q Carrying out response; and

(iii)

to

The transmitted value s = y + eb. If and only if g ^s ＝YB ^e When the utility model is in use,

and (6) receiving. The protocol is for honest verifiers

(e.g., a person who randomly selects e uniformly) is a pair of (b)Of) public-coin zero knowledge proof of knowledge. It can therefore be transformed into a signature scheme by the well-known Fiat-Shamir method, i.e.

Which is provably secure in a random oracle model.

Now, consider the following four-message variant of the Schnorr protocol, with the addition of a slave

ToThe first message of (a). In the first of the messages, it is,to

Transmission value X = g ^x . Then, followed by the signal from SchnorrThe three messages of (iv) are used, except in message (iii), i.e. in the fourth message in the modified protocol,

transmitting S = X ^s Rather than to

Send s = y + eb. If and only if S = (YB) ^e ) ^x Time of flight

And (6) receiving. It can be shown that the protocol is a pair

The proof of the "ability" of the Diffie-Hellman value CDH (B, X) is computed at any value X ∈ G. In addition, the protocol is for the verifier of randomly selected eIs zero knowledge and X can be chosen arbitrarily.

The challenge-response signature XCR of the present invention can be obtained by applying the Fiat-Shamir transformation to the protocol. This also explains why the term "exponent" is used when naming the XCR scheme: it involves using X in the last message of the protocol ^s Replace s = y + eb in the Schnorr scheme.

Other aspects of the security of the XCR signature scheme under CDH assumptions are further discussed in the above provisional application.

In explaining some of the above terms, U = G for two elements in G ^u 、V＝g ^v We denote by CDH (U, V) the result of applying Diffie-Hellman to compute U and V (e.g., CDH (U, V) = g ^uv ). If the algorithm takes the element pair (U, V) in G as input and outputs the Diffie-Hellman result CDH (U, V), the algorithm is referred to as the "CDH solver (solver) of G". Further mentioned in said provisional applicationThe main difficult-to-process assumption used in the analysis for this is computational Diffie-Hellman (CDH uniform if all valid CDH solvers for G are, for U, V ∈ C _R G, the probability of the resolver computing the correct value CDH (U, V) over the (U, V) pair is negligible (the probability of being taken over the random coin (randomcoin) of the resolver and the independent random selection of U, V in G), then we say that CDH is assumed to be true in the group G.

The number of bits in (1):

let l be

The number of bits in the output of (a). Clearly, a smaller l means that the signature scheme has a higher efficiency. On the other hand, too small l means a poor safety margin, since once the exponent is incremented

It is predictable that the signature scheme is insecure. But how much is needed for safety purposesl is the letter?

It can be seen (see discussion in the above-referenced provisional application) that setting l =1/2 a luminance q | provides a good security performance tradeoff, and thus this value is used in the exemplary illustration of XCR signatures (and for its exemplary application to the HMQV protocol of the present invention).

Change the order of interaction with B:

in some applications of XCR signatures, in particular as applied to analysis of the HMQV protocol, the challenger may be changed

And signerThe order of interaction between them.

In the above definition of the XCR scheme,

in the direction of

Providing simultaneous direction to query X

Present message m, thereby allowing

Immediately utilizing signature pairs

And (6) responding. In the modified version now considered, there is the following order of interaction:

(i)

to

Present a message m, and

y is output and then, at some later time,

(ii)

to the direction of

Providing (Y, m, X), and

output of

Now, assume a direction F

To retrieve the modified order. In particular, F may be interleaved with

I.e. F may run several instances of step (i) before running the corresponding step (ii). This requires

The state with values Y, Y and m is maintained after step (i). When F later presents (Y, m, X) in step (ii),checking that it has a (Y, m) pair in its state, and if so, utilizing

Respond and clear (Y, m) from its state (if

Does not have a (Y, m) pair in its state, then it does not issue a signature).

Notice a pair of

Is ensured by the description of the actions of

The same Y value will never be used for two different signatures. Can be easily verified, the proof of security of the XCR signature is still valid for this modified sequence, simply because of the simulated pattern

Selecting Y does not require knowledge of X, but only requires a determination

The required value of m.

Hashed XCR variant (HCR):

it is possible to replace the XCR signature pair (Y, σ) with a (Y, H (σ)) pair, where H is a hash function and such a "hashed XCR" signature is abbreviated "HCR". Note that because of the XCR property by which the verifier can recalculate σ for a given Y, it can then also calculate H (σ) and thus can verify the modified HCR signature.

HCR signatures have a range of characteristics that are important in certain settings. For example, it may be shorter than a normal XCR signature, it may produce a random or pseudo-random value, it may prevent an attacker from learning any algebraic structure in σ, and so on.

In particular, HCR signatures provide a more secure alternative to DSA signatures in interactive and verifier-specific authentication environments (e.g., in key exchange protocols). Indeed, although in DSA, a single ephemeral index (e.g., the component r = g of the DSA signature) is present ^k K) makes the signature scheme completely insecure by revealing the secret signature key, but even if the ephemeral exponent y is revealed to the attacker (provided that in this case the signer tests the order of the challenge X or uses a cofactor exponentiation to force the value to have at least q orders), the HCR signature is still not forgeable.

Non-interactive XCR variants:

the XCR (and HCR) signature may be non-interactive by making X = a, but specific to the verifier, where a is the verifier's public key, as shown in fig. 6. This provides a very efficient non-interactive verifier-specific repudiatable authentication mechanism. In a variant, instead of using

The party's unique public key a, which may publish (e.g., post on a website) one or more queries used by the signer, such that the queries are even at the time of signing, at the time of signing

May still be available if not available per se.

Convertible XCR signature:

the salient property of XCR signatures (which, in particular, distinguishes them from other "repudiatable" challenge-response mechanisms, including those based on shared secrets and public-key encryption) is the ability to "transform" these signatures into conventional, non-repudiatable signatures. Convertible signatures possess the property of being authenticatable, i.e., they can only be verified by the intended recipient, and also allow the signer to ultimately prove that he or she is the author of a given signature without revealing his or her secret signing key.

This convertibility from a secret signature to a public signature may be required, for example, for official, reportable communications that must be converted to verifiable public records over the course of years. In the case of an XCR signature, the signature (Y, σ) on the message m under the challenge X can be represented by a revealed value

Which is converted by a legitimate signer into a conventional non-repudiatable signature.

While other (recipient-specific) convertible signatures have emerged in the literature, all of these do not allow the intended recipient (or challenger) to recalculate the signature itself, and therefore do not enjoy the many advantages that this recalculation feature provides to XCR signatures, as exemplified by the following dual XCR signatures.

Dual XCR signature (DCR):

an important characteristic of XCR signatures is that the challenger who has selected the challenge can compute the signature itself. It is shown here how this property can be exploited in order to derive a relevant challenge-response signature scheme (referred to herein as the "dual XCR scheme", or simply DCR) with the property that any two parties are

Can interact with each other using the dual roles of the challenger and signer and each produce a signature that cannot be forged by any third party. Furthermore, the obtained

And

has the same value, which also makes the scheme significant for the HMQV protocol. More precisely, they have the same XSIG composition in the XCR signature pair.

Defining: a dual (exponential) challenge-response (DCR) signature scheme. Order to

Are respectively provided with public keys A = g ^a 、B＝g ^b Both sides of (1). Let m ₁ 、m ₂ Are two messages.

And

respectively in message m ₁ 、 m ₂ The double XCR signature (DCR for short) of (1) is definedIs the triplet value: x, Y and

wherein X = g ^x And Y = g ^y Are respectively composed of

Selected interrogation and symbols d and e respectively represent

And

(see FIG. 7.)

Thus, the basic characteristics of a DCR signature are: in the exchange of values X and Y (then respectively by

And

after the selection of x and y) of x,

and

can all compute (and verify) the same signature

This can be seen from the following equivalents:

where x + da and y + eb are reduced modulo q.

Furthermore, as demonstrated by the discussion in the above-referenced provisional application, an attacker cannot feasibly compute the signature.

Briefly, the double signature is under the query YB ^e Lower part

At message m ₁ And at the same time is under the challenge XA ^d Lower part

At message m ₂ XCR signature of (2). More precisely, since the values d and e are determined during the signing process (by applying to the message m) ₁ 、m ₂ Against which it is possible to fightAlternative), then it may be demonstrated

DCR signature of (a) any value a = g not selected by the attacker ^a It is safe.

Description of the basic HMQV protocol in terms of its form:

in its basic two-message exchange, the HMQV protocol includes as a challenge a Diffie-Hellman value X = g ^x And Y = g ^y In thatA method for preparing

Exchange between parties, both parties calculating dual XCR signatures from the challenge

The session key is then derived by hashing the value. In this way, there is no need to transmit the signature itself: it is the uniqueness of the signature that ensures the public derived value of the session key, and it is the unique ability to compute the key (equivalent to the signature) that provides what is supposed to be

A method for preparing

Proof of the exchange performed by the parties.

Basically, the message m on which the signature is computed ₁ 、m ₂ Is the identity of the peer (i.e.,

both parties can ensure that the key they calculate must be the correct identity uniquely. The identity of the parties is included under the signature (in particular, in the calculation of the values d and e) (not just the ephemeral Diffie-Hellman values), essentially to avoid some authentication failures such as UKS attacks.

Thus, is at

And

the session of the HMQV protocol between the two parties includes a DH value X = g with a session key calculated as H (pi) ^x And Y = g ^y Basic Diffie-Hellman exchange (FIG. 1), in whichThat is, π is as

And

double signatures on each other's identity. The above signature is made by shorthand

Represents, i.e.:

wherein, the first and the second end of the pipe are connected with each other,

and A = g ^a 、B＝g ^y Are respectively

A method for preparing

The party's public key. Note that at this momentIn a variant, H (pi) may be replaced by a different function of pi, in particular the hash may comprise additional information such as the identity of the parties.

The HMQV protocol typically runs in a multi-party network, where either party can be invoked to run the protocol. Each invocation of the protocol at a party creates a session (a local state containing information related to that particular instance of the protocol) that can generate an outgoing message and, upon completion, output a session key. During a session, three types of activation may be utilized to activate a party as follows (in the following description,

represents the identity of the party being activated, an

Identity representing the desired peer for the session):

1. starting up

Resulting value X = g ^x ，x∈ _R Z _q Creating a local session of the HMQV protocol,she identifies it as a (incomplete) session

And outputs the value X as its output message.

The activation means that

Has already been used as

Is activated and X is a desire to be delivered to a peer as part of the session

The message of (2).

A party will be referred to as the "holder" (or "owner") of a session,

will be the "peer" of the session, and X is the output (DH) value.

2. Answering

Check Y ≠ 0. If so, it generates a value of X = g ^x ，x∈ _R Z _q X is output, and completion has an identifier

And session key

Of the session. Here, the first and second liquid crystal display panels are,is activated as a peer in

And the responder who entered the value Y. In this case, it is preferable that the air conditioner,its session is completed immediately (without further incoming messages). Note that if the input value Y is zero, thenThe activation is ignored.

3. Complete the process

Check Y ≠ 0 and it has an identifier

Is open session. If any of these conditions is not met, then

Ignoring the activation, otherwise it completes with the session identifier

And session key

Of the user. This means havingTransfer of a second message in a protocol of an input value Y, from a peer (decided)

The response of (2).

Three-message HMQV-C protocol:

the three-message HMQV-C (where C stands for "key confirmation") protocol is depicted in fig. 8. The protocol enjoys all the security features of HMQV and essentially the same computational cost. However, it adds a third message to the protocol and slightly increases the length of the protocol message.

In return, HMQV-C provides some of the features missing in the basic HMQV protocol, including key validation, PFS, and universal combinability.

And (3) key confirmation:

HMQV protocol direction

The party provides the completion and peer

And the basic guarantee of the session key K: if it is used

Is not destroyed, then only

It is possible that K will be known. What this protocol does not provide is: to the direction ofSquare noodle making machine

Any guarantees of completing the session or computing the session key. In addition, during the execution of the session,may not yet be "valid".

This is not just a disadvantage of HMQV, as it is done for any two-message protocol based on public keysThe situation is said to be the same (assuming, as in the case of a typical public key, thatAnd

without creating any prior shared state at earlier communications therebetween). In addition, as pointed out by Shoup, this seemingly natural goal cannot be achieved by any key exchange protocol, i.e., both parties have guaranteed that a peer has completed a session before the parties begin using keys. In fact, an attacker can always prevent this mutual guarantee from reaching its goal by stopping the last protocol message.

However, such a weak guarantee is achievable for each party and is referred to in the literature as a key confirmation feature, i.e. the peer is able to compute the key (but it does not necessarily output the key to the calling application). While not critical to the basic security of the key exchange (e.g., the lack of key confirmation does not threaten the confidentiality or trustworthiness of communications protected with the key), this feature may provide a useful "operational robustness check" for some applications.

In this case, the protocol HMQV-C is more appropriate than HMQV, since the increased MAC value provides key confirmation. In addition, the MAC verification confirms the valid involvement of the identified peer for the session and the fact that the peer possesses a matching session (i.e., has the same peer and the same session key). Note that to achieve these characteristics, the MAC in HMQV-C need not apply to any particular session information, but only to a single bit used to indicate the "direction" of the message and prevent reflections. It is also worth noting that the protocol consisting of only the first two messages in HMQV-C has provided key confirmation to the initiator (which can add useful features to the HMQV without increasing the number of protocol messages).

In many applications of key exchange, the lack of key validation may result in a form of "denial of service" (DoS) attack in which

Parties start using the key, say to

Transmitting the protected information, andthis information cannot be processed because it has not yet established a key. As mentioned, this situation cannot be completely avoided, since mutual "session completion" acknowledgements cannot be achieved.

Furthermore, there are more serious forms of DoS attacks against public key operation based protocols, where a party is forced to spend considerable computing cycles (and create session states) before discovering that a peer is invalid. Some useful but limited scope of countermeasures (counter-measures) to DoS attacks exist, which can be applied to any key exchange protocol (including HMQV) at the cost of adding protocol messages.

Full forward secrecy (PFS):

full forward secrecy is a very desirable feature of key exchange protocols, whereby the leakage of long-term private keys does not compromise the security of old session keys. More formally, if not destroyed

The party establishes a peer with the incoming corruption

Even when the attacker is in K

After having expired, destroy

Or it is at KAfter taking expiration, destroy

The session key K remains secure. Any two-message protocol with implicit authentication, including HMQV, cannot provide complete full forward secrecy for a valid attacker. Rather, we may expect the best weak form of PFS provided by HMQV. As further explained in the provisional application, the main advantage of HMQV-C over the basic two-message HMQV is that it relieves this inherent limitation of HMQV and provides a complete PFS.

General composable security:

the model of Canetti/Krawczyk for key exchange, which is the basis for analyzing MQV and HMQV in provisional applications, has been extended to a more challenging model that aims to ensure the security of the key exchange protocol when running concurrently with other applications (as is the case in real-world environments). This model is referred to as the Universal Combinable (UC) model of key exchange.

For HMQV-C it can be shown that when the first party who completes the session outputs its session key, the state of the peer then contains only information that can be "modeled" from the common information in the protocol and session key. Canetti/Krawczyk shows that this property, together with other security properties of HMQV shown in the provisional application, is sufficient to guarantee universal combinability of the HMQV protocol.

Unidirectional (One-Pass) HMQV:

the one-way key exchange protocol shown in FIG. 9 includes a slave sender

Sent to a recipient

Whereby both parties derive only using their private and public keys as long as both parties and the session are not corrupted as defined below

And

there is a unique key that may be known.

The requirements from the established key are the same as in conventional key exchange protocols, except possibly by

The received message is from

Out of the playback of older messages. This replay is unavoidable in unidirectional protocols, although it may be detectable by other means such as synchronized time or shared state.

In addition, such protocols are not able to provide PFS due to the lack of data from

Session-specific transport ofIn said introduction, use is made of

Should be computable.

In one embodiment of the present invention,respectively have public keys A = g ^a 、B＝g ^b Is/are as follows

Fang YuThe one-way HMQV protocol between the parties includes a slave

Is transmitted toSingle value of (X = g) ^x Therein is composed of

Selecting x ∈ _R Z _q . By

The session key K is calculated as follows:

(i) Order to

The representation includes two identities

And

and d is set to

The result of (1);

(ii) Calculating out

(iii) Is provided with

Where H outputs a number of bits equal to the length of the required key. In the inspection ofAfter X ≠ 0, is prepared from

The same key K was calculated as K = H ((XA) ^d ) ^b ). In a variant of this, the first and second,

in other words, the key in this embodiment of the one-way HMQV is to be

Is used as a challenge derived from a non-interactive XCR signature.

It is also noted that the one-way protocol may be used as an authentication selection ciphertext security (CCA) encryption scheme. That is to say that the temperature of the molten steel is,

can be directed to (from)

) Encryption (against chosen ciphertext attacks) and authentication

The message m is transmitted. In one embodiment of the present invention,

a triplet (X, c, t) may be sent, where X = g ^x C is as the secret key K ₁ Ciphertext obtained by symmetric selective plaintext security (CPA) encryption of the next message m, and t is at the key K ₂ The MAC value calculated on c. Key K, as in the one-way HMQV protocol ₁ And K ₂ Is derived from the key K calculated from X.

The overall cost of the process is to

Exponentiation twice (one is offline) and for

1.5 And (4) performing power next. This is only for alternative CCA encryption schemes such as DHIES (Diffie-Hellman integrated encryption scheme)

Raised by a 1/2 th power, but in return it is provided with a power from

(with DHIES, the authentication will be from

Return the complete additional signature). This efficient authenticated CCA encryption is attractive for "store-and-forward" applications, such as the general purpose "Good Privacy (PGP)" application, and is much cheaper than the commonly used signature-encryption paradigm. The only caveat here is that the identity needs to be transmitted clearly

(and possibly its certificate) as required in the decryption operation.

Yet another characteristic of the above protocol that is noteworthy is that it can be used only as a proxy

The verifier-specific signature over message m without adding an encryption part. However, the signature is the recipientDedicated and therefore it is not non-repudiatable. Instead, it possesses characteristics that are valuable in many applications such as PGP: repudiation is possible.

Note that many standards that have adopted MQV have also adopted their one-way variants. It may be meaningful for the standards of interest to employ various forms of HMQV (one, two, and three messages), to define key derivation in a one-way protocol (similar to derivation in other variants of HMQV).

Specifically, by replacing Y with B in the double signature defining the HMQV protocol, we obtain the following values for the one-way key:

and

respectively calculate

And

and sets the key K to a hash of these (equal) values. Note that in this case, the exponent e does not add any value to the protocol, except to make it compatible with other variants. Which actually slightly detracts from the protocol efficiency.

However, the additional difference retains the value in the one-way version of HMQVAnd in two message versions

In between. The way to provide compatibility between the three modes would be to have all of them

、

Wherein Y = B in the case of one-way, and adds an identity to the session key derivation function

That is to say that the first and second electrodes,

(using some fixed criteriaAs defined

And

in the case of order (ii). This replaces the addition to the calculation of d

The requirements of (a). It also has the advantage of strengthening the HMQV and avoiding possible unknown key sharing attacks in case of a leaked pre-computed DH value.

Summary of the security aspects of HMQV:

compared to the conventional MQV protocol, the HMQV protocol provides a number of performance advantages, including the following. HMQV may prove to obviate the need for costly prime-order testing on DH values transmitted in a protocol. As demonstrated in the provisional application, the only way an attacker can benefit from selecting a rogue DH value is by choosing it to be zero, and thus, all that is required in HMQV is a simple non-zero check. Therefore, no prime order test or cofactor h is required to be used concurrently in the MQV protocol.

The following are a series of properties that the HMQV protocol implements in a mathematically provable manner:

(1) HMQV is secure in the strongly formalized (strong format) key exchange model of Canetti and Krawczyk;

(2) HMQV defends against impersonation by an attacker that does not have access to the private keys of the parties;

(3) HMQV establishes a unique binding to the exchange between the key and the identities of the parties (by applying XCR signatures to these identities), thereby avoiding UKS and other authentication attacks;

(4) HMQV is also secure in the presence of partial leakage of session keys and other session information; in other words, HMQV is resistant to so-called "known key" attacks. In particular, it is ensured that different session keys are "computationally independent" of each other;

(5) This protocol provides an additional level of protection, called "key leakage impersonation (KCI)" attack, i.e. it prevents an attacker who knows the private key of party a from being able to fake the other party a;

(6) The three-message HMQV protocol with key validation provides a provable full forward secrecy (PFS), that is, session keys created by both parties before disclosure remain secure even if their long-term private keys are eventually disclosed;

(7) The three-message protocol with key validation enjoys the added security advantage of the so-called "generic combinable" key exchange protocol, i.e. it can be combined securely with other protocols;

(8) The security of HMQV does not depend on a special test of the static public key in form and structure, nor does it require a so-called "proof of possession" of the corresponding private key. These advantages of HMQV over similar protocols, including MQV, relieve the Certification Authority (CA) from the burden of making these specialized checks on the registration public key, providing a more practical and practical security assurance, particularly since many local CAs are not able or configured to make these checks. Furthermore, it is worth noting that such testing (e.g., proof of possession) performed specifically by the CA makes the protocol open additional security vulnerabilities;

(9) The two-message and three-message HMQV protocols do not require testing the order of the ephemeral public key (i.e., the values X and Y), thereby avoiding testing that may be costly in some cases. However, these tests are required if the security of the protocol is to protect against attackers who may learn ephemeral secret keys of the parties. This test is also required for the security of the one-way HMQV protocol. These tests can be replaced by "cofactor exponentiation" of the sigma values in the protocol, as in the case of MQV. Additional tests on group elements (e.g., members in a predetermined group) may be required according to the underlying algebraic group.

One of the outstanding advantages of the HMQV protocol of the present invention is that it is the most efficient authenticated Diffie-Hellman key exchange protocol that can be demonstrated to be valid in a formal mathematical way, with a wide range of security features. Indeed, this formal provability is one of the main differences between HMQV and its predecessor MQV.

Not only does MQV have no evidence of security, but it also has significant protocol vulnerabilities over time (e.g., kaliski's work and the report by Rogaway et al), including some of the vulnerabilities first described in the above-referenced provisional applications. These vulnerabilities or attacks defeat some of the security claims made by their inventors to MQV, and in particular, they show that MQV cannot be proven to be secure.

Comparison of XCR signature with "Implicit Signatures (Implicit Signatures)" of MQV:

as a way of comparison, it is worth noting that MQV also uses the concept of signatures in the design and description of protocols, as described in patents and in academic papers. These are referred to as "implicit signatures" in the case of MQV, and they follow the more conventional concept of digital signatures, i.e. where the signature value can only be generated by the owner of the secret signature key (in particular, MQV refers to ElGamal-like signatures formed by the linear combination of the secret signature key and the ephemeral secret and public keys). However, the protocol is not good at fully using the characteristics of these signatures. In particular, the MQV protocol does not use signatures as a way to unambiguously authenticate the identities of the parties to the protocol, which results in serious authentication failures, such as the well-known "Unknown Key Share (UKS)" attack discovered by Kaliski.

In contrast, HMQV introduces two important elements in its design. One is to use XCR, which is an exponential version of the EIGamal signature. More specifically, it is an exponential version of Schnorr's signature, which in turn is a specific instantiation of the EIGamal signature. The other is an explicit signature of the identity of the peer, which ensures secure binding of the session key to the peer of the session and, in particular, prevents authentication failures such as UKS.

The key novelty of XCR signatures is the property that both the signer and the verifier (or challenger) can compute the same signature. This property is typically present in shared key cryptography-based authentication mechanisms (i.e., where both the signer and the verifier have a shared key a priori), but is new in public key-based signatures. XCR signatures are not only well suited for deriving shared keys, as in HMQV, but they provide various advantages as authentication tools, some of which are described above.

It should be clear to a person skilled in the art that the invention encompasses various embodiments.

Thus, in one exemplary embodiment, there are two parties, a verifier V and a signer S. The signer S has a private key B and a public key B, and it is assumed that the verifier V owns or obtains the authentic public key B of S (e.g., by a digital certificate sent from S). The authentication protocol includes for a given message m:

(1) V selects the secret value X and calculates value X = F ₁ (x) In which F is ₁ Is a given function and sends X to S.

(2) S selects the secret value Y and calculates the value Y = F ₂ (y) wherein F ₂ Is a given function and transmits Y to V.

(3) S calculated S = F ₃ (y, b, X, m) wherein F ₃ Is a given function and transmits S to V.

(4) V calculated value s' = F ₄ (x, Y, B, m) and the trustworthiness of m is determined based on the value s' and its relation to the received value s.

Some exemplary variants of this embodiment include:

(a)F ₁ 、F ₂ is a one-way function. In XCR these one-way functions are X = g ^x And Y = g ^y 。

(b) In XCR signatures, functions

And is provided with

(c) Accepting m as authentication if and only if s' = s. This last variant takes advantage of the properties of a typical XCR signature, whereby the verifier can recalculate the signature with knowledge of the secret after the challenge X.

(d) Calculating out

And test H (s') = s, etc.

In at least one embodiment of applying XCR to HMQV, the value S computed by S in step (3) is never sent to V. Instead, V computes a value S', which will equal S (unless S is a nominated replacer), and uses S (which is σ in HMQV) to derive the session key from it. In particular, V never implements explicit checks. In this embodiment, instead of a method for verifying the authenticity of the message m, there would be a method by which both parties calculate a common "authentication value" (i.e. a value that both parties can and cannot only calculate), and by which this value is uniquely bound to the corresponding identity (a basic condition in typical key exchange protocols obtained by the signing of the parties' identities in HMQV by means of a double XCR signature).

Additional variations are described above and in the claims.

Exemplary hardware implementation:

fig. 10 illustrates a typical hardware configuration of an information handling/computer system in accordance with the present invention, and preferably has at least one processor or Central Processing Unit (CPU) 1011.

The CPU 1011 is interconnected by a system bus 1012 to a Random Access Memory (RAM) 1014, a Read Only Memory (ROM) 1016, an input/output (I/O) adapter 1018 (for connecting peripheral devices such as disk units 1021 and tape drives 1040 to the bus 1012), a user interface adapter 1022 (for connecting a keyboard 1024, mouse 1026, speaker 1028, microphone 1032, and/or other user interface devices to the bus 1012), a communications adapter 1034 for connecting the information handling system to a data processing network, the Internet, an intranet, a Personal Area Network (PAN), etc., and a display adapter 1036 for connecting the bus 1012 to a display device 1038 and/or a printer 1039 (e.g., a digital printer, etc.).

In addition to the hardware/software environment described above, various aspects of the invention include a computer-implemented method for implementing the above method. For example, the method may be implemented in the particular environment discussed above.

For example, such a method may be implemented by operating a computer, as embodied by a digital data processing apparatus, to execute a sequence of machine-readable instructions. The instructions may reside in various types of signal-bearing media.

Accordingly, this aspect of the present invention is directed to a programmed product comprising a signal-bearing medium tangibly embodying a program of machine-readable instructions executable by a digital data processor incorporating the CPU 1011 and hardware above, to perform the method of the present invention.

The signal bearing media may comprise, for example, RAM contained within the CPU 1011, as represented by, for example, fast access memory. Alternatively, the instructions may be contained in another signal-bearing medium, such as a magnetic data storage diskette 1100 (FIG. 11), directly or indirectly accessible by the CPU 1011.

Whether contained in the diskette 1100, the computer/CPU 1011, or elsewhere, the instructions may be stored on a variety of machine-readable data storage media, such as DASD storage (e.g., a conventional "hard drive" or a RAID array), magnetic tape, electronic read-only memory (e.g., ROM, EPROM, or EEPROM), an optical storage device (e.g., CD-ROM, WORM, DVD, digital optical tape, etc.), paper "punch" cards, or other suitable signal-bearing media including transmission media such as digital and analog and communication links and wireless. In an illustrative embodiment of the present invention, the machine-readable instructions may comprise software object code.

1. A method of switching between two parties interconnected by a device or network, the method comprising:

the recipient (verifier) selects a secret value X for calculating a value X = F1 (X), wherein F1 comprises a first predetermined function having at least one argument, said value X being one of said at least one argument of F1;

the signer (signer) selects a secret value Y for calculating a value Y = F2 (Y), where F2 comprises a second predetermined function having at least one argument, the value Y being one of the at least one argument of F2;

the signer obtains the value X, the signer having a private key B and a public key B; and

the signer computed value s = F3 (y, b, X), wherein F3 comprises a third predetermined function having at least three arguments, the value y, the private key b and the value X being three of the at least three arguments of F3,

wherein a fourth predetermined function F4 (x, Y, B) is present to calculate a value s', F4 having at least three arguments, the value x, the value Y and the public key B being three of the at least three arguments of F4, but the value s not being an argument of F4,

there is no shared secret between the verifier and the signer that is used as a basis for any argument in any of the F1, F2, F3 and F4, an

If it is determined that the value s 'is related to the value s in a predetermined manner, the verifier may consider the values s and s' as valid authenticators.

2. The method of claim 1, wherein at least one of F1 and F2 comprises a one-way function.

3. The method of claim 1, wherein if s = s ', it is determined that the values s and s' are valid authenticators.

4. The method of claim 1, wherein at least one of the following is performed by a party other than the verifier and the signer: calculating s 'and determining whether the values s and s' are determined to be relevant.

5. The method of claim 1, wherein the value s and the value s' are used to derive a secret shared between the two parties.

6. The method of claim 1, further comprising:

the verifier obtains the value Y and uses the same value to calculate the value s 'for determining whether s and s' are related in the predetermined manner.

7. The method of claim 1, wherein a message m is to be authenticated and includes an argument of F3 and an argument of F4, thereby allowing said value s and said value s' to include information in said message m; and

authenticating the message if it is determined that the values s and s' are related in the predetermined manner.

8. The method of claim 7, wherein the value s and the value s' are used to derive a secret shared between the two parties.

9. The method according to claim 8, wherein said message m comprises an identity of at least one of said parties in said exchange.

10. The method of claim 7, further comprising:

the signer sends the value s to the verifier.

11. The method of claim 7, wherein if said s = s', said message is authenticated.

12. The method of claim 1, wherein:

the public key B = g ^b G is a generator of a q-order finite group, and the private key b is an integer such that b is greater than or equal to 0 and less than or equal to q-1;

the value X = g ^x X is an integer such that 0 ≦ x ≦ q-1, and the value Y = g ^y Y is an integer such that 0. Ltoreq. Y.ltoreq.q-1; and

the signatureCalculates the value

f ₁ Including a first mathematical function, and f ₂ Including the second mathematical function, and the argument m comprises the message.

13. The method of claim 12, wherein q is a prime number.

14. The method according to claim 12, wherein said message m is considered to be authenticated if it is determined that said value s and said value s' are related in said predetermined manner.

15. The method of claim 14, wherein the message m is considered to be authenticated if the value s is determined to be equal to the value s'.

16. The method of claim 12, wherein f ₁ Including an identity function.

17. The method of claim 12, wherein f ₂ Including a hash function to hash f ₂ At least one of said arguments.

18. The method of claim 17, wherein one of the hash arguments is a non-null message m.

19. The method of claim 12, wherein the message m comprises an identity of a party in the computer or system or network.

20. The method according to claim 17, wherein f ₂ (m, Y, b) = Y + H (Y, m) bmodq, where H includes a cryptographic function, an encryption function, and a cryptographic hash function that are one of the one-way functions.

21. The method of claim 20, wherein the value is

Wherein f is ₃ (x) Comprising a mathematical function having at least one argument, said value x being f ₃ (x) One of the at least one argument.

22. The method of claim 21, wherein f ₃ (x)＝x。

23. The method of claim 21, further comprising:

authenticating the message m if and only if s = s.

24. The method of claim 21, wherein the verifier has a private key a, a public key a = g ^a And a message m ', the value s comprising the signature of the verifier on m ', while the value s ' comprises the signature of the signer on m.

25. The method of claim 24, wherein said function f ₃ (x)＝x+H(X，m′)amod q。

26. The method of claim 1, wherein x is randomly selected by the verifier and y is randomly selected by the signer.

27. The method of claim 1, wherein the first value X = g ^x Including a value published by the verifier so as to be retrievable by the signer, permitting a non-interactive version of the authentication.

28. The method of claim 21, wherein the values s and s' are further hashed.

29. A signal-bearing medium tangibly embodying a program of machine-readable instructions executable by a digital processing apparatus to perform the steps of the method recited in claim 1.

30. An apparatus, comprising:

a calculator to calculate functions F2 and F3 as described in claim 1 for the signer.

31. A method for establishing an authentication key between two parties interconnected by a device or network, the method comprising:

given a first party having a private key a and a public key A, the private key a is an integer such that 0 ≦ a ≦ q-1, q is a positive integer, g is a generator of a finite group of order q, and A is an element in a group generated by the value g and calculated as A = g ^a And an

Given having a private key B and a public key B = g ^b The second party of (b), the private key b being an integer such that 0. Ltoreq. B. Ltoreq.q-1,

the first party chooses to calculate a value of X = g ^x Is an integer such that 0 ≦ X ≦ q-1, and the value X is communicated to the second party;

the second party is selected to calculate a value of Y = g ^y Is an integer such that 0 ≦ Y ≦ q-1, and the value Y is communicated to the first party;

the first square calculated value

Wherein m, m' comprise messages known or exchanged between the parties and the second party calculates a value

The function f ₂ And f ₄ Comprises a function H having at least one argument, one such argument being at least one of said messages m and m', wherein H comprises a cryptographic function being one of a one-way function, an encryption function, and a cryptographic hash function;

the first and second parties derive a shared key from the values s and s', respectively.

32. The method of claim 31, wherein at least one of:

(i) The calculation of the values X and X comprises a private key of the first party and a public key of one or more of the parties; and

(ii) The calculation of the values Y and Y comprises the private key of the second party and the public key of one or more of the parties.

33. The method of claim 31, wherein said deriving the shared key from s and s' comprises a cryptographic function that is one of a one-way function, an encryption function, and a cryptographic hash function.

34. The method of claim 31, wherein at least one of the messages m and m' comprises an identity of one of the first and second parties.

35. The method of claim 31, wherein:

f ₁ (Y，B，m)＝YB ^H(Y，m) ，

f ₂ (x，a，m′)＝(x+H(X，m′)a)mod q，

f ₃ (X，A，m′)＝XA ^H(X，m′) ，

f ₄ (Y, b, m) = (Y + H (Y, m) b) modq, and

h is a function having at least two arguments including a cryptographic function, which is one of the one-way functions, an encryption function, and a cryptographic hash function.

36. A method according to claim 35, wherein at least one of said messages m and m' comprises an identity of at least one of said first and second parties.

37. The method of claim 36, wherein at least one of:

(i) The calculation of the values X and X comprises a private key of the first party and a public key of one or more of the parties; and

(ii) The calculation of the values Y and Y comprises a private key of the second party and a public key of one or more of the parties.

38. The method of claim 36, wherein said deriving the shared key from s and s' comprises a cryptographic function that is one of a one-way function, an encryption function, and a cryptographic hash function.

Claims (38)

1. A method of switching between two parties interconnected by a device or network, the method comprising:

the recipient (verifier) selects a secret value X for calculating a value X = F1 (X), wherein F1 comprises a first predetermined function having at least one argument, said value X being one of said at least one argument of F1;

the signer (signer) selects a secret value Y for calculating a value Y = F2 (Y), where F2 comprises a second predetermined function having at least one argument, the value Y being one of the at least one argument of F2;

the signer obtains the value x, the signer having a private key B and a public key B; and

the signer computed value s = F3 (y, b, X), wherein F3 comprises a third predetermined function having at least three arguments, the value y, the private key b and the value X being three of the at least three arguments of F3,

wherein a fourth predetermined function F4 (x, Y, B) is present to calculate a value s', F4 having at least three arguments, the value x, the value Y and the public key B being three of the at least three arguments of F4, but the value s not being an argument of F4,

there is no shared secret between the verifier and the signer that is used as a basis for any argument in any of the F1, F2, F3 and F4, an

If it is determined that the value s 'is related to the value s in a predetermined manner, the verifier may consider the values s and s' as valid authenticators.

2. The method of claim 1, wherein at least one of F1 and F2 comprises a one-way function.

3. The method of claim 1, wherein if s = s ', it is determined that the values s and s' are valid authenticators.

4. The method of claim 1, wherein at least one of the following is performed by a party other than the verifier and the signer: calculating s 'and determining whether the values s and s' are determined to be relevant.

5. The method of claim 1, wherein the value s and the value s' are used to derive a secret shared between the two parties.

6. The method of claim 1, further comprising:

the verifier obtains the value Y and uses the same value to calculate the value s 'for determining whether s and s' are related in the predetermined manner.

7. The method according to claim 1, wherein a message m is to be authenticated and comprises an argument of F3 and an argument of F4, thereby allowing said value s and said value s' to comprise information in said message m; and

authenticating the message if it is determined that the values s and s' are related in the predetermined manner.

8. The method of claim 7, wherein the value s and the value s' are used to derive a secret shared between the two parties.

9. The method according to claim 8, wherein said message m comprises an identity of at least one of said parties in said exchange.

10. The method of claim 7, further comprising:

the signer sends the value s to the verifier.

11. The method of claim 7, wherein if the s = s', the message is authenticated.

12. The method of claim 1, wherein:

the public key B = g ^b G is a generator of a q-order finite group, and the private key b is an integer which enables b to be more than or equal to 0 and less than or equal to q-1;

said value X = g ^x X is an integer such that 0 ≦ x ≦ q-1, and the value Y = g ^y Y is an integer such that 0. Ltoreq. Y.ltoreq.q-1; and

the signer calculates the value

f ₁ Comprising a first mathematical function, and f ₂ A second mathematical function is included and the argument m comprises a message.

13. The method of claim 12, wherein q is a prime number.

14. The method according to claim 12, wherein said message m is considered to be authenticated if it is determined that said value s and said value s' are related in said predetermined manner.

15. The method of claim 14, wherein the message m is considered to be authenticated if the value s is determined to be equal to the value s'.

16. The method of claim 12, wherein f ₁ Including an identity function.

17. The method according to claim 12, wherein f ₂ Including a hash function to hash f ₂ At least one of said arguments.

18. The method of claim 17, wherein one of the hash arguments is a non-null message m.

19. The method of claim 12, wherein the message m comprises an identity of a party in the computer or system or network.

20. The method of claim 17, wherein f ₂ (m, Y, b) = Y + H (Y, m) bmodq, where H includes a cryptographic function, an encryption function, and a cryptographic hash function that are one of the one-way functions.

21. The method of claim 20, wherein the value is

Wherein f is ₃ (x) Comprising a mathematical function having at least one argument, said value x being f ₃ (x) Of the at least one argument of (a).

22. The method of claim 21, wherein f ₃ (x)＝x。

23. The method of claim 21, further comprising:

authenticating the message m if and only if s = s'.

24. The method of claim 21, wherein the verifier has a private key a, a public key a = g ^a And a message m ', the value s comprising the signature of the verifier on m ', while the value s ' comprises the signature of the signer on m.

25. The method of claim 24, wherein said function f ₃ (x)＝x+H(X，m′)amod q。

26. The method of claim 1, wherein x is randomly selected by the verifier and y is randomly selected by the signer.

27. The method of claim 1, wherein the first value X = g ^x Including a value published by the verifier so as to be retrievable by the signer, permitting a non-interactive version of the authentication.

28. The method of claim 21, wherein the values s and s' are further hashed.

29. A signal bearing medium tangibly embodying a program of machine-readable instructions executable by a digital processing apparatus to perform at least one of the steps of the method recited in claim 1.

30. An apparatus, comprising:

a calculator to calculate functions F2 and F3 as described in claim 1 for the signer.

31. A method for establishing an authentication key between two parties interconnected by a device or network, the method comprising:

given a first party having a private key a and a public key A, the private key a is an integer such that 0 ≦ a ≦ q-1, q is a positive integer, g is a generator of a finite group of order q, and A is an element in a group generated by the value g and calculated as A = g ^a And, and

given having a private key B and a public key B = g ^b The second party of (b), the private key b being an integer such that 0 < b < q-1,

the first party selects to calculate a value of X = g ^x Is an integer such that 0 ≦ x ≦ q-1, and the value x is communicated to the second party;

the second party selects to calculate a value of Y = g ^y Is an integer such that 0 ≦ Y ≦ q-1, and the value Y is communicated to the first party;

the first party calculated value

Wherein m, m' comprise messages known or exchanged between the parties and the second party calculates a value

The function f ₂ And f ₄ Comprises a function H having at least one argument, one such argument being at least one of said messages m and m', wherein H comprises a cryptographic function being one of a one-way function, an encryption function, and a cryptographic hash function;

the first and second parties derive a shared key from the values s and s', respectively.

32. The method of claim 31, wherein at least one of:

(i) The calculation of the values X and X comprises a private key of the first party and a public key of one or more of the parties; and

(ii) The calculation of the values Y and Y comprises a private key of the second party and a public key of one or more of the parties.

33. The method of claim 31, wherein said deriving the shared key from s and s' comprises a cryptographic function that is one of a one-way function, an encryption function, and a cryptographic hash function.

34. The method of claim 31, wherein at least one of the messages m and m' comprises an identity of one of the first and second parties.

35. The method of claim 31, wherein:

f ₁ (Y，B，m)＝YB ^H(Y，m) ，

f ₂ (x，a，m′)＝(x+H(X，m′)a)modq，

f ₃ (X，A，m′)＝XAH ^(X，m′) ，

f ₄ (Y, b, m) = (Y + H (Y, m) b) modq, and

h is a function having at least two arguments including a cryptographic function, which is one of the one-way functions, an encryption function, and a cryptographic hash function.

36. A method according to claim 35, wherein at least one of said messages m and m' comprises an identity of at least one of said first and second parties.

37. The method of claim 36, wherein at least one of:

(i) The calculation of the values X and X comprises a private key of the first party and a public key of one or more of the parties; and

(ii) The calculation of the values Y and Y comprises a private key of the second party and a public key of one or more of the parties.

38. The method of claim 36, wherein said deriving the shared key from s and s' comprises a cryptographic function that is one of a one-way function, an encryption function, and a cryptographic hash function.

Images