JP4750274B2 - 鍵共有攻撃防御方法 - Google Patents

Description

この発明は、暗号化システムに関するものであり、特に、鍵共有攻撃を防止するために、鍵一致プロトコルの改良を行ったものである。
【０００１】
〔背景技術〕
鍵の設定は、複数の主体(entities)が共有の秘密鍵を確立するプロセスである。
【０００２】
上記鍵は、例えば機密性やデータの正当性などを目的として、暗号化を行う際に用いられるものである。理想的には、設定された鍵は、両者が面と向かって設定した鍵としての特性を正確に有しているべきものであり、鍵空間から偏りなくランダムに設定されるべきものであり、権利を有していない主体がその鍵について何ら知ることができない（計算上の限界がある）ものであるべきである。
【０００３】
広く言えば、鍵設定プロトコルとしては、鍵輸送(key transport) プロトコルと、鍵一致(key agreement) プロトコルとの２種類の方法が存在する。鍵輸送プロトコルは、第１の主体によって鍵が生成され、この鍵が第２の主体に安全に伝達される方法である。鍵一致プロトコルは、各主体が情報を提供し合って、これらを繋げる(joint) ことによって共有の秘密鍵を設定する方法である。
【０００４】
ここで、ＡおよびＢという２者の誠実な（例えば法律に則った）主体を想定する。両者は、正確にプロトコルのステップを実行するものとする。簡単に言えば、主体Ａが、特別に身元が確認された第２の主体Ｂ以外のものが秘密鍵の値を知ることができないことを確認できる場合には、鍵一致プロトコルは、暗示鍵認証(implicit key authentication) （Ａに対するＢの認証）を供給することになる。なお、暗示鍵認証は、Ａが、Ｂが鍵を実際に有しているかを確認できることが必ずしも必要とされるものではないという特性を有している。関係する両方の主体に対して暗示鍵認証を供給する鍵一致プロトコルは、認証鍵一致プロトコル（ＡＫプロトコル）と呼ばれる。
【０００５】
また、主体Ａが、第２の主体Ｂが実際に計算された一致鍵を有していることを確認できる場合には、鍵一致プロトコルは、明示鍵確認(explicit key confirmation) （Ａに対するＢの確認）を供給する、と言われる。また、Ａが、Ｂが一致鍵を計算することができることを確認できる場合には、鍵一致プロトコルは、暗示鍵確認(implicit key authentication) を供給する、と言われる。暗示鍵確認は、明示鍵確認よりもＡに対する保証が強くなるが（特に、前者が後者を含む場合）、全ての実際の目的に対して、実際には保証を同等とすることができる。これは、Ｂは、明示鍵確認プロセスの後に、即座にその鍵を削除することが可能であるからである。
【０００６】
暗示鍵認証（Ａに対するＢの認証）と（暗示または明示）鍵確認（Ａに対するＢの確認）との両方が供給されるならば、鍵設定プロトコルは明示鍵認証（Ａに対するＢの認証）を供給すると言われる。関係する両方の主体に対して明示鍵認証を供給する鍵一致プロトコルは、鍵確認を伴う認証鍵一致プロトコル（ＡＫＣプロトコル）と呼ばれる。
【０００７】
ＡＫプロトコルまたはＡＫＣプロトコルに対する、未知の鍵共有攻撃（ＵＫＳ攻撃(unknown key-share attack)）は、主体Ａが、Ａが認識していない（例えば、Ａが、Ｂではない主体Ｅと鍵を共有していると信じている場合など）うちに、主体Ｂに対して鍵の共有が強制されることによって行われる。なお、ＡＫプロトコルまたはＡＫＣプロトコルがＵＫＳ攻撃に屈してしまうとしても、これらのプロトコルの暗示鍵認証特性が否定されるものではない。これは、定義によれば、暗示鍵認証の供給は、Ａがそのプロトコルによって誠実な主体（Ｅではない）と関係する場合を前提としたものとなっているからである。
【０００８】
station-to-station（ＳＴＳ）プロトコルは、Diffie-Hellmanの方式を基本にしたＡＫＣプロトコルであり、（相互）暗示鍵認証と（相互）鍵確認との両方を供給するプロトコルを意味している。また、このＳＴＳプロトコルは、さらに、所望とする安全性の特性、例えば秘密事項の転送や鍵の妥協(key compromise)によるなりすまし(impersonation) などに対する安全性の特性を有するようになっている。W. Diffie et al., “Authentication and authenticated key exchanges”, Designs, Codes and Cryptography, 2 (1992) 107-125 には、ＳＴＳの２つの主要な変形例が示されている。１つは、鍵確認が、ＭＡＣアルゴリズム（ＳＴＳ−ＭＡＣ）による一致鍵Ｋを用いることによって供給されるものであり、もう１つは、Ｋが暗号化方式（ＳＴＳ−ＥＮＣ）によって用いられるものである。ＳＴＳ−ＭＡＣは、多くの実際の場面において、ＳＴＳ−ＥＮＣよりも好ましいものとなっている。また、ＳＴＳ−ＥＮＣによって、鍵確認を供給するための暗号化を行うと、信用度が低くなる。これは、暗号化方式の目的は、機密性を供給するものであり、鍵の所有を検証するための認証機構ではないからである。ＳＴＳ−ＥＮＣが、ＳＴＳ−ＭＡＣよりも有利である点は、ＳＴＳ−ＥＮＣが、匿名性の供給を容易にすることができることである。
【０００９】
ＳＴＳに関連した多くのプロトコルが文献に出現している。しかしながら、これらのプロトコルは、ＳＴＳの小さな変形例(minor variants)であるとみなすことができないものであることに注意すべきである。
【００１０】
明瞭にすることを目的として、最初に、以降の説明において用いる表記を次のように概説しておく。
Ａ，Ｂ 誠実な主体
Ｅ 攻撃者
Ｓ_A 署名方式ＳによるＡの（個人）署名鍵
ＰＡ ＳによるＡの公開照合鍵
Ｓ_A （Ｍ） メッセージＭにおけるＡの署名
Ｃｅｒｔ_A Ａの名前、公開署名鍵ＰＡ、およびその他情報を含んだ証明書
Ｅ_K （Ｍ） 鍵Ｋによる対称鍵暗号化方式を用いた、Ｍの暗号
ＭＡＣ_K （Ｍ） 鍵Ｋに基づくメッセージ認証コード
Ｇ，α，ｎ Diffle-Hellmanパラメータ；αは、有限群Ｇの首位の位数(prime order) ｎの要素
ｒＡ Ａの、短命(ephemeral) Diffle-Hellman個人鍵；１≦ｒＡ≦ｎ−１
Ｋ 短命Diffle-Hellman共有秘密；Ｋ＝α^rArB
２つのＳＴＳ変形例を以下に示す。これらの記述において、Ａを開始者(initiator) と呼び、Ｂを応答者(responder) と呼ぶことにする。
【００１１】
〔ＳＴＳ−ＭＡＣプロトコル〕
以下に、ＳＴＳ−ＭＡＣプロトコルについて説明する。開始者Ａがランダムな秘密の整数ｒＡ（１≦ｒＡ≦ｎ−１）を選択し、Ｂに対してメッセージ（１）を送信する。（１）を受信すると、Ｂは、ランダムな秘密の整数ｒＢ（１≦ｒＢ≦ｎ−１）を選択し、共有秘密Ｋ＝α^rArBを計算し、Ａに対してメッセージ（２）を送信する。（２）を受信すると、Ａは、Ｂの署名鍵ＰＢの認証を検証するためにＣｅｒｔ_B を使用し、メッセージ（α^rB，α^rA）上の署名を検証し、共有秘密Ｋを計算し、Ｓ_B （α^rB，α^rA）のＭＡＣを検証した後に、Ｂに対してメッセージ（３）を送信する。（３）を受信すると、Ｂは、Ａの署名鍵ＰＡの認証を検証するためにＣｅｒｔ_A を使用し、メッセージ（α^rA，α^rB）上の署名を検証し、共有秘密Ｋを計算し、Ｓ_B （α^rA，α^rB）のＭＡＣを検証する。もし、ＡまたはＢにおいて行われる任意の段階のチェックや検証が失敗した場合には、その主体がプロトコルの動作を終了させ、拒絶する。
（１）Ａ→Ｂ Ａ，α^rA
（２）Ａ←Ｂ Ｃｅｒｔ_B ，α^rB，Ｓ_B （α^rB，α^rA），ＭＡＣ_K （Ｓ_B （α^rB，α^rA））
（３）Ａ→Ｂ Ｃｅｒｔ_A ，Ｓ_A （α^rA，α^rB），ＭＡＣ_K （Ｓ_A （α^rA，α^rB））
〔ＳＴＳ−ＥＮＣプロトコル〕
以下に、ＳＴＳ−ＥＮＣプロトコルについて説明する。簡潔に説明するために、ＡおよびＢによって行われるチェックに関しては、以下では省略する。
（１）Ａ→Ｂ Ａ，α^rA
（２）Ａ←Ｂ Ｃｅｒｔ_B ，α^rB，Ｅ_K （Ｓ_B （α^rB，α^rA））
（３）Ａ→Ｂ Ｃｅｒｔ_A ，Ｅ_K （Ｓ_A （α^rA，α^rB））
鍵一致プロトコルに対する未知の鍵共有（ＵＫＳ）攻撃について、より明確に理解するために、ＵＫＳ攻撃によって引き起こされる損害の結果に関する仮想的なシナリオについてここで考えてみる。Ａが銀行の支店であり、Ｂが口座の所有者であると仮定する。銀行の本社によって、口座所有者の口座情報に関する証明書が発行される。電子預金のプロトコルが、ＡＫＣプロトコルによって、銀行の支店に対して鍵の交換を行うためのものであると仮定する。このプロトコルを実行した結果、証明書内の口座番号に対して暗号化された金額が預金される。ここで、暗号化された預金額のメッセージにおいて、さらなる認証が行われなかった場合を仮定する（例えば、帯域幅を節約するためなど）。ここで、上記したＵＫＳ攻撃がうまく行われた場合には、Ｂの口座に代えて、Ｅの口座が作られることになる。
【００１２】
ＡＫＣプロトコルに対するＵＫＳ攻撃は、ＡＫプロトコル（鍵確認を提供しない）に対するＵＫＳ攻撃よりも重大な結果を招くことに注意することが重要である。
【００１３】
ＡＫプロトコルにおいて一致された鍵は、鍵確認なしに用いられることはない。実際、ある基準では、ＡＫプロトコルにおいて一致された鍵の鍵確認を命令する保守的な方法が採用されている。適当な鍵確認が続いて供給される場合には、ＵＫＳ攻撃の企みは検出されることになる。この理由により、上記の仮想的なシナリオ（特に、鍵一致プロトコルが終了した後に行われるさらなる認証がないと仮定した場合）は、ＡＫＣプロトコルが用いられた場合には（鍵確認がすでに供給されているので）現実的なものとなる一方、ＡＫプロトコルが用いられた場合には（鍵確認がまだ供給されていないので）非現実的なものとなる。
【００１４】
応答者に対するＵＫＳ攻撃において、攻撃者Ｅは、例えばＰＥ＝ＰＡというように、Ａの公開鍵ＰＡを自分自身のものとして登録する。ＡがＢにメッセージ（１）を送信したとき、Ｅはそれを横取りし、Ａの身元情報をＥのものとして置き換える。そして、Ｅは、ＢからＡに対するメッセージ（２）を変化させないで送る。最後に、Ｅはメッセージ（３）を横取りし、Ｃｅｒｔ_A をＣｅｒｔ_E に置き換える。ＰＡ＝ＰＥとなっているので、Ｓ_A （α^rA，α^rB）＝ＳＥ（α^rA，α^rB）となる。よって、Ｂは、鍵Ｋを受領し、Ｋは実際にはＡと共有されているにも拘らず、Ｅと共有されていると信じることになる。なお、ＥはＫの値を知ることがないことになっている。この攻撃について以下に説明する。Ａ！→Ｂという符号は、Ａが、Ｂに対してメッセージを送ることを意図しているにも拘らず、攻撃者によって横取りされて、Ｂに送信されていない状態を示している。
（１）Ａ！→Ｂ Ａ，α^rA
（１’）Ｅ→Ｂ Ｅ，α^rA
（２）Ｅ←Ｂ Ｃｅｒｔ_B ，α^rB，Ｓ_B （α^rB，α^rA），ＭＡＣ_K （Ｓ_B （α^rB，α^rA））
（２’）Ａ←Ｅ Ｃｅｒｔ_B ，α^rB，Ｓ_B （α^rB，α^rA），ＭＡＣ_K （Ｓ_B （α^rB，α^rA））
（３）Ａ！→Ｂ Ｃｅｒｔ_A ，Ｓ_A （α^rB，α^rA），ＭＡＣ_K （Ｓ_A （α^rB，α^rA））
（３’）Ｅ→Ｂ Ｃｅｒｔ_A ，Ｓ_A （α^rB，α^rA），ＭＡＣ_K （Ｓ_A （α^rB，α^rA））
同様に、主体Ｅは、Ｂの公開鍵ＰＢを自分自身のものとして登録することによって、開始者Ａに対してＵＫＳ攻撃を行うことができる。この攻撃について以下に説明する。
（１）Ａ→Ｅ Ａ，α^rA
（１’）Ｅ→Ｂ Ｅ，α^rA
（２）Ａ←！Ｂ Ｃｅｒｔ_B ，α^rB，Ｓ_B （α^rB，α^rA），ＭＡＣ_K （Ｓ_B （α^rB，α^rA））
（２’）Ａ←Ｅ Ｃｅｒｔ_E ，α^rB，Ｓ_B （α^rB，α^rA），ＭＡＣ_K （Ｓ_B （α^rB，α^rA））
（３）Ａ→Ｅ Ｃｅｒｔ_A ，Ｓ_A （α^rB，α^rA），ＭＡＣ_K （Ｓ_A （α^rB，α^rA））
（３’）Ｅ→Ｂ Ｃｅｒｔ_A ，Ｓ_A （α^rB，α^rA），ＭＡＣ_K （Ｓ_A （α^rB，α^rA））
新しいオンラインＵＫＳ攻撃について説明するにあたって、次のような仮定を設けることにする。第１に、ＳＴＳにおいて用いられる署名方式Ｓが、次のような２つの署名鍵を選択する特性を有していると仮定する。ＰＡ（Ａの公開鍵）、および、メッセージＭにおけるＡの署名Ｓ_A が知られているとする。この場合、攻撃者は、Ｓ_A がメッセージＭにおけるＥの署名となっている鍵の組（ＰＥ；ＳＥ）を選択することが可能となっている。
【００１５】
第２に、Ｅは、ＳＴＳプロトコルが実行されている際に証明された公開鍵を得ることができる。この仮定は、例えば、メッセージの移動における遅延が通常である場合や、ＣＡがオンラインとなっている場合などにおいて、ありがちなことである。
【００１６】
この応答者に対する新しいＵＫＳ攻撃は、前記した、応答者に対する公開鍵代理攻撃と同様のものとなっている。Ａがメッセージ（３）を送った後に、Ｅはそれを横取りし、ＳＥ（α^rA，α^rB）＝Ｓ_A （α^rA，α^rB）というように、用いられている署名方式における鍵の組（ＰＥ；ＳＥ）を選択する。その後、ＥはＰＥに対する証明書Ｃｅｒｔ_E を入手し、メッセージ（３’）をＢに送信する。
【００１７】
この開始者に対する新しいＵＫＳ攻撃は、前記した、開始者に対する公開鍵代理攻撃と同様のものとなっている。Ｂがメッセージ（２）を送った後に、Ｅはそれを横取りし、ＳＥ（α^rB，α^rA）＝Ｓ_B （α^rB，α^rA）というように、用いられている署名方式における鍵の組（ＰＥ；ＳＥ）を選択する。その後、ＥはＰＥに対する証明書Ｃｅｒｔ_E を入手し、メッセージ（２’）をＢに送信する。
【００１８】
オンラインＵＫＳ攻撃では、攻撃者は、選択されている公開鍵ＰＥに相当する個人鍵ＳＥを知っている。よって、公開鍵代理攻撃の場合とは異なり、証明プロセスにおいて、主体が、公開鍵に相当する個人鍵を所有しているという証明書発行の権利を証明することを必要とすることによっては、このオンライン攻撃を防ぐことはできない。
【００１９】
出願人は、ＳＴＳプロトコルが安全に対して欠如している特性を有していることを発見した。それは、未知の鍵共有攻撃を最小にするために、ＳＴＳプロトコルが有していることが望まれるものである。
【００２０】
〔発明の開示〕
本発明の総体的な特徴としては、オンラインＵＫＳ攻撃を防ぐために、署名されたメッセージにおけるフローナンバー(flow number) とともに、送信者と受信者との身元情報を含んだステップが、鍵一致プロトコルにおいて備えられていることである。
【００２１】
本発明の１つの特徴としては、応答者に対するオンラインＵＫＳ攻撃を最小にするために、第１のフロー(first flow)において、証明書Ｃｅｒｔ_A を送る主体Ａのうちの一者が、ＳＴＳ−ＭＡＣプロトコルにおいて備えられていることである。
【００２２】
本発明の他の特徴としては、明示ではなく、暗示鍵確認のステップが備えられていることである。
【００２３】
本発明のさらに他の特徴としては、署名されたメッセージではなく、鍵導出関数において主体の身元情報が含まれていることである。
【００２４】
本発明のさらに他の特徴としては、ＳＴＳ−ＥＮＣおよびＳＴＳ−ＭＡＣプロトコルによるアプリケーションが備えられていることである。
【００２５】
本発明の好適な実施形態に係る上記の特徴およびその他の特徴は、添付図面を参照した次の詳細な説明で明白になるであろう。
【００２６】
〔発明の実施における好適な形態〕
図１に示すように、電子通信システム１０は、通信経路１６によって接続されている送信者１２および受信者１４で示されているＡおよびＢの２つの通信者を有している。通信者１２および１４のそれぞれは、情報処理および経路１６を通しての情報の移動の準備を行う暗号化ユニット１８および２０を有している。第３の主体２２は攻撃者として説明される。
【００２７】
鍵設定／一致プロトコルにおいて、本発明の実施形態では、主体同志の間で、次に示すようなメッセージの流れが行われる。
項目１
（１）Ａ→Ｅ Ａ，α^rA
（２）Ａ←Ｂ Ｃｅｒｔ_B ，α^rB，Ｓ_B （２，Ｂ，Ａ，α^rB，α^rA），ＭＡＣ_K （Ｓ_B （２，Ｂ，Ａ，α^rB，α^rA））
（３）Ａ→Ｂ Ｃｅｒｔ_A ，Ｓ_A （３，Ａ，Ｂ，α^rA，α^rB），ＭＡＣ_K （３，Ａ，Ｂ，Ｓ_A （α^rA，α^rB））
従来の技術で説明した、元のＳＴＳ−ＭＡＣプロトコル、および上記のように修正したプロトコルでは、一致鍵Ｋが、明示鍵確認を提供することを目的として、ＭＡＣ鍵として用いられている。受動的な攻撃者(passive adversary) は、Ｋに関する何らかの情報、すなわち、Ｋに基づいて知らされたメッセージのＭＡＣを有している。この攻撃者は、これを用いることによって、Ｋと、鍵空間１からランダムに偏りなく選択された鍵とを区別することが可能となる。ここでの鍵空間は、Ｋ＝｛αⁱ ：１≦ｉ≦ｎ−１｝で示される。また、この方法において、明示鍵確認を供給することによる他の欠点としては、一致鍵Ｋが、ＭＡＣアルゴリズムとは異なる原始的な暗号化方式によって用いられる可能性があることである。これによって、鍵が１つの以上の目的で使われるべきではないという暗号化における基本原理が犯されることになる。
【００２８】
明示ではなく、暗示鍵確認が達成される２つの方法としては、次のようなものがある。
（ｉ）同じ共有秘密からＫ，Ｋ’＝Ｈ（α^rArB）（Ｈは、暗号化ハッシュ関数）の２つの鍵を取り出す。
（ｉｉ）Ｋ’＝Ｈ₁ （α^rArB），Ｋ＝Ｈ₂ （α^rArB）（Ｈ₁ ，Ｈ₂ は、独立したランダムオラクル(oracles) である） の２つの鍵を取り出す。
【００２９】
Ｋは、一致セッション鍵として用いられる一方、Ｋ’は、そのセッションにおけるＭＡＣ鍵として用いられる。この改訂されたプロトコルについて以下に説明する。
項目２
（１）Ａ→Ｅ Ａ，α^rA
（２）Ａ←Ｂ Ｃｅｒｔ_B ，α^rB，Ｓ_B （２，Ｂ，Ａ，α^rB，α^rA），ＭＡＣ_K'（Ｓ_B （２，Ｂ，Ａ，α^rB，α^rA））
（３）Ａ→Ｂ Ｃｅｒｔ_A ，Ｓ_A （３，Ａ，Ｂ，α^rA，α^rB），ＭＡＣ_K'（３，Ａ，Ｂ，Ｓ_A （α^rA，α^rB））
署名されたメッセージに主体の身元情報が含まれる代わりに、共有秘密α^rArBから共有鍵を導出することを目的として、鍵導出関数の中に、それらが含まれることになる。項目１におけるプロトコルでは、共有鍵はＫ＝Ｈ（α^rArB，Ａ，Ｂ）となるが、項目２におけるプロトコルでは、共有鍵は、Ｋ，Ｋ’＝Ｈ（α^rArB，Ａ，Ｂ）、および（ｉｉ）Ｋ’＝Ｈ₁ （α^rArB，Ａ，Ｂ），Ｋ＝Ｈ₂ （α^rArB，Ａ，Ｂ）となる。
【００３０】
しかしながら、鍵導出関数は、暗号化の世界において良く研究されていないので、鍵導出関数において所望とされる特性がまだ特定されていない。よって、項目１および２において示したプロトコルは、鍵導出関数に身元情報が含まれる変形例においても好ましく用いることができる。
【００３１】
項目２によるプロトコルは、暗示鍵確認を提供している。ほかの主体が実際に共有鍵Ｋを計算したという保証がない場合には、それぞれの主体は、他の主体が共有秘密α^rArBを計算したという保証を得ることができる。ＭＡＣがフローの中に含まれていない場合には、暗示鍵確認がさらに（いくらか低い程度で）供給されることになる。この改訂されたプロトコルを以下に示す。
項目３
（１）Ａ→Ｂ Ａ，α^rA
（２）Ａ←Ｂ Ｃｅｒｔ_B ，α^rB，Ｓ_B （２，Ｂ，Ａ，α^rB，α^rA）
（３）Ａ→Ｂ Ｃｅｒｔ_A ，Ｓ_A （３，Ａ，Ｂ，α^rA，α^rB）
オンラインＵＫＳ攻撃は、ＳＴＳ−ＥＮＣに対しては実行することができない。これは、署名Ｓ_A （α^rA，α^rB）および署名Ｓ_B （α^rB，α^rA）が、攻撃者に知られていないからである。しかしながら、予防策として、フローナンバーおよび送信者と意図されている受信者との身元情報が、署名されたメッセージに含まれるようにするか、上記の鍵導出関数に身元情報が含まれるようにするというような修正を行うことが好ましい。
【００３２】
発明の詳細な説明の項においてなされた具体的な実施態様または実施例は、あくまでも、本発明の技術内容を明らかにするものであって、そのような具体例にのみ限定して狭義に解釈されるべきものではなく、本発明の精神と次に記載する特許請求事項との範囲内で、いろいろと変更して実施することができるものである。例えば、ＳＴＳ−ＭＡＣに関して複数の項目を記載したが、これらは、ＳＴＳ−ＥＮＣに関しても同様に定義されうるものである。さらに、これらは、例えば楕円曲線群のような他の群に適用することも可能である。
【図面の簡単な説明】
【図１】 データ通信システムの概要を示すブロック図である。

