JP2009526411A - Method of exchange between two parties interconnected by a device or network, signal transmission medium, and device (method and structure for challenge-response signatures and high performance secure Diffie-Hellman protocol) - 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

  Aspects of the invention generally relate to signatures that are provably secure for the sending and receiving parties of an information exchange. More specifically, the challenge-response signature scheme allows both verifiers and signers to calculate the same or related signatures, the former knows the challenge By doing so, the latter can do this by ascertaining a private signature key, which in the exemplary embodiments includes conventional key exchange protocols, including variations of the well-known MQV protocol. It has the characteristic of enabling safe deformation in a verifiable manner.

  As originally proposed, the Diffie-Hellman (DH) key exchange protocol 100 illustrated in FIG. 1 is believed to be secure against eavesdropping attackers. Myriad ad hoc proposals have been made as a result of the search for the “Authentication Diffie-Hellman” protocol that resists active man-in-the-middle attacks, many of which have been abandoned Or is known to suffer from shortcomings. With the development of strict security models for key exchanges over the last few years, one of ordinary skill in the art can now determine the security of these protocols and develop a design that can withstand realistic and active attacks. It is in a very good position.

  As expected, adding safety features against active attacks results in added complexity in terms of both additional communication and computation. The latter is particularly important in protocols authenticated by public key techniques that usually require additional expensive group exponentiation. In addition to the need for robust security, many practical applications for key exchange have forced designers to improve performance costs associated with authentication mechanisms, particularly those based on public keys. .

A research area initiated by Matsumoto, Takashima, and Imai in 1986 is the search for public key (PK) authenticated DH protocols that would add minimal complexity to the protocol. Theoretically, until a public key exchange is guaranteed, it is desired that protocol communications look exactly like a basic DH exchange. In this technique, the authentication of the protocol must be obtained via a key derivation procedure and not an agreement on the basic Diffie-Hellman key g ^xy , but the party will be able to accept the party's public / private key and g ^x , It would be able to agree on a key to combine the g ^y.

  Due in part to the practical advantages that such a protocol would offer, and in part to the mathematical challenges behind such a design, the “Implicit Authentication Diffie-Hellman Protocol” A number of protocols often referred to have been developed based on this approach. This approach not only can generate a very efficient protocol in communication, but can also potentially save significant computational savings through a combination of authentication and key derivation procedures. For these reasons, some of these “implicit authentication” protocols have been standardized by major national and international security standards.

  Of these protocols, the MQV protocol appears to be widely standardized. This protocol has been standardized by many organizations and has recently become the key underlying "next-generation cryptography for protecting US government information", including the protection of "confidential or mission-critical national security information". The exchange mechanism has been announced by the US National Security Agency (NSA).

  In addition, MQV appears to be designed to meet a number of security goals. A basic version of the MQV protocol is described, for example, in US Pat. No. 5,761,305 issued to Vanstone et al.

  However, despite its appeal and success, MQV has so far avoided formal analysis in well-defined key exchange models. The present invention is motivated by the desire to perform such an analysis. In conducting the study, the inventor found that almost all of the stated MQV goals were implemented as implemented in the Canetti and Krawczzyk computational key exchange model and as described in the above provisional application. I realized I could prove that it was not effective.

As a result, concerns regarding the security of this conventional protocol have been raised to the inventors. Therefore, based on this analysis that the conventional MQV protocol has not been provably secure, additional security for MQV is needed, preferably while preserving its existing performance and diversity.
US Pat. No. 5,761,305

  In view of the above and other exemplary problems, disadvantages, and disadvantages of conventional systems, one exemplary feature of the present invention achieves the security goals of the MQV protocol in a verifiable manner, and It is to provide a method and structure for a new variant of MQV, referred to herein as HMQV.

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

  Another exemplary feature of the present invention is that both the challenger and the signer can calculate the same signature or associated signature, the former choosing the challenge and the latter knowing the secret signing key As a protocol mechanism with the property that it can do this, a version derived from the Schnorr identification scheme and referred to herein as an "exponential challenge response (XCR) signature scheme" The challenge is to demonstrate this challenge-response signature scheme.

  Accordingly, an exemplary object of the present invention is a structure and method for improving security with respect to the authenticated Diffie-Hellman protocol, by which the concept of the XCR signature scheme can be realized and security can be demonstrated. Is to provide.

  In a first exemplary aspect of the invention, in order to achieve the above features and objectives, a receiving party (verifier) that selects a secret value x to calculate a value X = F1 (x). Where F1 includes a first predetermined function having at least one argument, and the value x is one of at least one argument of F1, between two parties interconnected by a device or network The method of exchange is described herein. The signing party (signer) selects a secret value y to calculate the value Y = F2 (y), where F2 includes a second predetermined function with at least one argument, and the value y Is one of at least one argument of F2. The signer gets the value X, and the signer has the private key b and the public key B. The signer calculates the value s = F3 (y, b, X), where F3 includes a third predetermined function with at least three arguments, the value y, the secret key b, and the value X are F3's Three of the at least three arguments. There is a fourth predetermined function F4 (x, Y, B) for calculating the value s', F4 has at least three arguments, and the value x, the value Y, and the public key B are at least of F4. Of the three arguments, there are three arguments, but the value s is not an argument of F4. There is no secret that is shared between the verifier and the signer and serves as the basis for any argument in any of the functions F1, F2, F3, and F4. If the value s 'is determined to be related to the value s in a predetermined manner, the verifier can consider the values s and s' as valid authenticators.

  In the second and third exemplary aspects of the present invention, the apparatus comprises a device for performing the method described in the previous paragraph and a plurality of machine readable instructions executable by a digital processing device to perform the method. A signal transmission medium that specifically implements the program is also described herein.

In a fourth exemplary aspect of the present invention, a method for establishing an authenticated key between two parties interconnected by a device or network is also described herein. The first party has a secret key a and a public key A, the secret key a is an integer such that 0 < a < q−1, q is a positive integer, and g is a finite group of order q. a (finitegroup) of origin (generator), a is generated by the value g, which is the original (element) in the group is calculated as ^a = g ^a. The second party has a secret key b and a public key B = g ^b , and the secret key b is an integer such that 0 < b < q−1. The first party selects a secret value ^x to calculate the value X = g ^x , where x is an integer such that 0 < x < q−1, and the value X is communicated to the second party The The second party selects a secret value ^y to calculate the value Y = g ^y , where y is an integer such that 0 < y < q−1, and the value Y is communicated to the first party The The first party calculates the value s = f ₁ (Y, B, m) ^{{f2 (x, a, m ′)}} , where m and m ′ are known or exchanged between the parties. The second party calculates the value s ′ = f ₃ (X, A, m ′) ^{{f4 (y, b, m)}} . At least one of the functions f ₂ and f ₄ includes a function H having at least one argument, such one argument being at least one of the messages m and m ′, where H is one. It includes a cryptographic function that is 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.

  The above and other objects, aspects and advantages will be better understood from the following detailed description of a preferred embodiment of the invention in conjunction with the drawings.

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

であり、最近隣数（nearestinteger）まで丸められた２を底とするｑの対数を意味する）によって表され、この数量は暗黙セキュリティ・パラメータとして使用される。パラメータＧ、ｇ、およびｑは、単純にするため、実際に一般的であるように、一定であり、あらかじめ両当事者にとって既知のものであると想定される。代わって、これらの値を証明書などに含めることもできるであろう。 As a preliminary note on groups and notation, all protocols and operations discussed herein are cyclic groups G of order q, which is typically the prime number generated by the generator g. Is assumed. The bit length of q is | q |

, Meaning the logarithm of 2 base q rounded to the nearest integer), and this quantity is used as an implicit security parameter. The parameters G, g, and q are assumed to be constant and known in advance to both parties for simplicity, as is common in practice. Alternatively, these values could be included in certificates etc.

In this specification, a multiplication expression of group operations is used, but the process is an additive group such as an elliptic curve, or any other algebraic group or a specific group, a finite field. ), Composite moduli, etc. are equally applicable. In the protocol, public keys represented by uppercase letters (eg A, B) are elements in group G, and private keys represented by corresponding lowercase letters (eg a, b) are _elements in Z _q , Where Z _q represents a set of integers 0, 1,..., Q−1.

は以降Ａハットと記載する。
によって表され、伝統的には「アリス（Alice）」と見なされることになる（第２の当事者

