JP2002514841A

JP2002514841A - 認証鍵一致プロトコル

Info

Publication number: JP2002514841A
Application number: JP2000547728A
Authority: JP
Inventors: ブレイク−ウィルソン，シモン; ジョンソン，ドナルド，ビー．; メネゼス，アルフレッド
Original assignee: サーティコムコーポレーション
Priority date: 1998-05-01
Filing date: 1999-05-03
Publication date: 2002-05-21
Also published as: DE69928519D1; AU3590299A; EP1075746A1; WO1999057844A1; EP1075746B1; DE69928519T2

Abstract

(57)【要約】ディジタルデータ通信システムにおける、一組の主体ｉとｊとの間の鍵一致方法であって、主体(entity)ｉおよびｊのそれぞれは、個人鍵(private key) およびそれに対応する公開鍵(public key)ペアであるＳ(i) Ｐ(i) とＳ(j)Ｐ(j) とを持っており、上記のシステムは、１つの群の要素を生成するための広域のパラメータをもっている鍵一致方法において、（ａ）主体ｉが、ランダムな個人セッション値(private session value) Ｒ(i) を選択し、（ｂ）上記個人セッション値Ｒ(i) に相当する公開セッション値(public session value)を上記主体ｊに転送し、（ｃ）主体ｊが、第１の関数Ｈ₁を利用し、主体ｉの公開鍵とｊの個人鍵とから導かれる長い句の共有秘密鍵(long term shared secret key) ｋ’を算出し、（ｄ）上記主体ｊは、上記鍵ｋ’を利用し、主体の身元ｉ、ｊと主体の公開セッション鍵とに関する認証メッセージ(authenticated message) を算出し、上記認証メッセージを主体ｉへ転送し、（ｅ）上記主体ｉが、上記認証メッセージを確認し、（ｆ）上記主体ｉが、上記第１の関数Ｈ₁に従って、上記主体ｊの公開鍵と主体ｉの個人鍵とから導かれる上記長い句の共有秘密鍵ｋ’を算出し、（ｇ）上記主体ｉは、上記長い句の共有秘密鍵ｋ’を利用し、上記主体ｉおよびｊの身元情報と上記公開セッション鍵とに関する認証メッセージを算出し、上記認証メッセージを上記主体ｊへ転送し、（ｈ）主体ｊは、上記受け取られた認証メッセージを確認し、（ｉ）上記主体ｉおよびｊの両方が、上記認証メッセージを確認し、各々のセッション公開鍵と個人鍵とを利用する短い句(short term)の共有秘密鍵の算出を行うように設定されているステップを含む鍵一致方法。

Description

【発明の詳細な説明】

本発明は、暗号システム、特に、暗号システムに用いられる認証鍵一致(authe
nticated key agreement) プロトコルに関するものである。

【０００１】鍵一致の問題は、２つの主体が、分散型のネットワーク(distributed network
) を通じて、秘密状態で鍵の情報を一致させたいときに生じる。。鍵一致の問題
の解決法では、有限群でのDiffie-Hellman問題によって安全性を確保しているも
のが、広範囲で使用されている。

【０００２】仮に、主体ｉが、主体ｊと秘密鍵の情報（secret keying information)を一致
させることを望んでいるとする。それぞれの側(each party)は、ｉおよびｊ以外
の誰も、鍵の情報を算出できないという保証を望む。これを認証鍵一致（authen
ticated key agreement;ＡＫ）問題と呼ぶ。この問題は、一致させる鍵の主体を
選ばない場合の鍵一致問題より、明らかに難しい問題である。なぜなら、この問
題では、ｉが、鍵はｊ以外の誰とも共用されないことを保証するためである。

【０００３】ＡＫ問題を解決するために、Diffie-Hellman問題に関する手法がいくつか提案
されている。しかしながら、多くの場合、目的の達成を実証できそうな、実用的
な解決策はなく、このような不具合は、欠陥のあるプロトコルの使用に結びつい
ている。