Claims (18)

1. 第１の通信者と第２の通信者との間で共通の共有鍵を確立する方法であって、
   該第１の通信者は、該第１の通信者の秘密情報とそれに対応する公開情報とを有し、該第２の通信者は、該第２の通信者の秘密情報とそれに対応する公開情報とを有し、該第１の通信者および該第２の通信者のそれぞれは、メッセージを送信および受信することが可能な暗号化ユニットを含み、
   該方法は、
   該第１の通信者の該暗号化ユニットが、第１のメッセージを該第２の通信者に送信するステップであって、該第１のメッセージは、該第１のメッセージの一部分の署名を含み、該第１のメッセージの該一部分は、該第１の通信者および該第２の通信者のそれぞれの身元および公開情報を含み、該第１のメッセージの該一部分の該署名は、該第１の通信者を認証するために、該第２の通信者によって検証可能である、ステップと、
   該第２の通信者の該暗号化ユニットが、第２のメッセージを該第１の通信者に送信するステップであって、該第２のメッセージは、該第２のメッセージの一部分の署名を含み、該第２のメッセージの該一部分は、該第１の通信者および該第２の通信者のそれぞれの身元および公開情報を含み、該第２のメッセージの該一部分の該署名は、該第２の通信者を認証するために、該第１の通信者によって検証可能である、ステップと、
   該第１の通信者の該暗号化ユニットが、該第１の通信者の該秘密情報と該第２の通信者の該公開情報とを用いて、該共有鍵を構成し、該第２の通信者の該暗号化ユニットが、該第２の通信者の該秘密情報と該第１の通信者の該公開情報とを用いて、該共有鍵を構成するステップと
   を含む、方法。