は以降Ｂハットと記載する。
は伝統的には「ボブ（Bob）」と見なされる）。一般に、「ハット表記法（hatnotation）」は、名前、電子メール・アドレス、役割など、プロトコル内の当事者の論理ＩＤまたは「識別（distinguishing）」ＩＤを表すために使用される。場合によっては、これらのＩＤはデジタル証明書で増強することができる。本明細書では繰り返さないが、仮出願で提供されるより完全な数理解析のために、攻撃者を含むプロトコル内のすべての当事者は、確率的多項式タイム・マシンを介して実現されるものと見なされる。また、攻撃者はＭによっても表され、ここでＭは「悪意のある（malicious）」ことを意味する可能性がある。 For example, public key ^A = g ^a corresponds to a secret key a. A party with A as its public key

Is hereinafter referred to as A hat.
And would traditionally be considered "Alice" (second party)

Is hereinafter referred to as B-hat.
Is traditionally considered "Bob"). In general, “hatnotation” is used to represent a logical ID or “distinguishing” ID of a party in the protocol, such as name, email address, role, etc. In some cases, these IDs can be augmented with digital certificates. Although not repeated here, for the more complete mathematical analysis provided in the provisional application, all parties in the protocol, including the attacker, are considered to be implemented via a stochastic polynomial time machine. It is. An attacker may also be represented by M, where M may mean “malicious”.

Thus, as illustrated in FIG. 1, the calculation of the session key for the basic unauthenticated Diffie-Hellman protocol 100 consists of an exchange between a two party A hat and a B hat, where the party A hat first has its own key. Send X = g ^x to party B hat, who then responds by returning his key Y = ^gy to party A hat, where x and y are each from set Z _q A secret chosen randomly by A and B hats, and the shared session key is calculated as g ^xy .

It should be noted that in the description herein, the symbol ∈ _R may be used to represent a random selection. For example, x ∈ _R Z _q is typically by using a random number generator or pseudo-random number generator, it means to select a random value x from the set of integers Z _q.

MQV protocol The IDs of A hat and B hat may include additional information such as public key certificates, or all of these IDs may be omitted together. The communication is identical to the basic unauthenticated DH protocol 100 depicted in FIG.

  The first challenge in designing a two-message authentication key exchange protocol is to prevent a successful attack based on the reproduction of the first protocol message. This is a problem because the first message cannot contain any form of session-specific “freshness guarantee” (eg, nonce or fresh DH value) given by the responder. There is something. One solution to this problem is to provide freshness via session key computation.

も学習する。これにより、攻撃者は、Ａハットの長期秘密署名鍵を学習する必要なしに、同じメッセージとｘに関する知識を使用して、漠然とＢハットに対してＡハットを詐称することができる。 For example, the two-message Diffie-Hellman protocol 200 illustrated in FIG. 2 is authenticated using a digital signature adopted from the ISO (International Standards Organization) 9793 protocol. Although including g ^x under the B-hat signature provides freshness for authentication, this safety feature is not present in the A-hat message. However, since session key g ^xy is randomized by fresh y, it is guaranteed to be fresh (as well as independent of other session keys). However, if the attacker can find a single pair (x, g ^x ) used by A-hat in a session with B-hat, then the protocol security breaks, in which case the attacker

Also learn. This allows an attacker to spoof A hat to B hat vaguely using the same message and knowledge about x without having to learn A hat's long-term secret signing key.

This is a serious vulnerability that violates the basic principle that other sessions should not be destroyed by disclosure of ephemeral session specific information (eg, pair (x, g ^x )). This is particularly critical considering that many applications will compute this pair (x, g ^x ) offline and will retain it in storage that is not as protected as, for example, a long-term private key .

  Therefore, the problem is how to design a two-message protocol that is not affected by a replay attack even if temporary information is leaked. Including the long-term secret key in the session key calculation is a natural answer. This was the approach undertaken in a 1986 study by Matsumoto, Takashima, and Imai, which is the motivation for many of the so-called “implicit authentication” variants of Diffie-Hellman, including MQV. In this approach, each party has a long-term DH public key and a corresponding secret exponent, and a session is generated by combining the session-specific temporary DH value with both parties' public and private keys. The Thus, the security of such a protocol as a whole depends on the exact details of this key combination. Surprisingly, this seemingly simple idea is difficult to ensure, and all previous proposals have some disadvantages.

Next, considering the following natural solution to the problem of combining temporary and long-term keys in session key calculation, if A hat and B hat want to exchange keys, both will be the basic Diffie− The Hellman protocol is executed, and a session key is calculated as K = g ^{(x + a) (y + b)} = (YB) ^{x + a} = (XA) ^{y + b} . In this case, if the attacker learns x instead of a, the attacker cannot calculate K.

However, as demonstrated by the following simple attack, the protocol is still insecure, ie M chooses the value x ^* ∈ _R Z _q , calculates X ^* = g ^{X *} / A and from A hat X ^* is sent to B-hat as a spoof of the initial message. B hat sends Y = gy and calculates the session key K = (X ^* A) ^{y + b} . Unfortunately, M can also calculate K as (BY) ^{x *} . Therefore this protocol is not secure.

は以降Ｘバーと記載する。
およびｅ＝

は以降Ｙバーと記載する。
である。 Moreover, even if the calculation of K is changed to be K = g ^{(x + da) (y + eb)} for constants d and e, an attack is still possible. On the other hand, if the constants d and e can change with X and Y so that the attacker cannot control e and Y individually, the above simple attack may not work. This idea brings us back to the MQV design, where d =

Is hereinafter referred to as X bar.
And e =

Is hereinafter referred to as Y bar.
It is.

Calculated 301, 302 of the session key K in MQV is illustrated in Figure 3, where the parties A hat owns the public key A = g ^a corresponding long-term private key a∈Z _q. Similarly, B's private / public key pair is (b, B = g ^b ), and the temporary DH values are X = g ^x and Y = g ^y , where x and y are A and B respectively. Selected by. The session key calculation also uses the values d = X bar and e = Y bar, where, if l = | q | / 2, X bar = 2 ^l + (X mod 2 ^l ) and Y bar. = ^2l + (Y mod ^2l ).