【０００４】ＡＫ問題においては、ｉは、ただｊのみがその鍵を算出できることを望んでい
るだけであって、ｊが実際にその鍵を算出することを望んでいる訳ではないので
、解決方法は、暗黙の（鍵）認証（implicit (key) authentication)を供給する
ことであるとよく言われている。この他に、もし、ｊが一致鍵を実際に算出した
ことを、ｉが確かめたい場合には、いわゆる明白な証明（explicit authenticat
ion ）を示すために、鍵一致プロトコルに鍵確認(key confirmation)が組み込ま
れる。その場合の目的は、鍵確認を伴った認証鍵一致（authenticated key conf
irmation; ＡＫＣ）と呼ばれるものである。鍵確認は、ｉが本当にｊと通信して
いるという保証を、本質的に加えるものである。このようにして、鍵確認の目的
は、Diffie-Hellmanにおいて定義されたような主体の証明(entity authenticati
on) の目的と一致する。しかしながら、もっと正確にいうと、ＡＫＡプロトコル
に主体の認証を組み込むことは、ｊが実際にその鍵を算出したという強い保証よ
りも、むしろ、ｊがその鍵を算出できるという付加的な保証を、ｉに供給するこ
とになる。

【０００５】区別可能な多種類の攻撃が、従来の方法(schemes) に対して提案されていた。
これには、プロトコルの耐えうるべき主要な攻撃が２つあった。１つ目は、消極
的な攻撃であり、プロトコルを実行し、プロトコルを実行している正当な主体を
単に観察することによって、攻撃者(adversary) がプロトコルの目的達成を妨害
するというものである。２つ目は、積極的な攻撃であり、メッセージを配列した
り、メッセージを横取りしたり、メッセージに応答したり、メッセージを変更し
たりするなどの何らかの可能な方法で、攻撃者が通信自体を破壊するというもの
である。

【０００６】攻撃者は、合理的にみて、分散型ネットワークの中でこれらの能力をもってい
ると想定される。したがって、消極的攻撃、積極的攻撃の両方に耐えうることは
、安定したプロトコルにとって欠かせない。

【０００７】それゆえ、上記した攻撃の強みの少なくとも１部を緩和する鍵一致プロトコル
を供給することが望まれている。

【０００８】［発明の要約］ディジタルデータ通信システムにおける、一組の主体ｉとｊとの間の鍵一致方
法であって、主体(entity)ｉおよびｊのそれぞれは、個人鍵(private key) およ
びそれに対応する公開鍵(public key)ペアであるＳ(i) Ｐ(i) とＳ(j) Ｐ(j) と
を持っており、上記のシステムは、１つの群の要素を生成するための広域のパラ
メータをもっている鍵一致方法において、（ａ）主体ｉが、ランダムな個人セッション値(private session value) Ｒ(i
) を選択し、（ｂ）上記個人セッション値Ｒ(i) に相当する公開セッション値(public sess
ion value)を上記主体ｊに転送し、（ｃ）主体ｊが、第１の関数Ｈ₁を利用し、主体ｉの公開鍵とｊの個人鍵とか
ら導かれる長い句の共有秘密鍵(long term shared secret key) ｋ’を算出し、（ｄ）上記主体ｊは、上記鍵ｋ’を利用し、主体の身元ｉ、ｊと主体の公開セ
ッション鍵とに関する認証メッセージ(authenticated message) を算出し、上記
認証メッセージを主体ｉへ転送し、（ｅ）上記主体ｉが、上記認証メッセージを確認し、（ｆ）上記主体ｉが、上記第１の関数Ｈ₁に従って、上記主体ｊの公開鍵と主
体ｉの個人鍵とから導かれる上記長い句の共有秘密鍵ｋ’を算出し、（ｇ）上記主体ｉは、上記長い句の共有秘密鍵ｋ’を利用し、上記主体ｉおよ
びｊの身元情報と上記公開セッション鍵とに関する認証メッセージを算出し、上
記認証メッセージを上記主体ｊへ転送し、（ｈ）主体ｊは、上記受け取られた認証メッセージを確認し、（ｉ）上記主体ｉおよびｊの両方が、上記認証メッセージを確認し、各々のセ
ッション公開鍵と個人鍵とを利用する短い句(short term)の共有秘密鍵の算出を
行うように設定されているステップを含む鍵一致方法。