2. 前記第１のメッセージの前記一部分および前記第２のメッセージの前記一部分の中にフローナンバーを設けるステップをさらに含む、請求項１に記載の方法。
3. オペレーションは、ＳＴＳ−ＭＡＣプロトコルに基づている、請求項１または２に記載の方法。
4. 前記第１の通信者が、第１のフローにおいて、公開鍵に対する証明書を第２の通信者に送信するステップをさらに含む、請求項１〜３のいずれか一項に記載の方法。
5. オペレーションは、ＳＴＳ−ＥＮＣプロトコルに基づいている、請求項１または２に記載の方法。
6. 前記第１のメッセージおよび前記第２のメッセージのそれぞれは、メッセージ認証コード（ＭＡＣ）を含み、該ＭＡＣは、フローナンバーを含む、請求項１〜５のいずれか一項に記載の方法。
7. 第１の通信者と第２の通信者との間での情報の交換を安全化するために用いられる共通の共有鍵を確立する方法であって、該第１の通信者および該第２の通信者のそれぞれは、メッセージを送信および受信することが可能な暗号化ユニットを含み、
   該方法は、
   該第１の通信者の該暗号化ユニットが、該第１の通信者の秘密情報とそれに対応する公開情報とを生成するステップと、
   該第１の通信者の該暗号化ユニットが、該第１の通信者の該公開情報を該第２の通信者に対して利用可能にするステップと、
   該第２の通信者の該暗号化ユニットが、該第２の通信者の秘密情報とそれに対応する公開情報とを生成するステップと、
   該第２の通信者の該暗号化ユニットが、該第２の通信者の該公開情報を該第１の通信者に対して利用可能にするステップと、
   該第１の通信者の該暗号化ユニットが、鍵導出関数を用いて、該第１の通信者の該秘密情報と、該第２の通信者の該公開情報とを組み合わせることにより、共有の秘密を生成し、該共有の秘密と、該第１の通信者の身元と、該第２の通信者の身元とを組み合わせることにより、該共有鍵を生成するステップと、
   該第２の通信者の該暗号化ユニットが、該鍵導出関数を用いて、該第２の通信者の該秘密情報と、該第１の通信者の該公開情報とを組み合わせることにより、該共有の秘密を生成し、該共有の秘密と、該第１の通信者の該身元と、該第２の通信者の該身元とを組み合わせることにより、該共有鍵を生成するステップと
   を含む、方法。