Calculation of a session key by the A-hat is offline power for computing X = g ^x and (off-lineexponentiation), online power for computing B ^e and (on-line exponentiation), ( YB e) x + Note that it requires an additional online power with respect to ^da . However, the second power uses an exponent e of length | q | / 2, so it is a “halfexponentiation” (eg, the number of modular multiplications for a regular exponentiation of g It should also be noted that is considered to be half). The same calculation count is effective for the B hat.

  Overall, the performance of MQV is really impressive, the same communication as the basic unauthenticated DH protocol (except for the possibility of transmitting a certificate as part of both parties' identity), and a half power higher than the basic protocol , Only a 25% increase in the calculation to achieve the authentication exchange. This is significantly better than either a proven DH protocol that relies on digital signatures or public key encryption for authentication, with more expensive computations and increased bandwidth. This is also the most efficient of the implicit authentication DH protocols, and the closest one requires three full exponentiations, but provides substantially less security features. “Unified Model” protocol.

  This exceptional performance and security promise makes MQV an attractive candidate when choosing an authentication DH protocol. For these reasons, this protocol has been adopted by many standards and has been extensively discussed in the literature. However, since none of the formal models of the key exchange security has successfully performed any formal analysis of the MQV protocol, one question that has not been answered so far is how secure the MQV protocol is in practice. That's what it means.

  In contrast, MQV designers were clear about the security goals behind the design. These include intrinsic security against spoofing and known key attacks (including resistance to “unknown key share” attacks) and perfect forward secrecy (PFS) and KCI (keys). Includes more specific features such as resistance to key-compromise impersonation. Resistance to known key attacks represents the principle that the disclosure of temporary session-specific secret information should not destroy the security of other sessions.

  PFS and KCI characteristics refer to confining security damage if a party's private key leaks to attacker M. More specifically, the PFS allows M to retain its session key even if both parties are destroyed after any session key established between the two undestructed parties is erased from both parties' memory. It means you can't learn. Resistance to a KCI attack learns one party's A-hat's long-term secret key, so that an attacker who can clearly misrepresent an A-hat to another party is another undestructed party against the A-hat You need to not be able to misrepresent.

  Unfortunately, as further described in the above provisional application, the results of the inventor's analysis indicate that, when studied formally, none of these properties are satisfied by the MQV protocol. Specifically, Canetti and Krawczzyk's security model demonstrates that this protocol is vulnerable to a range of attacks that contradict the above security characteristics that are said to be satisfied by MQV. ing.

HMQV Protocol The HMQV protocol ("H" can be considered to mean "hash") is, in some exemplary embodiments, to the conventional MQV protocol shown in step 302 for comparison. A simple but powerful variant of MQV that can include hashes as shown in step 303 of FIG. However, since alternative embodiments that do not perform hashing and do not use techniques other than hashing are discussed herein and are also included in the concepts of the present invention, the first problem is that one of these exemplary embodiments. It should also be noted that one or more hash steps are not a prerequisite for the present invention. A more basic concept of the invention relates to a challenge response signature scheme from which some applications and embodiments have evolved, including an exemplary hash version of the MQV protocol.

  As is well known in the art, hashing requires the use of a hash function to convert a character string as an output to a number, a fixed length string (eg, a hash or message digest), etc. The basic function of a hash function in cryptography is that it is impossible to retrieve the original data, and it must also be impossible to build a data block that matches a given hash value. To provide a “one-way” or “irreversible” transformation. Hash functions can range from simple “mixing” functions to transformations that resemble purely random scrambling. The latter is called “strong cryptographic hash function” and is often modeled in cryptographic analysis by an ideal random function (or “random oracle”).

  Some hash functions are widely used for strong cryptographic hashes. For example, MD5 takes an arbitrarily sized data block as input and uses a table of values based on bitwise operations, addition, and a sine function to process the data in 64-byte blocks. As a result, a 128-bit (16-byte) hash is generated. Another major hash function is the NIST (National Institute of Standards and Technology) Secure Hash Algorithm (SHA) which provides a 160-bit hash.

  Typically, the hash function is not used directly for encryption, but the encryption function provides a one-way transformation, and thus for some hash applications, including some exemplary embodiments of the invention. Applicable. The hash function is also appropriate for data authentication, and is called a secret key (in these settings, it is called a message authentication code (MAC in the case of Message Authentication Code), and is a pseudo-random function (Pseudo-RandomFunction). Together with a signature scheme (in this case, the hash value is used for "message digest") and is used for such purposes.

  Various exemplary embodiments of the present invention use at least one hash function H that is summarized as an ideal random oracle in the security analysis described in more detail in the above provisional application. The two tasks in which the function H is used in these exemplary embodiments are firstly the calculation of the indices d, e and secondly the derivation of the session key itself.

  The first task illustratively uses two arguments to H and outputs a string of length | q | / 2, and the second task applies H to a single argument and specifies A key having a length of (for example, 128 bits) is output. To simplify the notation, the same symbol H is used to represent both applications of the hash function. In practice, variable-length inputs can be processed, perhaps using some combination of truncation / expansion when generating hash results to adapt the two tasks above. A single H, eg, SHA-1, that can adjust the output size would be used.

  However, when using a hash as in the first task, instead of hashing only the message or party ID, additional arguments such as timestamp, nonce, etc. can be included as input to the hash function, so It should also be noted that it is not necessarily limited to two arguments.

は以降Ｈバーと記載する。
で表される場合が多く、ｋビットの出力を有し、σ値に適用されるハッシュ関数はＨで表される。実際には、異なる出力長を有する同じハッシュ関数を使用することができ、このため、Ｈバーの代わりに記号Ｈが使用されることもある。ニーモニックとして、Ｈバー内のバーは、この関数の出力が指数として使用されることを示している。 When using a hash, the hash function (typically having an output of l = | q | / 2 bits) used to generate the indices d, e is

Is hereinafter referred to as H bar.
The hash function having k-bit output and applied to the σ value is represented by H. In practice, the same hash function with different output lengths can be used, so the symbol H may be used instead of the H bar. As a mnemonic, the bar in the H bar indicates that the output of this function is used as an exponent.

という値からｋビットの鍵へのハッシュを指定し、ここでｋは所望のセッション鍵の長さである。代替実施形態では、１つまたは両方のσ関数はハッシュされない。 Like MQV, HMQV protocol communication is the same as the basic DH exchange previously illustrated in FIG. 1, but certificates may be added. As illustrated in FIG. 3, the calculation of the session key K differs from that of the MQV in calculating the values d and e and requires a hash of the party's own DH value and peer ID. A typical output of this hash is l = | q | / 2 bits. In addition, in one exemplary embodiment, the HMQV is

Specifies a hash to a k-bit key, where k is the desired session key length. In an alternative embodiment, one or both sigma functions are not hashed.

  From this description, it can be seen that HMQV retains the superior performance of MQV both in terms of communication and computation. At the same time, HMQV overcomes all the security shortcomings of MQV discussed in the above provisional patent application to the maximum extent possible with the two message protocol further discussed and proven therein. A more complete description of the security properties and benefits of HMQV and its variants will be presented later in this application.

Challenge-response signature Although it should be clear how the HMQV protocol differs from the MQV protocol, there is another aspect of the invention that is more basic in a sense. In other words, the main technical tool that exists as the central design and analysis element behind HMQV is called “challenge-response signature” and is based on a new variant of Schnorr's identification scheme using the Fiat-Shamir method. A new form of interactive signature that will be realized. The result is an “exponential challenge response” (XCR) signature of the present invention. The relationship between Schnorr and Fiat-Shamir methods and XCR signatures is discussed below.

  These XCR signatures are secure in a random oracle model (based on the computational Diffie-Hellman (Computational Diffie-Hellman) or CDH hypothesis—see below), both verifiers and signers are exemplary Have the property that the same signature can be calculated. The former can accomplish this by grasping the challenge, and the latter can do this by grasping the secret signing key. Variations on calculating the same signature include calculating different but related signatures by the signer and verifier.

  For example, a signature value calculated by one may be a hash variant of a signature calculated by the other, or both signatures may be related, such as by some specific algebraic characteristic. The various HMQV protocols of the present invention are one exemplary mechanism that uses these XCR signatures, which provide authentication (DH value and peer ID) and session key computation.

  Thus, XCR signatures and their “dual versions” (eg, DCR), when briefly discussed, provide a natural interpretation, both technically and conceptually, of the concepts underlying HMQV design and analysis. Is.

  In addition, it should be noted that XCR signatures can also be used in applications beyond the HMQV protocol. In each basic form, XCR signatures are interactive, challenge specific, and non-transferable and therefore do not provide the classic functionality of digital signatures. That is, they cannot be used for non-repudiation.

  In contrast, they provide “deniable authentication”, which is an important property for some applications, including key exchanges, so that messages to XCR signature recipients Alternatively, the source and integrity of the key can be guaranteed, but this source cannot be proved to a third party. In particular, these signatures and the resulting key exchange protocol are ideally suited for “off-the-record” communication and privacy protection. In addition, non-interactive versions of XCR exist as described below and provide an alternative to established signature schemes such as the well-known digital signature algorithm (DSA) in some cases.

  Like the regular digital signature scheme, in the challenge-response signature scheme, the signer has a private / public key pair that is used for signature generation and verification, respectively, and the verifier uses the signer's authentic public key. It is supposed to be obtained. In particular, both parties are not expected to share a secret prior to the start of the signature protocol, and such a shared secret is not required for signature calculations. However, in its basic form, as opposed to a legitimate signature, challenge-response signatures are interactive, and the signature recipient (e.g., before the signer generates the signature on a given message) The verifier needs to issue a challenge to the signer. A secure challenge-response signature scheme needs to ensure that no one other than the legitimate signer can generate a signature that would convince the challenger to accept the signature as valid. In particular, the signature is not only message specific but also challenge specific.

  On the other hand, it is of interest to ensure the verifiability of signatures by challengers, so there are no assumptions or requirements regarding the transferability of signatures or verifiability by third parties. In addition, the particular scheme described below has the property that the party selecting the challenge can always generate a valid signature on any message for that particular challenge. More important with respect to this application, what distinguishes this scheme from other interactive signatures is that the verifier can use the challenge to calculate the same (or associated) signature string as the signer.

を出力するハッシュ関数であるが、この場合も、「素数次数（prime order）」の使用およびＨの出力の特定の長さは、模範的な諸実施形態の模範的な設計の詳細に過ぎず、本発明に不可欠なものではない。 As described above, g is a generator of a group G of order q (usually a prime number). H is | q | / 2 bits

, Where again the use of “prime order” and the specific length of the output of H are only exemplary design details of exemplary embodiments. It is not essential to the present invention.

というペアとして定義され、ここでＹ＝ｇ^yであり、ｙ∈_RＺ_qはＢハットによって選択され、指数ｙ＋Ｈバー（Ｙ，ｍ）ｂはｑを法として換算される。検証者Ａハットは、それが

であると判断した場合のみ、（メッセージｍおよびチャレンジＸ＝ｇ^xについて）有効なものとして署名ペア（Ｙ，σ）を受け入れる。 Definition of XCR Signature Scheme The exponential challenge response (XCR) signature scheme 500 illustrated in FIG. 4 is defined as follows. In other words, the signer in XCR scheme represented by B hat, owns a public key B = g ^b a secret key b∈ _R Z _q. Verifier represented by A hat (or challenger) provides initial challenge X, A hat is calculated as X = g ^x in the case of x ∈ _R Z _q, where x is chosen by A hat, Kept secret. The signature of B-hat on a given message m using challenge X is

Where Y = g ^y , yε _R Z _q is selected by the B hat, and the exponent y + H bar (Y, m) b is converted modulo q. Verifier A hat

Only if it is determined that the signature pair (Y, σ) is valid (for message m and challenge X = g ^x ).

と定義する。すなわち、

は、ＸＣＲ署名ペア内の第２の元を表している。一般的な注記として、「メッセージ」という単語の上記の使用が、送信データ、ファイル、媒体などを含むビット・ストリームによって表すことができ、それ自体がより長いメッセージのハッシュ・バージョンになりうる任意の形式のデータまたは情報を表すことは注目する価値がある。このメッセージは、図５に図示されているように両当事者に対して入力できるか、ある当事者から他の当事者に伝送できるか、あるいは第三者、外部ソースなどから提供することができる。 Here, the following notation is used. That is, for a given message m, challenge X, and value Y,

It is defined as That is,

Represents the second element in the XCR signature pair. As a general note, any of the above uses of the word “message” can be represented by a bit stream that includes transmitted data, files, media, etc., and can be any hashed version of the message itself. Representing a form of data or information is worth noting. This message can be entered for both parties as illustrated in FIG. 5, can be transmitted from one party to another, or can be provided from a third party, an external source, or the like.

  As described in this application, the advantages of XCR signing include: soundness of analysis (verifiable), computability by both verifiers and provers, duality (a single calculation is signed by two or more parties) ), “Hashability” (ie ability to process and verify hash signatures), derivation of keys or common values, non-transferability and repudiation, (traditional from repudible signatures) Convertibility (to non-repudible signatures), providing a robust alternative to DSS (especially in interactive environments), as well as the presence of non-interactive variants.

The motivation for the design of the XCR scheme through its association with Schnorr's identification scheme from which the XCR signature is derived may be illustrative. Schnorr's (interactive) identification scheme consists of a proof that he knows the discrete logarithm b for a given input B = g ^b . Let B-hat represent the prover of this scheme (which owns b), and let A-hat represent the verifier (given input B). Basic Schnorr identification consists of the following three messages.
(I) B hat selects ^y ∈ _R Z _q and sends Y = g ^y to A hat.
(Ii) A hat responds with a random value e∈ _R Z _q.
(Iii) The B hat sends the value s = y + eb to the A hat. A hat will only accept if g ^s = YB ^e is valid.

に変換することができる。 This protocol is a public-coin zero-knowledge proof of knowledge (of b) for an honest verifier A hat (eg, someone who randomly selects e uniformly). This is therefore a secure signature scheme that can be verified with the random oracle model via the well known Fiat-Shamir method, ie

Can be converted to

Next, consider the following four message variants of the Schnorr protocol to which a first message from A hat to B hat is added. In this first message, A-hat sends the value X = g ^x to B-hat. Next, three messages from the Schnorr scheme follow, but in message (iii), the fourth message of the modified protocol, instead of sending s = y + eb to A hat, B hat has S = Send X ^s . A hat is accepted only if S = (YB ^e ) ^x . It can be seen that this protocol is a proof of B's “ability” to compute Diffie-Hellman values CDH (B, X) for any value XεG. Moreover, this protocol is zero knowledge for a verifier A hat that randomly selects e, and X can be chosen arbitrarily.

By applying the Fiat-Shamir transformation to this protocol, the challenge-response signature XCR of the present invention is obtained. It also explains why the term “exponent” is used when naming the XCR scheme, and refers to replacing the Schnorr scheme s = y + eb with the X ^s of the last message in this protocol. Yes.

  Additional aspects of XCR signature based security based on the CDH hypothesis are further discussed in the above provisional application.

In describing some of the above terms, if the two elements in G are U = g ^u and V = g ^v , the result of applying the Diffie-Hellman calculation to U and V is expressed as CDH (U, V ) (For example, CDH (U, V) = g ^uv ). This algorithm is called a “CDH solver for G (solver)” when it takes a pair of elements (U, V) in G as input and outputs a Diffie-Hellman result CDH (U, V). The main intractability assumption used in the analysis further provided in the provisional application is the computational Diffie-Hellman (CDH) hypothesis. For all efficient CDH solving routines for G, if the probability that the solving routine calculates the correct value CDH (U, V) for the pair (U, V) for U, Vε _R G is negligible ( This probability is taken for random coins in the solution routine, and the selection of U and V is done randomly and independently within G), and the CDH hypothesis is valid for group G.

The number of bits in H bar (Y, m) l is the number of bits in H bar (Y, m). Obviously, the smaller the l, the higher the efficiency of the signature scheme. On the other hand, if the index H bar (Y, m) is predictable, the signature scheme becomes unstable. If l is too small, it indicates that the security bound is bad. However, it is a problem how large l is necessary for security.

  The setting l = 1/2 | q | provides a good security performance trade-off, so that in the exemplary designation of the XCR signature (and for its exemplary application to the HMQV protocol of the present invention) It can be seen that this value is used (see discussion of provisional application above).

Changing the order of interactions with B In particular, in some applications of XCR signatures applied to the analysis of the HMQV protocol, the order of interactions between the challenger A hat and the signer B hat can be changed.

で直ちに応答することができる。現在検討している変更済みバージョンでは、以下の順序の対話が行われる。
（ｉ）ＡハットはＢハットにメッセージｍを提示し、ＢハットはＹを出力し、その後の何らかの時点で
（ｉｉ）ＡハットはＢハットに（Ｙ，ｍ，Ｘ）を提供し、Ｂハットは

を出力する。 In the above definition of the XCR scheme, A-hat provides challenge X to B-hat and simultaneously presents message m to B-hat so that B-hat is signed

You can respond immediately. In the modified version currently under consideration, the following sequence of interactions takes place:
(I) A hat presents message m to B hat, B hat outputs Y, and at some point thereafter (ii) A hat provides (Y, m, X) to B hat, and B hat Is

Is output.

で応答し、その状態から（Ｙ，ｍ）を消去する（Ｂハットがその状態内にペア（Ｙ，ｍ）を持っていない場合、それはその署名を発行しない）。 Next, assume that party F queries B hat to take this changed order. In particular, F can interleave various interactions with the B hat, ie, F can perform several instances of step (i) before performing the corresponding step (ii). This requires the B hat to keep the state after step (i) with values Y, y and m. Later, when F presents (Y, m, X) in step (ii), B-hat checks that it has a pair (Y, m) in its state and

And delete (Y, m) from that state (if B-hat does not have a pair (Y, m) in that state, it does not issue its signature).

  Note that this designation of the action of B-hat ensures that B-hat does not use the same Y value for two different signatures. Proof of XCR signature security just because the simulation of the selection of Y by B-hat does not require knowledge of X, but only the value of m is needed to determine H bar (Y, m)) It can be easily verified that is still valid for this modified order.