【０００９】［好ましい実施の形態の詳細な説明］本発明において用いられている、以下におおまかに示された記号（後述）は、
「New Directions in Cryptography」という表題を付けられたIEEE Transaction
on Information Theory , November 1976 のDiffie-Hellmanの論文を利用して
詳細に説明されており、その文献は、この明細書の参考文献となるものである。

【００１０】図１に示すように、データ通信システム１０は、通信チャンネル１６で接続さ
れている通信側(sender)ｉおよび受信側(recipient) ｊとして設計された一組の
主体(entities)または通信器(correspondents)を含んでいる。各通信器であるｉ
、ｊは、後述する、ディジタル情報を加工し、この情報をチャンネル１６を通じ
て伝達するように整える暗号化ユニットを含んでいる。また、暗号化ユニットは
、専用プロセッサーか、一般的な目的に用いられる計算器をプログラミングする
ための特殊な暗号機能を実行するソフトウェアーを含んでいる、汎用のプロセッ
サーかのどちらかである。

【００１１】以下では、ｋ(i)(j)（便宜上、ｋ(i)(j)は、ｋ_ijを示す）は、ｊの公開値を有
するｉの鍵ペアｋ(i) であり、トラン(tran)は、ｉ、ｊ間で送受信されたメッセ
ージの配列されたセット(ordered set) の転写物であり、一致した鍵である。

【００１２】プロトコルは、倍数的に増加していく群Ｚ^* _p＝｛１，２，..... ，ｐ−１｝（ｐは素数）内の主要な配列（order ）ｑ
の要素αによって生成された下位群(subgroup)における数学的処理(arithmetic
operations) の言葉で記述されている。各々の場合において、主体の秘密値は、
群Ｚ^* _qの要素Ｓ(i) ＝｛１，２，... ，ｑ−１｝であり、対応する公開値は、
Ｐ(i) ＝α^S(i)ＭＯＤ_p ²なるＰ(i) であり、ｉの鍵ペアは、Ｋ_i'＝（Ｓ(i)
，Ｐ(i) ）である（便宜上、Ｓ(i) はＳ_i、Ｐ(i) はＰ_iを示す）。複数のプロ
トコル(protocols) が、何らかの有限群内での数学的処理の言葉で、等しく記述
できるということには注意すべきであり、もちろん、これにより、Diffie-Hellm
an問題に基づく安全性の前提をその群に転換することが必要となる。さらに、プ
ロトコルの特定の実行(particular run)は、セッションと呼ばれているものもあ
る。例えば、プロトコルの実行中に一致した鍵の情報(keying information)はセ
ッション鍵(session key) に属する。プロトコルの実行を形成する個々のメッセ
ージは、フローと呼ばれる。

【００１３】後述するように、プロトコルは、様々な基本命令(primitives)を採用している
。これらの基本命令のうち、使用されている２つの基本命令に、認証子（messag
e authentication codes; ＭＡＣ）とDiffie-Hellman法（Diffie-Hellman schem
es; ＤＨＳ）とがある。もちろん、確認するための他の基本命令を使用すること
を望むアプリケーションがあってもよい。例えば、もし、一致したセッション鍵
を後で暗号に使用するのであれば、ＭＡＣを実行して無駄に時間を使うよりもむ
しろ、鍵の確認をするための暗号方法(encryption schemes)を採用することの方
が目的にかなっていると思われる。