8. 前記第１の通信者は、第１のメッセージを前記第２の通信者に送信し、該第１のメッセージは、該第１の通信者の前記公開情報とフローナンバーとを含み、前記第２の通信者は、第２のメッセージを前記第１の通信者に送信し、該第２のメッセージは、該第２の通信者の前記公開情報と別のフローナンバーとを含む、請求項７に記載の方法。
9. オペレーションは、ＳＴＳ−ＭＡＣプロトコルまたはＳＴＳ−ＥＮＣプロトコルのいずれかに基づいている、請求項７または８に記載の方法。
10. 前記第１の通信者および前記第２の通信者のうちの一方が、第１のフローにおいて、公開鍵に対する証明書を該第１の通信者および該第２の通信者のうちの他方に送信することをさらに含む、請求項７〜９のいずれか一項に記載の方法。
11. 前記第１の通信者および前記第２の通信者のうちの前記一方が、メッセージ認証コード（ＭＡＣ）を該第１の通信者および該第２の通信者のうちの前記他方に送信するステップをさらに含み、該ＭＡＣは、フローナンバーを含む、請求項７〜９のいずれか一項に記載の方法。
12. 第１の通信者と第２の通信者との間での情報の交換を安全化するために用いられる共通の共有鍵を確立する方法であって、該第１の通信者は、メッセージを送信および受信することが可能な暗号化ユニットを含み、
    該方法は、
    該第１の通信者の該暗号化ユニットが、該第１の通信者の秘密情報とそれに対応する公開情報とを生成するステップと、
    該第１の通信者の該暗号化ユニットが、該第１の通信者の該公開情報を該第２の通信者に対して利用可能にするステップと、
    該第１の通信者の該暗号化ユニットが、該第２の通信者の暗号化ユニットによって利用可能にされた該第２の通信者の公開情報を受信するステップであって、該第２の通信者の該公開情報は、該第２の通信者の秘密情報に対応する、ステップと、
    該第１の通信者の該暗号化ユニットが、鍵導出関数を用いて、該第１の通信者の該秘密情報と、該第２の通信者の該公開情報とを組み合わせることにより、共有の秘密を生成し、該共有の秘密と、該第１の通信者の身元と、該第２の通信者の身元とを組み合わせることにより、該共有鍵を生成するステップであって、該共有鍵は、該鍵導出関数を用いて、該第２の通信者の該秘密情報と、該第１の通信者の該公開情報とを組み合わせることにより、該共有の秘密を生成し、該共有の秘密と、該第１の通信者の該身元と、該第２の通信者の該身元とを組み合わせることにより、該第２の通信者によって構成可能である、ステップと
    を含む、方法。
