JP2009526411A - 装置またはネットワークによって相互接続された2当事者間の交換の方法、信号伝送媒体、および装置(チャレンジ・レスポンス署名および高性能で安全なDiffie−Hellmanプロトコルに関する方法および構造) - Google Patents

装置またはネットワークによって相互接続された2当事者間の交換の方法、信号伝送媒体、および装置(チャレンジ・レスポンス署名および高性能で安全なDiffie−Hellmanプロトコルに関する方法および構造) Download PDF

Info

Publication number
JP2009526411A
JP2009526411A JP2007554563A JP2007554563A JP2009526411A JP 2009526411 A JP2009526411 A JP 2009526411A JP 2007554563 A JP2007554563 A JP 2007554563A JP 2007554563 A JP2007554563 A JP 2007554563A JP 2009526411 A JP2009526411 A JP 2009526411A
Authority
JP
Japan
Prior art keywords
value
key
hat
function
party
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
JP2007554563A
Other languages
English (en)
Other versions
JP2009526411A5 (ja
Inventor
クラフチック、ヒューゴ
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
International Business Machines Corp
Original Assignee
International Business Machines Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by International Business Machines Corp filed Critical International Business Machines Corp
Publication of JP2009526411A publication Critical patent/JP2009526411A/ja
Publication of JP2009526411A5 publication Critical patent/JP2009526411A5/ja
Withdrawn legal-status Critical Current

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0838Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these
    • H04L9/0841Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these involving Diffie-Hellman or related key agreement protocols
    • H04L9/0844Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these involving Diffie-Hellman or related key agreement protocols with user authentication or key authentication, e.g. ElGamal, MTI, MQV-Menezes-Qu-Vanstone protocol or Diffie-Hellman protocols using implicitly-certified keys
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/30Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/36Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G06Q20/367Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes
    • G06Q20/3678Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes e-cash details, e.g. blinded, divisible or detecting double spending
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/06Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for block-wise or stream coding, e.g. DES systems or RC4; Hash functions; Pseudorandom sequence generators
    • H04L9/0643Hash functions, e.g. MD5, SHA, HMAC or f9 MAC
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/083Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) involving central third party, e.g. key distribution center [KDC] or trusted third party [TTP]
    • H04L9/0833Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) involving central third party, e.g. key distribution center [KDC] or trusted third party [TTP] involving conference or group key
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/30Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy
    • H04L9/3066Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy involving algebraic varieties, e.g. elliptic or hyper-elliptic curves
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/321Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3218Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using proof of knowledge, e.g. Fiat-Shamir, GQ, Schnorr, ornon-interactive zero-knowledge proofs
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3271Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using challenge-response

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Theoretical Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Mathematical Optimization (AREA)
  • Strategic Management (AREA)
  • Power Engineering (AREA)
  • Algebra (AREA)
  • Mathematical Analysis (AREA)
  • General Business, Economics & Management (AREA)
  • Mathematical Physics (AREA)
  • Pure & Applied Mathematics (AREA)
  • Computing Systems (AREA)
  • Storage Device Security (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Medicines Containing Antibodies Or Antigens For Use As Internal Diagnostic Agents (AREA)

Abstract

【課題】 装置またはネットワークによって相互接続された2当事者間の交換の方法(および構造)を提供することにある。
【解決手段】 受信側当事者(検証者)は、値X=F1(x)を計算するために秘密の値xを選択し、ここでF1は少なくとも1つの引数を有する第1の所定の関数を含み、値xはF1の少なくとも1つの引数のうちの1つである。署名側当事者(署名者)は、値Y=F2(y)を計算するために秘密の値yを選択し、ここでF2は少なくとも1つの引数を有する第2の所定の関数を含み、値yはF2の少なくとも1つの引数のうちの1つである。署名者は値Xを入手し、署名者は秘密鍵bと公開鍵Bとを有する。署名者は値s=F3(y,b,X)を計算し、ここでF3は少なくとも3つの引数を有する第3の所定の関数を含み、値y、秘密鍵b、および値XはF3の少なくとも3つの引数のうちの3つの引数である。
【選択図】 図10

Description

本発明の諸態様は、一般に、情報交換の送信側および受信側当事者にとって立証可能に(provably)安全な署名に関する。より具体的には、チャレンジ・レスポンス署名方式(challenge-responsesignature scheme)は、検証者(verifier)と署名者(signer)の両方が同じ署名または関連署名を計算することができ、前者はチャレンジを把握することにより、後者は秘密署名鍵(privatesignature key)を把握することによりこれを行うことができ、これにより、模範的な諸実施形態では、周知のMQVプロトコルの変形を含む、従来の鍵交換プロトコルの立証可能に安全な変形を可能にするという特性を有する。
当初の提案通り、図1に図示されているDiffie−Hellman(DH)鍵交換プロトコル100は、盗聴専門の攻撃者(attacker)に対して安全であると考えられている。活発なマン・イン・ザ・ミドル(man-in-the-middle)攻撃に抵抗する「認証Diffie−Hellman」プロトコルの探求の結果、無数のアドホック提案が行われたが、その多くは破棄されているかまたは欠点に苦しんでいることが分かっている。鍵交換のための厳格なセキュリティ・モデルに関するこの数年間の発展により、当業者は、現在、これらのプロトコルのセキュリティを判断できるとともに、現実的に活発な攻撃に立証可能に耐える設計を開発できる、かなり良好な立場にある。
予想通り、活発な攻撃に対する安全機能を追加すると、その結果、追加の通信および計算のいずれの点でも複雑さが追加される。後者は、通常、追加の高価な群べき乗(group exponentiation)を必要とする公開鍵技法によって認証されたプロトコルで特に重要なものである。しっかりしたセキュリティの必要性に加えて、鍵交換に対する多くの実用的な適用例のために、設計者は、認証メカニズム、特に公開鍵に基づくものに関連するパフォーマンス・コストの改善を余儀なくされてきた。
1986年に松本、高島、および今井によって着手された研究分野は、そのプロトコルに最小限の複雑さを追加することになると思われる公開鍵(PK)認証DHプロトコルの探索である。理論的には、しかも保証された公開鍵の交換までは、プロトコルの通信は、正確に基本DH交換に見えることが望まれている。この技法では、プロトコルの認証は鍵導出手順を介して入手しなければならず、基本Diffie−Hellman鍵gxyについて合意することではなく、当事者は、その当事者の公開鍵/秘密鍵とgx、gyを結合する鍵について合意することになるであろう。
一部にはこのようなプロトコルが提供すると思われる実用的な利点ために、また、一部にはこのような設計の背後にある数学的難題のために、「暗黙認証Diffie−Hellmanプロトコル」と呼ばれる場合が多い多数のプロトコルが、この手法に基づいて開発されてきた。この手法は通信面で非常に効率的なプロトコルを生成できるだけでなく、認証と鍵導出手順の組み合わせにより、潜在的に大幅な計算上の節約を行うこともできる。これらの理由で、これらの「暗黙認証」プロトコルのうちのいくつかは、主要な国内および国際的セキュリティ規格によって標準化されている。
これらのプロトコルのうち、MQVプロトコルは広範囲にわたって標準化されているように思われる。このプロトコルは、多くの組織によって標準化され、最近、「機密扱いのまたは主幹業務の国家的セキュリティ情報」の保護を含む、「米国政府情報を保護するための次世代暗号方式」の基礎となる鍵交換メカニズムであると米国国家安全保障局(NSA:National Security Agency)によって発表されている。
さらに、MQVは、多数のセキュリティ上の目標を満足するように設計されているように思われる。MQVプロトコルの基本バージョンは、たとえば、Vanstone他に交付された米国特許第5761305号に説明されている。
しかし、その魅力および成功にもかかわらず、MQVはこれまで明確に定義された鍵交換のモデルにおける形式的分析を避けてきた。本発明は、このような分析を行いたいという希望が動機になっている。研究を行った際に、本発明者は、CanettiおよびKrawczykの計算鍵交換モデルで実行されるように、しかも上記の仮出願に記載されているように、明記されたMQVの目標のほぼすべてが有効ではないことが証明できると気付いていた。
この結果、この従来のプロトコルのセキュリティに関する懸念が本発明者に提起された。したがって、従来のMQVプロトコルは立証可能に安全ではなかったというこの分析に基づいて、好ましくはその既存のパフォーマンスおよび多様性を保持しながら、MQVに対する追加のセキュリティが必要になっている。
米国特許第5761305号
従来のシステムの上記およびその他の模範的な問題、欠点、および不利点を考慮すると、本発明の1つの模範的な特徴は、MQVプロトコルのセキュリティ上の目標を立証可能な方法で達成し、本明細書でHMQVと呼ばれるMQVの新しい変形に関する方法および構造を提供することにある。
本発明の他の模範的な特徴は、本明細書で「チャレンジ・レスポンス署名」と呼ばれる新しいデジタル署名方式を実証することにある。
本発明の他の模範的な特徴は、チャレンジャ(challenger)と署名者の両方が同じ署名または関連署名を計算することができ、前者はチャレンジを選択したことにより、後者は秘密署名鍵を把握することによりこれを行うことができるという特性を有するプロトコル・メカニズムを提供するものとして、Schnorr識別方式から導出され、本明細書で「指数チャレンジ・レスポンス」(XCR:exponentialchallenge response)署名方式と呼ばれるバージョンを含むものとしてこのチャレンジ・レスポンス署名方式を実証することにある。
したがって、本発明の模範的な一目的は、そこにXCR署名方式の概念を実現することによりセキュリティを立証可能に実証することができる、認証Diffie−Hellmanプロトコルに関するセキュリティを改善するための構造および方法を提供することにある。
本発明の第1の模範的な態様では、上記の特徴および目的を達成するために、値X=F1(x)を計算するために秘密の値xを選択する受信側当事者(検証者)を含み、ここでF1は少なくとも1つの引数を有する第1の所定の関数を含み、値xはF1の少なくとも1つの引数のうちの1つである、装置またはネットワークによって相互接続された2当事者間の交換の方法が本明細書に記載されている。署名側当事者(署名者)は、値Y=F2(y)を計算するために秘密の値yを選択し、ここでF2は少なくとも1つの引数を有する第2の所定の関数を含み、値yはF2の少なくとも1つの引数のうちの1つである。署名者は値Xを入手し、署名者は秘密鍵bと公開鍵Bとを有する。署名者は値s=F3(y,b,X)を計算し、ここでF3は少なくとも3つの引数を有する第3の所定の関数を含み、値y、秘密鍵b、および値XはF3の少なくとも3つの引数のうちの3つの引数である。値s′を計算するために第4の所定の関数F4(x,Y,B)が存在し、F4は少なくとも3つの引数を有し、値x、値Y、および公開鍵BはF4の少なくとも3つの引数のうちの3つの引数であるが、値sはF4の引数ではない。検証者と署名者との間で共有され、関数F1、F2、F3、およびF4のいずれかにおいて任意の引数の基礎として働くような秘密はまったく存在しない。値s′が所定の方法で値sに関連するものと判断された場合に検証者は値sおよびs′を有効な認証子(authenticator)と見なすことができる。
本発明の第2および第3の模範的な態様では、前の段落に記載された方法を実行する装置と、その方法を実行するためにデジタル処理装置によって実行可能な複数の機械可読命令からなるプログラムを具体的に実施する信号伝送媒体も本明細書に記載されている。
本発明の第4の模範的な態様では、装置またはネットワークによって相互接続された2当事者間で認証鍵(authenticated key)を確立するための方法も本明細書に記載されている。第1の当事者は秘密鍵aと公開鍵Aとを有し、秘密鍵aは0q−1になるような整数であり、qは正整数であり、gは次数qの有限群(finitegroup)の生成元(generator)であり、Aは値gによって生成され、A=gaとして計算された群内の元(element)である。第2の当事者は秘密鍵bと公開鍵B=gbとを有し、秘密鍵bは0q−1になるような整数である。第1の当事者は値X=gxを計算するために秘密の値xを選択し、xは0q−1になるような整数であり、値Xは第2の当事者に伝達される。第2の当事者は値Y=gyを計算するために秘密の値yを選択し、yは0q−1になるような整数であり、値Yは第1の当事者に伝達される。第1の当事者は値s=f1(Y,B,m){f2(x,a,m’)}を計算し、ここでm、m′は両当事者間で既知であるかまたは交換されたメッセージを含み、第2の当事者は値s′=f3(X,A,m′){f4(y,b,m)}を計算する。関数f2およびf4のうちの少なくとも1つは少なくとも1つの引数を有する関数Hを含み、このような1つの引数はメッセージmおよびm′のうちの少なくとも1つであり、ここでHは一方向関数(one-way function)、暗号化関数(encryption function)、および暗号ハッシュ関数(cryptographichash function)のうちの1つである暗号関数(cryptographic function)を含む。第1および第2の当事者はそれぞれ値sおよびs′から共有鍵(sharedkey)を導出する。
上記およびその他の目的、態様、および利点は、図面に関連して本発明の好ましい一実施形態に関する以下の詳細な説明からより良好に理解されるであろう。
次に、図面、詳細には図1〜図11を参照すると、本発明による方法および構造の模範的な諸実施形態が示されている。
群および表記法に関する予備的注記として、本明細書で論ずるすべてのプロトコルおよび演算は、典型的には生成元gによって生成された素数(prime number)である次数qの巡回群(cyclic group)Gを想定している。qのビット長は|q|(たとえば、
Figure 2009526411
であり、最近隣数(nearestinteger)まで丸められた2を底とするqの対数を意味する)によって表され、この数量は暗黙セキュリティ・パラメータとして使用される。パラメータG、g、およびqは、単純にするため、実際に一般的であるように、一定であり、あらかじめ両当事者にとって既知のものであると想定される。代わって、これらの値を証明書などに含めることもできるであろう。
本明細書では群演算の乗算表現が使用されるが、その処理は、楕円曲線などの加法群(additive group)、あるいは任意のその他の代数群(algebraic group)または特定の群、有限体(finitefield)、複合法(composite moduli)などに等しく適用可能である。プロトコルでは、大文字(たとえば、A、B)によって表される公開鍵は群G内の元であり、対応する小文字(たとえば、a、b)によって表される秘密鍵はZq内の元であり、ここでZqは整数0、1、・・・、q−1の集合を表している。
たとえば、公開鍵A=gaは秘密鍵aに対応する。その公開鍵としてAを有する当事者は、
Figure 2009526411
は以降Aハットと記載する。
によって表され、伝統的には「アリス(Alice)」と見なされることになる(第2の当事者
Figure 2009526411
は以降Bハットと記載する。
は伝統的には「ボブ(Bob)」と見なされる)。一般に、「ハット表記法(hatnotation)」は、名前、電子メール・アドレス、役割など、プロトコル内の当事者の論理IDまたは「識別(distinguishing)」IDを表すために使用される。場合によっては、これらのIDはデジタル証明書で増強することができる。本明細書では繰り返さないが、仮出願で提供されるより完全な数理解析のために、攻撃者を含むプロトコル内のすべての当事者は、確率的多項式タイム・マシンを介して実現されるものと見なされる。また、攻撃者はMによっても表され、ここでMは「悪意のある(malicious)」ことを意味する可能性がある。
したがって、図1に図示されている通り、基本非認証Diffie−Hellmanプロトコル100に関するセッション鍵の計算は、2当事者AハットとBハットとの間の交換から構成され、当事者Aハットはまず自分の鍵X=gxを当事者Bハットに送信し、次に当事者Bハットは、自分の鍵Y=gyを当事者Aハットに返送することによって応答し、ここでxおよびyはそれぞれ、集合ZqからランダムにAハットおよびBハットによって選択された秘密であり、共有セッション鍵はgxyとして計算される。
本明細書の説明では、ランダム選択を表すために記号∈Rが使用される場合があることは留意すべきである。たとえば、x∈Rqは、典型的には乱数発生器または疑似乱数発生器を使用することにより、整数Zqの集合からランダムに値xを選択することを意味する。
MQVプロトコル
Aハット、BハットというIDが公開鍵証明書などの追加の情報を含む可能性があるかまたはこれらのIDがすべてまとめて省略される可能性があることを除いて、MQVプロトコルでの通信は、図1に描写されている基本非認証DHプロトコル100と同一である。
2メッセージ認証鍵交換プロトコルを設計する際の第1の難題は、第1のプロトコル・メッセージの再生に基づく攻撃の成功を防止することである。第1のメッセージは、応答側(responder)によって与えられた任意の形式のセッション固有「鮮度保証(freshness guarantee)」(たとえば、nonceまたは新鮮なDH値など)を含むことができないので、これは問題のあるものである。この問題の解決策の1つは、セッション鍵の計算を介して鮮度を提供することである。
たとえば、図2に図示されている2メッセージDiffie−Hellmanプロトコル200は、ISO(国際標準化機構:International Standards Organization)9793プロトコルから採用されたデジタル署名を使用して認証される。Bハットの署名の下にgxを含めることによって認証に鮮度が提供されるが、この安全機能はAハットのメッセージには存在しない。しかし、セッション鍵gxyは、新鮮なyによってランダム化されるので、新鮮であること(ならびに他のセッション鍵から独立していること)が保証される。しかし、攻撃者がBハットとのセッションにおいてAハットによって使用される単一のペア(x,gx)を見つけることができる場合、プロトコルのセキュリティが途切れ、その場合、攻撃者は
Figure 2009526411
も学習する。これにより、攻撃者は、Aハットの長期秘密署名鍵を学習する必要なしに、同じメッセージとxに関する知識を使用して、漠然とBハットに対してAハットを詐称することができる。
これは、一時(ephemeral)セッション固有情報(たとえば、ペア(x,gx))の開示によって他のセッションを破壊してはならないという基本原理に違反する重大な脆弱性である。多くの適用例がこのペア(x,gx)をオフラインで計算し、たとえば、長期秘密鍵ほど保護されていない記憶域にそれを保持することになることを考慮すると、これは特に重大である。
したがって、一時情報が漏れた場合でもリプレイ・アタック(replay attack)に影響されない2メッセージ・プロトコルをどのように設計できるかが問題である。セッション鍵の計算に長期秘密鍵を含めることは当然の答えである。これは、MQVを含む、Diffie−Hellmanのいわゆる「暗黙認証」変種の多くの動機になっている、松本、高島、および今井による1986年の研究で着手された手法であった。この手法では、各当事者は長期DH公開鍵とそれに対応する秘密の指数(exponent)とを有し、セッション固有の一時DH値と両当事者の公開鍵および秘密鍵とを組み合わせることによってセッションが生成される。したがって、このようなプロトコルのセキュリティは全体として、この鍵の組み合わせの正確な詳細に依存する。意外なことに、この表面上単純な考え方は確実に実現するには困難なものであり、これまでの提案はいずれもいくつかの短所を抱えている。
次に、セッション鍵計算において一時鍵と長期鍵を組み合わせることの問題に対する以下のような当然の解決策を考慮すると、AハットおよびBハットが鍵を交換したいと希望する場合、両者は基本Diffie−Hellmanプロトコルを実行し、K=g(x+a)(y+b)=(YB)x+a=(XA)y+bとしてセッション鍵を計算する。この場合、攻撃者がaではなくxを学習すると、攻撃者はKを計算することができない。
しかし、以下の単純な攻撃によって実証される通り、プロトコルは依然として安全ではなく、すなわち、Mは値x*Rqを選択し、X*=gX*/Aを計算し、Aハットからの初期メッセージの詐称としてBハットにX*を送信する。BハットはY=gyを送信し、セッション鍵K=(X*A)y+bを計算する。残念なことに、MはKを(BY)x*として計算することもできる。したがって、このプロトコルは安全ではない。
そのうえ、Kの計算が定数d、eに関するK=g(x+da)(y+eb)になるように変更された場合でも、攻撃は依然として可能である。これに対して、攻撃者がeおよびYを個別に制御できないように定数d、eがX、Yにつれて変化することができる場合、上記の単純な攻撃は機能しない可能性がある。この考え方は我々をMQVの設計に戻すものであり、ここでd=
Figure 2009526411
は以降Xバーと記載する。
およびe=
Figure 2009526411
は以降Yバーと記載する。
である。
MQVにおけるセッション鍵Kの計算301、302は図3に図示されており、ここで当事者Aハットは長期秘密鍵a∈Zqと対応する公開鍵A=gaとを所有している。同様に、Bの秘密鍵/公開鍵のペアは(b,B=gb)であり、一時DH値はX=gx、Y=gyであり、ここでx、yはそれぞれA、Bによって選択されたものである。セッション鍵の計算では、d=Xバーおよびe=Yバーという値も使用し、ここで、l=|q|/2の場合に、Xバー=2l+(X mod 2l)およびYバー=2l+(Y mod 2l)である。
Aハットによるセッション鍵の計算は、X=gxを計算するためのオフラインべき乗(off-lineexponentiation)と、Beを計算するためのオンラインべき乗(on-line exponentiation)と、(YBex+daに関する追加のオンラインべき乗とを必要とすることは留意すべきである。しかし、第2のべき乗は長さ|q|/2の指数eを使用し、したがって、それが「半べき乗(halfexponentiation)」(たとえば、gという正規べき乗(regular exponentiation)に対してモジュラ乗算の回数が半分である)と見なされることも留意すべきである。Bハットについても同じ演算カウントが有効である。
全体として、MQVのパフォーマンスは本当に印象的であり、基本非認証DHプロトコルと同じ通信(両当事者のIDの一部として証明書を伝送する可能性を除く)であり、基本プロトコルより半べき乗だけ多く、認証交換を達成するための計算において25%の増加に過ぎない。これは、認証のためにデジタル署名または公開鍵暗号化に依存する証明されたDHプロトコルのいずれよりも大幅に良好なものであり、より高価な演算と帯域幅の増加を伴うものである。また、これは、暗黙認証DHプロトコルのうちの最も効率的なものであり、最も近いものは、3つの完全べき乗(full exponentiation)を必要とするが、実質的により少ないセキュリティ上の特徴を提供する「統一モデル(UnifiedModel)」プロトコルである。
この例外的パフォーマンスおよびセキュリティの約束により、認証DHプロトコルを選択するときにMQVが魅力的な候補になる。これらの理由で、このプロトコルは、多くの規格に採用され、広く文献で論じられてきた。しかし、鍵交換セキュリティの形式モデルのいずれでもMQVプロトコルのいかなる形式的分析も正常に実行されなかったので、これまで回答されていない質問の1つは、MQVプロトコルが実際にどの程度安全であるのかということである。
これに対して、MQV設計者は、設計の背後にあるセキュリティ上の目標について明確であった。これらは、詐称および既知の鍵の攻撃(「未知の鍵の共有(UKS:unknown key share)」攻撃に対する抵抗を含む)に対する本質的なセキュリティならびに完全転送秘密(PFS:perfectforward secrecy)およびKCI(鍵漏洩詐称:key-compromise impersonation)攻撃に対する抵抗などのより具体的な特徴を含む。既知の鍵の攻撃に対する抵抗は、一時セッション固有秘密情報の開示によって他のセッションのセキュリティを破壊してはならないという原理を表している。
PFSおよびKCI特性は、ある当事者の秘密鍵が攻撃者Mに漏れた場合にセキュリティ上の損害を閉じこめることを指す。より具体的には、PFSは、破壊されていない2当事者間で確立された任意のセッション鍵が両当事者のメモリから消去された後で両当事者が破壊された場合でも、そのセッション鍵をMが学習できないことを意味する。KCI攻撃に対する抵抗は、ある当事者Aハットの長期秘密鍵を学習し、このため、明らかに他の当事者に対してAハットを詐称できる攻撃者が、Aハットに対して他の破壊されていない当事者を詐称できないことを必要とする。
残念なことに、上記の仮出願にさらに記載されているように、本発明者の分析の結果は、形式的に研究すると、これらの特性のいずれもMQVプロトコルによって満足されないことを示している。具体的には、CanettiおよびKrawczykのセキュリティ・モデルでは、このプロトコルは、MQVによって満足されると言われている上述のセキュリティ特性と矛盾する、ある範囲の攻撃に対して無防備であることが実証されている。
HMQVプロトコル
HMQVプロトコル(「H」は「ハッシュ」を意味するものと見なすことができる)は、いくつかの模範的な実施形態では、比較のためにステップ302に示されている従来のMQVプロトコルへの追加であり、図3のステップ303に示されているようなハッシュを含むことができる、MQVの単純だが強力な変種である。しかし、ハッシュを行わず、ハッシュ以外の技法を使用しない代替諸実施形態が本明細書で論じられ、本発明の概念にも含まれるので、最初の問題として、これらの模範的な実施形態の1つまたは複数のハッシュ・ステップが本発明にとって前提条件ではないことも留意すべきである。本発明のより基本的な概念は、MQVプロトコルの模範的なハッシュ・バージョンを含む、いくつかの適用例および実施形態がそこから進化したチャレンジ・レスポンス署名方式に関するものである。
当技術分野で周知の通り、ハッシュは、出力として文字ストリングを数値、固定長ストリング(たとえば、ハッシュまたはメッセージ・ダイジェスト)などに変換するためにハッシュ関数を使用することを必要とする。暗号方式におけるハッシュ関数の基本機能は、元のデータを検索することが実行不可能であり、所与のハッシュ値に一致するデータ・ブロックを構築することも実行不可能でなければならないことを意味する、「一方向(one-way)」または「非可逆(irreversible)」変換を提供することである。ハッシュ関数は、単純な「混合(mixing)」関数から、純粋にランダムなスクランブルに似ている変換まで及ぶ可能性がある。後者は、「強い暗号ハッシュ関数」と呼ばれ、理想的な確率関数(randomfunction)(または「ランダム・オラクル(random oracle)」によって暗号分析でモデル化される場合が多い。
いくつかのハッシュ関数は、強い暗号ハッシュに広く使用される。たとえば、MD5は、任意のサイズのデータ・ブロックを入力として取り、ビット単位演算、加算、および64バイト・ブロック単位でデータを処理するための正弦関数(sine function)に基づく値の表を使用することによって、128ビット(16バイト)のハッシュを生成する。もう1つの主要なハッシュ関数は、160ビット・ハッシュを提供するNIST(国立標準技術研究所:NationalInstitute of Standards and Technology)のセキュア・ハッシュ・アルゴリズム(SHA:Secure Hash Algorithm)である。
典型的には、ハッシュ関数は暗号化に直接使用されないが、暗号化関数は一方向変換を提供し、このため、本発明のいくつかの模範的な実施形態を含む、いくつかのハッシュ用途に適用可能である。また、ハッシュ関数は、データ認証にも適切なものであり、秘密鍵(これらの設定では、メッセージ認証コード(Message Authentication Codeの場合にMAC)と呼ばれ、疑似確率関数(Pseudo-RandomFunction)の場合にPRFと呼ばれる場合が多い)または署名方式(この場合、ハッシュ値は「メッセージ・ダイジェスト」に使用される)とともに、このような目的に使用される。
本発明の様々な模範的な実施形態では、上記の仮出願により詳細に記載されているセキュリティ分析において理想的なランダム・オラクルとして要約される少なくとも1つのハッシュ関数Hを使用する。これらの模範的な実施形態で関数Hが使用される2つのタスクは、第1に指数d、eの計算であり、第2にセッション鍵そのものの導出である。
第1のタスクは例示的に、Hへの2つの引数を使用し、長さが|q|/2のストリングを出力し、第2のタスクは、単一の引数にHを適用し、指定の長さ(たとえば、128ビット)の鍵を出力する。表記法を単純にするために、同じ記号Hを使用して、ハッシュ関数の両方の適用例を表す。実際には、可変長入力を処理することができ、おそらく、ハッシュ結果を生成する際に短縮/拡張(truncation/expansion)の何らかの組み合わせを使用して、上記の2つのタスクに適合するようにその出力サイズを調整できる、単一のH、たとえば、SHA−1を使用することになるであろう。
しかし、第1のタスクのようにハッシュを使用する場合、メッセージまたは当事者のIDのみをハッシュするのではなく、タイムスタンプ、nonceなどの追加の引数をハッシュ関数への入力として含めることができるので、必ずしも2つの引数に制限されないことも留意すべきである。
ハッシュを使用する場合、指数d、eを生成するために使用されるハッシュ関数(典型的にはl=|q|/2ビットの出力を有する)は、
Figure 2009526411
は以降Hバーと記載する。
で表される場合が多く、kビットの出力を有し、σ値に適用されるハッシュ関数はHで表される。実際には、異なる出力長を有する同じハッシュ関数を使用することができ、このため、Hバーの代わりに記号Hが使用されることもある。ニーモニックとして、Hバー内のバーは、この関数の出力が指数として使用されることを示している。
MQVのように、HMQVプロトコルの通信は、以前、図1に図示されている基本DH交換と同一であるが、証明書が追加される可能性がある。図3に例証されている通り、セッション鍵Kの計算は、値dおよびeの計算におけるMQVのものとは異なり、当事者自身のDH値とピア(peer)のIDのハッシュを必要とする。このハッシュの典型的な出力はl=|q|/2ビットである。加えて、模範的な一実施形態では、HMQVは、
Figure 2009526411
という値からkビットの鍵へのハッシュを指定し、ここでkは所望のセッション鍵の長さである。代替実施形態では、1つまたは両方のσ関数はハッシュされない。
この説明から、HMQVは、通信および計算の両方の点でMQVの優れたパフォーマンスを保持していることが分かる。同時に、HMQVは、上記の仮特許出願で論じられているMQVのすべてのセキュリティ上の短所を、そこでさらに論じられ証明される2メッセージ・プロトコルで最大限可能な範囲で、克服するものである。HMQVおよびその変種のセキュリティ上の特性および利点に関するより完全な説明については、本出願で後で提示する。
チャレンジ・レスポンス署名
HMQVプロトコルがMQVプロトコルとはどのように異なるかは明らかでなければならないが、ある意味でより基本的な本発明のもう1つの態様が存在する。すなわち、HMQVの背後にある中心的設計および分析要素として存在する主なテクニカル・ツールは、「チャレンジ・レスポンス署名」と呼ばれ、Fiat−Shamir方法を使用するSchnorrの識別方式の新しい変種を基礎として実現される、新しい形の対話式署名である。その結果として、本発明の「指数チャレンジ・レスポンス」(XCR)署名が得られる。SchnorrおよびFiat−Shamir方法とXCR署名との関係については以下に論じる。
これらのXCR署名は、ランダム・オラクル・モデル(計算Diffie−Hellman(Computational Diffie-Hellman)またはCDH仮説に基づくもの−以下を参照)において安全なものであり、検証者と署名者の両方が例示的に同じ署名を計算できるという特性を有する。前者はチャレンジを把握することによってこれを達成し、後者は秘密署名鍵を把握することによってこれを行うことができる。同一の署名の計算に関する変形は、署名者および検証者によって異なるが関連のある署名を計算することを含む。
たとえば、一方によって計算された署名値は、もう一方によって計算された署名のハッシュ変種である可能性があるか、あるいは両方の署名は何らかの特定の代数特性などによって関連している可能性がある。本発明の様々なHMQVプロトコルは、これらのXCR署名を使用する模範的なメカニズムの1つであり、これらは(DH値およびピアIDの)認証ならびにセッション鍵の計算を提供する。
したがって、XCR署名ならびにその「二重バージョン(dual version)」(たとえば、DCR)は、簡潔に論じると、HMQV設計および分析の基礎となる考え方について、技術ならびに概念の両面で当然の解釈を提供するものである。
加えて、HMQVプロトコルを超える適用例ではXCR署名も使用できることは留意すべきである。それぞれの基本的形式では、XCR署名は、対話式で、チャレンジ固有であり、移転不能であるので、デジタル署名の古典的機能を提供しない。すなわち、これらは、否認防止(non-repudiation)のために使用することができない。
これに対して、これらは、鍵交換を含む、何らかの適用例の場合に重要な特性である「否認可能認証(deniable authentication)」を提供し、それにより、XCR署名の受信側に対して、メッセージまたは鍵の発信元および保全性を保証することができるが、第三者に対してこの発信元を証明することはできない。とりわけ、これらの署名および結果として生じる鍵交換プロトコルは理想的には「非公式の(off-therecord)」の通信およびプライバシ保護に適している。加えて、XCRの非対話式バージョンは、後述の通りに存在し、何らかの場合に周知のデジタル署名アルゴリズム(DSA:DigitalSignature Algorithm)などの確立された署名方式に代わるものを提供する。
正規のデジタル署名方式のように、チャレンジ・レスポンス署名方式では、署名者は、署名の生成および検証にそれぞれ使用する秘密鍵と公開鍵のペアを有し、検証者は署名者の真正公開鍵を入手するものと想定されている。とりわけ、両当事者は署名プロトコルの開始前に秘密を共有しているものとは想定されておらず、署名の計算にこのような共有秘密は必要ではない。しかし、正規の署名とは対照的に、その基本的な形式では、チャレンジ・レスポンス署名は対話式であり、署名者が所与のメッセージ上に署名を生成する前に署名の受信側(たとえば、検証者)が署名者に対してチャレンジを発行する必要がある。安全なチャレンジ・レスポンス署名方式は、正当な署名者以外の人は誰も、その署名を有効なものとして受け入れるようチャレンジャを納得させるような署名を生成できないことを保証する必要がある。とりわけ、署名は、メッセージ固有であるだけでなく、チャレンジ固有のものでもある。
これに対して、チャレンジャによる署名の検証可能性を保証することは関心のあることであり、したがって、署名の転送可能性または第三者による検証可能性に関する想定または要件はまったく存在しない。その上、後述の特定の方式は、チャレンジを選択する当事者が、その特定のチャレンジに関して有効な署名をどのメッセージ上でも必ず生成できるという特性を有する。本出願に関してより重要であり、この方式を他の対話式署名から区別するものは、検証者がチャレンジを使用して、署名者と同じ(または関連する)署名ストリングを計算できることである。
上記の通り、gは(通常は素数)次数qの群Gの生成元である。また、Hは|q|/2ビット
Figure 2009526411
を出力するハッシュ関数であるが、この場合も、「素数次数(prime order)」の使用およびHの出力の特定の長さは、模範的な諸実施形態の模範的な設計の詳細に過ぎず、本発明に不可欠なものではない。
XCR署名方式の定義
図4に例示されている指数チャレンジ・レスポンス(XCR)署名方式500は以下のように定義される。すなわち、Bハットで表されるXCR方式内の署名者は、秘密鍵b∈Rqと公開鍵B=gbとを所有する。Aハットで表される検証者(またはチャレンジャ)は、x∈Rqの場合にAハットがX=gxとして計算する最初のチャレンジXを提供し、ここでxはAハットによって選択され、秘密に保持される。チャレンジXを使用する所与のメッセージm上のBハットの署名は、
Figure 2009526411
というペアとして定義され、ここでY=gyであり、y∈RqはBハットによって選択され、指数y+Hバー(Y,m)bはqを法として換算される。検証者Aハットは、それが
Figure 2009526411
であると判断した場合のみ、(メッセージmおよびチャレンジX=gxについて)有効なものとして署名ペア(Y,σ)を受け入れる。
ここで以下の表記法を使用する。すなわち、所与のメッセージm、チャレンジX、および値Yの場合に、
Figure 2009526411
と定義する。すなわち、
Figure 2009526411
は、XCR署名ペア内の第2の元を表している。一般的な注記として、「メッセージ」という単語の上記の使用が、送信データ、ファイル、媒体などを含むビット・ストリームによって表すことができ、それ自体がより長いメッセージのハッシュ・バージョンになりうる任意の形式のデータまたは情報を表すことは注目する価値がある。このメッセージは、図5に図示されているように両当事者に対して入力できるか、ある当事者から他の当事者に伝送できるか、あるいは第三者、外部ソースなどから提供することができる。
本出願に記載されている通り、XCR署名の利点としては、分析の健全性(立証可能性)、検証者と証明者の両方による計算可能性、二重性(単一の計算は2当事者以上による署名の結合を表す)、「ハッシュ可能性(hashability)」(すなわち、ハッシュ署名を処理し検証する能力)、鍵または共通値の導出、転送不能性および否認可能性、(否認可能な署名から伝統的な否認不能な署名への)変換可能性、(特に対話環境で)DSSより堅固な代替策を提供すること、ならびに非対話式変種の存在を含む。
そこからXCR署名が導出されるSchnorrの識別方式に対する関連を介してXCR方式の設計の動機になることは、例証となる可能性がある。Schnorrの(対話式)識別方式は、所与の入力B=gbに関する離散対数bを把握していることの証明から構成される。Bハットがこの方式の証明者(bを所有するもの)を表し、Aハットが検証者(入力Bが与えられるもの)を表すものとする。基本的なSchnorrの識別は以下の3つのメッセージから構成される。
(i)Bハットはy∈Rqを選択し、Y=gyをAハットに送信する。
(ii)Aハットはランダム値e∈Rqで応答する。
(iii)Bハットは値s=y+ebをAハットに送信する。Aハットは、gs=YBeが有効である場合のみ、受け入れる。
このプロトコルは、正直な検証者Aハット(たとえば、ランダムに一律にeを選択する人)に対する(bの)知識のパブリックコイン型ゼロ知識証明(public-coin zero-knowledge proof)である。したがって、これは、周知のFiat−Shamir方法を介してランダム・オラクル・モデルで立証可能に安全な署名方式、すなわち、
Figure 2009526411
に変換することができる。
次に、AハットからBハットへの第1のメッセージが追加される、以下のSchnorrプロトコルの4メッセージ変種について検討する。この第1のメッセージで、Aハットは値X=gxをBハットに送信する。次に、Schnorrの方式からの3つのメッセージが続くが、メッセージ(iii)、すなわち、変更済みプロトコルの第4のメッセージでは、s=y+ebをAハットに送信するのではなく、BハットがS=Xsを送信する。Aハットは、S=(YBexである場合のみ、受け入れる。このプロトコルは任意の値X∈GについてDiffie−Hellman値CDH(B,X)を計算するBハットの「能力」の証明であることが分かる。その上、このプロトコルはランダムにeを選択する検証者Aハットに対するゼロ知識であり、Xは任意に選択することができる。
Fiat−Shamir変換をこのプロトコルに適用することにより、本発明のチャレンジ・レスポンス署名XCRが得られる。また、これは、XCR方式を命名する際に「指数」という用語が使用される理由も説明しており、Schnorr方式のs=y+ebをこのプロトコルの最後のメッセージのXsで置き換えることを指している。
CDH仮説に基づくXCR署名方式のセキュリティの追加の態様については上記の仮出願でさらに論じられている。
上記の用語のいくつかを説明する際に、G内の2つの元であるU=gu、V=gvの場合、Diffie−Hellman計算をUおよびVに適用した結果をCDH(U,V)によって表す(たとえば、CDH(U,V)=guv)。このアルゴリズムは、入力としてG内の元(U,V)のペアを取り、Diffie−Hellman結果CDH(U,V)を出力する場合、「Gに関するCDH求解ルーチン(solver)」と呼ばれる。仮出願でさらに提供される分析で使用される主な至難性仮説(intractability assumption)は計算Diffie−Hellman(CDH)仮説である。Gに関するすべての効率的なCDH求解ルーチンの場合、U,V∈RGに関するペア(U,V)について求解ルーチンが正しい値CDH(U,V)を計算する確率が無視できるものである場合(この確率は求解ルーチンのランダム・コインについて取られ、U,Vの選択はG内でランダムに独立して行われる)、CDH仮説は群Gで有効であると言える。
Hバー(Y,m)内のビット数
lはHバー(Y,m)内のビット数とする。明らかなことに、lが小さくなるほど署名方式の効率が高くなることを示す。これに対して、指数Hバー(Y,m)が予測可能であると、署名方式が不安定になるので、lが小さすぎる場合、セキュリティ・バウンド(security bound)が不良であることを示す。しかし、セキュリティのためにどの程度の大きさのlが必要であるかが問題である。
l=1/2|q|という設定によって良好なセキュリティ・パフォーマンスのトレードオフが得られ、このため、XCR署名の模範的な指定で(しかも本発明のHMQVプロトコルへのその模範的な適用のために)この値が使用されることが分かる(上記の仮出願の考察を参照されたい)。
Bとの対話の順序の変更
とりわけ、HMQVプロトコルの分析に適用されるXCR署名のいくつかの適用例では、チャレンジャAハットと署名者Bハットとの対話の順序を変更することができる。
XCR方式の上記の定義では、Aハットは、BハットにチャレンジXを提供すると同時にBハットにメッセージmを提示し、その結果、Bハットは署名ペア
Figure 2009526411
で直ちに応答することができる。現在検討している変更済みバージョンでは、以下の順序の対話が行われる。
(i)AハットはBハットにメッセージmを提示し、BハットはYを出力し、その後の何らかの時点で
(ii)AハットはBハットに(Y,m,X)を提供し、Bハットは
Figure 2009526411
を出力する。
次に、当事者Fがこの変更済み順序を取るようBハットに照会するものと想定する。とりわけ、FはBハットとの種々の対話をインターリーブすることができ、すなわち、Fは、対応するステップ(ii)を実行する前にステップ(i)のいくつかのインスタンスを実行することができる。これは、BハットがY、y、およびmという値でステップ(i)後の状態を保持することを必要とする。その後、Fがステップ(ii)で(Y,m,X)を提示すると、Bハットは、それがその状態内にペア(Y,m)を有することをチェックし、有する場合に
Figure 2009526411
で応答し、その状態から(Y,m)を消去する(Bハットがその状態内にペア(Y,m)を持っていない場合、それはその署名を発行しない)。
Bハットのアクションのこの指定によって、Bハットが2つの異なる署名に同じY値を使用しないことを保証することに留意されたい。BハットによるYの選択のシミュレーションがXの知識を必要としないが、Hバー(Y,m))を決定するためにmの値のみが必要であるという理由だけで、XCR署名のセキュリティの証明がこの変更済み順序について引き続き有効であることは、容易に検証することができる。
ハッシュXCR変種(HCR)
XCR署名(Y,σ)のペアをペア(Y,H(σ))で置き換えることが可能であり、ここでHはハッシュ関数であり、このような「ハッシュXCR」署名は「HCR」と略記される。XCR特性によって検証者がYのついてσを再計算できるので、Yが与えられると、H(σ)も計算することができ、このため、変更済みHCR署名を検証できることに留意されたい。
HCR署名は、いくつかの設定で重要な、所定の範囲の特性を有する。たとえば、その署名は正規のXCR署名より短い場合もあれば、結果的にランダム値または疑似ランダム値になる場合もあり、攻撃者がσ内の代数構造を学習するのを防止する場合などもある。
とりわけ、対話式および検証者固有の認証環境(鍵交換プロトコルなど)では、HCR署名は、DSA署名に代わるより安全なものを提供する。実際に、DSAでは、単一の一時指数(たとえば、DSA署名の成分r=gk内のk)を開示すると、秘密署名鍵を明かすことにより、署名方式が完全に不安定になり、一時指数yが攻撃者に明かされた場合でも、HCR署名は捏造不能である(ただし、この場合、署名者がチャレンジXの順序をテストするかまたは余因数べき乗(co-factor exponentiation)を使用して強制的にその値を少なくとも次数qのものにすることを条件とする)。
非対話式XCR変種
XCR(およびHCR)署名は、X=Aを書き込むことにより、非対話式だが検証者固有のものにすることができ、ここでAは、図6に図示されている通り、検証者の公開鍵である。これは、非常に効率的な非対話式で検証者固有の否認可能認証メカニズムを提供する。ある変形では、当事者Aハットの固有の公開鍵Aを使用するのではなく、後者は署名者が使用するために1つまたは複数のチャレンジを公表する(たとえば、Webサイトでポストする)ことができ、したがって、Aハット自体が署名時に使用可能ではない場合でも、これらのチャレンジが使用可能になる。
変換可能XCR署名
XCR署名の顕著な特性(とりわけ、共有秘密および公開鍵暗号化に基づくものを含み、他の「否認可能」チャレンジ・レスポンス・メカニズムからそれを区別するもの)は、これらの署名を正規の否認不能な署名に「変換」する能力である。変換可能署名は、否認可能認証の特性を有し、すなわち、意図された受信側のみによって検証することができるが、署名者も自分の秘密署名鍵を明かさずに自分が所与の署名の作成者であることを最終的に証明することができる。
秘密署名から公開署名へのこの変換可能性は、たとえば、数年後に検証可能な公開記録に変換しなければならない職務上の非公式通信のために必要である可能性がある。XCR署名の場合、チャレンジXに基づくメッセージm上の署名(Y,σ)は、値y+Hバー(Y,m)bを明かすことにより、正当な署名者によって正規の否認不能な署名に変換することができる。
他の(受信側固有の)変換可能署名は文献に提示されているが、そのいずれでも、意図された受信側(またはチャレンジャ)は独力で署名を再計算することができず、このため、以下の二重XCR署名によって例示されている通り、この再計算特性がXCR署名に提供する多くの利点を共有しない。
二重XCR署名(DCR)
XCR署名の重要な特性の1つは、チャレンジを選択したチャレンジャが独力で署名を計算できることである。ここで、任意の2当事者Aハット、Bハットがチャレンジャと署名者という二重の役割で互いに対話でき、それぞれがいかなる第三者も捏造できない署名を生成するという特性を備えた関連チャレンジ・レスポンス署名方式(本明細書では「二重XCR方式」または略してDCRという)を導出するためにこの特性を利用する方法が示される。その上、これは、この方式をHMQVプロトコルにとって重要なものにするものであり、結果として得られるAハットおよびBハットによる署名は同じ値を有する。より正確には、それらはXCR署名ペア内に同じXSIG成分を有する。
定義: 二重(指数)チャレンジ・レスポンス(DCR)署名方式。AハットおよびBハットは、それぞれ公開鍵A=ga、B=gbを有する2当事者とする。m1、m2は2つのメッセージとする。それぞれメッセージm1、m2上のAハットおよびBハットの二重XCR署名(略してDCR)は、X、Y、および
Figure 2009526411
という3つ組の値として定義され、ここでX=gxおよびY=gyはそれぞれAハットおよびBハットによって選択されたチャレンジであり、記号dおよびeはそれぞれHバー(X,m1)およびHバー(Y,m2)を表している。(図7を参照されたい。)
このため、DCR署名の基本的な特性は、値XおよびY(それぞれAハットおよびBハットによって選択されたxおよびyを含む)を交換した後、AハットとBハットの両方が同じ署名
Figure 2009526411
を計算(および検証)できることである。これは、
Figure 2009526411
という等値(equivalence)から分かり、ここでx+daおよびy+ebはqを法として換算される。
その上、上記の仮出願の考察に実証されている通り、攻撃者はこの署名を実行できるように計算することができない。
大ざっぱに言えば、二重署名は、チャレンジYBeに基づくメッセージm1上のAハットによるXCR署名であると同時にチャレンジXAdに基づくメッセージm2上のBハットによるXCR署名である。より正確には、値dおよびeは署名プロセス中に(メッセージm1、m2のおそらく敵対的な選択により)決定されるので、BハットのDCR署名は攻撃者によって選択されたわけではない任意の値A=gaに関して安全であることを実証することができる。
基本HMQVプロトコルの形式的説明
HMQVプロトコルは、その基本的2メッセージ交換において、そこから両当事者AハットおよびBハットが
Figure 2009526411
という二重XCR署名を計算するためのチャレンジとして機能するDiffie−Hellman値X=gxおよびY=gyの両当事者間の交換から構成される。次に、この値をハッシュすることにより、セッション鍵が導出される。このように、署名自体は伝送する必要がなく、セッション鍵の共通導出値を保証するのは署名の一意性(uniqueness)であり、主張された当事者Aハット、Bハットによって交換が実行されたという証明を可能にするのは鍵(同等に、署名)を計算する固有の能力である。
基本的に、署名が計算されるメッセージm1、m2はピアのID(すなわち、Aハット、Bハット)であるので、両当事者は、自分が計算した鍵が正しいIDに一意的に拘束されるという保証を得る。署名の元に(とりわけ、値dおよびeの計算において)一時Diffie−Hellman値だけでなく、両当事者のIDをこのように含めることは、UKS攻撃などの何らかの認証障害を回避するために不可欠である。
したがって、2当事者Aハット、Bハット間のHMQVプロトコルのセッションは、H(π)として計算されたセッション鍵によるDH値X=gxおよびY=gy(図1)の基本Diffie−Hellman交換から構成され、ここで
Figure 2009526411
である。すなわち、πは互いのIDに関するAハットおよびBハットの二重署名として計算される。上記の署名は、省略表現π(Aハット,Bハット,X,Y)によって表され、すなわち、
Figure 2009526411
であり、ここでd=Hバー(X,Bハット)、e=Hバー(Y,Aハット)であり、A=ga、B=gyはそれぞれ両当事者Aハット、Bハットの公開鍵である。π(Aハット,Bハット,X,Y)=π(Bハット,Aハット,Y,X)であることは、この時点で留意すべきである。ある変形では、H(π)はπの異なる関数で置き換えることができ、とりわけ、ハッシュは両当事者のIDなどの追加の情報を含むことができる。
HMQVプロトコルは典型的には、そのプロトコルを実行するために全当事者のいずれかを呼び出すことができるマルチパーティ・ネットワークで実行される。ある当事者側でプロトコルを呼び出すたびにセッション(プロトコルのこの特定のインスタンスに関連する情報を含むローカル状態)が作成され、それにより、完了時に発信メッセージとセッション鍵の出力を生成することができる。セッション中に以下のように3通りのタイプの起動によってある当事者を起動することができる(以下の説明では、Aハットは起動される当事者のIDを表し、Bハットはセッションに対する意図されたピアのIDを表している)。
1.Initiate(Aハット,Bハット): Aハットは、値X=gx、x∈Rqを生成し、(不完全な)セッション(Aハット,Bハット,X)として識別するHMQVのローカル・セッションを作成し、その発信メッセージとして値Xを出力する。
この起動の意味は、AハットがBハットとのセッションの起動側(initiator)として起動されていることであり、Xはこのセッションの一部としてピアBハットに配信する予定のメッセージである。当事者Aハットはセッションの「保有者(holder)」(または「所有者(owner)」)と呼ばれ、Bハットはセッションに対する「ピア」と呼ばれ、Xは発信(DH)値と呼ばれる。
2.Respond(Aハット,Bハット,Y): AハットはY≠0であることをチェックする。そうである場合、Aハットは、値X=gx、x∈Rqを生成し、Xを出力し、ID(Aハット,Bハット,X,Y)およびセッション鍵H(π((Aハット,Bハット,X,Y))を有するセッションを完了する。ここで、Aハットは、ピアBハットおよび着信値Yを有するセッションにおいて応答側として起動されている。この場合、Aハットは直ちにそのセッションを完了する(それ以上の着信メッセージはまったく存在しない)。着信値Yがゼロである場合、Aハットが起動を無視することに留意されたい。
3.Complete(Aハット,Bハット,X,Y): Aハットは、Y≠0であることと、ID(Aハット,Bハット,X)を有する公開セッションを有することをチェックする。これらの条件のいずれかが適合しない場合、Aハットは起動を無視し、適合する場合、AハットはセッションID(Aハット,Bハット,X,Y)およびセッション鍵K=H(π((Aハット,Bハット,X,Y))を有するセッションを完了する。これは、(申し立てによると)ピアBハットからの応答である着信値Yによる、このプロトコルにおける第2のメッセージの配信を表している。
3メッセージHMQV−Cプロトコル
3メッセージHMQV−C(Cは「鍵確認(key Confirmation)」を意味する)プロトコルは図8に描写されている。このプロトコルは、HMQVのすべてのセキュリティ特性、特に同じ計算コストを享受する。しかし、これは、第3のメッセージをプロトコルに追加し、プロトコル・メッセージの長さをわずかに増加させるものである。
代わりに、HMQV−Cは、鍵確認、PFS、および汎用構成可能性(universal composability)を含む、基本HMQVプロトコルで欠けているいくつかの特性を提供する。
鍵確認
HMQVプロトコルは、ピアBハットおよびセッション鍵Kを有するセッションを完了する当事者Aハットに基本的な保証を提供し、Bハットが破壊されていない場合、BハットのみがおそらくKを把握することができる。このプロトコルが提供しないものは、Bハットがセッションを完了したかまたはセッション鍵を計算したというAハットに対する保証である。その上、Bハットは、セッションの実行中に「活動中」ではなかった可能性がある。
(典型的な公開鍵シナリオのように、AハットとBハットとの間のそれ以前の通信で、いかなる事前共有状態も作成されなかったと想定すると)いずれの2メッセージ公開鍵ベースのプロトコルについても同じことが当てはまるので、これはHMQVのみの欠点ではない。さらに、Shoupによって指摘されたように、その鍵を使用してそれぞれが開始する前にピアがセッションを完了しているという保証を両当事者が有するという表面上当然の目標は、いずれの鍵交換プロトコルでも達成することができない。実際に、攻撃者は、最後のプロトコル・メッセージがその宛先に到着しないようにすることにより、この相互保証を必ず阻止することができる。
しかし、ピアが鍵を計算できたという両当事者のそれぞれに対する保証が弱い場合(しかし、必ずしも、呼び出し側アプリケーションに鍵を出力するという保証ではない)、その保証は達成可能であり、文献では鍵確認特性と呼ばれる。鍵交換の基本セキュリティにとって決定的なものではないが(たとえば、鍵確認の欠如は鍵によって保護された通信のプライバシまたは確実性にとって脅威ではない)、この特性はいくつかの適用例に有用な「動作上の健全性のチェック(operational sanity check)」を提供することができる。
この場合、追加のMAC値が鍵確認を可能にするので、プロトコルHMQV−CはHMQVより適している。その上、MAC妥当性検査は、セッションに対する識別済みピアの積極的な関わりとともに、このピアが一致セッション(すなわち、同じピアおよび同じセッション鍵を有する)を所有するという事実を確認する。これらの特性を達成するために、HMQV−CのMACは、任意の特定のセッション情報に適用する必要はないが、単にメッセージの「方向」を示すためならびに反射を防止するために使用される単一ビットに適用する必要があることに留意されたい。また、HMQV−Cの最初の2つのメッセージのみから構成されるプロトコルが起動側に鍵確認を提供すること(それにより、プロトコル・メッセージの数を増加せずにHMQVに有用な特徴を追加する可能性がある)も留意する価値がある。
鍵交換の多くの適用例では、鍵確認の欠如の結果、たとえば、Bハットに保護情報を送信するために、当事者Aハットが鍵を使用し始めるが、Bハットはまだその鍵を確立していないので、この情報を処理することができないという、ある形の「サービス妨害」(DoS:denial of service)攻撃が行われる可能性がある。言われている通り、相互「セッション完了」確認は達成不能なので、この状況は完全に回避することができない。
その上、ある当事者がピアの無効性を発見する前に相当な計算サイクルを費やすこと(およびセッション状態を作成すること)を強要されるという、公開鍵動作に基づくプロトコルに対してより深刻な形のDoS攻撃が存在する。プロトコル・メッセージの追加という犠牲を払って任意の鍵交換プロトコル(HMQVを含む)に適用でき、DoS攻撃に対して有用だが範囲が限られた対策がいくつか存在する。
完全転送秘密(PFS)
完全転送秘密は、それにより長期秘密鍵が漏洩しても古いセッション鍵のセキュリティを危険にさらさない、鍵交換プロトコルの非常に望ましい特性である。より形式的には、破壊されていない当事者Aハットが破壊されていないピアBハットとの鍵交換セッションを確立する場合、AハットでKが満了した後で攻撃者がAハットを破壊するかまたはBハットでKが満了した後で攻撃者がBハットを破壊しても、セッション鍵Kは引き続き安全である。HMQVを含む、暗黙認証を伴う2メッセージ・プロトコルはいずれも、活発な攻撃者に対する完全な完全転送秘密を提供することができない。その代わりに、望むことができる最良のものは、HMQVによって提供される弱い形のPFSである。基本的な2メッセージHMQVに対するHMQV−Cの主な利点は、仮出願にさらに説明されている通り、それがHMQVの固有の制限を引き上げ、完全なPFSを提供することである。
汎用構成可能性セキュリティ
鍵交換に関するCanetti/Krawczykのモデルは、仮出願におけるMQVおよびHMQVの分析の基礎であり、実社会環境の場合のように、他のアプリケーションと同時に実行されたときに鍵交換プロトコルのセキュリティを保証することを目標とする、より意欲的なモデルに拡張されている。このモデルは、鍵交換の汎用構成可能性(UC:Universal-Composability)モデルとして知られている。
HMQV−Cの場合、セッションを完了すべき第1の当事者がそのセッション鍵を出力すると、ピアの状態は、プロトコルおよびセッション鍵内の公開情報から「シミュレート」可能な情報のみを含むことが分かる。Canatti/Krawczykは、仮出願に示されているHMQVの他のセキュリティ特性とともに、この特性がHMQVプロトコルの汎用構成可能性を保証するために十分であることを示している。
1パスHMQV
図9に示されている1パス鍵交換プロトコルは、送信側Aハットから受信側Bハットに送信された単一メッセージから構成され、両当事者およびセッションが以下に定義するように破壊されていない限り、そこから両当事者はそれぞれの秘密鍵と公開鍵を使用して、AハットおよびBハットのみがおそらく把握できる固有の鍵を導出する。
確立された鍵からの要件は、Bハットによって受信されたメッセージがAハットからの古いメッセージの再生である可能性を除いて、正規の鍵交換プロトコルと同じである。この再生は、1パス・プロトコルで避けられないものであるが、同期時間または共有状態などのその他の手段によって検出可能である可能性がある。
加えて、Bハットからのセッション固有の入力の欠如により、その鍵はBハットの秘密鍵の単独知識で計算可能でなければならないので、このようなプロトコルはPFSを提供することができない。
本発明の一実施形態では、それぞれ公開鍵A=ga、B=gbを有する当事者AハットとBハットとの間の1パスHMQVプロトコルは、AハットからBハットに伝送された単一値X=gxから構成され、ここでx∈RqはAハットによって選択される。セッション鍵Kは以下のようにAハットによって計算される。
(i)(Aハット,Bハット)は2つのID AハットおよびBハットを含むメッセージを表すものとし、d=Hバー(X,(Aハット,Bハット))の結果になるようにdを設定する。
(ii)
Figure 2009526411
を計算する。
(iii)K=H(σ,Aハット)を設定し、ここでHは必要な鍵の長さに等しいビット数を出力する。同じ鍵Kは、X≠0であることをチェックした後、BハットによってK=H((XAdb)として計算される。変形では、K=H(σ,Aハット,Bハット)である。
換言すれば、1パスHMQVのこの実施形態の鍵は、Bハットの公開鍵をチャレンジとして使用して、非対話式XCR著名から導出される。
1パス・プロトコルは認証選択暗号文セキュア(CCA:chosen-ciphertext secure)暗号化方式として使用できることも指摘されている。すなわち、Aハットは、(選択暗号文攻撃に対して)暗号化されるとともに(Aハットにより)認証されたメッセージmをBハットに伝送することができる。一実施形態では、Aハットは、3つ組(X,c,t)を送信することになり、ここでX=gxであり、cは鍵K1に基づいてメッセージmの対称選択平文セキュア(CPA:chosen-plaintextsecure)暗号化として得られる暗号文であり、tは鍵K2に基づいてcについて計算されたMAC値である。鍵K1およびK2は、1パスHMQVプロトコルのようにXから計算された鍵Kから導出される。
この手順の全体的なコストは、Aハットについては2つのべき乗(一方はオフライン)であり、Bハットについては1.5である。これは、DHIES(Diffie−Hellman統合暗号化方式:Diffie-Hellman Integrated Encryption Scheme)などの代替CCA暗号化方式と比較してBハットについて1/2べき乗多いだけであるが、代わりに、Aハットからの認証を提供する(DHIESの場合、この認証はAハットから完全な追加の署名を返すことになるであろう)。この効率的な認証CCA暗号化は、一般的な「プリティグッド・プライバシ(PGP:Pretty-GoodPrivacy)」アプリケーションなどの「蓄積交換(store-and-forward)」アプリケーションにとって非常に魅力的であり、通常の署名暗号化(sign-and-encrypt)パラダイムよりかなり安価である。この場合、唯一の警告は、暗号化解除動作に必要であるので、ID Aハット(およびおそらくその証明書)は平文で伝送する必要があることである。
上記のプロトコルのさらに他の特性のうち、留意する価値のあるものは、必ずしも暗号化部分を追加せずにメッセージm上のAハットの検証者固有の署名としてのみ使用できることである。しかし、この署名は、受信側固有のものであり、したがって、否認防止を提供しない。その代わりに、PGPなどの多くの適用例で非常に価値ある特徴である否認可能性を提供する。
MQVを採用した規格の多くはその1パス変種も採用していることは留意すべきである。その種々の形(1メッセージ、2メッセージ、および3メッセージ)でのHMQVの採用に関心のある規格の場合、HMQVの他の変種の導出と同様に、1パス・プロトコルで鍵の導出を定義することは意味をなすであろう。
具体的には、HMQVプロトコルを定義する二重署名においてYをBで置き換えることにより、1パス鍵について以下の値が得られ、AハットおよびBハットはそれぞれ、
Figure 2009526411
および
Figure 2009526411
を計算し、鍵Kをこれらの(等しい)値のハッシュに設定する。この場合、他の変種と互換性のあるものにすることを除き、指数eはいかなる値もプロトコルに追加しないことに留意されたい。これは、実際に、プロトコル効率をいくらか減ずるものである。
しかし、HMQVの1パス・バージョンのd=Hバー(X,(Aハット,Bハット))という値と2メッセージ・バージョンのd=Hバー(X,Bハット)という値の間には追加の矛盾が存続する。3つのモード間の互換性を提供する方法は、これらのいずれでもd=Hバー(X,Bハット)、e=Hバー(Y,Aハット)を有し、ここで1パスの場合にY=Bであり、セッション鍵導出関数、すなわち、K=H(σ,Aハット,Bハット)(何らかの固定基準を使用して定義されたAハットおよびBハットの次数を有する)にID Aハット、Bハットを追加することになるであろう。これは、dの計算においてAハットを追加する必要性に取って代わるものである。また、事前計算DH値が漏洩した場合にHMQVを強化し、潜在的に未知の鍵共有攻撃を回避するという利点も有する。
HMQVのセキュリティ態様の要約
従来のMQVプロトコルに比較して、HMQVプロトコルは、以下のものを含む、いくつかのパフォーマンス上の利点を提供する。HMQVは、このプロトコルで伝送されるDH値に関する高価な素数次数テストの必要性を立証可能に省くものである。仮出願で実証されている通り、攻撃者がローグ(rogue)DH値の選択の恩恵を受けうる唯一の方法は、ゼロになるようにそれらを選択することであり、したがって、単純な非ゼロ・チェックがHMQVで必要なすべてである。このため、素数次数テストの必要性またはMQVプロトコルで同時に使用される余因数hの必要性はまったくない。
HMQVプロトコルが数学的に立証可能な方法で達成する特性のリストは以下の通りである。
(1)HMQVは、CanettiおよびKrawczykの強い形式的鍵交換モデルで安全なものである。
(2)HMQVは、両当事者の秘密鍵にアクセスできない攻撃者による詐称に耐えるものである。
(3)HMQVは、交換の当事者のIDにXCR署名を適用し、その結果、UKSおよびその他の認証攻撃を回避することにより、これらの当事者のIDと鍵との間に固有の結合を確立する。
(4)HMQVは、セッション鍵およびその他のセッション情報の部分漏洩が存在しても安全であり、換言すれば、HMQVはいわゆる「既知の鍵(known key)」の攻撃に対する抵抗力がある。とりわけ、異なるセッション鍵は、互いに「計算上独立」するように保証される。
(5)このプロトコルは、「鍵漏洩詐称(KCI:key-compromise impersonation)」攻撃に対する抵抗力として知られる追加レベルの保護を提供し、すなわち、これは、Aに対して他の当事者を詐称できるように当事者Aの秘密鍵を学習する攻撃者を阻止する。
(6)鍵確認を有する3メッセージHMQVプロトコルは、立証可能な完全転送秘密(PFS)を提供し、すなわち、2当事者の長期秘密鍵が最終的に開示された場合でも、漏洩前にこれらの当事者によって作成されたセッション鍵は引き続き安全である。
(7)鍵確認を有する3メッセージ・プロトコルは、いわゆる「汎用構成可能」鍵交換プロトコルの追加のセキュリティ上の利点を享受し、すなわち、他のプロトコルによって安全に構成することができる。
(8)HMQVのセキュリティは、静的公開鍵の形式および構造に関する特別なテストに依存せず、対応する秘密鍵のいわゆる「所有証明(proof of possession)」を必要としない。MQVを含む、同様のプロトコルを上回るHMQVのこのような利点により、認証局(CA:certificationauthority)は、登録公開鍵についてこのような特別なチェックを実行する負担から解放され、その結果、より現実的で実用的なセキュリティの保証が得られるが、とりわけ、多くのローカルCAがこのようなチェックを実行できないかまたは実行するように構成されていないためである。その上、CAによるこのようなテスト(たとえば、所有証明)の正当な実行により、追加のセキュリティ上の脆弱性に対してプロトコルを開放することは、留意する価値がある。
(9)2メッセージおよび3メッセージHMQVプロトコルは、一時公開鍵(すなわち、値XおよびY)の次数のテストを必要とせず、その結果、場合によっては高価なものになりうるテストを回避する。しかし、両当事者の一時秘密鍵を学習する可能性のある攻撃者に耐えることがプロトコルのセキュリティである場合、このようなテストは必要である。また、1パスHMQVプロトコルのセキュリティについても、このテストは必要である。MQVのように、これらのテストは、プロトコル内のσ値の「余因数べき乗」で置き換えることができる。基礎となる代数群に応じて、所定の群内の帰属関係など、群の元に関する追加のテストが必要になる場合もある。
本発明のHMQVプロトコルの重要な利点の1つは、形式的に数学的に有効であることを証明できる広範囲のセキュリティ上の特性が存在するときに、それがほぼ間違いなく最も効率的な認証Diffie−Hellman鍵交換プロトコルであることである。実際に、この形式的な立証可能性は、HMQVとその先行MQVとの間の主な相違点の1つである。
MQVはセキュリティの証明を備えることができなかっただけでなく、上記の仮出願に初めて記載されたいくつかの弱点を含む、このプロトコルの明示的な弱点が時間の経過につれて明らかになっている(たとえば、Kaliskiによる研究およびRogaway他による報告)。このような弱点または攻撃は、その発明者によって行われたMQVに関するセキュリティ上の主張のいくつかを無効にしており、とりわけ、MQVが安全なものであることを証明できないことが示されている。
XCR署名とMQVの「暗黙署名(Implicit Signature)」との比較
比較のやり方として、特許および学術論文に記載されているMQVはプロトコルの設計および説明でも署名の概念を使用することは、留意する価値がある。これは、MQVに関連して「暗黙署名」と呼ばれ、秘密署名鍵の所有者のみが署名値を生成できるデジタル署名のより伝統的な概念に従うものである(具体的には、MQVは、秘密署名鍵と、一時秘密鍵および公開鍵との1次結合によって形成されるElGamalのような署名を指す)。しかし、プロトコルは、これらの署名の特性を完全に使用するまでには至らない。とりわけ、MQVプロトコルは、そのプロトコルの当事者のIDを明示的に認証する方法として署名を使用せず、これにより、Kaliskiによって発見された有名な「未知の鍵の共有(UKS:unknown key share)」などの重大な認証障害が発生する。
対照的に、HMQVは、2つの重要な要素をその設計に採り入れている。1つは、XCRの使用であり、これはElGamal署名の指数バージョンである。より具体的には、これはSchnorrの署名の指数バージョンであり、次にこれはElGamal署名の特定のインスタンス化である。もう1つは、ピアのIDの明示的な署名であり、これは、セッションのピアに対するセッション鍵の安全な結合を保証し、とりわけ、UKSなどの認証障害を防止する。
XCR署名の重要な新規性は、署名者と検証者(またはチャレンジャ)の両方が同じ署名を計算できるという特性である。この特性は、通常、共有鍵暗号方式に基づく認証メカニズムに見られる(すなわち、署名者と検証者の両方が事前(a-priori)共有鍵を有する場合)が、公開鍵ベースの署名では新しいものである。XCR署名は、HMQVのように、共有鍵の導出に完全に適しているだけでなく、認証ツールとして様々な利点を提示し、そのうちのいくつかについては上述した通りである。
本発明が様々な実施形態を包含することは当業者にとって明白であるはずである。
したがって、模範的な一実施形態では、検証者Vと署名者Sという2当事者が存在する。署名者Sは秘密鍵bと公開鍵Bとを有し、検証者VはSの真正公開鍵Bを所有するかまたは(たとえば、Sから送信されたデジタル証明書を介して)入手するものと想定される。所与のメッセージmに関する認証プロトコルは以下のものを含む。
(1)Vは、秘密の値xを選択し、値X=F1(x)を計算し、ここでF1は所与の関数であり、次にXをSに送信する。
(2)Sは、秘密の値yを選択し、値Y=F2(y)を計算し、ここでF2は所与の関数であり、次にYをVに送信する。
(3)Sは、値s=F3(y,b,X,m)を計算し、ここでF3は所与の関数であり、次にsをVに送信する。
(4)Vは、値s′=F4(x,Y,B,m)を計算し、値s′と受信した値sに対するその関連とを基礎として、mの確実性を決定する。
この実施形態のいくつかの模範的な変種は以下のものを含む。
(a)F1、F2は一方向関数である。XCRでは、これらの一方向関数はX=gxおよびY=gyである。
(b)XCR署名では、この関数は
Figure 2009526411
および
Figure 2009526411
である。
(c)s′=sである場合のみ、mを認証として受け入れる。この最後の変種は、それにより、チャレンジXの背後にある秘密を把握することによって検証者が署名を再計算できる、典型的なXCR署名の特性を利用する。
(d)
Figure 2009526411
を計算し、H(s′)=sなどをテストする。
HMQVに対するXCRの適用例の少なくとも1つの実施形態では、ステップ(3)でSによって計算された値sはけっしてVに送信されない。その代わりに、Vは、(Sが詐称者(impostor)である場合を除き)sと同一になるはずの値s′を計算し、s(これはHMQVではσである)を使用してそこからセッション鍵を導出する。とりわけ、Vは明示的検証をけっして実行しない。この実施形態では、メッセージmの確実性を検証するための方法ではなく、それにより両当事者が共通の「認証値(authenticatedvalue)」(すなわち、両当事者のみが計算できる値)を計算し、この値がそれぞれのIDに一意に結合される(二重XCR署名を介して両当事者のIDを署名することによりHMQVで達成される典型的な鍵交換プロトコルにおける本質的な条件である)方法が存在することになるであろう。
追加の変形例については上記の説明および特許請求の範囲に記載されている。
模範的なハードウェア実現例
図10は、本発明による情報処理/コンピュータ・システムの典型的なハードウェア構成を例示しており、このシステムは好ましくは少なくとも1つのプロセッサまたは中央演算処理装置(CPU:central processing unit)1011を有する。
CPU1011は、システム・バス1012を介して、ランダム・アクセス・メモリ(RAM:random access memory)1014、読み取り専用メモリ(ROM:read-only memory)1016、入出力(I/O)アダプタ1018(ディスク装置1021およびテープ・ドライブ1040などの周辺装置をバス1012に接続するため)、ユーザ・インターフェース・アダプタ1022(キーボード1024、マウス1026、スピーカ1028、マイクロホン1032、またはその他のユーザ・インターフェース・デバイス、あるいはこれらの組み合わせをバス1012に接続するため)、情報処理システムをデータ処理ネットワーク、インターネット、イントラネット、パーソナル・エリア・ネットワーク(PAN:personalarea network)などに接続するための通信アダプタ1034、およびバス1012をディスプレイ装置1038またはプリンタ1039(たとえば、デジタル・プリンタなど)あるいはその両方に接続するためのディスプレイ・アダプタ1036に相互接続される。
上述のハードウェア/ソフトウェアの実施形態に加えて、本発明の異なる一態様は、上記の方法を実行するためのコンピュータで実行される方法を含む。一例として、この方法は、上記で論じた特定の実施形態で実現することができる。
このような方法は、たとえば、一連の機械可読命令を実行するように、デジタル・データ処理装置によって実施されるコンピュータを操作することによって実現することができる。これらの命令は、様々なタイプの信号伝送媒体に常駐することができる。
したがって、本発明のこの態様は、本発明の方法を実行するために、CPU1011および上記のハードウェアを組み込むデジタル・データ・プロセッサによって実行可能な複数の機械可読命令からなるプログラムを具体的に実施する信号伝送媒体を含むプログラム式製品を対象とする。
この信号伝送媒体としては、たとえば、高速アクセス記憶装置によって表される、たとえば、CPU1011内に収容されたRAMを含むことができる。代わって、命令は、CPU1011によって直接または間接的にアクセス可能な磁気データ記憶ディスケット1100(図11)などの他の信号伝送媒体に収容することもできる。
ディスケット1100に収容されているか、コンピュータ/CPU1011に収容されているか、またはその他の場所に収容されているかにかかわらず、命令は、DASD記憶装置(たとえば、従来の「ハード・ディスク」またはRAIDアレイ)、磁気テープ、電子読み取り専用メモリ(たとえば、ROM、EPROM、またはEEPROM)、光学記憶装置(たとえば、CD−ROM、WORM、DVD、デジタル光テープなど)、紙の「パンチ」カード、または、デジタルおよびアナログの通信リンクおよび無線などの伝送媒体を含むその他の適切な信号伝送媒体などの様々な機械可読データ記憶媒体に保管することができる。本発明の例示的な一実施形態では、機械可読命令は、ソフトウェア・オブジェクト・コードを含むことができる。
基本(非認証)Diffie−Hellmanプロトコル100を示す図である。 デジタル署名を使用することによって認証された2メッセージDiffie−Hellmanプロトコル200を示す図である。 本発明のHMQVプロトコルのセッション鍵の計算に対する従来のMQVプロトコルのセッション鍵Kの計算の比較300を示し、MQVで使用されるハッシュへの追加である模範的な一実施形態のハッシュをHMQVがどのように使用するかを実証する図である。 図3に示されているHMQVプロトコルの異なるグラフィック表現400である。 XCRの計算500を例示的に示す図である。 非対話式XCR署名の計算600の一例を示す図である。 2当事者による二重XCR署名の計算700を示す図である。 3メッセージ鍵確認(HMQV−C)プロトコル800で例示的に実施されたHMQVを示す図である。 1パス鍵交換900で例示的に実施されたHMQVを示す図である。 そこに本発明を組み込むための模範的なハードウェア/情報処理システム1000を例示する図である。 本発明による方法のプログラムの諸ステップを保管するための信号伝送媒体1100(たとえば、記憶媒体)を例示する図である。

Claims (38)

  1. 装置またはネットワークによって相互接続された2当事者間の交換の方法において、
    受信側当事者(検証者)が値X=F1(x)を計算するために秘密の値xを選択し、ここでF1は少なくとも1つの引数を有する第1の所定の関数を含み、前記値xはF1の前記少なくとも1つの引数のうちの1つであり、
    署名側当事者(署名者)が値Y=F2(y)を計算するために秘密の値yを選択し、ここでF2は少なくとも1つの引数を有する第2の所定の関数を含み、前記値yはF2の前記少なくとも1つの引数のうちの1つであり、
    前記署名者が前記値Xを入手し、前記署名者が秘密鍵bと公開鍵Bとを有し、
    前記署名者が値s=F3(y,b,X)を計算し、ここでF3は少なくとも3つの引数を有する第3の所定の関数を含み、前記値y、前記秘密鍵b、および前記値XはF3の前記少なくとも3つの引数のうちの3つの引数であり、
    値s′を計算するために第4の所定の関数F4(x,Y,B)が存在し、F4は少なくとも3つの引数を有し、前記値x、前記値Y、および前記公開鍵BはF4の前記少なくとも3つの引数のうちの3つの引数であるが、値sはF4の引数ではなく、
    前記検証者と前記署名者との間で共有され、前記F1、F2、F3、およびF4のいずれかにおいて任意の引数の基礎として働くような秘密が存在せず、
    前記値s′が所定の方法で前記値sに関連するものと判断された場合に前記検証者が前記値sおよびs′を有効な認証子と見なすことができる、方法。
  2. F1およびF2のうちの少なくとも1つが一方向関数を含む、請求項1に記載の方法。
  3. 前記値sおよびs′が、s=s′である場合に有効な認証子であると判断される、請求項1に記載の方法。
  4. s′の計算ならびに前記値sおよびs′が関連するものであると判断されるかどうかの判断のうちの少なくとも一方が、前記検証者および前記署名者以外の当事者によって実行される、請求項1に記載の方法。
  5. 2当事者間で共有される秘密を導出するために前記値sおよび前記値s′が使用される、請求項1に記載の方法。
  6. 前記検証者が前記値Yを入手し、sおよびs′が前記所定の方法で関連するかどうかを判断するために前記値s′を計算するためにこれを使用すること
    をさらに含む、請求項1に記載の方法。
  7. メッセージmが、認証対象であり、F3の引数およびF4の引数を含み、それにより、前記値sおよび前記値s′が前記メッセージm内の情報を含むことができ、
    前記値sおよびs′が前記所定の方法で関連するものであると判断された場合に前記メッセージが認証される、請求項1に記載の方法。
  8. 2当事者間で共有される秘密を導出するために前記値sおよび前記値s′が使用される、請求項7に記載の方法。
  9. 前記メッセージmが、少なくとも前記交換の前記当事者の一方のIDを含む、請求項8に記載の方法。
  10. 前記署名者が前記値sを前記検証者に送信すること
    をさらに含む、請求項7に記載の方法。
  11. 前記s=s′である場合に前記メッセージが認証される、請求項7に記載の方法。
  12. 前記公開鍵B=gbであり、gが次数qの有限群の生成元であり、前記秘密鍵bが0q−1になるような整数であり、
    前記値X=gxであり、xが0q−1になるような整数であり、前記値Y=gyであり、yが0q−1になるような整数であり、
    前記署名者が前記値s=f1(X)f2(m,Y,y,b)を計算し、f1が第1の数学関数を含み、f2が第2の数学関数を含み、引数mがメッセージを含む、請求項1に記載の方法。
  13. qが素数である、請求項12に記載の方法。
  14. 前記値sが所定の方法で前記値s′に関連するものと判断された場合に前記メッセージmが認証済みと見なされる、請求項12に記載の方法。
  15. 前記値sが前記値s′に等しいと判断された場合に前記メッセージmが認証済みと見なされる、請求項14に記載の方法。
  16. 1が恒等関数から構成される、請求項12に記載の方法。
  17. 2が、f2の前記引数の少なくとも1つがハッシュされるようなハッシュ関数を含む、請求項12に記載の方法。
  18. ハッシュされた前記引数の1つが非ヌル・メッセージmである、請求項17に記載の方法。
  19. 前記メッセージmが、コンピュータまたはシステムあるいはネットワーク内の当事者のIDを含む、請求項12に記載の方法。
  20. 2(m,Y,y,b)=y+H(Y,m)b mod qであり、ここでHは一方向関数、暗号化関数、および暗号ハッシュ関数のうちの1つである暗号関数を含む、請求項17に記載の方法。
  21. 前記値s′=(YB{H(Y,m)}f3(x)であり、ここでf3(x)は少なくとも1つの引数を有する数学関数を含み、前記値xはf3(x)の前記少なくとも1つの引数のうちの1つの引数である、請求項20に記載の方法。
  22. 3(x)=xである、請求項21に記載の方法。
  23. s=s′である場合のみ、前記メッセージmを認証すること
    をさらに含む、請求項21に記載の方法。
  24. 前記検証者が、秘密鍵a、公開鍵A=ga、およびメッセージm′を有し、前記値s′がm上の前記署名者の署名を含むと同時に、前記値sがm′上の前記検証者の署名を含む、請求項21に記載の方法。
  25. 前記関数f3(x)=x+H(X,m′)a mod qである、請求項24に記載の方法。
  26. xが前記検証者によってランダムに選択され、yが前記署名者によってランダムに選択される、請求項1に記載の方法。
  27. 前記第1の値X=gxが、前記証明者により検索可能になるように前記検証者によって公開された値を含み、それにより、前記認証の非対話式バージョンを可能にする、請求項1に記載の方法。
  28. 前記値sおよびs′がさらにハッシュされる、請求項21に記載の方法。
  29. 請求項1に記載の前記方法の諸ステップの少なくとも1つを実行するためにデジタル処理装置によって実行可能な複数の機械可読命令からなるプログラムを具体的に実施する信号伝送媒体。
  30. 前記署名者について請求項1に記載した前記関数F2およびF3を計算するための計算機
    を含む装置。
  31. 装置またはネットワークによって相互接続された2当事者間で認証鍵を確立するための方法において、
    第1の当事者が秘密鍵aと公開鍵Aとを有する場合に、前記秘密鍵aが0q−1になるような整数であり、qが正整数であり、gが次数qの有限群の生成元であり、Aが前記値gによって生成され、A=gaとして計算された前記群内の元であり、
    第2の当事者が秘密鍵bと公開鍵B=gbとを有し、前記秘密鍵bが0q−1になるような整数であり、
    前記第1の当事者が値X=gxを計算するために秘密の値xを選択し、xが0q−1になるような整数であり、前記値Xが前記第2の当事者に伝達され、
    前記第2の当事者が値Y=gyを計算するために秘密の値yを選択し、yが0q−1になるような整数であり、前記値Yが前記第1の当事者に伝達され、
    前記第1の当事者が値s=f1(Y,B,m){f2(x,a,m’)}を計算し、ここでm、m′は前記当事者間で既知であるかまたは交換されたメッセージを含み、前記第2の当事者が値s′=f3(X,A,m′){f4(y,b,m)}を計算し、
    前記関数f2およびf4のうちの少なくとも1つが少なくとも1つの引数を有する関数Hを含み、このような1つの引数が前記メッセージmおよびm′のうちの少なくとも1つであり、ここでHは一方向関数、暗号化関数、および暗号ハッシュ関数のうちの1つである暗号関数を含み、
    前記第1および第2の当事者がそれぞれ前記値sおよびs′から共有鍵を導出する、方法。
  32. (i)前記値xおよびXの計算が、前記第1の当事者の前記秘密鍵と、前記当事者のうちの一方または複数の前記公開鍵とを含むことと、
    (ii)前記値yおよびYの計算が、前記第2の当事者の前記秘密鍵と、前記当事者のうちの一方または複数の前記公開鍵とを含むこと
    のうちの少なくとも一方が該当する、請求項31に記載の方法。
  33. sおよびs′からの共有鍵の前記導出が、一方向関数、暗号化関数、および暗号ハッシュ関数のうちの1つである暗号関数を含む、請求項31に記載の方法。
  34. 前記メッセージmおよびm′のうちの少なくとも1つが前記第1および第2の当事者のうちの一方のIDを含む、請求項31に記載の方法。
  35. 1(Y,B,m)=YBH(Y,m)であり、
    2(x,a,m′)=(x+H(X,m′)a) mod qであり、
    3(X,A,m′)=XAH(X,m’)であり、
    4(y,b,m)=(y+H(Y,m)b) mod qであり、
    Hが一方向関数、暗号化関数、および暗号ハッシュ関数のうちの1つである暗号関数を含む、少なくとも2つの引数からなる関数である、請求項31に記載の方法。
  36. 前記メッセージmおよびm′のうちの少なくとも1つが前記第1および第2の当事者のうちの少なくとも一方のIDを含む、請求項35に記載の方法。
  37. (i)前記値xおよびXの計算が、前記第1の当事者の前記秘密鍵と、前記当事者のうちの一方または複数の前記公開鍵とを含むことと、
    (ii)前記値yおよびYの計算が、前記第2の当事者の前記秘密鍵と、前記当事者のうちの一方または複数の前記公開鍵とを含むこと
    のうちの少なくとも一方が該当する、請求項36に記載の方法。
  38. sおよびs′からの共有鍵の前記導出が、一方向関数、暗号化関数、および暗号ハッシュ関数のうちの1つである暗号関数を含む、請求項36に記載の方法。
JP2007554563A 2005-02-10 2006-02-10 装置またはネットワークによって相互接続された2当事者間の交換の方法、信号伝送媒体、および装置(チャレンジ・レスポンス署名および高性能で安全なDiffie−Hellmanプロトコルに関する方法および構造) Withdrawn JP2009526411A (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US65179805P 2005-02-10 2005-02-10
US11/348,304 US7747865B2 (en) 2005-02-10 2006-02-07 Method and structure for challenge-response signatures and high-performance secure Diffie-Hellman protocols
PCT/EP2006/050841 WO2006084896A1 (en) 2005-02-10 2006-02-10 Challenge-response signatures and secure diffie-hellman protocols

Publications (2)

Publication Number Publication Date
JP2009526411A true JP2009526411A (ja) 2009-07-16
JP2009526411A5 JP2009526411A5 (ja) 2010-09-02

Family

ID=36781288

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2007554563A Withdrawn JP2009526411A (ja) 2005-02-10 2006-02-10 装置またはネットワークによって相互接続された2当事者間の交換の方法、信号伝送媒体、および装置(チャレンジ・レスポンス署名および高性能で安全なDiffie−Hellmanプロトコルに関する方法および構造)

Country Status (8)

Country Link
US (1) US7747865B2 (ja)
EP (1) EP1847062B1 (ja)
JP (1) JP2009526411A (ja)
AT (1) ATE403297T1 (ja)
CA (1) CA2596500C (ja)
DE (1) DE602006002025D1 (ja)
ES (1) ES2308725T3 (ja)
WO (1) WO2006084896A1 (ja)

Cited By (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2009130872A (ja) * 2007-11-28 2009-06-11 Nippon Telegr & Teleph Corp <Ntt> 鍵共有方法、第1装置、第2装置、及び、それらのプログラム
JP2011061306A (ja) * 2009-09-07 2011-03-24 Nippon Telegr & Teleph Corp <Ntt> 情報共有システム、方法及びプログラム
JP2012151648A (ja) * 2011-01-19 2012-08-09 Nippon Telegr & Teleph Corp <Ntt> 情報共有方法、情報共有システム、情報共有装置、及びプログラム
JP2014050084A (ja) * 2012-09-04 2014-03-17 Nippon Telegr & Teleph Corp <Ntt> 鍵交換システム、要求装置、応答装置、鍵交換方法、およびプログラム
JP2017501637A (ja) * 2014-01-02 2017-01-12 テンセント・テクノロジー・(シェンジェン)・カンパニー・リミテッド 署名検証方法、装置、およびシステム
JP2019507510A (ja) * 2016-02-23 2019-03-14 エヌチェーン ホールディングス リミテッドNchain Holdings Limited 情報及び階層的で決定性の暗号化鍵のセキュアな交換のための共通秘密の決定
JP2019511035A (ja) * 2016-02-23 2019-04-18 エヌチェーン ホールディングス リミテッドNchain Holdings Limited スマートコントラクトに基づく自動給与支払方法及びシステムをもたらす、ブロックチェーン上の給与支払に関連付けられた暗号通貨の効率的な転送のための方法及びシステム
US10659223B2 (en) 2016-02-23 2020-05-19 nChain Holdings Limited Secure multiparty loss resistant storage and transfer of cryptographic keys for blockchain based systems in conjunction with a wallet management system
US10715336B2 (en) 2016-02-23 2020-07-14 nChain Holdings Limited Personal device security using elliptic curve cryptography for secret sharing
US11120437B2 (en) 2016-02-23 2021-09-14 nChain Holdings Limited Registry and automated management method for blockchain-enforced smart contracts
US11182782B2 (en) 2016-02-23 2021-11-23 nChain Holdings Limited Tokenisation method and system for implementing exchanges on a blockchain
US11194898B2 (en) 2016-02-23 2021-12-07 nChain Holdings Limited Agent-based turing complete transactions integrating feedback within a blockchain system
JP2022037089A (ja) * 2016-02-23 2022-03-08 エヌチェーン ホールディングス リミテッド ブロックチェーンからのデータのセキュアな抽出のための暗号方法及びシステム
US11308486B2 (en) 2016-02-23 2022-04-19 nChain Holdings Limited Method and system for the secure transfer of entities on a blockchain
US11373152B2 (en) 2016-02-23 2022-06-28 nChain Holdings Limited Universal tokenisation system for blockchain-based cryptocurrencies
US11410145B2 (en) 2016-02-23 2022-08-09 nChain Holdings Limited Blockchain-implemented method for control and distribution of digital content
US11455378B2 (en) 2016-02-23 2022-09-27 nChain Holdings Limited Method and system for securing computer software using a distributed hash table and a blockchain
US11606219B2 (en) 2016-02-23 2023-03-14 Nchain Licensing Ag System and method for controlling asset-related actions via a block chain
US11625694B2 (en) 2016-02-23 2023-04-11 Nchain Licensing Ag Blockchain-based exchange with tokenisation
US12107952B2 (en) 2016-02-23 2024-10-01 Nchain Licensing Ag Methods and systems for efficient transfer of entities on a peer-to-peer distributed ledger using the blockchain

Families Citing this family (38)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9054861B2 (en) * 2005-06-14 2015-06-09 Certicom Corp. Enhanced key agreement and transport protocol
DE102007001070B3 (de) * 2006-09-29 2008-04-30 Siemens Ag Verfahren zum verschlüsselten Datenausgleich eines Systems mit mindestens einem Datenträger und einem Lesegerät
KR100753843B1 (ko) 2006-09-29 2007-08-31 한국전자통신연구원 양 방향 채널 환경에서의 키 교환 프로토콜을 단 방향 채널환경에서의 키 교환 프로토콜로 변환하는 방법
KR101356736B1 (ko) * 2007-01-19 2014-02-06 삼성전자주식회사 콘텐츠의 무결성을 확인하기 위한 콘텐츠 제공 장치 및방법 및 콘텐츠 사용 장치 및 방법, 및 콘텐츠 사용 장치를폐지하는 콘텐츠 제공 장치 및 방법
US20090006202A1 (en) * 2007-02-26 2009-01-01 Picup, Llc System and method for providing identity-based services
CN101175076B (zh) * 2007-10-23 2012-01-11 赵运磊 在线计算高效、可抵赖、不可锻造安全的密钥交换方法
US8533474B2 (en) * 2008-02-27 2013-09-10 Red Hat, Inc. Generating session keys
EP2124382A1 (de) * 2008-05-20 2009-11-25 Siemens Aktiengesellschaft Verfahren zum verschlüsselten Datenaustausch und Kommunikationssystem
CN102318260B (zh) 2008-12-16 2016-04-20 塞尔蒂卡姆公司 密钥协商协议的加速
US10068282B2 (en) * 2009-06-24 2018-09-04 Uniloc 2017 Llc System and method for preventing multiple online purchases
EP2334008A1 (en) * 2009-12-10 2011-06-15 Tata Consultancy Services Limited A system and method for designing secure client-server communication protocols based on certificateless public key infrastructure
US8837741B2 (en) 2011-09-12 2014-09-16 Qualcomm Incorporated Systems and methods for encoding exchanges with a set of shared ephemeral key data
US9143937B2 (en) 2011-09-12 2015-09-22 Qualcomm Incorporated Wireless communication using concurrent re-authentication and connection setup
US9439067B2 (en) 2011-09-12 2016-09-06 George Cherian Systems and methods of performing link setup and authentication
US9503259B2 (en) * 2012-02-09 2016-11-22 Irdeto B.V. System and method for generating and protecting cryptographic keys
EP2677681A1 (de) * 2012-06-19 2013-12-25 Bundesrepublik Deutschland, vertreten durch das Bundesministerium des Innern, vertreten durch das Bundesamt für Sicherheit Verfahren zur zumindest einseitig authentisierten, sicheren Kommunikation zwischen zwei Kommunikationspartnern
WO2014181189A2 (en) * 2013-03-15 2014-11-13 Assa Abloy Ab Non-repudiation of electronic transactions
US9294503B2 (en) 2013-08-26 2016-03-22 A10 Networks, Inc. Health monitor based distributed denial of service attack mitigation
US10574633B2 (en) * 2014-06-18 2020-02-25 Visa International Service Association Efficient methods for authenticated communication
US9756071B1 (en) 2014-09-16 2017-09-05 A10 Networks, Inc. DNS denial of service attack protection
US9537886B1 (en) 2014-10-23 2017-01-03 A10 Networks, Inc. Flagging security threats in web service requests
US9584318B1 (en) 2014-12-30 2017-02-28 A10 Networks, Inc. Perfect forward secrecy distributed denial of service attack defense
US9900343B1 (en) 2015-01-05 2018-02-20 A10 Networks, Inc. Distributed denial of service cellular signaling
US9848013B1 (en) * 2015-02-05 2017-12-19 A10 Networks, Inc. Perfect forward secrecy distributed denial of service attack detection
US10063591B1 (en) 2015-02-14 2018-08-28 A10 Networks, Inc. Implementing and optimizing secure socket layer intercept
RU2663972C1 (ru) 2015-02-27 2018-08-14 Телефонактиеболагет Лм Эрикссон (Пабл) Обеспечение безопасности при связи между устройством связи и сетевым устройством
US20170063853A1 (en) * 2015-07-10 2017-03-02 Infineon Technologies Ag Data cipher and decipher based on device and data authentication
US10505984B2 (en) 2015-12-08 2019-12-10 A10 Networks, Inc. Exchange of control information between secure socket layer gateways
US10469594B2 (en) 2015-12-08 2019-11-05 A10 Networks, Inc. Implementation of secure socket layer intercept
US11184168B2 (en) * 2016-02-19 2021-11-23 Nec Corporation Method for storing data on a storage entity
US10116634B2 (en) 2016-06-28 2018-10-30 A10 Networks, Inc. Intercepting secure session upon receipt of untrusted certificate
SG10201606164TA (en) * 2016-07-26 2018-02-27 Huawei Int Pte Ltd System and method for obtaining a common session key between devices
US10158666B2 (en) 2016-07-26 2018-12-18 A10 Networks, Inc. Mitigating TCP SYN DDoS attacks using TCP reset
US11012435B2 (en) 2017-12-19 2021-05-18 International Business Machines Corporation Multi factor authentication
US11122033B2 (en) * 2017-12-19 2021-09-14 International Business Machines Corporation Multi factor authentication
CN109995509B (zh) * 2019-05-08 2021-07-06 西安电子科技大学 基于消息恢复签名的认证密钥交换方法
CN114154200B (zh) * 2021-12-09 2024-05-24 山东大学 基于可交换弱伪随机函数的隐私集合求并方法及系统
US11973861B2 (en) * 2022-02-09 2024-04-30 Northrop Grumman Systems Corporation Secure key generation

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4200770A (en) * 1977-09-06 1980-04-29 Stanford University Cryptographic apparatus and method
US5491750A (en) * 1993-12-30 1996-02-13 International Business Machines Corporation Method and apparatus for three-party entity authentication and key distribution using message authentication codes
US6487661B2 (en) * 1995-04-21 2002-11-26 Certicom Corp. Key agreement and transport protocol
US5761305A (en) 1995-04-21 1998-06-02 Certicom Corporation Key agreement and transport protocol with implicit signatures
US6226383B1 (en) * 1996-04-17 2001-05-01 Integrity Sciences, Inc. Cryptographic methods for remote authentication
GB9621274D0 (en) * 1996-10-11 1996-11-27 Certicom Corp Signature protocol for mail delivery
CA2369540C (en) * 2001-12-31 2013-10-01 Certicom Corp. Method and apparatus for computing a shared secret key
US7073068B2 (en) * 2002-05-24 2006-07-04 Lucent Technologies Inc. Method and apparatus for distributing shares of a password for use in multi-server password authentication

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
JPN6010044353, Hugo Krawczyk, "HMQV:A High−Performance Secure Diffie−Hellman Protocol", Cryptology ePrint Archive, 20050706, Report 2005/176, p.1−62 *

Cited By (38)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2009130872A (ja) * 2007-11-28 2009-06-11 Nippon Telegr & Teleph Corp <Ntt> 鍵共有方法、第1装置、第2装置、及び、それらのプログラム
JP2011061306A (ja) * 2009-09-07 2011-03-24 Nippon Telegr & Teleph Corp <Ntt> 情報共有システム、方法及びプログラム
JP2012151648A (ja) * 2011-01-19 2012-08-09 Nippon Telegr & Teleph Corp <Ntt> 情報共有方法、情報共有システム、情報共有装置、及びプログラム
JP2014050084A (ja) * 2012-09-04 2014-03-17 Nippon Telegr & Teleph Corp <Ntt> 鍵交換システム、要求装置、応答装置、鍵交換方法、およびプログラム
US10915896B2 (en) 2014-01-02 2021-02-09 Tencent Technology (Shenzhen) Company Limited Signature verification method, apparatus, and system
JP2017501637A (ja) * 2014-01-02 2017-01-12 テンセント・テクノロジー・(シェンジェン)・カンパニー・リミテッド 署名検証方法、装置、およびシステム
US11854003B2 (en) 2014-01-02 2023-12-26 Tencent Technology (Shenzhen) Company Limited Signature verification method, apparatus, and system
US11347838B2 (en) 2016-02-23 2022-05-31 Nchain Holdings Ltd. Blockchain implemented counting system and method for use in secure voting and distribution
US11373152B2 (en) 2016-02-23 2022-06-28 nChain Holdings Limited Universal tokenisation system for blockchain-based cryptocurrencies
US10715336B2 (en) 2016-02-23 2020-07-14 nChain Holdings Limited Personal device security using elliptic curve cryptography for secret sharing
US10652014B2 (en) 2016-02-23 2020-05-12 nChain Holdings Limited Determining a common secret for the secure exchange of information and hierarchical, deterministic cryptographic keys
JP2021044828A (ja) * 2016-02-23 2021-03-18 エヌチェーン ホールディングス リミテッドNchain Holdings Limited ウォレット管理システムと併せたブロックチェーンベースのシステムのための暗号鍵のセキュアなマルチパーティ損失耐性のある記憶及び転送
US11120437B2 (en) 2016-02-23 2021-09-14 nChain Holdings Limited Registry and automated management method for blockchain-enforced smart contracts
US11126976B2 (en) 2016-02-23 2021-09-21 nChain Holdings Limited Method and system for efficient transfer of cryptocurrency associated with a payroll on a blockchain that leads to an automated payroll method and system based on smart contracts
US11182782B2 (en) 2016-02-23 2021-11-23 nChain Holdings Limited Tokenisation method and system for implementing exchanges on a blockchain
US11194898B2 (en) 2016-02-23 2021-12-07 nChain Holdings Limited Agent-based turing complete transactions integrating feedback within a blockchain system
JP2022037089A (ja) * 2016-02-23 2022-03-08 エヌチェーン ホールディングス リミテッド ブロックチェーンからのデータのセキュアな抽出のための暗号方法及びシステム
US11308486B2 (en) 2016-02-23 2022-04-19 nChain Holdings Limited Method and system for the secure transfer of entities on a blockchain
JP2019511035A (ja) * 2016-02-23 2019-04-18 エヌチェーン ホールディングス リミテッドNchain Holdings Limited スマートコントラクトに基づく自動給与支払方法及びシステムをもたらす、ブロックチェーン上の給与支払に関連付けられた暗号通貨の効率的な転送のための方法及びシステム
US11349645B2 (en) 2016-02-23 2022-05-31 Nchain Holdings Ltd. Determining a common secret for the secure exchange of information and hierarchical, deterministic cryptographic keys
US11356280B2 (en) 2016-02-23 2022-06-07 Nchain Holdings Ltd Personal device security using cryptocurrency wallets
JP7083754B2 (ja) 2016-02-23 2022-06-13 エヌチェーン ホールディングス リミテッド スマートコントラクトに基づく自動給与支払方法及びシステムをもたらす、ブロックチェーン上の給与支払に関連付けられた暗号通貨の効率的な転送のための方法及びシステム
US10659223B2 (en) 2016-02-23 2020-05-19 nChain Holdings Limited Secure multiparty loss resistant storage and transfer of cryptographic keys for blockchain based systems in conjunction with a wallet management system
US11410145B2 (en) 2016-02-23 2022-08-09 nChain Holdings Limited Blockchain-implemented method for control and distribution of digital content
US11455378B2 (en) 2016-02-23 2022-09-27 nChain Holdings Limited Method and system for securing computer software using a distributed hash table and a blockchain
JP7164580B2 (ja) 2016-02-23 2022-11-01 エヌチェーン ホールディングス リミテッド ウォレット管理システムと併せたブロックチェーンベースのシステムのための暗号鍵のセキュアなマルチパーティ損失耐性のある記憶及び転送
JP7164580B6 (ja) 2016-02-23 2022-11-28 エヌチェーン ライセンシング アーゲー ウォレット管理システムと併せたブロックチェーンベースのシステムのための暗号鍵のセキュアなマルチパーティ損失耐性のある記憶及び転送
US11606219B2 (en) 2016-02-23 2023-03-14 Nchain Licensing Ag System and method for controlling asset-related actions via a block chain
US11621833B2 (en) 2016-02-23 2023-04-04 Nchain Licensing Ag Secure multiparty loss resistant storage and transfer of cryptographic keys for blockchain based systems in conjunction with a wallet management system
US11625694B2 (en) 2016-02-23 2023-04-11 Nchain Licensing Ag Blockchain-based exchange with tokenisation
JP7292365B2 (ja) 2016-02-23 2023-06-16 エヌチェーン ライセンシング アーゲー ブロックチェーンからのデータのセキュアな抽出のための暗号方法及びシステム
US11727501B2 (en) 2016-02-23 2023-08-15 Nchain Licensing Ag Cryptographic method and system for secure extraction of data from a blockchain
US11755718B2 (en) 2016-02-23 2023-09-12 Nchain Licensing Ag Blockchain implemented counting system and method for use in secure voting and distribution
JP2019507510A (ja) * 2016-02-23 2019-03-14 エヌチェーン ホールディングス リミテッドNchain Holdings Limited 情報及び階層的で決定性の暗号化鍵のセキュアな交換のための共通秘密の決定
US11936774B2 (en) 2016-02-23 2024-03-19 Nchain Licensing Ag Determining a common secret for the secure exchange of information and hierarchical, deterministic cryptographic keys
US11972422B2 (en) 2016-02-23 2024-04-30 Nchain Licensing Ag Registry and automated management method for blockchain-enforced smart contracts
US12032677B2 (en) 2016-02-23 2024-07-09 Nchain Licensing Ag Agent-based turing complete transactions integrating feedback within a blockchain system
US12107952B2 (en) 2016-02-23 2024-10-01 Nchain Licensing Ag Methods and systems for efficient transfer of entities on a peer-to-peer distributed ledger using the blockchain

Also Published As

Publication number Publication date
DE602006002025D1 (de) 2008-09-11
EP1847062B1 (en) 2008-07-30
ES2308725T3 (es) 2008-12-01
US7747865B2 (en) 2010-06-29
CA2596500C (en) 2014-03-25
CA2596500A1 (en) 2006-08-17
ATE403297T1 (de) 2008-08-15
WO2006084896A1 (en) 2006-08-17
US20060179319A1 (en) 2006-08-10
EP1847062A1 (en) 2007-10-24

Similar Documents

Publication Publication Date Title
JP2009526411A (ja) 装置またはネットワークによって相互接続された2当事者間の交換の方法、信号伝送媒体、および装置(チャレンジ・レスポンス署名および高性能で安全なDiffie−Hellmanプロトコルに関する方法および構造)
Krawczyk HMQV: A high-performance secure Diffie-Hellman protocol
JP4384728B2 (ja) 内在的署名を用いた鍵一致及び輸送プロトコル
US7139917B2 (en) Systems, methods and software for remote password authentication using multiple servers
US9571274B2 (en) Key agreement protocol
Cremers et al. One-round Strongly Secure Key Exchange with Perfect Forward Secrecy and Deniability.
JP2001313634A (ja) 通信方法
US20100169658A1 (en) Elliptic curve-based message authentication code
Daniel et al. An efficient eCK secure certificateless authenticated key agreement scheme with security against public key replacement attacks
CN101116281A (zh) 询问-应答签名和安全迪菲-海尔曼协议
US20160352689A1 (en) Key agreement protocol
Abusukhon et al. An authenticated, secure, and mutable multiple‐session‐keys protocol based on elliptic curve cryptography and text‐to‐image encryption algorithm
Yoon et al. A new authentication scheme for session initiation protocol
Farash et al. A provably secure and efficient two‐party password‐based explicit authenticated key exchange protocol resistance to password guessing attacks
Zhao et al. sHMQV: An efficient key exchange protocol for power-limited devices
Krzywiecki et al. Deniable key establishment resistance against eKCI attacks
Yeun Design, analysis and applications of cryptographic techniques
Vesterås Analysis of key agreement protocols
Asbullah et al. A proposed CCA-secure encryption on an ElGamal variant
Shim The risks of compromising secret information
Farash et al. Security of multiple-key agreement protocols and propose an enhanced protocol
Tan Identity-based authenticated multiple key agreement protocol with PKG forward security
Glushachenko Public key cryptosystems and their application in digital signature algorithms
Flores On Provable Security of Entity Authentication Schemes
Luo et al. Secure authentication protocols resistant to guessing attacks

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20100712

A871 Explanation of circumstances concerning accelerated examination

Free format text: JAPANESE INTERMEDIATE CODE: A871

Effective date: 20100712

A975 Report on accelerated examination

Free format text: JAPANESE INTERMEDIATE CODE: A971005

Effective date: 20100727

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20100803

A761 Written withdrawal of application

Free format text: JAPANESE INTERMEDIATE CODE: A761

Effective date: 20100902