Hash XCR variant (HCR)
It is possible to replace a pair of XCR signatures (Y, σ) with a pair (Y, H (σ)), where H is a hash function, and such a “hash XCR” signature is abbreviated as “HCR”. Is done. Note that the XCR property allows the verifier to recalculate σ for Y, so given Y, H (σ) can also be calculated, and thus the modified HCR signature can be verified.

  HCR signatures have a range of characteristics that are important in some settings. For example, the signature may be shorter than a regular XCR signature, may result in a random or pseudo-random value, and may prevent an attacker from learning the algebraic structure in σ. .

In particular, in interactive and verifier-specific authentication environments (such as key exchange protocols), HCR signatures provide a more secure alternative to DSA signatures. In fact, in DSA, disclosing a single temporary exponent (eg, ^k in the DSA signature component r = g k) makes the signature scheme completely unstable by revealing the secret signature key, and the temporary exponent Even if y is revealed to the attacker, the HCR signature cannot be forged (but in this case the signer must test the order of challenge X or enforce it using co-factor exponentiation) The value is at least of order q).

Non-interactive XCR variants XCR (and HCR) signatures can be made non-interactive but verifier-specific by writing X = A, where A is as illustrated in FIG. The verifier's public key. This provides a very efficient non-interactive and verifier specific non-repudiation authentication mechanism. In one variation, rather than using party A's own public key A, the latter can publish one or more challenges (eg, post on a website) for use by the signer. Thus, these challenges can be used even if the A hat itself is not available at the time of signing.