【００１４】図２に、本発明にかかるＡＫＣプロトコル（プロトコル１）の第１の実施形態
を示すグラフ表示を、符号２２によって概して示す。ここでは、ランダムに独立
して選択された要素を∈_Rで示し、連鎖内の固有の符号化(unique encoding thr
ough concatenation) （または、どれか他の固有の符号化）をコンマ（commas）
で示している。Ｈ₁とＨ₂とは、独立したランダムオラクルを表しており、（ｐ
，ｑ，α）は、全体のパラメータである。ランダムオラクルは、以下の方法での
コイントスの言葉で定義されてもよい。すべての側(party) に、ブラックボック
スのランダム関数Ｈ( ・ ) :｛0,1 ｝^k→｛0,1 ｝^kが与えられていると仮定す
る。最初にＨにx という一連の数字を当てはめる(queried) と、Ｈは、Ｈ(x) と
してその最初のｋ回のコイントスに相当する長さｋの一連の数字をもどしてくる
。第２の一連の数字x ’を当てはめると、まず、Ｈは、x とx ’とを比較する。
もし、x ’がｎと等しければ、Ｈは再び最初のｋ回のコイントスＨ(n）をもどし
てくる。それ以外は、Ｈは、Ｈ(x')としてその２回目のｋ回のトスをもどしてく
る。例を挙げると(In instantiations) 、Ｈは、一般的にハッシュ関数Ｈによっ
て表されている。主体(entity)ｉが、主体ｊとＰの実行を開始することを望むと
き、ｉは、ランダムな要素Ｒ(i) ∈_RＺ^* _qを選択し、ｊにα^R(i)を送る。この
一連の数字を受け取って、ｊは、２≦α^R(i)≦ｐ−１、および( α^R(i)) ^q＝１
をチェックし、それから、ｊは、Ｒ(i) ∈_RＺ^* _qを選んで、α^R(j)、およびｋ
'=Ｈ₁（α^S(i)S(j)）を算出する。最後に、ｊは、ＭＡＣ_k(j)（２，ｉ，ｊ，α ^R(j) , α^R(i)）を算出するために、ｋ’を使用して、この認証メッセージ(authe
nticated message) をｉへ送る( ＭＡＣ_k'( ｍ）が、ただのａでなく、ペア（ｍ
，ａ）を表しているのを思い出すべきである）。この一連の数字を受け取って、
ｉは、このメッセージの形が修正されているか否かおよび、２≦α^R(j)≦ｐ−１
および（α^R(j)）^q＝１であることをチェックする。主体ｉは、それから、ｋ’
＝Ｈ₁(α^S(i)S(j)）を算出し、α^S(j)がｊの長い句の公開鍵(long term public
key)であることを思い出して、受けとられた認証メッセージが適切であることを
確認する。認証メッセージが適切であることを確認したら、ｉはメッセージを受
け取って、ｊに、ＭＡＣ_k(j)( ３，ｉ，ｊ，α^R(i), α^R(j)）を送り返す。この
一連の数字を受け取って、ｊは、メッセージの形式をチェックして、認証メッセ
ージが適切であることを確認し、受け取る。両方の側は、ｋ＝Ｈ₂(α^R(i)R(j))
である一致したセッション鍵を算出する。もし、どれかの段階で、ｉやｊのチェ
ックや立証が失敗したら、その失敗した側はプロトコルの実施を終了させて、拒
絶する。

【００１５】実行する上で、主体ｉは、プロトコル１の最初のフローにその身元(identity)
を付けることを望むこともある。メッセージのレベルではなくパケットレベルで
、関係者の身元を確認することを望むアプリケーションもあるかもしれないので
、本例では、この身元は削除される。この例では、それゆえ、再びｉの身元を確
認することは、不必要である。

【００１６】主体が、プロトコル１における２つの区別できる鍵、つまり確認用の鍵と、次
回使用のためのセッション鍵としてのもう１つの鍵と、を使用することに着目す
べきである。特に、１つ以上の基本命令によって同じ鍵が使用されている場合、
確認鍵およびセッション鍵の両方の役割を果たす同じ鍵を共通として使用するこ
とは、不利な点である。

【００１７】プロトコル１は、主体が長い句の秘密値(long-term secret value)とセッショ
ン特有の秘密値(session-specific secret value) とを用いた方法で提案された
、ほとんどのＡＫＣプロトコルとは異なっている。提案されたほとんどのプロト
コルは、すべての鍵の構成に長い秘密句(long-term secrets) および短い秘密句
(short-term secrets)の両方を使用する。プロトコル１では、長い秘密句および
短い秘密句は、極めて独立した方法で使用される。長い秘密句は、セッション独
立確認鍵(session-independent confirmation key)を形成するためだけに使用さ
れ、短い秘密句は、一致したセッション鍵を形成するためだけに使用される。概
念的には、このアプローチは、伝統的な手法に比して、有利な点と、不利な点と
の両方を有している。良い面は、長い句の鍵および短い句の鍵の使用は別々であ
るため、長い秘密句の鍵の露見（compromise）の影響をはっきりさせるために役
立つことである。長い秘密句の露見は、将来のセッションの安全性に致命的であ
り、直ちに改善されなくてはならない。一方、短い秘密句の露見は、特定のセッ
ションのみに影響する。悪い面は、主体の両方が、プロトコル１における長い句
の共有秘密鍵ｋ’を持ちつづけなければならないことである。

【００１８】［プロトコル２］プロトコル２は、プロトコル１の不利な点のいくつかを処分するように設計さ
れたＡＫＣプロトコルである。図３にグラフで示している。主体ｉおよびｊによ
って行われる行為は、使用される両方の鍵の算出において、主体が、短い句およ
び長い句の値の両方を使用していること以外は、プロトコル１と同様である。特
に、主体は、このセッションのためのＭＡＣ鍵としてｋ’＝Ｈ₂(α^R(i)R(j), α ^S(i)S(j) ）を使用し、一致したセッション鍵として、ｋ＝Ｈ₂(α^R(i)R(j)，α^S( ^i)S(j) ）を使用している。プロトコル１と違い、プロトコル２では、それぞれの
鍵を作るために、両方の長い秘密句および両方の短い秘密句が使用されている。
これは、これらの値のうちの１つの露見の影響を分かりにくくし、さらに、ｉと
ｊとの間の各セッションにおいて、ＭＡＣメッセージに使用された長い句の共用
鍵が無いことも意味している。しかしながら、両者はまだ長い秘密句の値α^S(i) ^S(j) を共用している。この値は、それゆえ、Ｓ(i) Ｓ(j) 自身とともに、露見に
対して、注意深く保護されていなくてはならない。概念的には、プロトコル２に
おけるＡＫ段階と鍵の確認段階とを分離することは可能である。

【００１９】［プロトコル３］図４は、安全なＡＫプロトコルの実施の形態であり、プロトコル３の実施にお
けるｉとｊとによってなされた行為を示している。もし、攻撃者(adversary) が
未確認のセッション鍵を明らかにできるなら、プロトコル３は、安全なＡＫプロ
トコルではないことになるので、以下に示す攻撃に注目しなくてはならない。Ｅ
が、１つはП³ _i,j、もう１つはП^u _i,jを用いる２つのプロトコルを実行しは
じめたとする。П³ _i,jがα^R(i)を送り、П^u _i,jがα^R'(i)を送ると想定する
と、Ｅは、α^R(i)をП^u _i,jへ転送し、α^R'(i)をП^a _i,jへ転送する。ここで
、П^u _i,jによって得られる同一鍵（the (same) key）を明らかにすることによ
り、Ｅは、П³ _i,jによって得られるセッション鍵ｋ＝Ｈ₂(α^R(i)R(j), α^S(i) ^S(j) ) を見つけることができる。

【００２０】このプロトコルでは、認証鍵一致と、鍵の確認とが分離されている時には、注
意しなくてはならない。上記のプロトコル３は、分散型演算(distributed compu
ting) の完全形態(full model)となるＡＫプロトコルではないが、それでもなお
、プロトコル２のように、安全なＡＫＣプロトコルに変えることができる。ここ
で問題(issue) となるのは、確認されていない鍵を攻撃者が学びとれると予期す
ることが現実的であるかどうかである。

【００２１】それゆえ、この説明では、ＡＫとＡＫＣとの目的を分離しようとしている。認
証鍵一致を鍵の確認から分離しようとした理由は、鍵の確認を得るために、ある
特定の実行を、柔軟に選択できるようにするためである。例えば、構成的な考え
（architectural considerations）では、鍵一致と鍵の確認とは分離されている
必要があることもある、つまり、コンピュータネットワークを通じてセッション
鍵を一致させることに続いて、リアルタイムの電話での会話中に、鍵確認を行う
システムがあってもよい。一方、その代わりに、後の通信を暗号化するための鍵
を使用することにより、暗黙のうちに確認が実行されることを好むシステムがあ
ってもよい。

【００２２】ＤＨＳｓによる主要な配列(prime order) の下位群の使用を明白にしている理
由は、鍵が無理やりに、Ｚ^* _pという小さな下位群の中に置かれているかも知れ
ないという事実を利用するＡＫプロトコルに対する、多種多様な既知のセッショ
ン鍵攻撃を避けるためである。安全性の証明の観点から言うと、下位群Ｚ^* _pよ
りも、むしろ、Ｚ^* _p内に定義されたＤＨＳｓについて、同様にうまく仮説を立
てることができた。

【００２３】プロトコル３の場合のように、関係している主体がプロトコルの送信の開始者
あるいはプロトコルの応答者のどちらであるのかを識別するための非対象を、以
前からある多くのＡＫプロトコルが、一致した鍵の形成(formation) の中に、含
んでいることを特に注意するべきである。

【００２４】［プロトコル４］再度、このプロトコルでは、ｉおよびｊの行動を言葉で示すかわりに、これら
の行動を図５に示している。一見すると、プロトコル４は、算出された共有の値
はα^{S(i)R(j)+S(j)R(i)}であり、良く知られているＭＴＩプロトコルとほとんど
同一であるかのように見えるかもしれないが、以下の違いに注目すべきである。
主体ｉは、自身が送信開始者であるか応答者であるかによって、プロトコル４で
異なった鍵を算出する。第１の場合、ｉはｋ＝Ｈ₂(α^S(i)R(j), α^S(j)R(i)) を
算出し、第２の場合、ｋ＝Ｈ₂(α^S(j)R(i), α^S(i)R(j)) を算出している。上記
したように、このような非対称は安全なＡＫプロトコルでは望ましい。もちろん
、こういう非対称はいつも望ましい訳ではない。（ｉが送信開始者であるか応答
者であるかを問わず、ｉが同じ鍵の算出を必要とする特別な環境があるかもしれ
ない。）もし、プロトコル４が実際には安全なＡＫプロトコルであるということを示せ
るなら、プロトコル２と同じ考え方で、安全なＡＫＣプロトコルに変えることが
できる。

【００２５】１つの問題点は、ランダムオラクル(random oracles)Ｈ₁とＨ₂とを、どうや
って証明する(instantiate) かである。ＳＨＡ−１のようなハッシュ関数は、ほ
とんどのアプリケーションに対して十分な安全性を与えるべきである。独立した
ランダムオラクルの証明を与えることは、いろいろな方法で使用される。例えば
、プロトコル１の実行に、以下のものを使用してもよい。

【００２６】Ｈ₁(X):=ＳＨＡ−１(01,X)およびＨ₂(X):=ＳＨＡ−１(10,X) プロトコル２で使用されたランダムオラクルの特に効果的な証明（instantiatio
n ）は、ＳＨＡ−１や、ＲＩＰＥＭＤ−１６０を使うと可能である。８０ビット
のセッション鍵とＭＡＣ鍵とが必要とされていると想定すれば、第１の８０ビッ
トのＳＨＡ−１（α^R(i)R(j), α^S(i)S(j)) は、ｋ’として使用でき、第２の８
０ビットはｋとして使用される。もちろん、こういった効果的な実行は、考えら
れる最高の安全性の保証の証明を提供しないかもしれない。

【００２７】ＡＫＣプロトコルの実行で、バンド幅(bandwidth) を節約することは容易であ
る。フロー２や３で、全ての認証メッセージ（ｍ，ａ）を送るのではなく、両方
のケースで、主体がｍのほとんどを削除することができ、メッセージの余りの部
分を受取人が計算する。

【００２８】アプリケーションによっては、新しいセッション鍵が望まれるたびに、プロト
コルを実行することは好ましくないかもしれない。特にプロトコル２を例を挙げ
て考えると、主体は、Ｈ₂(α^R(i)R(j), α^S(i)S(j), counter)という一致した鍵
を算出することを望んでもよい。

【００２９】だから、新しい鍵が望まれるたびにプロトコル全体を実行するのではなく、ほ
とんどの場合には、回数(counter) を単純に増加させるだけである。そうすると
、主体は、使用しているセッション鍵が新しいものであると確信するために、プ
ロトコル自体を使用するという手段をときどき用いるだけでよい。

【００３０】プロトコル１、２、３では、静的なDiffie-Hellman番号（α₁ ^S(i)S(j)）の場
合には、実行と安全性との理由により、短命な（ephemeral ）Diffie-Hellman番
号（α₂ ^R(i)R(j)）の算出の場合よりも、より大きな（おそらくもっと安全な）
群を使用してもよい。静的な番号（static number ）は、より多く使用されるで
あろうから、もっと大きな群であることが望ましい。静的な番号は、セッション
鍵の算出において処理速度を向上させるために蓄えられていてもよい。

【００３１】なお、最後に、対応する公開値に関して証明書を発行する前に、証明書を使用
してＧ（Ｇが、各主体のための鍵ペアを生成すると仮定すると）を実際に証明す
るには、秘密値に関して知っていることをチェックをすべきである。証明組織（
Certification Hierarchy ）の具体化には、これが賢明な予防であると我々は信
じている。

【００３２】なお、発明を実施するための最良の形態の項においてなした具体的な実施態様
または実施例は、あくまでも、本発明の技術内容を明らかにするものであって、
そのような具体例にのみ限定して狭義に解釈されるべきものではなく、本発明の
精神および次に記載する特許請求の範囲内で、いろいろと変更して実施すること
ができるものである。

【００３３】この明細書のなかで用いられた用語や表現は、説明の用語であって制限ではな
く、そういった用語と表現を使用することにおいて、示され、記載された特徴の
同意語を除外しようとするものではない。しかし、様々な修正はこの発明におけ
る請求の範囲内で可能であることは認められる。

【図面の簡単な説明】

【図１】ディジタルデータ通信システムの概略図である。

【図２】本発明に関する鍵一致プロトコルの実施例である。

【図３】本発明に関する鍵一致プロトコルの実施例である。

【図４】本発明に関する鍵一致プロトコルの実施例である。

【図５】本発明に関する鍵一致プロトコルの実施例である。

───────────────────────────────────────────────────── フロントページの続き (81)指定国ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＣＹ，ＤＥ，ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，ＩＴ，ＬＵ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ，ＣＦ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＧＷ，ＭＬ，ＭＲ，ＮＥ，ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＧＨ，ＧＭ，ＫＥ，ＬＳ，ＭＷ，ＳＤ，ＳＬ，ＳＺ，ＵＧ，ＺＷ)，ＥＡ(ＡＭ，ＡＺ，ＢＹ，ＫＧ，ＫＺ，ＭＤ，ＲＵ，ＴＪ，ＴＭ)，ＡＥ，ＡＬ，ＡＭ，ＡＴ，ＡＵ，ＡＺ，ＢＡ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，ＣＡ，ＣＨ，ＣＮ，ＣＵ，ＣＺ，ＤＥ，ＤＫ，ＥＥ，ＥＳ，ＦＩ，ＧＢ，ＧＤ，ＧＥ，ＧＨ，ＧＭ，ＨＲ，ＨＵ，ＩＤ，ＩＬ，ＩＮ，ＩＳ，ＪＰ，ＫＥ，ＫＧ，ＫＰ，ＫＲ，ＫＺ，ＬＣ，ＬＫ，ＬＲ，ＬＳ，ＬＴ，ＬＵ，ＬＶ，ＭＤ，ＭＧ，ＭＫ，ＭＮ，ＭＷ，ＭＸ，ＮＯ，ＮＺ，ＰＬ，ＰＴ，ＲＯ，ＲＵ，ＳＤ，ＳＥ，ＳＧ，ＳＩ，ＳＫ，ＳＬ，ＴＪ，ＴＭ，ＴＲ，ＴＴ，ＵＡ，ＵＧ，ＵＳ，ＵＺ，ＶＮ，ＹＵ，ＺＡ，ＺＷ (72)発明者メネゼス，アルフレッドカナダ，オンタリオ州エヌ２ジェイ４エス３，ワーテルロー，ウィロウストリート６，アパートメント 1604 Ｆターム(参考） 5J104 AA08 AA16 AA38 AA41 EA04 LA01 NA02 NA03 【要約の続き】の個人鍵とから導かれる上記長い句の共有秘密鍵ｋ’を算出し、（ｇ）上記主体ｉは、上記長い句の共有秘密鍵ｋ’を利用し、上記主体ｉおよびｊの身元情報と上記公開セッション鍵とに関する認証メッセージを算出し、上記認証メッセージを上記主体ｊへ転送し、（ｈ）主体ｊは、上記受け取られた認証メッセージを確認し、（ｉ）上記主体ｉおよびｊの両方が、上記認証メッセージを確認し、各々のセッション公開鍵と個人鍵とを利用する短い句(short term)の共有秘密鍵の算出を行うように設定されているステップを含む鍵一致方法。

Claims

【特許請求の範囲】

【請求項１】ディジタルデータ通信システムにおける、一組の主体ｉとｊとの間の鍵一致方
法であって、主体(entity)ｉおよびｊのそれぞれは、個人鍵(private key) およ
びそれに対応する公開鍵(public key)ペアであるＳ(i) Ｐ(i) とＳ(j) Ｐ(j) と
を持っており、上記のシステムは、１つの群の要素を生成するための広域のパラ
メータをもっている鍵一致方法において、（ａ）主体ｉが、ランダムな個人セッション値(private session value) Ｒ(i
) を選択し、（ｂ）上記個人セッション値Ｒ(i) に相当する公開セッション値(public sess
ion value)を上記主体ｊに転送し、（ｃ）主体ｊが、第１の関数Ｈ₁を利用し、主体ｉの公開鍵とｊの個人鍵とか
ら導かれる長い句の共有秘密鍵(long term shared secret key) ｋ’を算出し、（ｄ）上記主体ｊは、上記鍵ｋ’を利用し、主体の身元ｉ、ｊと主体の公開セ
ッション鍵とに関する認証メッセージ(authenticated message) を算出し、上記
認証メッセージを主体ｉへ転送し、（ｅ）上記主体ｉが、上記認証メッセージを確認し、（ｆ）上記主体ｉが、上記第１の関数Ｈ₁に従って、上記主体ｊの公開鍵と主
体ｉの個人鍵とから導かれる上記長い句の共有秘密鍵ｋ’を算出し、（ｇ）上記主体ｉは、上記長い句の共有秘密鍵ｋ’を利用し、上記主体ｉおよ
びｊの身元情報と上記公開セッション鍵とに関する認証メッセージを算出し、上
記認証メッセージを上記主体ｊへ転送し、（ｈ）主体ｊは、上記受け取られた認証メッセージを確認し、上記主体ｉおよびｊの両方が、上記認証メッセージを確認し、各々のセッショ
ン公開鍵と個人鍵とを利用する短い句(short term)の共有秘密鍵の算出を行うよ
うに設定されているステップを含む鍵一致方法。