13. 前記第１の通信者は、第１のメッセージを前記第２の通信者の暗号化ユニットに送信し、該第１のメッセージは、該第１の通信者の前記公開情報とフローナンバーとを含む、請求項１２に記載の方法。
14. オペレーションは、ＳＴＳ−ＭＡＣプロトコルまたはＳＴＳ−ＥＮＣプロトコルのいずれかに基づいている、請求項１２または１３に記載の方法。
15. 前記第１の通信者が、第１のフローにおいて、該第１の通信者の公開鍵に対する証明書を前記第２の通信者の暗号化ユニットに送信するステップをさらに含む、請求項１２〜１４のいずれか一項に記載の方法。
16. 前記第１の通信者が、メッセージ認証コード（ＭＡＣ）を前記第２の通信者の暗号化ユニットに送信するステップをさらに含み、該ＭＡＣは、フローナンバーを含む、請求項１２〜１４のいずれか一項に記載の方法。
17. 第１の通信者および第２の通信者を含むシステムであって、該第１の通信者および該第２の通信者のそれぞれは、暗号化ユニットを有し、該第１の通信者および該第２の通信者は、請求項１〜１１のいずれか一項に記載のステップを実行するように構成されている、システム。
18. 請求項１２〜１６のいずれか一項に記載のステップを実行するように構成された暗号化ユニットを有する電子通信デバイス。

Images