Translatable XCR signatures The salient properties of XCR signatures, including those based on shared secrets and public key cryptography, that distinguish it from other “repudiation” challenge-response mechanisms, The ability to “convert” to a legitimate non-repudible signature. Translatable signatures have the characteristics of non-repudiation authentication, i.e. they can only be verified by the intended recipient, but the signer can also create a given signature without revealing his private signing key You can finally prove that you are a person.

  This convertibility from a private signature to a public signature may be necessary, for example, for professional informal communications that must be converted to a verifiable public record after several years. In the case of an XCR signature, the signature (Y, σ) on the message m based on the challenge X is converted to a legitimate non-repudible signature by a legitimate signer by revealing the value y + H bar (Y, m) b Can do.

  Other (receiver-specific) convertible signatures have been presented in the literature, but none of the intended recipients (or challengers) can recalculate the signatures on their own, so that This recomputation property does not share many of the benefits that XCR signatures provide, as illustrated by the double XCR signatures.

Double XCR signature (DCR)
One important property of XCR signatures is that the challenger who selects the challenge can calculate the signature on his own. Here, any two-party A-hat, B-hat can interact with each other in the dual role of challenger and signer, each associated challenge-response signature with the characteristic that it generates a signature that no third party can forge A method is shown that takes advantage of this property to derive a scheme (herein referred to as “dual XCR scheme” or DCR for short). Moreover, this makes this scheme important for the HMQV protocol, and the resulting signatures by A and B hats have the same value. More precisely, they have the same XSIG component in the XCR signature pair.

という３つ組の値として定義され、ここでＸ＝ｇ^xおよびＹ＝ｇ^yはそれぞれＡハットおよびＢハットによって選択されたチャレンジであり、記号ｄおよびｅはそれぞれＨバー（Ｘ，ｍ₁）およびＨバー（Ｙ，ｍ₂）を表している。（図７を参照されたい。） Definition: Double (exponential) challenge response (DCR) signature scheme. A hat and B hat, a 2 parties each having a public key A = g ^a, a B = g ^b. m ₁ and m ₂ are two messages. The double XCR signature (DCR for short) of A hat and B hat on messages m ₁ and m ₂ respectively is X, Y, and

Where X = g ^x and Y = g ^y are challenges selected by A hat and B hat, respectively, and the symbols d and e are H bars (X, m ₁ ), respectively. And H bar (Y, m ₂ ). (See FIG. 7)

を計算（および検証）できることである。これは、

という等値（equivalence）から分かり、ここでｘ＋ｄａおよびｙ＋ｅｂはｑを法として換算される。 Thus, the basic property of a DCR signature is that after exchanging the values X and Y (including x and y selected by A and B hats, respectively), both A and B hats have the same signature.

Can be calculated (and verified). this is,

Where x + da and y + eb are converted modulo q.

  Moreover, as demonstrated in the provisional application discussion above, the attacker cannot calculate to be able to execute this signature.

Roughly speaking, the double signature is an XCR signature by A hat on message m ₁ based on challenge YB ^e and at the same time an XCR signature by B hat on message m ₂ based on challenge XA ^d . More precisely, since the values d and e are determined during the signing process (possibly by hostile selection of messages m ₁ , m ₂ ), the B-hat DCR signature is not chosen by the attacker. it can be demonstrated to be safe with respect to the value ^a = g ^a.

という二重ＸＣＲ署名を計算するためのチャレンジとして機能するＤｉｆｆｉｅ−Ｈｅｌｌｍａｎ値Ｘ＝ｇ^xおよびＹ＝ｇ^yの両当事者間の交換から構成される。次に、この値をハッシュすることにより、セッション鍵が導出される。このように、署名自体は伝送する必要がなく、セッション鍵の共通導出値を保証するのは署名の一意性（uniqueness）であり、主張された当事者Ａハット、Ｂハットによって交換が実行されたという証明を可能にするのは鍵（同等に、署名）を計算する固有の能力である。 Formal description of the basic HMQV protocol The HMQV protocol is the basic two-message exchange in which both parties A and B

The Diffie-Hellman values X = g ^x and Y = g ^{y that} serve as a challenge to compute the double XCR signature Next, the session key is derived by hashing this value. Thus, the signature itself does not need to be transmitted, and it is the signature uniqueness that guarantees the common derived value of the session key, and that the exchange was performed by the claimed party A hat and B hat. It is the inherent ability to compute a key (equivalently, a signature) that allows proof.

Basically, the messages m ₁ and m ₂ for which signatures are calculated are peer IDs (ie, A hat and B hat), so that both parties are uniquely bound to the correct ID by their keys. Get a guarantee that This inclusion of both parties' IDs in addition to the temporary Diffie-Hellman value in the signature (especially in the calculation of the values d and e) is essential to avoid any authentication failure such as a UKS attack. is there.

である。すなわち、πは互いのＩＤに関するＡハットおよびＢハットの二重署名として計算される。上記の署名は、省略表現π（Ａハット，Ｂハット，Ｘ，Ｙ）によって表され、すなわち、

であり、ここでｄ＝Ｈバー（Ｘ，Ｂハット）、ｅ＝Ｈバー（Ｙ，Ａハット）であり、Ａ＝ｇ^a、Ｂ＝ｇ^yはそれぞれ両当事者Ａハット、Ｂハットの公開鍵である。π（Ａハット，Ｂハット，Ｘ，Ｙ）＝π（Ｂハット，Ａハット，Ｙ，Ｘ）であることは、この時点で留意すべきである。ある変形では、Ｈ（π）はπの異なる関数で置き換えることができ、とりわけ、ハッシュは両当事者のＩＤなどの追加の情報を含むことができる。 Therefore, the HMQV protocol session between the two parties A-hat and B-hat is based on the basic Diffie-Hellman exchange of DH values X = g ^x and Y = g ^y (FIG. 1) with the session key calculated as H (π). Composed here

It is. That is, π is calculated as a double signature of A hat and B hat regarding each other's ID. The above signature is represented by the abbreviation π (A hat, B hat, X, Y), ie

, And the where d = H bar (X, B hat), a e = H bar (Y, A ^{hat), A = g a, B} = g y each parties A hat, B hat public key It is. It should be noted at this point that π (A hat, B hat, X, Y) = π (B hat, A hat, Y, X). In one variation, H (π) can be replaced with a different function of π, and in particular, the hash can include additional information such as the IDs of both parties.

The HMQV protocol is typically implemented in a multi-party network that can call any of the parties to execute the protocol. Each time a party calls a protocol, a session (a local state containing information related to this particular instance of the protocol) is created, which can generate an outgoing message and session key output upon completion. During a session, a party can be activated by three types of activation as follows (in the following description, A hat represents the identity of the party to be activated and B hat is the intended peer of the session: ID).
1. Initiate (A hat, B hat): A hat generates the values X = g ^x , xε _R Z _q and identifies it as the (incomplete) session (A hat, B hat, X). Create a session and output the value X as its outgoing message.
The meaning of this activation is that A hat is activated as an initiator of a session with B hat, and X is a message scheduled to be delivered to peer B hat as part of this session. The party A hat is called the “holder” (or “owner”) of the session, the B hat is called the “peer” for the session, and X is called the originating (DH) value.
2. Response (A hat, B hat, Y): Check that A hat is Y ≠ 0. If so, A hat, the value _{^{X = g x, x∈ R Z}} q generates and outputs the X, ID (A hat, B hat, X, Y) and the session key H (π ((A Hat, B hat, X, Y)), where A hat is activated as the responder in the session with peer B hat and incoming value Y. In this case, A hat is immediately Complete the session (no more incoming messages at all) Note that if the incoming value Y is zero, the A hat ignores the activation.
3. Complete (A hat, B hat, X, Y): A hat checks that Y ≠ 0 and has a public session with ID (A hat, B hat, X). If any of these conditions are not met, the A hat ignores the activation, and if it does, the A hat has a session ID (A hat, B hat, X, Y) and a session key K = H (π ((A (Hat, B hat, X, Y)), which represents the delivery of the second message in this protocol by the incoming value Y, which is a response from the peer B hat (according to the complaint). Yes.

Three Message HMQV-C Protocol The three message HMQV-C (C stands for “key Confirmation”) protocol is depicted in FIG. This protocol enjoys all the security properties of HMQV, in particular the same computational cost. However, this adds a third message to the protocol and slightly increases the length of the protocol message.

  Instead, HMQV-C provides several characteristics that are lacking in the basic HMQV protocol, including key verification, PFS, and universal composability.

Key Verification The HMQV protocol provides basic assurance to a party A hat that completes a session with a peer B hat and a session key K, and if B hat is not destroyed, only B hat probably knows K Can do. What this protocol does not provide is a guarantee for A-hat that B-hat completed the session or calculated the session key. Moreover, B-Hat may not have been “active” during the session.

  Same for any two-message public key-based protocol (assuming no pre-shared state was created in the previous communication between A and B hats as in a typical public key scenario) This is not the only drawback of HMQV, as it is true. Furthermore, as pointed out by Shop, the obvious goal that both parties have a guarantee that the peer has completed the session before each using that key is the key to any key exchange protocol. But it cannot be achieved. In fact, an attacker can always prevent this cross-guarantee by preventing the last protocol message from reaching its destination.

  However, if the guarantee to each of the parties that the peer was able to calculate the key is weak (but not necessarily a guarantee that the key will be output to the calling application), that guarantee is achievable, and the key confirmation in the literature Called a characteristic. Although not critical to the basic security of key exchange (eg, lack of key verification is not a threat to the privacy or authenticity of communications protected by a key), this property is useful for some applications. An operational sanity check can be provided.

  In this case, the protocol HMQV-C is more suitable than HMQV because the additional MAC value allows key verification. In addition, MAC validation confirms the fact that this peer owns a matching session (ie, having the same peer and the same session key), along with the active involvement of the identified peer for the session. To achieve these characteristics, the HMQV-C MAC does not need to be applied to any particular session information, but is simply used to indicate the “direction” of the message as well as to prevent reflections. Note that one bit needs to be applied. Also, a protocol consisting of only the first two messages of HMQV-C provides key verification to the initiator (which can add useful features to HMQV without increasing the number of protocol messages Is also worthy of attention.

  In many key exchange applications, the result of a lack of key verification, for example, party A hat begins to use the key to send protection information to B hat, but B hat has not yet established the key. There is a possibility that some form of “denial of service” (DoS) attack will be carried out in which this information cannot be processed. As said, mutual "session completion" confirmation is not achievable, so this situation cannot be completely avoided.

  In addition, a more serious form of protocol based on public key behavior, in which a party is forced to spend a significant computational cycle (and create session state) before discovering peer invalidation. DoS attacks exist. There are several countermeasures that can be applied to any key exchange protocol (including HMQV) at the expense of adding protocol messages and that are useful but limited in scope for DoS attacks.

Full forwarding secret (PFS)
Perfect forward secrecy is a highly desirable property of a key exchange protocol that does not compromise the security of the old session key if a long-term secret key is leaked. More formally, if an unbroken party A hat establishes a key exchange session with an unbroken peer B hat, the attacker may destroy the A hat after K expires in the A hat or Even if an attacker destroys B-hat after K expires in B-hat, session key K is still secure. Neither of the two message protocols with implicit authentication, including HMQV, can provide a complete perfect forward secret for an active attacker. Instead, the best that can be desired is the weak form of PFS provided by HMQV. The main advantage of HMQV-C over basic two-message HMQV is that it raises the inherent limitations of HMQV and provides a complete PFS, as further explained in the provisional application.

General Configurability Security The Canetti / Krawczyk model for key exchange is the basis for the analysis of MQV and HMQV in provisional applications, and the key exchange protocol when executed concurrently with other applications, as in the real world environment. It has been extended to a more ambitious model with the goal of ensuring security. This model is known as a universal-composability (UC) model for key exchange.

  For HMQV-C, when the first party to complete the session outputs its session key, it can be seen that the state of the peer includes only information that can be “simulated” from the protocol and the public information in the session key. . Canatti / Krawczzyk, along with other security properties of HMQV shown in the provisional application, indicate that this property is sufficient to ensure universal configurability of the HMQV protocol.

1 pass HMQV
The one-pass key exchange protocol shown in FIG. 9 consists of a single message sent from the sender A hat to the receiver B hat, as long as both parties and the session are not destroyed as defined below. From there, both parties use their private and public keys to derive a unique key that only A-hat and B-hat can possibly grasp.

  The requirements from the established key are the same as the regular key exchange protocol, except that the message received by B-hat may be a replay of an old message from A-hat. This playback is unavoidable with the one-pass protocol, but may be detectable by other means such as synchronization time or shared state.

  In addition, such a protocol cannot provide PFS because the lack of session-specific input from the B-hat requires that the key be computable with a single knowledge of the B-hat's private key.

を計算する。
（ｉｉｉ）Ｋ＝Ｈ（σ，Ａハット）を設定し、ここでＨは必要な鍵の長さに等しいビット数を出力する。同じ鍵Ｋは、Ｘ≠０であることをチェックした後、ＢハットによってＫ＝Ｈ（（ＸＡ^d）^b）として計算される。変形では、Ｋ＝Ｈ（σ，Ａハット，Ｂハット）である。 In one embodiment of the present invention, each public key A = g ^a, B = 1-pass HMQV protocol between party A hat and B hat having a g ^b a single value that is transmitted from the A hat B hat consists X = g ^x, where x ∈ _R Z _q is chosen by A hat. Session key K is calculated by A hat as follows.
(I) (A hat, B hat) represents a message containing two IDs A hat and B hat, and d is set so that d = H bar (X, (A hat, B hat)). Set.
(Ii)

Calculate
(Iii) Set K = H (σ, A hat), where H outputs the number of bits equal to the required key length. The same key K is calculated as K = H ((XA ^d ) ^b ) by the B hat after checking that X ≠ 0. In the deformation, K = H (σ, A hat, B hat).

  In other words, the key for this embodiment of 1-pass HMQV is derived from a non-interactive XCR signature using the B-hat's public key as a challenge.

It has also been pointed out that the one-pass protocol can be used as an authentication-selected ciphertext secure (CCA) encryption scheme. That is, the A hat can transmit the message m that is encrypted (by the selected cipher attack) and authenticated (by the A hat) to the B hat. In one embodiment, A-Hat will send a triple (X, c, t), where X = g ^x and c is a symmetric selected plaintext secure message m based on key K ₁ (CPA: chosen-plaintextsecure) a ciphertext obtained as encryption, t is the calculated MAC value for c based on the key K _2. Keys K ₁ and K ₂ are derived from key K calculated from X as in the one-pass HMQV protocol.

  The overall cost of this procedure is two powers (one is offline) for the A hat and 1.5 for the B hat. This is only a power of a half for B hat compared to alternative CCA encryption schemes such as DHIES (Diffie-Hellman Integrated Encryption Scheme), but instead from A hat (In the case of DHIES, this authentication would return a complete additional signature from the A hat). This efficient authenticated CCA encryption is very attractive for “store-and-forward” applications, such as typical “Pretty-GoodPrivacy” applications, It is considerably cheaper than the sign-and-encrypt paradigm of In this case, the only warning is that the ID A hat (and possibly its certificate) needs to be transmitted in clear text as it is necessary for the decryption operation.

  Among other properties of the above protocol, it is worth noting that it can only be used as a verifier-specific signature of the A hat on message m without necessarily adding an encrypted part. However, this signature is unique to the receiver and therefore does not provide non-repudiation. Instead, it provides repudiation, which is a very valuable feature in many applications such as PGP.

  It should be noted that many standards that employ MQV also employ its one-pass variant. For standards interested in adopting HMQV in its various forms (1-message, 2-message, and 3-message), define derivation of keys in a one-pass protocol, as well as derivation of other variants of HMQV. That would make sense.

および

を計算し、鍵Ｋをこれらの（等しい）値のハッシュに設定する。この場合、他の変種と互換性のあるものにすることを除き、指数ｅはいかなる値もプロトコルに追加しないことに留意されたい。これは、実際に、プロトコル効率をいくらか減ずるものである。 Specifically, by substituting Y for B in the double signature that defines the HMQV protocol, the following values are obtained for one pass key, and A hat and B hat are respectively

and

And set the key K to a hash of these (equal) values. Note that in this case, the index e does not add any value to the protocol, except to make it compatible with other variants. This actually reduces some of the protocol efficiency.

  However, there is an additional difference between the value of d = H bar (X, (A hat, B hat)) for the one-pass version of HMQV and the value of d = H bar (X, B hat) for the two message version. Contradiction persists. Any of these methods providing compatibility between the three modes has d = H bar (X, B hat), e = H bar (Y, A hat), where Y in the case of one pass. = B and ID A hat to the session key derivation function, ie, K = H (σ, A hat, B hat) (with A and B hat orders defined using some fixed criteria), B hat will be added. This replaces the need to add an A hat in the calculation of d. It also has the advantage of enhancing HMQV and avoiding potentially unknown key-sharing attacks when the pre-calculated DH value leaks.

Summary of Security Aspects of HMQV Compared to the traditional MQV protocol, the HMQV protocol offers several performance advantages, including: HMQV eliminates the need for expensive prime order tests on the DH values transmitted in this protocol. As demonstrated in the provisional application, the only way an attacker can benefit from the selection of rogue DH values is to select them to be zero, and thus simple non-zero A check is all that is needed in HMQV. For this reason, there is no need for a prime order test or a cofactor h used simultaneously in the MQV protocol.

A list of properties that the HMQV protocol achieves in a mathematically verifiable way follows.
(1) HMQV is a secure formal key exchange model of Canetti and Krawczzyk.
(2) HMQV withstands spoofing by an attacker who cannot access the private keys of both parties.
(3) HMQV applies an XCR signature to the identity of the exchange parties, thus establishing a unique binding between these party IDs and keys by avoiding UKS and other authentication attacks. .
(4) HMQV is safe even 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, different session keys are guaranteed to be “computationally independent” from each other.
(5) This protocol provides an additional level of protection known as resistance to “key-compromise impersonation (KCI)” attacks, ie it can spoof other parties to A Thus, an attacker who learns the secret key of the party A is blocked.
(6) The three-message HMQV protocol with key verification provides verifiable complete transfer secrets (PFS), ie, even if the two parties' long-term secret keys are finally disclosed, these parties before leakage The session key created by is still secure.
(7) The three-message protocol with key confirmation enjoys the additional security benefits of the so-called “generic configurable” key exchange protocol, ie can be securely configured by other protocols.
(8) The security of HMQV does not rely on special tests on the format and structure of static public keys and does not require a so-called “proof of possession” of the corresponding private key. This advantage of HMQV over similar protocols, including MQV, frees the certification authority (CA) from the burden of performing such special checks on registered public keys, and as a result more realistic Provides a practical security guarantee, especially because many local CAs cannot or are not configured to perform such checks. Moreover, it is worth noting that opening the protocol to additional security vulnerabilities through the legitimate execution of such tests (eg, proof of ownership) by the CA.
(9) The two-message and three-message HMQV protocols do not require testing of the order of the temporary public keys (ie, values X and Y), thus avoiding tests that can be expensive in some cases. However, such a test is necessary if the security of the protocol is to withstand an attacker who may learn the temporary secret keys of both parties. This test is also necessary for the security of the one-pass HMQV protocol. Like MQV, these tests can be replaced by “cofactor power” of the σ value in the protocol. Depending on the underlying algebraic group, additional tests on group elements, such as membership within a given group, may be required.

  One of the key advantages of the HMQV protocol of the present invention is that it is almost certainly the most efficient authentication Diffie when there is a wide range of security properties that can be proved to be formally mathematically valid. -It is a Hellman key exchange protocol. In fact, this formal verifiability is one of the main differences between HMQV and its predecessor MQV.

  Not only was MQV unable to provide proof of security, but the explicit weaknesses of this protocol have become clear over time, including several weaknesses first described in the above provisional application ( For example, a study by Kalliski and a report by Rogaway et al.). Such weaknesses or attacks have invalidated some of the MQV security claims made by the inventor and have been shown, among other things, to be unable to prove that MQV is secure.

Comparison of XCR signatures with MQV's “Implicit Signature” As a comparison, it is worth noting that MQV described in patents and academic papers also uses the concept of signatures in protocol design and description. There is. This is called “implicit signature” in connection with MQV and follows the more traditional concept of digital signatures where only the owner of the private signing key can generate a signature value (specifically, MQV is Refers to a signature such as ElGamal formed by a primary combination of a private signing key with a temporary private key and a public key). However, the protocol does not fully use these signature characteristics. In particular, the MQV protocol does not use signatures as a way to explicitly authenticate the identity of the parties to the protocol, which makes it possible to use the famous “unknown key share (UKS)” discovered by Kalski. A serious authentication failure occurs.

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

  An important novelty of XCR signatures is the property that both the signer and verifier (or challenger) can calculate the same signature. This property is usually found in authentication mechanisms based on shared key cryptography (ie, when both the signer and verifier have an a-priori shared key), but new in public key-based signatures. It is. XCR signatures, like HMQV, are not only perfectly suited for derivation of shared keys, but also present various advantages as authentication tools, some of which are as described above.

  It should be apparent to those skilled in the art that the present invention includes various embodiments.

Thus, in an exemplary embodiment, there are two parties: verifier V and signer S. The signer S has a private key b and a public key B, and the verifier V owns or obtains (for example, via a digital certificate transmitted from S) the authentic public key B of S is assumed. Authentication protocols for a given message m include:
(1) V selects a secret value x and computes the value X = F ₁ (x), where F ₁ is a given function and then sends X to S.
(2) S selects the secret value y and calculates the value Y = F ₂ (y), where F ₂ is a given function and then sends Y to V.
(3) S calculates the value s = F ₃ (y, b, X, m), where F ₃ is a given function and then sends s to V.
(4) V calculates the value s ′ = F ₄ (x, Y, B, m) and determines the certainty of m based on the value s ′ and its relationship to the received value s.

および

である。
（ｃ）ｓ′＝ｓである場合のみ、ｍを認証として受け入れる。この最後の変種は、それにより、チャレンジＸの背後にある秘密を把握することによって検証者が署名を再計算できる、典型的なＸＣＲ署名の特性を利用する。
（ｄ）

を計算し、Ｈ（ｓ′）＝ｓなどをテストする。 Some exemplary variants of this embodiment include:
(A) F ₁ and F ₂ are one-way functions. In XCR, these one-way functions are X = g ^x and Y = g ^y .
(B) For XCR signatures, this function is

and

It is.
(C) Accept m as authentication only if s ′ = s. This last variant takes advantage of the characteristics of a typical XCR signature that allows the verifier to recalculate the signature by knowing the secret behind Challenge X.
(D)

And H (s ′) = s or the like is tested.

  In at least one embodiment of the application of XCR to HMQV, the value s calculated by S in step (3) is never sent to V. Instead, V computes a value s' that should be the same as s (except when S is an imposter) and uses s (which is σ in HMQV) The session key is derived from In particular, V never performs explicit verification. In this embodiment, rather than a method for verifying the authenticity of the message m, both parties calculate a common “authenticated value” (ie a value that only both parties can calculate), and this value Is uniquely bound to each ID (which is an essential condition in a typical key exchange protocol achieved with HMQV by signing both parties' IDs via a double XCR signature) It will be.

  Additional variations are described in the above description and the claims.

Exemplary Hardware Implementation FIG. 10 illustrates a typical hardware configuration of an information processing / computer system according to the present invention, which system preferably includes at least one processor or central processing unit (CPU). central processing unit) 1011.

  The CPU 1011 includes a random access memory (RAM) 1014, a read-only memory (ROM) 1016, and an input / output (I / O) adapter 1018 (disk device) via a system bus 1012. 1021 and peripheral devices such as tape drive 1040 to bus 1012), user interface adapter 1022 (keyboard 1024, mouse 1026, speaker 1028, microphone 1032, or other user interface device, or any of these) Connecting the information processing system to a data processing network, the Internet, an intranet, a personal area network (PAN), etc. Because communications adapter 1034, and a bus 1012 display device 1038 or the printer 1039 (e.g., a digital printer) or are interconnected to the display adapter 1036 for connecting both.

  In addition to the hardware / software embodiments described above, a different aspect of the present invention includes a computer-implemented method for performing the method described above. As an example, the method can be implemented in the specific embodiments discussed above.

  Such a method can be implemented, for example, by manipulating a computer implemented by a digital data processing device to execute a series of machine-readable instructions. These instructions can reside on various types of signal transmission media.

  Thus, this aspect of the invention specifically implements a program comprising a plurality of machine-readable instructions executable by a digital data processor incorporating the CPU 1011 and the hardware described above to perform the method of the invention. Intended for programmable products including signal transmission media.

  The signal transmission medium can include, for example, a RAM represented by a high-speed access storage device, for example, stored in the CPU 1011. Alternatively, the instructions can be contained in other signal transmission media such as a magnetic data storage diskette 1100 (FIG. 11) that can be accessed directly or indirectly by the CPU 1011.

  Whether stored on diskette 1100, computer / CPU 1011 or elsewhere, the instructions are stored in a DASD storage device (eg, a conventional “hard disk” or RAID array). Magnetic tape, electronic read-only memory (eg, ROM, EPROM, or EEPROM), optical storage (eg, CD-ROM, WORM, DVD, digital optical tape, etc.), paper “punch” cards, or digital and It can be stored on various machine-readable data storage media such as analog communication links and other suitable signal transmission media including transmission media such as wireless. In an exemplary embodiment of the invention, the machine readable instructions may include software object code.

1 is a diagram illustrating a basic (non-authenticated) Diffie-Hellman protocol 100. FIG. FIG. 2 shows a two-message Diffie-Hellman protocol 200 authenticated by using a digital signature. FIG. 5 shows a comparison 300 of the calculation of the session key K of the conventional MQV protocol to the calculation of the session key of the HMQV protocol of the present invention, and shows which HMQV the hash of an exemplary embodiment that is an addition to the hash used in MQV It is a figure demonstrating how to use. 4 is a different graphical representation 400 of the HMQV protocol shown in FIG. FIG. 6 illustrates an XCR calculation 500 exemplarily. FIG. 6 illustrates an example of a non-interactive XCR signature calculation 600. FIG. 7 illustrates a double XCR signature calculation 700 by two parties. FIG. 6 illustrates HMQV exemplarily implemented in a three message key verification (HMQV-C) protocol 800. FIG. 6 is a diagram illustrating HMQV exemplarily implemented in a one-pass key exchange 900. FIG. 2 illustrates an exemplary hardware / information processing system 1000 for incorporating the present invention therein. FIG. 7 illustrates a signal transmission medium 1100 (eg, storage medium) for storing program steps of a method according to the present invention.

Claims (38)

In a method of exchange between two parties interconnected by a device or network,
The receiving party (verifier) selects a secret value x to calculate the value X = F1 (x), where F1 comprises a first predetermined function with at least one argument, said value x Is one of the at least one argument of F1,
The signing party (signer) selects a secret value y to calculate the value Y = F2 (y), where F2 includes a second predetermined function with at least one argument, said value y Is one of the at least one argument of F2,
The signer obtains the value X, the signer has a private key b and a public key B;
The signer calculates the value s = F3 (y, b, X), where F3 includes a third predetermined function having at least three arguments, the value y, the secret key b, and the value X is three of the at least three arguments of F3;
There is a fourth predetermined function F4 (x, Y, B) for calculating the value s', F4 has at least three arguments, the value x, the value Y, and the public key B are Three of the at least three arguments of F4, but the value s is not an argument of F4,
There is no secret that is shared between the verifier and the signer and that serves as the basis for any argument in any of F1, F2, F3, and F4,
A method wherein the verifier can consider the values s and s ′ as valid authenticators if the value s ′ is determined to be related to the value s in a predetermined manner.   The method of claim 1, wherein at least one of F1 and F2 comprises a one-way function.   The method of claim 1, wherein the values s and s ′ are determined to be valid authenticators when s = s ′.   The at least one of calculating s 'and determining whether the values s and s' are relevant are performed by a party other than the verifier and the signer. The method described in 1.   The method of claim 1, wherein the value s and the value s' are used to derive a secret shared between two parties. The verifier further comprises obtaining the value Y and using it to calculate the value s 'to determine whether s and s' are related in the predetermined manner. The method according to 1. The message m is to be authenticated and includes an argument of F3 and an argument of F4, so that the value s and the value s ′ can include information in the message m;
The method of claim 1, wherein the message is authenticated if the values s and s' are determined to be related in the predetermined manner.   The method of claim 7, wherein the value s and the value s' are used to derive a secret shared between two parties.   The method of claim 8, wherein the message m includes at least one identity of the party of the exchange. The method of claim 7, further comprising the signer sending the value s to the verifier.   The method of claim 7, wherein the message is authenticated if s = s ′. The public key B = g ^b , g is a generator of a finite group of order q, and the secret key b is an integer such that 0 < b < q−1,
The value X = g ^x , x is an integer such that 0 < x < q−1, the value Y = g ^y , and y is an integer such that 0 < y < q−1. Yes,
The signer calculates the value s = f ₁ (X) ^{f2 (m, Y, y, b)} , f ₁ contains a first mathematical function, f ₂ contains a second mathematical function, and arguments The method of claim 1, wherein m comprises a message.   The method of claim 12, wherein q is a prime number.   13. The method of claim 12, wherein the message m is considered authenticated if the value s is determined to be related to the value s' in a predetermined manner.   The method of claim 14, wherein the message m is considered authenticated if it is determined that the value s is equal to the value s ′. f ₁ is composed of the identity function, method according to claim 12. f ₂ is at least one of the arguments of f ₂ includes the hash function as the hash method of claim 12.   The method of claim 17, wherein one of the hashed arguments is a non-null message m.   13. The method of claim 12, wherein the message m includes an identity of a party in a computer or system or network. f ₂ (m, Y, y, b) = y + H (Y, m) b mod q, where H is a cryptographic function that is one of a one-way function, an encryption function, and a cryptographic hash function. The method of claim 17 comprising. The value s ′ = (YB ^{{H (Y, m)}} ) ^{f3 (x)} , where f ₃ (x) includes a mathematical function having at least one argument, and the value x is f ₃ (x 21. The method of claim 20, wherein the method is one argument of the at least one argument. The method of claim 21, wherein f ₃ (x) = x. The method of claim 21, further comprising authenticating the message m only if s = s'. The verifier, the private key a, 'have the value s' public key A = g ^a, and the message m is simultaneously contain a signature of the signer on m, the value s m' on the The method of claim 21, comprising the verifier's signature.   25. The method of claim 24, wherein the function f3 (x) = x + H (X, m ') a mod q.   The method of claim 1, wherein x is randomly selected by the verifier and y is randomly selected by the signer. The first value X = g ^x includes a value published by the verifier to be searchable by the prover, thereby enabling a non-interactive version of the authentication. The method described in 1.   The method of claim 21, wherein the values s and s' are further hashed.   A signal transmission medium that specifically implements a program of machine-readable instructions executable by a digital processing device to perform at least one of the steps of the method of claim 1. An apparatus comprising a computer for calculating the functions F2 and F3 according to claim 1 for the signer. In a method for establishing an authentication key between two parties interconnected by a device or a network,
When the first party has a secret key a and a public key A, the secret key a is an integer such that 0 < a < q−1, q is a positive integer, and g is of order q a finite group of origin, a is generated by said value g, a calculated original within the group as ^a = g ^a,
The second party has a secret key b and a public key B = g ^b , the secret key b being an integer such that 0 < b < q−1;
The first party selects a secret value ^x to calculate the value X = g ^x , where x is an integer such that 0 < x < q−1, and the value X is the second party Communicated to
The second party selects a secret value ^y to calculate the value Y = g ^y , y is an integer such that 0 < y < q−1, and the value Y is the first party Communicated to
The first party calculates the value s = f ₁ (Y, B, m) ^{{f2 (x, a, m ′)}} , where m and m ′ are known or exchanged between the parties The second party calculates the value s ′ = f ₃ (X, A, m ′) ^{{f4 (y, b, m)}}
At least one of the functions f ₂ and f ₄ includes a function H having at least one argument, such one argument being at least one of the messages m and m ′, where H is A cryptographic function that is one of a one-way function, a cryptographic function, and a cryptographic hash function,
The method wherein the first and second parties derive a shared key from the values s and s ′, respectively. (I) the calculation of the values x and X includes the private key of the first party and one or more of the public keys of the parties;
(Ii) The calculation of the values y and Y corresponds to at least one of including the secret key of the second party and one or more of the public keys of the parties. 31. The method according to 31.   32. The method of claim 31, wherein the derivation of a shared key from s and s' includes a cryptographic function that is one of a one-way function, a cryptographic function, and a cryptographic hash function.   32. The method of claim 31, wherein at least one of the messages m and m 'includes an ID of one of the first and second parties. 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) mod q,
32. The method of claim 31, wherein H is a function of at least two arguments, including a cryptographic function that is one of a one-way function, a cryptographic function, and a cryptographic hash function.   36. The method of claim 35, wherein at least one of the messages m and m 'includes an ID of at least one of the first and second parties. (I) the calculation of the values x and X includes the private key of the first party and one or more of the public keys of the parties;
(Ii) The calculation of the values y and Y corresponds to at least one of including the secret key of the second party and one or more of the public keys of the parties. 36. The method according to 36.   37. The method of claim 36, wherein the derivation of the shared key from s and s' includes a cryptographic function that is one of a one-way function, a cryptographic function, and a cryptographic hash function.

Images