(57)【要約】【課題】  自分が行う計算量が少ない依頼計算は、安全性が低かった。【解決手段】  Ｄｉｆｆｉｅ−Ｈｅｌｌｍａｎ公開鍵配送方式を用いて、通信相手と秘密データｙ＿ＡＢを共有する場合に、ｙ＿１ｓｔをｒ＿１ｓｔから依頼計算を用いて求め、ｙ＿Ａを、ｙ＿ｉｎｉｔ＊ｙ＿１ｓｔ  ｍｏｄ  ｐにより生成し、ｙ＿Ａを通信相手に送信する（ステップＳ１０２、Ｓ１０６）。また、ｙ＿ＡＢを、ｒ＿ｉｎｉｔ＋ｒ＿１ｓｔから、依頼計算を用いて求める（ステップＳ１０７、Ｓ１１１）。なお、ｙ＿ｉｎｉｔ＝ｇ＾（ｒ＿ｉｎｉｔ）ｍｏｄ  ｐである。【選択図】  図１
2005086330.tif 000002
【特許請求の範囲】
【請求項１】
通信相手と第１のデータを共有するためのデータ共有方法であって、
第２のデータを第３のデータから依頼計算を用いて求め、
通信相手が第１のデータを求めるための第４のデータを、第２のデータ及び第５のデータから生成し、
通信相手と共有する第１のデータを、第３のデータ及び第７のデータから生成される第６のデータから、依頼計算を用いて求めることを特徴とするデータ共有方法。
【請求項２】
請求項１において、
第２のデータを第３のデータから求めるための依頼計算において、第１の変換により第３のデータから得られる第８のデータを元に、第９のデータを得て、第１の変換に対応する第２の変換を用いて第９のデータから第２のデータを生成し、
第１のデータを第６のデータから求めるための依頼計算において、第３の変換により第６のデータから得られる第１０のデータを元に、第１１のデータを得て、第３の変換に対応する第４の変換を用いて第１１のデータから第１のデータを生成することを特徴とするデータ共有方法。
【請求項３】
請求項１において、
第２のデータは、ｇの第３のデータ乗をｐで除算した剰余であり、
第４のデータは、第２のデータと第５のデータの乗算結果を、ｐで除算した剰余であり、
第１のデータは、第１２のデータの第６のデータ乗をｐで除算した剰余であり、
第６のデータは、第３のデータと第７のデータの加算結果であり、
第５のデータは、ｇの第７のデータ乗をｐで除算した剰余であることを特徴とするデータ共有方法。
【請求項４】
請求項１において、
第２のデータは、第３のデータと楕円曲線上の点Ｐとの乗算結果であり、
第４のデータは、楕円曲線上の第２のデータと楕円曲線上の第５のデータとの加算結果であり、
第１のデータは、第６のデータと楕円曲線上の第１２のデータとの乗算結果であり、
第６のデータは、第３のデータと第７のデータの加算結果であり、
第５のデータは、第７のデータと楕円曲線上の点Ｐとの乗算結果であることを特徴とするデータ共有方法。
【請求項５】
請求項１において、
第１の共有データを求めるための第２のデータ及び第３のデータを、第２の共有データを求めるための第５のデータ及び第７のデータとして用いることを特徴とするデータ共有方法。
【請求項６】
請求項１において、
第２のデータを第３のデータから求めるための依頼計算、及び、第１のデータを第６のデータから求めるための依頼計算を、通信相手に依頼することを特徴とするデータ共有方法。
【請求項７】
請求項１において、
第２のデータを第３のデータから求めるための依頼計算、及び、第１のデータを第６のデータから求めるための依頼計算を、通信相手との間に存在するサーバに依頼することを特徴とするデータ共有方法。
【請求項８】
請求項１において、
第１のデータを元に、通信相手との通信で用いる暗号化鍵を生成することを特徴とするデータ共有方法。
【請求項９】
請求項１から８のいずれか１項のデータ共有方法を実行するためのプログラム。
【請求項１０】
通信相手と第１のデータを共有するためのデータ共有装置であって、
第２のデータを第３のデータから依頼計算を用いて求める依頼計算手段と、
通信相手が第１のデータを求めるための第４のデータを、第２のデータ及び第５のデータから生成する生成手段を有し、
前記依頼計算手段は、通信相手と共有する第１のデータを、第３のデータ及び第７のデータから生成される第６のデータから、依頼計算を用いて求めることを特徴とするデータ共有装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データ共有方法、プログラム、及び、装置に関する。
【背景技術】
【０００２】
ＩＰｖ６の登場により、従来はネットワークに接続することが考えられなかった装置がネットワークに接続する場面が考えられてきた。例えば、インターネットに直接接続可能なエンドユーザ向けディジタルカメラである。
【０００３】
ＩＰｖ６で通信する装置が、ＩＰｓｅｃを用いて暗号通信を行うことを考える。
【０００４】
ＩＰｓｅｃは、インターネット上の２つの装置が他のだれも知らない秘密データを共有し、その秘密データに基づいて暗号化や認証を行うプロトコルであり、通信に際して秘密データやお互いのＩＰｖ６アドレス等を安全に共有する必要がある。秘密データやお互いのＩＰｖ６アドレス等のデータはＳＡ（Ｓｅｃｕｒｉｔｙ  Ａｓｓｏｃｉａｔｉｏｎ）と呼ばれる。ＳＡを安全に共有するプロトコルはＩＫＥ（Ｉｎｔｅｒｎｅｔ  Ｋｅｙ  Ｅｘｃｈａｎｇｅ）と呼ばれ、ＲＦＣ２４０９‘‘Ｔｈｅ  Ｉｎｔｅｒｎｅｔ  Ｋｅｙ  Ｅｘｃｈａｎｇｅ（ＩＫＥ）''において規定されている。ここで、ＳＡを安全に共有するという意味は、意図する相手のみと確実にＳＡを共有するという意味であり、相手を確実に認証することを必要とする。ＩＫＥでは秘密データを共有する方法としてＤｉｆｆｉｅ−Ｈｅｌｌｍａｎ公開鍵配送方式（以下、ＤＨと記す）が使われ、４つの認証方法が規定されている。
【０００５】
ＩＫＥの実行中に行われる処理のうち最も負荷が大きいものが、ＤＨの処理であり、ＤＨの処理の中でも、特に、大きな整数（例えば、１９９０年ごろであれば５１２ビット、最近は１０２４ビット程度が望ましい）のべき乗剰余演算の負荷が大きい。べき乗剰余演算とは、Ａ＝Ｂ＾｛Ｃ｝  ｍｏｄ  Ｄを満たすＡ、つまりＢのＣ乗をＤで除算した剰余Ａを、ＢとＣとＤから求める演算である。なお、Ｋビットの大きさの整数を用いてべき乗剰余演算を計算する場合、Ｋ＋（指数Ｂを２進表現したときの１の個数）−１回の乗算剰余演算が必要である。Ｋが５１２の場合は、平均７６７（＝５１２＋２５６−１）回である。
【０００６】
ＩＰｖ６で通信する装置の中には、前述のエンドユーザ向けディジタルカメラのように必ずしも計算能力が大きいとは限らない装置もありうる。そのような装置がＩＫＥを実行すると数分間もの処理時間を要することがあり、この処理時間を短縮することが課題となっている。なお、ＩＫＥに限らず、ＤＨやＲＳＡ暗号系、ＥｌＧａｍａｌ暗号方式、ＥｌＧａｍａｌ署名方式等の多くの公開鍵暗号がべき乗剰余演算を必要とするので、べき乗剰余演算を効率的に実行することは公開鍵暗号を利用する上で有用である。
【０００７】
なお、このべき乗剰余演算と逆の演算、すなわち、ある法と底のもとで、ある値の指数を求める演算は、離散対数問題と呼ばれ、法が大きい場合の離散対数問題は現実的には解かれないことが、上記の公開鍵暗号の安全性の根拠（の一部）になっている。また、ＤＨを実現するための数学的構造として、有限体上の乗法群（ｍｕｌｔｉｐｌｉｃａｔｉｖｅ  ｇｒｏｕｐ）、あるいは有限体上の楕円曲線を用いることができる。以下では上述の乗法群を例として説明するが、本発明は楕円曲線を用いる場合にも有効である。
【０００８】
ところで、計算能力の小さな装置が計算能力の大きな装置に計算を依頼する方式であって、計算に必要な秘密情報を隠しながら依頼する方法（以下、依頼計算と記す）が、研究・開発されている（非特許文献１、２参照）。
【０００９】
そのような方法の具体例としては、ＲＳＡ暗号の秘密変換（復号あるいは署名生成）が最も典型的である。これは、計算能力の小さな装置（クライアント）が秘密鍵を有し、その秘密鍵を計算能力の大きな装置（サーバ）に明らかにすることなく、秘密鍵を指数とするべき乗剰余演算を依頼する方法である。ＲＳＡ暗号の秘密変換の場合は法が合成数であり、ＤＨの場合は法が素数であるという違いがあるが、どちらも秘密鍵を指数とするべき乗剰余演算である。
【００１０】
これらにおいては、ＲＳＡ暗号の秘密変換を依頼計算する方法が複数提案されており、ＤＨのべき乗剰余演算にも応用可能な方法が含まれる。これらの中のある方法（後述のＲＳＡ−Ｓ１）は、離散対数問題は解けないという前提において、総当たりで破る場合の総当たり回数によってその安全性が評価される。総当たり回数を１０＾２０程度になるようにそのパラメータを定めるとき、ＲＳＡ−Ｓ１は乗算剰余演算を２０回必要とする。
【００１１】
また、ＲＳＡ暗号の秘密変換を依頼計算する方法も提案されている（特許文献１、２参照）。
【００１２】
それらの中には、ＤＨのべき乗剰余演算にも応用可能とされている方法がある。これらの方法は、クライアントが行う計算とサーバが行う計算を並列に実行可能にすることによって、計算能力の格差や通信回線の速度が異なる場合でもトータルの処理時間を最適に短縮可能にする方法であって、クライアントもべき乗剰余演算を行う方法である。従って、総当たりで破る場合の総当たり回数を１０＾２０程度（＝約２＾６７）とすると、クライアントは６７ビット程度の指数を使うべき乗剰余演算を自分で計算しなければならず、乗算剰余演算の回数は平均で約１００回となり、前述のＭＡＴＳＵＭＯＴＯらの方法（ＲＳＡ−Ｓ１）より多い。
【００１３】
また、ＲＳＡ暗号の秘密変換を依頼計算する方法も提案されており、ＤＨにも適用可能とされている（特許文献３参照）。
【００１４】
これらの方法は、秘密変換に必要な秘密情報をいっさい漏らさないことを主目的とし、かつ同様の従来方法よりも処理効率を向上させた方法である。しかし、５１２ビットの場合、クライアントが行う乗算剰余演算は１００回以上になると記載されているので、前述のＭＡＴＳＵＭＯＴＯらの方法（ＲＳＡ−Ｓ１）より多い。
【特許文献１】特開平２−２０４７６８号公報
【特許文献２】特開平３−７２７３７号公報
【特許文献３】特開平６−１９３９３号公報
【非特許文献１】松本勉、加藤光幾、今井秀樹、‘‘秘密を漏らさずにＩＣカードが端末を用いて計算するには、''第１０回情報理論とその応用シンポジウム（１９８７）
【非特許文献２】Ｔｓｕｔｏｍｕ  ＭＡＴＳＵＭＯＴＯ，Ｋｏｋｉ  ＫＡＴＯ，Ｈｉｄｅｋｉ  ＩＭＡＩ，‘‘Ｓｐｅｅｄｉｎｇ  ｕｐ  ｓｅｃｒｅｔ  ｃｏｍｐｕｔａｔｉｏｎｓ  ｗｉｔｈ  ｉｎｓｅｃｕｒｅ  ａｕｘｉｌｉａｒｙ  ｄｅｖｉｃｅｓ，’’Ａｄｖａｎｃｅｓ  ｉｎ  Ｃｒｙｐｔｏｌｏｇｙ−−ＣＲＹＰＴＯ’８８、ｐｐ．４９７５０６，Ｓｐｒｉｎｇｅｒ−Ｖｅｒｌａｇ（１９８８）
【発明の開示】
【発明が解決しようとする課題】
【００１５】
以上の依頼計算方法は、１回のべき乗剰余演算を依頼計算する場合に使える。ところで、ＤＨでは次のようにべき乗剰余演算が２回繰り返される。素数ｐ、生成元ｇを共通パラメータとして用い、エンティティＡとエンティティＢがＤＨを実行するときのプロトコルを、図４を参照しながら説明する。
【００１６】
ステップＳ４０１ＡでエンティティＡは秘密情報ｘ＿Ａを生成する。
【００１７】
ステップＳ４０１ＢでエンティティＢは秘密情報ｘ＿Ｂを生成する。
【００１８】
ステップＳ４０２ＡでエンティティＡはｙ＿Ａ＝ｇ＾（ｘ＿Ａ）ｍｏｄ  ｐを計算し、ステップＳ４０３ＡでエンティティＡはｙ＿ＡをエンティティＢに送る。
【００１９】
ステップＳ４０２ＢでエンティティＢは  ｙ＿Ｂ＝ｇ＾（ｘ＿Ｂ）  ｍｏｄ  ｐを計算し、ステップＳ４０３ＢでエンティティＢは  ｙ＿ＢをエンティティＡに送る。
【００２０】
ステップＳ４０４ＡでエンティティＡはｙ＿ＡＢ＝（ｙ＿Ｂ）＾（ｘ＿Ａ）ｍｏｄ  ｐを計算する。
【００２１】
ステップＳ４０４ＢでエンティティＢはｙ＿ＢＡ＝（ｙ＿Ａ）＾（ｘ＿Ｂ）ｍｏｄ  ｐを計算する。
【００２２】
ここで、ｙ＿ＡＢ＝（ｇ＾（ｘ＿Ｂ））＾（ｘ＿Ａ）ｍｏｄ  ｐ＝ｇ＾（ｘ＿Ａ＊ｘ＿Ｂ）ｍｏｄ  ｐ＝（ｇ＾（ｘ＿Ａ））＾（ｘ＿Ｂ）ｍｏｄ  ｐ＝ｙ＿ＢＡなので、このｙ＿ＡＢ＝ｙ＿ＢＡを共通の秘密データとして用いて、暗号化鍵等を生成する。従って、依頼計算を利用してＤＨを実行する場合は、同じ秘密情報を用いる２回のべき乗乗算演算の依頼計算が行われる。この点を考慮すると、ＤＨに応用した場合には、以下に説明する攻撃に対して弱い可能性がある。
【００２３】
エンティティＡに着目し、エンティティＡがクライアントとして依頼計算プロトコルを実行する場合を考える。具体的な依頼計算方法として、上記の非特許文献２のＰｒｏｔｏｃｏｌ  ＲＳＡ−Ｓ１を取り上げて説明する。クライアントは整数ｘ、ｄ、ｎを有し、ｙ＝ｘ＾ｄ  ｍｏｄ  ｎを求めたい。ｄはクライアントの秘密で、ｎは公開である。ｎのＣａｒｍｉｃｈａｅｌ  Ｆｕｎｃｔｉｏｎをλ（ｎ）と記す。図５を参照しながら説明する。
【００２４】
ステップＳ５０１で、クライアントは、ｄ＝ｆ＿１＊ｄ＿１＋ｆ＿２＊ｄ＿２＋．．．＋ｆ＿Ｍ＊ｄ＿Ｍ（ｍｏｄ  λ（ｎ））となるような整数ベクトルＤ＝［ｄ＿１、ｄ＿２、．．．、ｄ＿Ｍ］とバイナリーベクトルＦ＝［ｆ＿１、ｆ＿２、．．．、ｆ＿Ｍ］をランダムに生成する。ただし、ＭとＬをある整数として、ｄ＿ｉは１以上ｎ未満、Ｆの重み（Ｆの要素ｆ＿１、ｆ＿２、．．．、ｆ＿Ｍのうち値が１である要素の個数）はＬ以下である。なお、上記の式は、ｄをλ（ｎ）で除算した剰余と、ｆ＿１＊ｄ＿１＋ｆ＿２＊ｄ＿２＋．．．＋ｆ＿Ｍ＊ｄ＿Ｍを計算した値をλ（ｎ）で除算した剰余とが等しいことを示す。
【００２５】
ステップＳ５０２で、クライアントはｎとＤとｘをサーバに送る。
【００２６】
ステップＳ５０３で、サーバは、ｚ＿ｉ＝ｘ＾（ｄ＿ｉ）ｍｏｄ  ｎなるＺ＝［ｚ＿１、ｚ＿２、．．．、ｚ＿Ｍ］を計算する。ステップＳ５０４で、サーバは、Ｚをクライアントに送る。
【００２７】
ステップＳ５０５で、クライアントは、以下のようにしてｙ＝ｙ＿Ｍを計算する。すなわち、ｙ＿０＝１とし、ｉ＝１、２、．．．、Ｍに対して、ｆ＿ｉ＝１ならばｙ＿ｉ＝ｙ＿（ｉ−１）＊ｚ＿ｉ  ｍｏｄ  ｎとし、ｆ＿ｉ＝０ならばｙ＿ｉ＝ｙ＿（ｉ−１）とする。これを、ｉ＝１からｉ＝Ｍまで、繰り返す。すなわち、ｙ＿１、ｙ＿２、、、を順次求め、それを繰り返して、ｙ＿Ｍを求める。
【００２８】
このプロトコルの法ｎを素数ｐとするとき、λ（ｎ）＝λ（ｐ）＝ｐ−１となり、ＤＨに応用できる。従って、クライアントは、秘密の指数値ｄ＝ｘ＿Ａのべき乗剰余演算の依頼計算プロトコルを２回実行する。１回目はｙ＿Ａ＝ｇ＾（ｘ＿Ａ）ｍｏｄ  ｐを、２回目はｙ＿ＡＢ＝（ｙ＿Ｂ）＾（ｘ＿Ａ）ｍｏｄ  ｐを求めるための依頼計算プロトコルである。ここで、インターネット上で実行されるＩＫＥにおいてｙ＿ＡはエンティティＢに送られる値なので、攻撃者（インターネット上の第三者あるいは依頼計算のサーバ）はｙ＿Ａの値を得ることが出来ると考えるべきである。すると、そのような攻撃者は、ｙ＿Ａの値と一致するようなＦをＤとＺから総当たりによって求めることが原理的に可能である。現実的な時間では求められないような総当たりの回数になるようにパラメータＭとＬを設定するが、ｙ＿Ａの値が判明している限り、原理的に、Ｆを求める（ｙ＿Ａとなる組み合わせを少なくとも一つ定める）ことが可能である。
【００２９】
ここで、なんらかの手法に基づき、１回目の依頼計算プロトコルを総当たりで破る効率的な攻撃方法が実現する場合を考える。例えば、ＩＫＥで用いられるｐとｇは標準化されているので、多数の異なるｉに対してｇ＾ｉ  ｍｏｄ  ｐを事前計算したテーブルをインターネット上の多数の計算機それぞれが作成しておき、それらが同時並行して総当たりを効率的に実行する新しい分散アルゴリズムが発見されるかもしれない。このような攻撃が実現する場合、同じ指数値と同じＦを使用している限り、Ｄと１回目の依頼計算プロトコルを攻撃して判明したＦとを利用して２回目の依頼計算プロトコルの結果（ｙ＿ＡＢ）を直ちに求めることができるので、ＤＨが破られることになる。なお、２回目の依頼計算プロトコルでは底（ｙ＿Ｂ）の値が毎回異なるので上記のような総当たり攻撃は２回目の依頼計算プロトコル単独に対しては成立しない。
【００３０】
また、上記特許文献１および２の方法では、クライアントのみが知る秘密の指数値を用いてクライアントが自分でべき乗剰余計算を行うが、既に指摘したように総当たりに対する安全性をＲＳＡ−Ｓ１と同程度にした場合、計算量はＲＳＡ−Ｓ１より多い。従って、２回の依頼計算を行うＤＨに適用した場合は、計算量も２倍になり、当初の目的（計算力の小さい装置が負荷の大きな計算を自分で行わないでべき乗剰余演算結果を求める）を満たさない。
【００３１】
また、上記特許文献３は、指数値を一切漏らさないという意味では最も安全だが、計算量が増大する。従って、２回の依頼計算を行うＤＨに適用した場合は、計算量も２倍になり、当初の目的（計算力の小さい装置が負荷の大きな計算を自分で行わないで、べき乗剰余演算結果を求める）を満たさない。
【００３２】
すなわち、本発明が解決しようとする課題は、自分が行う計算量が少ない依頼計算は、安全性が低く、安全性が高い依頼計算は、自分が行う計算量が多いことである。
【００３３】
本発明は、自分が行う計算量と安全性を両立させることにある。
【課題を解決するための手段】
【００３４】
上記課題を解決するために、本出願に関わる第１の発明は、１回目の依頼計算プロトコルで用いるパラメータと２回目の依頼計算プロトコルで用いるパラメータとが独立となるようにパラメータを生成することを特徴とする。
【００３５】
前記第１の発明により、ＤＨを行う際に行われる２回のべき乗剰余計算の依頼計算プロトコルを実行する場合に、前述のような総当たり攻撃に対する耐性を高めることができる。
【００３６】
上記課題を解決するために、本出願に関わる第２の発明は、１回目のＤＨ実行時の１回目の依頼計算プロトコルの結果を、２回目のＤＨ実行時の１回目の依頼計算プロトコルに用いることを特徴とする。
【００３７】
前記第２の発明により、べき乗剰余演算を１回目のＤＨ実行時の依頼計算プロトコルの時にサーバに計算させることができ、クライアントが計算しなくてもすむ。
【００３８】
前記第２の発明により、２回目のＤＨ実行時の１回目の依頼計算プロトコルの総当たり攻撃に対する耐性は、１回目のＤＨ実行時の１回目の依頼計算プロトコルにおける総当たり攻撃に対する耐性と２回目のＤＨ実行時の１回目の依頼計算プロトコルの総当たり攻撃に対する耐性との積となる、つまり、べき乗剰余演算の依頼計算プロトコルを前述のような総当たり攻撃によって２回破る手間となるので、前述のような総当たり攻撃に対する耐性を強めることができる。また、前記第２の発明を３回目以降のＤＨ実行時にも適用することにより、前述のような総当たり攻撃に対する耐性を強めることができる。
【発明の効果】
【００３９】
以上説明したように、秘密情報を明らかにせず計算能力の大きな装置に計算させることができ、本出願に関わる発明によれば、安全性が高く、かつ、自分が行う計算量は少なくて済むという効果が得られる。
【００４０】
特に、１回目の依頼計算時のパラメータと２回目の依頼計算時のパラメータが独立であるので、総当たり攻撃によって１回目の依頼計算が破られた場合でも２回目の依頼計算は破られないので、安全性を確保することができる。
【００４１】
また、ｋ回目のＤｉｆｆｉｅ−Ｈｅｌｌｍａｎ公開鍵配送方式実行時の１回目の依頼計算プロトコルの結果をｋ＋１回目のＤｉｆｆｉｅ−Ｈｅｌｌｍａｎ公開鍵配送方式実行時の１回目の依頼計算プロトコルに作用させることにより、計算能力の小さな装置が計算しなくても済み、総当たり攻撃に対する耐性を強めている。しかも、Ｄｉｆｆｉｅ−Ｈｅｌｌｍａｎ公開鍵配送方式を依頼計算によって実行すればするほど耐性は強くなる。また、ｋ回目までのＤｉｆｆｉｅ−Ｈｅｌｌｍａｎ公開鍵配送方式の依頼計算で使用されたパラメータを全て収集できない場合はｋ＋１回目以降の依頼計算に対して総当たり攻撃が成り立たなくなる。従って、処理時間を増大させることなく安全性を向上させている。
【００４２】
負荷の大きな処理を高速に行う場合は専用のハードウェアを設けることが多いが、本発明により各装置に専用ハードウェアを設けなくてもすむので、各装置の製造コストの上昇を防ぐことができる。
【００４３】
秘密情報を明らかにせずに計算を依頼できるのでインターネットのような安全ではない通信ネットワーク上で依頼計算を行うことが可能であり、制約が少ない。
【発明を実施するための最良の形態】
【００４４】
本形態では、あるノード（ノードＡとする）が別のノード（ノードＢとする）とＩＫＥを用いてＩＰｓｅｃの通信を行う際に、依頼計算サーバ（ノードＳとする）と依頼計算プロトコルを実行することによってＤＨを実行する形態を説明する。
【００４５】
図２は、本形態における接続環境を模式的に示したものである。図２は、ＬＡＮに接続されたホスト２０４、２０５、２０６がｄｅｆａｕｌｔ  ｇａｔｅｗａｙ２０２経由でインターネット２０１にアクセスする環境を示す。本形態では、各ホストはリンク２０７で接続するものとし、具体的にはイーサネット（R)であるとする。リンクとは、それに接続された装置がそれを介して通信することができる設備もしくはメディアであり、ＩＰ層の下側に接する。リンクにはイーサネット（R)の他に、ＰＰＰリンク、Ｘ．２５、フレームリレー、ＡＴＭネットワークがある。リンクに接続されたＩＰｖ６対応装置をノードと呼ぶ。
【００４６】
ノードの内部構成の典型例を図３に示す。ノードには、ルーターとホストがあり、ルーターは自分宛ではないパケットを転送するがホストは転送しない。図３からわかるように、ノードは、ＣＰＵ３０３、ＲＯＭ３０４、ＲＡＭ３０５、ＨＤ（ハードディスク）３０６、ネットワーク・インターフェイス３０１、３０２等を有する計算機であり、ルーターは複数のネットワーク・インターフェイスを持つのに対し、ホストは多くの場合は一つのネットワーク・インターフェイスを持つ。ノードによってはＨＤを持たないものもある。
【００４７】
なお以下の処理内容（手順）は、装置もしくはプログラムとして実現され、その装置を有するノードが実行するもしくはそのプログラムがＲＯＭ３０５もしくはＨＤ３０６に格納されたノードが実行する。例えば、プログラムとして実現される場合は、そのプログラムをＣＰＵ３０３が読み込み、必要に応じてＲＡＭ３０５を計算のための空間として利用しながらバス３１０を介して対象データに対して暗号化の演算を施し暗号文を計算する、というような動作を行う。
【００４８】
図３のノードは、以降、詳細に説明するように、通信相手と第１のデータｙ＿ＡＢを共有するためのデータ共有装置である。
【００４９】
本形態のプロトコルを、図１を参照しながら説明する。以下の説明において、例えば、ノードＡはホスト２０４、ノードＢはホスト２０９である。ノードＳはホスト２０６あるいはｄｅｆａｕｌｔ  ｇａｔｅｗａｙ２０２あるいはインターネット２０１を介して通信できるホスト（図示せず）である。
【００５０】
図１は、クライアントとサーバがＤＨを実行するときに行われる（２回の依頼計算）プロトコルを示す。クライアント（ノードＡ、例えば、図２のホスト２０４）は、秘密情報ｘ＿Ａを有し、ＩＰｓｅｃ通信を行う通信相手（ノードＢ、例えば、図２のホスト２０９）との間で最終的に共有するｙ＿ＡＢ＝（ｙ＿Ｂ）＾（ｘ＿Ａ）ｍｏｄ  ｐと、そのｙ＿ＡＢを求めるために途中で必要なｙ＿Ａ＝ｇ＾（ｘ＿Ａ）ｍｏｄ  ｐを、依頼計算プロトコルを利用して求めたい。ｘ＿Ａはクライアントの秘密で、ｇとｐは公開である。ｐのＣａｒｍｉｃｈａｅｌ  Ｆｕｎｃｔｉｏｎをλ（ｐ）と記す。クライアントはサーバ（ノードＳ、例えば、ホスト２０６）のＩＰアドレスを知っている。
【００５１】
ステップＳ１０１で、クライアント（ホスト２０４）は、乱数ｒ＿ｉｎｉｔとｙ＿ｉｎｉｔ＝ｇ＾（ｒ＿ｉｎｉｔ）ｍｏｄ  ｐを用意する。ｒ＿ｉｎｉｔは、１以上ｐ未満の整数である。図１で説明するプロトコルが過去に実行されている場合、前回計算したｒとｇ＾ｒ  ｍｏｄ  ｐをｒ＿ｉｎｉｔとｙ＿ｉｎｉｔ＝ｇ＾（ｒ＿ｉｎｉｔ）ｍｏｄ  ｐとして利用する。図１で説明するプロトコルが過去に実行されている場合、前回計算したｒとｇ＾ｒ  ｍｏｄ  ｐをＲＡＭ３０５又はＨＤ３０６に記憶しておく。
【００５２】
また、初めてプロトコルを実行する場合は、クライアントは、例えば、製造時に乱数ｒ＿ｉｎｉｔが生成され、計算済みのｙ＿ｉｎｉｔ＝ｇ＾（ｒ＿ｉｎｉｔ）ｍｏｄ  ｐをＲＯＭ３０４又はＨＤ３０６に記録した状態で出荷することとする。あるいは、他の実施例では、待機状態（依頼計算プロトコルを実行していない状態）のときに乱数ｒ＿ｉｎｉｔを生成してｙ＿ｉｎｉｔ＝ｇ＾（ｒ＿ｉｎｉｔ）ｍｏｄ  ｐを計算しておき、その結果をＲＡＭ３０５又はＨＤ３０６に記録しておく。あるいは、更に他の形態では、後述の情報量的に安全な依頼計算プロトコルを、ＩＫＥのための依頼計算（図６で説明するプロトコル）より前にサーバと実行しておく。
【００５３】
ステップＳ１０２で、クライアントはｒ＿１ｓｔ＝ｆ＿１＊ｄ＿１＋ｆ＿２＊ｄ＿２＋．．．＋ｆ＿Ｍ＊ｄ＿Ｍ（ｍｏｄ  λ（ｐ））となるような整数ベクトルＤ＝［ｄ＿１、ｄ＿２、．．．、ｄ＿Ｍ］とバイナリーベクトルＦ＝［ｆ＿１、ｆ＿２、．．．、ｆ＿Ｍ］をランダムに生成する。ただし、ＭとＬをある整数として、ｄ＿ｉは１以上ｐ未満、Ｆの重み（Ｆの要素ｆ＿１、ｆ＿２、．．．、ｆ＿Ｍのうち値が１である要素の個数）はＬ以下である。なお、上記の式は、ｄをλ（ｎ）で除算した剰余と、ｆ＿１＊ｄ＿１＋ｆ＿２＊ｄ＿２＋．．．＋ｆ＿Ｍ＊ｄ＿Ｍを計算した値をλ（ｎ）で除算した剰余とが等しいことを示す。
【００５４】
ステップＳ１０３で、クライアントはｐとＤとｇをサーバに送る。
【００５５】
ステップＳ１０４で、サーバはｚ＿ｉ＝ｇ＾（ｄ＿ｉ）ｍｏｄｐなるＺ＝［ｚ＿１、ｚ＿２、．．．、ｚ＿Ｍ］を計算する。ステップＳ１０５で、サーバはＺをクライアントに送る。
【００５６】
ステップＳ１０６で、クライアントは以下のようにしてｙ＿Ｍを計算する。すなわち、ｙ＿０＝１とし、ｉ＝１、２、．．．、Ｍに対してｆ＿ｉ＝１ならばｙ＿ｉ＝ｙ＿（ｉ−１）＊（ｚ＿ｉ）  ｍｏｄ  ｐとし、ｆ＿ｉ＝０ならばｙ＿ｉ＝ｙ＿（ｉ−１）とする。これを、ｉ＝１からｉ＝Ｍまで、繰り返す。すなわち、ｙ＿１、ｙ＿２、、、を順次求め、それを繰り返して、ｙ＿Ｍを求める。ｙ＿Ｍをｙ＿１ｓｔとする。
【００５７】
そして、クライアントは、ｒ＿１ｓｔとｙ＿１ｓｔ（＝ｇ＾（ｒ＿１ｓｔ）ｍｏｄ  ｐ）をＲＡＭ３０５に記録し、ｙ＿Ａ＝ｙ＿ｉｎｉｔ＊ｙ＿１ｓｔ  ｍｏｄ  ｐとしてｙ＿Ａを求める。このＲＡＭ３０５に記録したｒ＿１ｓｔとｙ＿１ｓｔは、次回に、ｒ＿ｉｎｉｔとｙ＿ｉｎｉｔとして、使用する。
【００５８】
なお、クライアント（ノードＡ、例えば、図２のホスト２０４）はノードＢ（例えば、図２のホスト２０９）とＩＫＥを実行しているので、ｙ＿ＡをノードＢに送り、一方、ｙ＿ＢをノードＢから受け取る（図示せず）。なお、ノードＢは、図４のステップＳ４０１Ｂで説明したようにｙ＿Ｂを計算してもよいが、図１のステップＳ１０１〜Ｓ１０６と同様の手順で、ｙ＿Ｂを求めてもよい。
【００５９】
ステップＳ１０７で、クライアントはｒ＿ｉｎｉｔ＋ｒ＿１ｓｔ＝ｆ＿１’＊ｄ＿１’＋ｆ＿２’＊ｄ＿２’＋．．．＋ｆ＿Ｍ’＊ｄ＿Ｍ’（ｍｏｄ  λ（ｐ））となるような整数ベクトルＤ’＝［ｄ＿１’、ｄ＿２’、．．．、ｄ＿Ｍ’］とバイナリーベクトルＦ’＝［ｆ＿１’、ｆ＿２’、．．．、ｆ＿Ｍ’］をランダムに生成する。ただし、Ｍ’とＬをある整数として、ｄ＿ｉ’は１以上ｐ未満、Ｆ’の重み（Ｆ’の要素ｆ＿１’、ｆ＿２’、．．．、ｆ＿Ｍ’のうち値が１である要素の個数）はＬ以下である。
【００６０】
ステップＳ１０８で、クライアントはｐとＤ’とｙ＿Ｂをサーバに送る。
【００６１】
ステップＳ１０９で、サーバは、ｚ＿ｉ’＝（ｙ＿Ｂ）＾（ｄ＿ｉ’）ｍｏｄ  ｐなるＺ’＝［ｚ＿１’、ｚ＿２’、．．．、ｚ＿Ｍ’］を計算する。ステップＳ１１０で、サーバはＺ’をクライアントに送る。
【００６２】
ステップＳ１１１で、クライアントは以下のようにしてｙ＿Ｍ’を計算する。すなわち、ｙ＿０’＝１とし、ｉ＝１、２、．．．、Ｍに対してｆ＿ｉ’＝１ならばｙ＿ｉ’＝ｙ＿（ｉ−１）’＊（ｚ＿ｉ’）ｍｏｄ  ｐとし、ｆ＿ｉ’＝０ならばｙ＿ｉ’＝ｙ＿（ｉ−１）’とする。これを、ｉ＝１からｉ＝Ｍまで、繰り返す。すなわち、ｙ＿１’、ｙ＿２’、、、を順次求め、それを繰り返して、ｙ＿Ｍ’を求める。ｙ＿Ｍ’をｙ＿２ｎｄとする。求めたｙ＿２ｎｄをｙ＿ＡＢとする（ｙ＿ＡＢ：＝ｙ＿２ｎｄ）。
【００６３】
以上の依頼計算プロトコル２回の実行によってＤＨが１回実行される。次にＤＨを実行する際は、乱数ｒ＿ｉｎｉｔとｙ＿ｉｎｉｔ＝ｇ＾（ｒ＿ｉｎｉｔ）ｍｏｄ  ｐとして今回計算してＲＡＭ３０５に記憶したｒ＿１ｓｔとｙ＿１ｓｔ＝ｇ＾（ｒ＿１ｓｔ）ｍｏｄ  ｐを用いる。
【００６４】
以上のように、図１は、通信相手（ノードＢ）と第１のデータｙ＿ＡＢを共有するためのデータ共有方法を、ＣＰＵ３０３が実行するためのプログラムを示す。
【００６５】
すなわち、上記説明のように、図１では、第２のデータｙ＿１ｓｔを第３のデータｒ＿１ｓｔから依頼計算を用いて求め、通信相手が第１のデータｙ＿ＡＢを求めるための第４のデータｙ＿Ａを、第２のデータｙ＿１ｓｔ及び第５のデータｙ＿ｉｎｉｔから生成する（ステップＳ１０２、Ｓ１０６）。また、通信相手と共有する第１のデータｙ＿ＡＢを、第３のデータｒ＿１ｓｔ及び第７のデータｒ＿ｉｎｉｔから生成される第６のデータｒ＿ｉｎｉｔ＋ｒ＿１ｓｔから、依頼計算を用いて求める（ステップＳ１０７、Ｓ１１１）。
【００６６】
詳細には、第２のデータｙ＿１ｓｔを第３のデータｒ＿１ｓｔから求めるための依頼計算において（ステップＳ１０６、Ｓ１０７）、第１の変換（上述のデータＦを用いた分解）により第３のデータｒ＿１ｓｔから得られる第８のデータＤを元に、第９のデータＺを得て、第１の変換に対応する第２の変換（上述のデータＦを用いた合成）を用いて第９のデータＺから第２のデータｙ＿１ｓｔを生成する。また、第１のデータｙ＿ＡＢを第６のデータｒ＿ｉｎｉｔ＋ｒ＿１ｓｔから求めるための依頼計算において（ステップＳ１０７、Ｓ１１１）、第３の変換（上述のデータＦ’を用いた分解）により第６のデータｒ＿ｉｎｉｔ＋ｒ＿１ｓｔから得られる第１０のデータＤ’を元に、第１１のデータＺ’を得て、第３の変換に対応する第４の変換（上述のデータＦ’を用いた合成）を用いて第１１のデータＺ’から第１のデータｙ＿ＡＢを生成する。
【００６７】
更に詳細には、第２のデータｙ＿１ｓｔは、ｇの第３のデータｒ＿１ｓｔ乗をｐで除算した剰余であり、第１のデータｙ＿ＡＢは、第１２のデータｙ＿Ｂの第６のデータｒ＿ｉｎｉｔ＋ｒ＿１ｓｔ乗をｐで除算した剰余である。また、第４のデータｙ＿Ａは、第２のデータｙ＿１ｓｔと第５のデータｙ＿ｉｎｉｔの乗算結果を、ｐで除算した剰余であり、第６のデータｒ＿ｉｎｉｔ＋ｒ＿１ｓｔは、第３のデータｒ＿１ｓｔと第７のデータｒ＿ｉｎｉｔの加算結果である（ステップＳ１０７）。第５のデータｙ＿ｉｎｉｔは、ｇの第７のデータｒ＿ｉｎｉｔ乗をｐで除算した剰余である。
【００６８】
本形態では、更に、第１の共有データｙ＿ＡＢを求めるための第２のデータｙ＿１ｓｔ及び第３のデータｒ＿１ｓｔを、第２の共有データを求めるための第５のデータｙ＿ｉｎｉｔ及び第７のデータｒ＿ｉｎｉｔとして用いる。
【００６９】
また、第１のデータｙ＿ＡＢを元に、通信相手との通信で用いる暗号化鍵を生成する。
【００７０】
図３において、ＣＰＵ３０３は、第３のデータｒ＿１ｓｔを生成し、ネットワーク・インタフェース３０１を用いて、第２のデータｙ＿１ｓｔを第３のデータｒ＿１ｓｔから依頼計算を用いて求める依頼計算手段として動作する。
【００７１】
また、ＣＰＵ３０３は、依頼計算により求めた第２のデータｙ＿１ｓｔ、及び、ＲＡＭ３０５に格納された第５のデータｙ＿ｉｎｉｔを用いて、通信相手が第１のデータｙ＿ＡＢを求めるための第４のデータｙ＿Ａを、第２のデータｙ＿１ｓｔ及び第５のデータｙ＿ｉｎｉｔから生成する生成手段として動作する。
【００７２】
依頼計算手段として動作するＣＰＵ３０３は、先に生成した第３のデータｒ＿１ｓｔ、ＲＡＭ３０５に格納された第７のデータｒ＿ｉｎｉｔを用いて、通信相手と共有する第１のデータｙ＿ＡＢを、第３のデータｒ＿１ｓｔ及び第７のデータｒ＿ｉｎｉｔから生成される第６のデータｒ＿ｉｎｉｔ＋ｒ＿１ｓｔから、依頼計算を用いて求める。
【００７３】
以上の２回の依頼計算プロトコルにおいて、１回目の依頼計算プロトコルのベクトルＤおよびＦと、２回目の依頼計算プロトコルのベクトルＤ’およびＦ’とは、独立である。つまり、１回目の依頼計算プロトコルはｒ＿１ｓｔを秘密情報とする依頼計算であるが、２回目の依頼計算プロトコルはｒ＿ｉｎｉｔ＋ｒ＿１ｓｔ（ｍｏｄ  λ（ｐ））を秘密情報とする依頼計算である。なお、この式は、ｒ＿ｉｎｉｔ＋ｒ＿１ｓｔを計算した値、もしくは、ｒ＿ｉｎｉｔ＋ｒ＿１ｓｔを計算した値をλ（ｐ）で除算した剰余を示す。クライアントの秘密ｒ＿ｉｎｉｔおよびｙ＿ｉｎｉｔ＝ｇ＾（ｒ＿ｉｎｉｔ）ｍｏｄ  ｐは、クライアント以外は知らない乱数なので、第三者の立場から見るとそれら２つの依頼計算プロトコルは独立した異なる依頼計算プロトコルとして観測される。
【００７４】
また、ｙ＿ＡとＤとから総当たりによってｒ＿１ｓｔを（つまりＦを）求めようとしても、乱数ｒ＿ｉｎｉｔがあるためので、一意に定めることはできない。従って、課題としてあげた攻撃、つまりＤと１回目の依頼計算プロトコルを攻撃して判明したＦを利用して２回目の依頼計算プロトコルの結果（ｙ＿ＡＢ）を求めてＤＨを破る攻撃は成り立たない。
【００７５】
２回目の依頼計算プロトコルは、ｒ＿ｉｎｉｔ＋ｒ＿１ｓｔ（ｍｏｄ  λ（ｐ））を指数値とするべき乗剰余演算の依頼計算である。ｒ＿ｉｎｉｔは秘密の値であり、それを一意に特定するための情報ｙ＿ｉｎｉｔが秘密なので２回目の依頼計算プロトコルからｒ＿ｉｎｉｔを特定することはできない。
【００７６】
次に、２回目のＤＨ実行時を考える。変数に‘〜｛ｎ｝’を付加した記号は、ｎ回目のＤＨ実行時の変数を示す。
【００７７】
２回目のＤＨにおいて用いるｙ＿ｉｎｉｔ〜｛２｝＝ｇ＾（ｒ＿ｉｎｉｔ〜｛２｝）ｍｏｄ  ｐは、１回目のＤＨを実行する際に、サーバに計算させているので（ｙ＿１ｓｔ〜｛１｝＝ｇ＾（ｒ＿１ｓｔ〜｛１｝）ｍｏｄ  ｐ）、クライアントが新たに計算しなくてすむ。
【００７８】
次に、２回目のＤＨ実行時における１回目の依頼計算プロトコルの総当たり攻撃に対する耐性を考える。１回目のＤＨ実行時とは異なり、２回目のＤＨ実行時に用いるｒ＿ｉｎｉｔ〜｛２｝とｙ＿ｉｎｉｔ〜｛２｝＝ｇ＾（ｒ＿ｉｎｉｔ〜｛２｝）ｍｏｄ  ｐは、１回目のＤＨ実行時に計算された値である。つまり、２回目のＤＨ実行時に用いるｒ＿ｉｎｉｔ〜｛２｝＝ｒ＿１ｓｔ〜｛１｝とｙ＿ｉｎｉｔ〜｛２｝＝ｙ＿１ｓｔ〜｛１｝（＝ｇ＾（ｒ＿１ｓｔ〜｛１｝）ｍｏｄ  ｐ）は、１回目のＤＨ実行時におけるＤ〜｛１｝とＺ〜｛１｝の要素から組み合わせて求められた値である。
【００７９】
そして、ｙ＿ｉｎｉｔ〜｛２｝＝ｙ＿１ｓｔ〜｛１｝（＝ｇ＾（ｒ＿１ｓｔ〜｛１｝）ｍｏｄ  ｐ）と、２回目のＤＨ実行時に用いられるＤ〜｛２｝とＺ〜｛２｝の要素から組み合わせて求められた値ｙ＿１ｓｔ〜｛２｝とが乗算剰余演算された結果（ｙ＿ｉｎｉｔ〜｛２｝＊ｙ＿１ｓｔ〜｛２｝ｍｏｄ  ｐ）は、ｙ＿Ａ〜｛２｝として通信相手にインターネットを介して送られるので、攻撃者はｙ＿Ａ〜｛２｝を入手可能だと考えられる。
【００８０】
一方、ｙ＿１ｓｔ〜｛２｝の値はクライアントがローカルに計算するが、インターネット上で通信されないので攻撃者は入手できない。
【００８１】
従って、ｙ＿Ａ〜｛２｝の指数値ｒ＿ｉｎｉｔ〜｛２｝＋ｒ＿１ｓｔ〜｛２｝ｍｏｄ  λ（ｐ）を総当たりで求める攻撃を考えるとき、ｙ＿ｉｎｉｔ〜｛２｝＝ｙ＿１ｓｔ〜｛１｝（＝ｇ＾（ｒ＿１ｓｔ〜｛１｝）ｍｏｄ  ｐ）の指数値を総当たりで求める攻撃とｙ＿１ｓｔ〜｛２｝（＝ｇ＾（ｒ＿１ｓｔ〜｛２｝）ｍｏｄ  ｐ）の指数値を総当たりで求める攻撃の両方を同時に成功しなければならない。つまり、２回目のＤＨ実行時における１回目の依頼計算プロトコルの総当たり攻撃に対する耐性は、１回目のＤＨ実行時における１回目の依頼計算プロトコルにおける総当たり攻撃に対する耐性と２回目のＤＨ実行時における１回目の依頼計算プロトコルの総当たり攻撃に対する耐性との積となる。
【００８２】
従って、べき乗剰余演算の依頼計算プロトコルを前述のような総当たり攻撃によって２回分同時に破る手間となる。１回破るための手間が１０＾２０回の総当たりを要する場合は、１０＾２０＊１０＾２０＝１０＾４０回の総当たりを要することになるので、前述のような総当たり攻撃に対する耐性を強めることができる。
【００８３】
同様の関係は、ｋ回目のＤＨ実行とｋ＋１回目のＤＨ実行との間に成立する。従って、ＤＨ実行の最初の依頼計算の指数値を求めるための手間が１０＾２０回の総当たりを要する場合、任意の２回連続したＤＨ実行（ｋ回目のＤＨ実行とｋ＋１回目のＤＨ実行とする）において、ｋ＋１回目のＤＨ実行の最初の依頼計算の指数値ｒ＿１ｓｔ〜｛ｋ＋１｝を求めるための手間は１０＾２０＊１０＾２０＝１０＾４０回の総当たりを要する。
【００８４】
一方、１回目と３回目のＤＨ実行に着目すると、ｙ＿ｉｎｉｔ〜｛１｝＝ｇ＾（ｒ＿ｉｎｉｔ〜｛１｝）ｍｏｄ  ｐ、ｙ＿１ｓｔ〜｛１｝＝ｇ＾（ｒ＿１ｓｔ〜｛１｝）ｍｏｄ  ｐ、ｙ＿ｉｎｉｔ〜｛３｝＝ｙ＿１ｓｔ〜｛２｝＝ｇ＾（ｒ＿１ｓｔ〜｛２｝）ｍｏｄ  ｐ、ｙ＿１ｓｔ〜｛３｝＝ｇ＾（ｒ＿１ｓｔ〜｛３｝）ｍｏｄ  ｐには共通の変数が使われていないので、１回目と３回目のＤＨ実行は独立である。そこで、３回目のＤＨ実行時において使われるｙ＿ｉｎｉｔ〜｛３｝として、ｙ＿ｉｎｉｔ〜｛３｝＝ｙ＿ｉｎｉｔ〜｛１｝＊ｙ＿１ｓｔ〜｛２｝ｍｏｄ  ｐを用いると、ｙ＿ｉｎｉｔ〜｛１｝（つまり、ｒ＿ｉｎｉｔ〜｛１｝）が攻撃者にとって不明であるため、３回目のＤＨ実行時のｙ＿Ａ〜｛３｝＝ｙ＿ｉｎｉｔ〜｛３｝＊ｙ＿１ｓｔ〜｛３｝＝ｙ＿ｉｎｉｔ〜｛１｝＊ｙ＿１ｓｔ〜｛２｝＊ｙ＿１ｓｔ〜｛３｝＝ｇ＾（ｒ＿ｉｎｉｔ〜｛１｝）＊ｇ＾（ｒ＿１ｓｔ〜｛２｝）＊ｇ＾（ｒ＿１ｓｔ〜｛３｝）（ｍｏｄ  ｐ）からｒ＿１ｓｔ〜｛３｝を一意に求めることができなくなる。
【００８５】
同様の処理を４回目以降も繰り返すことを考える。つまり、４回目のＤＨ実行時において使われるｙ＿ｉｎｉｔ〜｛４｝として、ｙ＿ｉｎｉｔ〜｛４｝＝ｙ＿ｉｎｉｔ〜｛１｝＊ｙ＿１ｓｔ〜｛３｝ｍｏｄ  ｐを用い、５回目のＤＨ実行時において使われるｙ＿ｉｎｉｔ〜｛５｝として、ｙ＿ｉｎｉｔ〜｛５｝＝ｙ＿ｉｎｉｔ〜｛１｝＊ｙ＿１ｓｔ〜｛４｝ｍｏｄ  ｐを用い、・・・ｋ回目のＤＨ実行時において使われるｙ＿ｉｎｉｔ〜｛ｋ｝として、ｙ＿ｉｎｉｔ〜｛ｋ｝＝ｙ＿ｉｎｉｔ〜｛１｝＊ｙ＿１ｓｔ〜｛ｋ−１｝ｍｏｄ  ｐを用いる場合を考える。
【００８６】
ｋ＝４回目以降のＤＨ実行において、ｙ＿ｉｎｉｔ〜｛ｋ｝＝ｙ＿ｉｎｉｔ〜｛１｝＊ｙ＿１ｓｔ〜｛ｋ−１｝＝ｇ＾（ｒ＿ｉｎｉｔ〜｛１｝）＊ｇ＾｛ｒ＿１ｓｔ〜｛ｋ−１｝｝（ｍｏｄ  ｐ）であり、ｙ＿ｉｎｉｔ〜｛１｝とｒ＿ｉｎｉｔ〜｛１｝を攻撃者は知らないので、Ｄ〜｛ｋ｝とＺ〜｛ｋ｝からｙ＿１ｓｔ〜｛ｋ−１｝＝ｇ＾（ｒ＿１ｓｔ〜｛ｋ−１｝）ｍｏｄ  ｐの値を一意に特定することはできず、総当たりによる攻撃によってｒ＿１ｓｔ〜｛ｋ−１｝の値を求められることはできない。従って、ｎ＝３回目以降のＤＨの実行において、課題としてあげた攻撃、つまりＤ〜｛ｎ｝と１回目の依頼計算プロトコルを攻撃して判明したＦ〜｛ｎ｝とを利用して２回目の依頼計算プロトコルの結果（ｙ＿ＡＢ〜｛ｎ｝）を求めてＤＨを破る攻撃は成り立たない。
【００８７】
まとめると、ｙ＿ｉｎｉｔ〜｛ｎ｝＝ｙ＿ｉｎｉｔ〜｛１｝＊ｙ＿１ｓｔ〜｛ｎ−１｝ｍｏｄ  ｐとすれば、課題としてあげた攻撃はｎ回目以降（ただし、ｎは３以上）のＤＨ実行時においては成り立たなくなる。
【００８８】
以上から、２回目のＤＨ実行時のときに限り、１０＾４０の総当たりで破られる可能性があることがわかった。この攻撃を無効化する（攻撃が成り立たなくする）ためには、クライアントのみが知るｒ＿ｉｎｉｔ２とｙ＿ｉｎｉｔ２＝ｇ＾（ｒ＿ｉｎｉｔ２）ｍｏｄ  ｐを設け、ｙ＿ｉｎｉｔ〜｛２｝＝ｙ＿ｉｎｉｔ２＊ｙ＿１ｓｔ〜｛１｝ｍｏｄ  ｐとして計算すればよい。つまり、２つの乱数ｒ＿ｉｎｉｔとｒ＿ｉｎｉｔ２、それらの指数計算値ｙ＿ｉｎｉｔ＝ｇ＾（ｒ＿ｉｎｉｔ）ｍｏｄ  ｐとｙ＿ｉｎｉｔ２＝ｇ＾（ｒ＿ｉｎｉｔ２）ｍｏｄ  ｐを最初に用意しておき、ｙ＿ｉｎｉｔ〜｛２｝＝ｙ＿ｉｎｉｔ２＊ｙ＿１ｓｔ〜｛１｝ｍｏｄ  ｐ、ｙ＿ｉｎｉｔ〜｛ｎ｝＝ｙ＿ｉｎｉｔ〜｛１｝＊ｙ＿１ｓｔ〜｛ｎ−１｝ｍｏｄ  ｐ（ただし、ｎ＝３、４、．．．）とすれば、課題としてあげた攻撃は成り立たなくなる。
【００８９】
［情報量的に安全な依頼計算プロトコル］
図１のプロトコルにおいて用いるｙ＿ｉｎｉｔ（＝ｇ＾（ｒ＿ｉｎｉｔ）ｍｏｄ  ｐ）を得るために行う依頼計算プロトコルを説明する。
【００９０】
これは、依頼計算サーバあるいは第三者がクライアントの秘密情報ｘを特定することが情報量的に不可能であるという特徴を持つ依頼計算プロトコルである。秘密情報ｘ（Ｋビットの整数とする）の２進数表現をｘ＿（Ｋ−１）｜ｘ＿（Ｋ−２）｜．．．｜ｘ＿２｜ｘ＿１｜ｘ＿０とする（‘｜’は、各ビットを明示的に分離する記号であり、各桁はｘ＿ｉである。ただし、ｘ＿ｉの値は０か１のいずれかである）。
（１）クライアントは、法ｐ、生成元ｇ、Ｋをサーバに送る。
（２）サーバは、ｚ＿ｉ＝ｇ＾（ｂ＿ｉ）ｍｏｄ  ｐ、ただしｂ＿ｉ＝２＾ｉ（ｉ＝０、１、．．．、Ｋ−１）を計算し、Ｚ＝［ｚ＿０、ｚ＿１、ｚ＿２、．．．、ｚ＿（Ｋ−１）］をクライアントに送る。
（３）クライアントは以下のようにしてｇ＾ｘ  ｍｏｄ  ｐ＝ｙ＿Ｋを計算する。すなわち、ｙ＿０＝１とし、ｉ＝０、１、．．．、Ｋ−１に対して、ｘ＿ｉ＝０ならばｙ＿（ｉ＋１）＝ｙ＿ｉ  ｍｏｄ  ｐとし、ｘ＿ｉ＝１ならばｙ＿（ｉ＋１）＝ｙ＿ｉ＊ｚ＿ｉ  ｍｏｄ  ｐとする。これを、ｉ＝１からｉ＝Ｋ−１まで、繰り返す。すなわち、ｙ＿１、ｙ＿２、、、を順次求め、それを繰り返して、ｙ＿Ｋを求める。
【００９１】
図１のプロトコルにおいて、この秘密情報ｘをｒ＿ｉｎｉｔ、ｙ＿Ｋをｙ＿ｉｎｉｔ（＝ｇ＾（ｒ＿ｉｎｉｔ）ｍｏｄ  ｐ）として、用いる。
【００９２】
［情報量的に安全な依頼計算プロトコルおわり］
以上の実施の形態説明では、離散対数問題が困難となるような乗法群とその乗法群における乱数を指数とするべき乗剰余演算の形態を説明したが、離散対数問題が困難となるような楕円曲線とその楕円曲線上の点と乱数との乗算を用いることもできる。
【００９３】
上記の乗法群を用いた形態では、秘密鍵として整数ｘ、パラメータとして素数ｐとＧＦ（ｐ）の生成元ｇ、公開鍵としてｙ＝ｇ＾｛ｘ｝ｍｏｄ  ｐを用いたが、楕円曲線を用いる形態では、秘密鍵として整数ｘ、パラメータとしてある楕円曲線とその楕円曲線上の点Ｐ、公開鍵としてｙ＝ｘ＊Ｐを用いる。
【００９４】
図４のプロトコルは、次のようになる。エンティティＡは、秘密鍵ｘ＿Ａを生成し、ｙ＿Ａ＝ｘ＿Ａ＊Ｐを計算し、ｙ＿ＡをエンティティＢに送り、エンティティＢは、秘密鍵ｘ＿Ｂを生成し、ｙ＿Ｂ＝ｘ＿Ｂ＊Ｐを計算し、ｙ＿ＢをエンティティＡに送る。そして、エンティティＡは、ｙ＿Ｂを受け取り、ｙ＿ＡＢ＝ｘ＿Ａ＊ｙ＿Ｂを計算し、エンティティＢは、ｙ＿Ａを受け取り、ｙ＿ＢＡ＝ｘ＿Ｂ＊ｙ＿Ａを計算する。
【００９５】
楕円曲線を用いる形態では、乗法群上のある要素（整数）は、楕円曲線上の点（ｘ座標とｙ座標を有する）に対応し、乗法群の乗算は、楕円曲線では点の点の加算に対応する。乗法群の指数演算は、楕円曲線では同じ点を複数回加算することに相当するので、点と整数の乗算に対応する。
【００９６】
従って、乗法群のべき乗剰余演算で使われる指数（整数）ｒ＿ｉｎｉｔ＋ｒ＿１ｓｔ（図１のステップＳ１０７）は、楕円曲線の場合でもｒ＿ｉｎｉｔ＋ｒ＿１ｓｔであり、乗法群のｙ＿Ａ＝ｙ＿ｉｎｉｔ＊ｙ＿１ｓｔ  ｍｏｄ  ｐ（図１のステップＳ１０６）は、楕円曲線の場合ｙ＿Ａ＝ｙ＿ｉｎｉｔ＋ｙ＿１ｓｔである。ただし、楕円曲線上の点と点の加算（＋で示した演算）、乗算（＊で示した演算）は、上記の定義の通りである。
【００９７】
図１のプロトコルでは、第２のデータｙ＿１ｓｔは、第３のデータｒ＿１ｓｔと楕円曲線上の点Ｐとの乗算結果であり、第４のデータｙ＿Ａは、楕円曲線上の第２のデータｙ＿１ｓｔと楕円曲線上の第５のデータｙ＿ｉｎｉｔとの加算結果である。また、第１のデータｙ＿ＡＢは、第６のデータｒ＿１ｓｔ＋ｒ＿ｉｎｉｔと楕円曲線上の第１２のデータｙ＿Ｂとの乗算結果であり、第６のデータｒ＿ｉｎｉｔ＋ｒ＿１ｓｔは、第３のデータｒ＿１ｓｔと第７のデータｒ＿ｉｎｉｔの加算結果である。第５のデータｙ＿ｉｎｉｔは、第７のデータｒ＿ｉｎｉｔと楕円曲線上の点Ｐとの乗算結果である。
【００９８】
なお、図１のステップＳ１０３では、楕円曲線を定義するパラメータ（含むＰ）とＤをサーバに送って、ステップＳ１０８では、Ｄ’とｙ＿Ｂをサーバに送る。
【００９９】
以下の実施例においても、離散対数問題が困難となるような乗法群とその乗法群における乱数を指数とするべき乗剰余演算の代りに、離散対数問題が困難となるような楕円曲線とその楕円曲線上の点と乱数との乗算を用いることができる。
【０１００】
なお、依頼計算プロトコルのサーバは、単独ノード、例えば、図２のホスト２０６としてＬＡＮ上に設けられ、そのＬＡＮ上の他のＩＰｖ６装置（ホスト２０４）がＤＨの計算を依頼計算サーバに依頼することができる。あるいは、例えば、オフィスあるいは家庭のＬＡＮ上に計算能力の大きなＰＣ、例えば、図２のホスト２０５を設置して依頼計算サーバとして動作させ、ＬＡＮ上の他のＩＰｖ６装置、例えば計算能力の小さなディジタルカメラ（ホスト２０４）がインターネット２０１上の他のＩＰｖ６装置（ホスト２０９）とＩＫＥによるＩＰｓｅｃ通信を行う際に、サーバ（ホスト２０５）に依頼計算することによってＩＫＥを行うことができる。なお、依頼計算プロトコルのサーバをインターネット２０１上に設けることも可能である。
【実施例１】
【０１０１】
次に、上述した依頼計算プロトコル（図１）をＩＫＥと統合したプロトコルであって、ＩＫＥを行うノードが依頼計算プロトコルのサーバを兼ねている場合を説明する。
【０１０２】
例えば、インターネット上のＷｅｂサイトのサーバを依頼計算サーバとしても動作させ、インターネットの他のＩＰｖ６装置、例えば計算能力の小さな携帯端末がそのＷｅｂサイトにアクセスしＩＫＥによるＩＰｓｅｃ通信を行う際に、ＩＫＥをサーバと実行しながら同時にサーバに依頼計算するような場合が該当する。
【０１０３】
本実施例は、図１の形態において、第２のデータｙ＿１ｓｔを第３のデータｒ＿１ｓｔから求めるための依頼計算、及び、第１のデータｙ＿ＡＢを第６のデータｒ＿ｉｎｉｔ＋ｒ＿１ｓｔから求めるための依頼計算を、通信相手に依頼する例である。
【０１０４】
最初に、ＩＫＥを簡単に説明するが、ＩＫＥの詳細はＲＦＣ２４０９‘‘Ｔｈｅ  Ｉｎｔｅｒｎｅｔ  Ｋｅｙ  Ｅｘｃｈａｎｇｅ（ＩＫＥ）’’に記載されている。
【０１０５】
ＩＫＥは、フェーズ１とフェーズ２からなり、フェーズ１でＩＳＡＫＭＰ  ＳＡを確立し、フェーズ２でＩＰｓｅｃ  ＳＡを確立する。フェーズ１ではメイン・モード（６回のデータ送受信）とアグレッシブ・モード（３回のデータ送受信）のいずれかが４つの認証方法と組み合わされて実行されるので、フェーズ１だけで８つの組み合わせが存在する。各モードのそれぞれの組み合わせにおいて、送受信されるデータが異なる。４つの認証方法のうち、公開鍵暗号の暗号化を用いる２つについては、ＤＨのデータが暗号化される。一方、フェーズ２はクイックモードのみであり、ＤＨはオプションである。ところで、ＩＫＥの本質はＳＡの合意とＤＨの実行であり、それらに関するデータ送受信が暗号化されないならば、上述した依頼計算プロトコル（図１）を直接適用できる。
【０１０６】
ＲＦＣ２４０９によると、ｐｒｅ−ｓｈａｒｅｄ  ｋｅｙを用いた認証方法を採用するメイン・モードは、図１０のようなプロトコルである（データの詳細は後述）。
【０１０７】
なお、図１０のＨＤＲはＩＳＡＫＭＰヘッダを示し、その右に記載されたデータがペイロードを示す。例えば、‘‘ＨＤＲ、ＳＡ’’は、ＩＳＡＫＭＰパケットのペイロードがＳＡであることを示す。ＨＤＲ＊は、そのパケットのペイロードが暗号化されていることを示す。ＫＥはＤｉｆｆｉｅ−Ｈｅｌｌｍａｎにおいて交換される情報、ＮｉとＮｒはＮｏｎｃｅ（乱数）、ＩＤｉｉとＩＤｉｒはｉｄｅｎｔｉｆｉｃａｔｉｏｎ  ｐａｙｌｏａｄ、ＨＡＳＨ＿ＩとＨＡＳＨ＿Ｒは、それまでに交換したデータから生成したハッシュ値である。最後の２つの暗号化データは、Ｄｉｆｆｉｅ−Ｈｅｌｌｍａｎで共有した秘密情報を基にして生成した暗号化鍵を用いて暗号化されている。
【０１０８】
一方、ディジタル署名を用いた認証方法を採用したメイン・モードは、図１１のようなプロトコルである。
【０１０９】
ＳＩＧ＿Ｉ、ＳＩＧ＿Ｒは、それぞれＨＡＳＨ＿Ｉ、ＨＡＳＨ＿Ｒに対してディジタル署名を適用した結果であることを踏まえて、上記２つのプロトコルを比較すれば明らかなように、上記２つのプロトコルは本質的に同じである。
【０１１０】
そこで、以下、ＩＫＥを実装する場合には必ずサポートすべきメイン・モードを対象とし、メイン・モードにおいてｐｒｅ−ｓｈａｒｅｄ  ｋｅｙを用いた認証方法およびディジタル署名を用いた認証方法の本質を取り出したプロトコル（抽象化ＩＫＥプロトコル（メイン・モード）と呼ぶことにする）を、図６を参照しながら説明する。
【０１１１】
［抽象化ＩＫＥプロトコル（メイン・モード）］
ステップＳ６０１でＩＫＥの始動者（Ｉｎｉｔｉａｔｏｒ）は、ＳＡのプロポーザル（１つ以上のＳｅｃｕｒｉｔｙ  Ａｓｓｏｃｉａｔｉｏｎｓ）を応答者（Ｒｅｓｐｏｎｄｅｒ）に送る。
【０１１２】
ステップＳ６０２でＲｅｓｐｏｎｄｅｒは、使用するＳｅｃｕｒｉｔｙ  Ａｓｓｏｃｉａｔｉｏｎ（一つ）をプロポーザルの中から選択し、Ｉｎｉｔｉａｔｏｒに送る（Ｓｅｃｕｒｉｔｙ  Ａｓｓｏｃｉａｔｉｏｎが定まるとｐとｇが定まる）。
【０１１３】
ステップＳ６０３でＩｎｉｔｉａｔｏｒは、ｙ＿ｉ（＝ｇ＾（ｘ＿ｉ）ｍｏｄ  ｐ）とＮｏｎｃｅ  ＮｉをＲｅｓｐｏｎｄｅｒに送る（ｘ＿ｉはＩｎｉｔｉａｔｏｒの秘密情報）。
【０１１４】
ステップＳ６０４でＲｅｓｐｏｎｄｅｒは、ｙ＿ｒ（＝ｇ＾（ｘ＿ｒ）ｍｏｄ  ｐ）とＮｏｎｃｅ  ＮｒをＩｎｉｔｉａｔｏｒに送る（ｘ＿ｒはＲｅｓｐｏｎｄｅｒの秘密情報）。
【０１１５】
ステップＳ６０５でＩｎｉｔｉａｔｏｒは、Ｒｅｓｐｏｎｄｅｒから受け取ったｙ＿ｒ＝ｇ＾（ｘ＿ｒ）ｍｏｄ  ｐと自分の秘密情報ｘ＿ｉとから（ｇ＾（ｘ＿ｒ））＾（ｘ＿ｉ）ｍｏｄ  ｐを計算して求め、それを基にして暗号化の鍵を生成し、その鍵を用いてｉｄｅｎｔｉｆｉｃａｔｉｏｎ  ｐａｙｌｏａｄ  ＩＤｉｉとＨＡＳＨ＿Ｉを暗号化したデータをＲｅｓｐｏｎｄｅｒに送る（暗号化の鍵やＨＡＳＨ＿ＩはＲＦＣ２４０９に記載されている方法に従って生成する）。
【０１１６】
ステップＳ６０６でＲｅｓｐｏｎｄｅｒは、Ｉｎｉｔｉａｔｏｒから受け取ったｙ＿ｉ＝ｇ＾（ｘ＿ｉ）ｍｏｄ  ｐと自分の秘密情報ｘ＿ｒとから（ｇ＾（ｘ＿ｉ））＾（ｘ＿ｒ）ｍｏｄ  ｐを計算して求め、それを基にして暗号化の鍵を生成し、その鍵を用いてｉｄｅｎｔｉｆｉｃａｔｉｏｎ  ｐａｙｌｏａｄ  ＩＤｉｒとＨＡＳＨ＿Ｒを暗号化したデータをＩｎｉｔｉａｔｏｒに送る（暗号化の鍵やＨＡＳＨ＿ＲはＲＦＣ２４０９に記載されている方法に従って生成する）。
【０１１７】
以上の抽象化ＩＫＥプロトコル（メイン・モード）に図１の依頼計算プロトコルを適用し、ＩＫＥを行うノード（Ｒｅｓｐｏｎｄｅｒ）が依頼計算プロトコルのサーバを兼ねている場合を、図７を参照しながら説明する。図７は、図１の依頼計算プロトコルと図６の抽象化ＩＫＥプロトコル（メイン・モード）とを統合したプロトコルである。図７においては、１回のデータ転送においてＩＫＥのデータと依頼計算のデータの両方が含まれるように表記してあるが、２つのプロトコルを同時並列に実行しても同様の効果を得られるので、両方のデータが１回のデータ転送に含まれなくてもよい。なお、Ｉｎｉｔｉａｔｏｒ及びＲｅｓｐｏｎｄｅｒは、図３の構成を有する。
【０１１８】
Ｉｎｉｔｉａｔｏｒは、Ｒｅｓｐｏｎｄｅｒが依頼計算サーバでありＩＫＥでＩＰｓｅｃ通信する相手でもあることを知っており、そのアドレスや依頼計算サーバとしての設定が行われているものとする。
【０１１９】
ステップＳ７０１でＩｎｉｔｉａｔｏｒは、図１のステップＳ１０１、Ｓ１０２と同様に、乱数ｒ（＝ｒ＿１ｓｔ）、依頼計算のパラメータＤとＦを決定し、ＳＡのプロポーザルとＤをＲｅｓｐｏｎｄｅｒに送る。
【０１２０】
ステップＳ７０２でＲｅｓｐｏｎｄｅｒは、使用するＳｅｃｕｒｉｔｙ  Ａｓｓｏｃｉａｔｉｏｎ（一つ）をプロポーザルの中から選択する。ｐとｇが定まるので、それらとＤとからＺ（ただし、ｚ＿ｉ＝ｇ＾（ｄ＿ｉ）ｍｏｄ  ｐ）を計算し、選択したＳｅｃｕｒｉｔｙ  ＡｓｓｏｃｉａｔｉｏｎとＺをＩｎｉｔｉａｔｏｒに送る。
【０１２１】
ステップＳ７０３でＩｎｉｔｉａｔｏｒは、図１のステップＳ１０６と同様にして、（Ｆと）Ｚからｙ＿１ｓｔを求め、更に、ｙ＿ｉを計算する。このｙ＿ｉは、図１のステップＳ１０６のｙ＿Ａ（＝ｙ＿ｉｎｉｔ＊ｙ＿１ｓｔ  ｍｏｄ  ｐ）同じものである。ｙ＿ｉｎｉｔは、図１と同様に、予め準備されている。また、図１のステップＳ１０７と同様にして、ｒ＿ｉｎｉｔ＋ｒから依頼計算のパラメータＤ’とＦ’を決定する。ｒ＿ｉｎｉｔは、図１と同様に、予め準備されている。そして、ｙ＿ｉとＮｏｎｃｅ  ＮｉとＤ’をＲｅｓｐｏｎｄｅｒに送る。
【０１２２】
ステップＳ７０４でＲｅｓｐｏｎｄｅｒは、ｙ＿ｒを定める。このｙ＿ｒは、図４のｙ＿Ａ、ｙ＿Ｂと同様に、計算することができる。また、Ｒｅｓｐｏｎｄｅｒは、ｙ＿ｒとＤ’とからＺ’（ただし、ｚ＿ｉ’＝（ｙ＿ｒ）＾（ｄ＿ｉ’）ｍｏｄ  ｐ）を計算する。ｙ＿ｒとＮｏｎｃｅ  ＮｒとＺ’をＩｎｉｔｉａｔｏｒに送る。
【０１２３】
ステップＳ７０５でＩｎｉｔｉａｔｏｒは、（Ｆ’と）Ｚ’からｙ＿ｉｒを求める。このｙ＿ｉｒは、図１のステップＳ１１１のｙ＿ＡＢと同様に求めることができる。また、Ｉｎｉｔｉａｔｏｒは、ｙ＿ｉｒを基にして暗号化の鍵を生成し、ＨＡＳＨ＿Ｉを求める（暗号化の鍵やＨＡＳＨ＿ＩはＲＦＣ２４０９に記載されている方法に従って生成する）。ｉｄｅｎｔｉｆｉｃａｔｉｏｎ  ｐａｙｌｏａｄ  ＩＤｉｉとＨＡＳＨ＿Ｉを暗号化したデータをＲｅｓｐｏｎｄｅｒに送る。
【０１２４】
ステップＳ７０６でＲｅｓｐｏｎｄｅｒは、ｙ＿ｒｉを求める。このｙ＿ｒｉは、図４のステップＳ４０４Ａ、Ｓ４０４Ｂと同様に検することができる。ｙ＿ｒｉを基にして暗号化の鍵を生成し、ＨＡＳＨ＿Ｒを求める。ｉｄｅｎｔｉｆｉｃａｔｉｏｎ  ｐａｙｌｏａｄ  ＩＤｉｒとＨＡＳＨ＿Ｒを暗号化したデータをＩｎｉｔｉａｔｏｒに送る。
【０１２５】
以上のプロトコルによって、計算能力の小さなＩＰｖ６装置と計算能力の大きなＩＰｖ６装置がＩＫＥを行うときに、負荷を分散しながら安全にＩＫＥを実行できる。
【０１２６】
なお、ステップＳ７０３でＩｎｉｔｉａｔｏｒがＲｅｓｐｏｎｄｅｒに送るＤ’は、ステップＳ７０１で送ることもできる。
【実施例２】
【０１２７】
本実施例では、図１で説明した依頼計算プロトコルをＩＫＥと統合したプロトコルであって、依頼計算プロトコルのサーバが例えば家庭ＬＡＮのｇａｔｅｗａｙ上で動作している場合を説明する。
【０１２８】
例えば、出先のインターネットカフェからＰＣや携帯端末を用いて、あるいはオフィスのＰＣを用いて、インターネット経由で家庭ＬＡＮ内部のＩＰｖ６端末にアクセスするときにＩＫＥでＩＰｓｅｃ通信を行う場合が該当する。このとき、家庭ＬＡＮ内部のＩＰｖ６端末はＩＫＥのＲｅｓｐｏｎｄｅｒとして動作するが、ｇａｔｅｗａｙ（図２のゲートウェイ２０２）はＩｎｉｔｉａｔｏｒ（例えば、図２のホスト２０９）とＲｅｓｐｏｎｄｅｒ（例えば、図２のホスト２０４）の間に位置しＩＫＥのパケットを中継するので、ＩＫＥのプロトコルと依頼計算のプロトコルを重ね合わせながら依頼計算サービスを提供することが可能になる。
【０１２９】
本実施例は、図１の形態において、第２のデータｙ＿１ｓｔを第３のデータｒ＿１ｓｔから求めるための依頼計算、及び、第１のデータｙ＿ＡＢを第６のデータｒ＿ｉｎｉｔ＋ｒ＿１ｓｔから求めるための依頼計算を、通信相手との間に存在するサーバに依頼する例である。
【０１３０】
図８を参照しながら説明する。図８においては、１回のデータ転送においてＩＫＥのデータと依頼計算のデータの両方が含まれるように表記してあるが、２つのプロトコルを同時並列に同期させながら実行しても同様の効果を得られるので、両方のデータが１回のデータ転送に含まれなくてもよい。
【０１３１】
Ｒｅｓｐｏｎｄｅｒ（例えば、図２のホスト２０４）は、ｇａｔｅｗａｙ（ｓｅｒｖｅｒ）２０２をｄｅｆａｕｌｔ  ｇａｔｅｗａｙ兼依頼計算サーバとして設定しておく。Ｉｎｉｔｉａｔｏｒ（例えば、図２のホスト２０９）は、Ｒｅｓｐｏｎｄｅｒのアドレスを知っているものとする。
【０１３２】
ステップＳ８０１でＩｎｉｔｉａｔｏｒは、ＳＡのプロポーザル（１つ以上のＳｅｃｕｒｉｔｙ  Ａｓｓｏｃｉａｔｉｏｎｓ）をＲｅｓｐｏｎｄｅｒに送る。
【０１３３】
ステップＳ８０２でｇａｔｅｗａｙは、ＳＡのプロポーザル（１つ以上のＳｅｃｕｒｉｔｙ  Ａｓｓｏｃｉａｔｉｏｎｓ）をＩｎｉｔｉａｔｏｒからＲｅｓｐｏｎｄｅｒに中継する。
【０１３４】
ステップＳ８０３でＲｅｓｐｏｎｄｅｒは、ｒ＿１ｓｔを決定し、ｒ＿ｉｎｉｔ＋ｒ＿１ｓｔを求め、ｒ＿１ｓｔから依頼計算のパラメータＤとＦを決定し、ｒ＿ｉｎｉｔ＋ｒ＿１ｓｔから依頼計算のパラメータＤ’とＦ’を決定する。なお、ｒ＿ｉｎｉｔは、図１と同様に、予め準備されている。そして、使用するＳｅｃｕｒｉｔｙ  Ａｓｓｏｃｉａｔｉｏｎ（一つ）をプロポーザルの中から選択し、それをｇａｔｅｗａｙ経由でＩｎｉｔｉａｔｏｒに送り、それとＤとＤ’をｇａｔｅｗａｙに送る。
【０１３５】
ステップＳ８０４でｇａｔｅｗａｙは、選択されたＳｅｃｕｒｉｔｙ  Ａｓｓｏｃｉａｔｉｏｎ（ｐとｇが定まる）とＤからＺ（ｚ＿ｒ＝ｇ＾（ｄ＿ｒ）ｍｏｄ  ｐ）を計算する。
【０１３６】
ステップＳ８０５でｇａｔｅｗａｙは、選択されたＳｅｃｕｒｉｔｙ  ＡｓｓｏｃｉａｔｉｏｎをＩｎｉｔｉａｔｏｒに中継する。なお、ステップＳ８０４とステップＳ８０５はかならずしもこの順番で実行されなくてもよい。
【０１３７】
ステップＳ８０６でＩｎｉｔｉａｔｏｒは、ｙ＿ｉ（＝ｇ＾（ｘ＿ｉ）ｍｏｄ  ｐ）とＮｏｎｃｅ  Ｎｉをｇａｔｅｗａｙ経由でＲｅｓｐｏｎｄｅｒに送る（ｘ＿ｉはＩｎｉｔｉａｔｏｒの秘密情報）。
【０１３８】
ステップＳ８０７でｇａｔｅｗａｙは、Ｉｎｉｔｉａｔｏｒから（Ｒｅｓｐｏｎｄｅｒに中継するために）受け取ったｙ＿ｉとＤ’とからＺ’（ｚ＿ｒ）’＝（ｙ＿ｉ）＾（ｄ＿ｒ’）ｍｏｄ  ｐ）を計算する。
【０１３９】
ステップＳ８０８でｇａｔｅｗａｙは、ｙ＿ｉとＮｉをＲｅｓｐｏｎｄｅｒに中継し、ＺとＺ’をＲｅｓｐｏｎｄｅｒに送る。
【０１４０】
ステップＳ８０９でＲｅｓｐｏｎｄｅｒは、図１のステップＳ１０６と同様に、（Ｆと）Ｚからｙ＿１ｓｔを求め、更に、ｙ＿ｒを計算する。このｙ＿ｒは、図１のステップＳ１０６のｙ＿Ａ（＝ｙ＿ｉｎｉｔ＊ｙ＿１ｓｔ  ｍｏｄ  ｐ）と同じものである。なお、ｙ＿ｉｎｉｔは、図１と同様に、予め準備されている。
【０１４１】
ステップＳ８１０でＲｅｓｐｏｎｄｅｒは、ｙ＿ｒとＮｏｎｃｅ  ＮｒをＩｎｉｔｉａｔｏｒに送る。
【０１４２】
ステップＳ８１０とステップＳ８１４の間でＲｅｓｐｏｎｄｅｒは、（Ｆ’と）Ｚ’からｙ＿ｒｉを計算し、ｙ＿ｒｉを基にして暗号化の鍵を生成し、ＨＡＳＨ＿Ｒを求める。このｙ＿ｒｉは、図１のステップＳ１１１のｙ＿ＡＢと同様に求めることができる。
【０１４３】
ステップＳ８１１でｇａｔｅｗａｙは、ｙ＿ｒとＮｏｎｃｅ  ＮｒをＩｎｉｔｉａｔｏｒに中継する。
【０１４４】
ステップＳ８１２でＩｎｉｔｉａｔｏｒは、Ｒｅｓｐｏｎｄｅｒから受け取ったｙ＿ｒと自分の秘密情報ｘ＿ｉとからｙ＿ｉｒ（＝（ｙ＿ｒ）＾（ｘ＿ｉ）ｍｏｄ  ｐ）を求め、ｙ＿ｉｒを基にして暗号化の鍵を生成し、ＨＡＳＨ＿Ｉを求め、ｉｄｅｎｔｉｆｉｃａｔｉｏｎ  ｐａｙｌｏａｄ  ＩＤｉｉとＨＡＳＨ＿Ｉを暗号化したデータをＲｅｓｐｏｎｄｅｒに送る。
【０１４５】
ステップＳ８１３でｇａｔｅｗａｙは、ｉｄｅｎｔｉｆｉｃａｔｉｏｎ  ｐａｙｌｏａｄ  ＩＤｉｉとＨＡＳＨ＿Ｉが暗号化されたデータをＲｅｓｐｏｎｄｅｒに中継する。
【０１４６】
ステップＳ８１４でＲｅｓｐｏｎｄｅｒは、ｉｄｅｎｔｉｆｉｃａｔｉｏｎ  ｐａｙｌｏａｄ  ＩＤｉｒとＨＡＳＨ＿Ｒを暗号化したデータをＩｎｉｔｉａｔｏｒに送る。この暗号化には、ｙ＿ｒｉを元に生成した鍵を用いる。
【０１４７】
ステップＳ８１５でｇａｔｅｗａｙは、ｉｄｅｎｔｉｆｉｃａｔｉｏｎ  ｐａｙｌｏａｄ  ＩＤｉｒとＨＡＳＨ＿Ｒが暗号化されたデータをＩｎｉｔｉａｔｏｒに中継する。
【０１４８】
以上のプロトコルによって、計算能力の小さなＩＰｖ６装置がｇａｔｅｗａｙを依頼計算サーバとして利用しながら安全にＩＫＥを実行できる。
【実施例３】
【０１４９】
本実施例では、第１の実施例の依頼計算プロトコルをＩＫＥと組み合わせたプロトコルであって、依頼計算プロトコルのサーバが依頼計算サービスの提供を専門とするノードとしてインターネット上に設けられ、かつそのノードがプロキシーのように動作する場合を説明する。
【０１５０】
例えば、インターネット上の２つのＩＰｖ６装置が、ＩＫＥによるＩＰｓｅｃ通信を行う際に、２つの装置が共にその依頼計算サーバに依頼計算してＩＫＥを行う場合であって、ＩＫＥのパケットがその依頼計算サーバを必ず経由する場合が該当する。この場合、依頼計算サーバはいわばＩＫＥプロキシーとして動作するとみなすことが可能である。
【０１５１】
本実施例は、図１の形態において、第２のデータｙ＿１ｓｔを第３のデータｒ＿１ｓｔから求めるための依頼計算、及び、第１のデータｙ＿ＡＢを第６のデータｒ＿ｉｎｉｔ＋ｒ＿１ｓｔから求めるための依頼計算を、通信相手との間に存在するサーバに依頼する例である。
【０１５２】
なお、本実施例は、図７のプロトコルと図８のプロトコルを組み合わせたプロトコルだとみなすこともできる。つまり、ＩｎｉｔｉａｔｏｒとＲｅｓｐｏｎｄｅｒの間に依頼計算サーバが位置し、ＩＫＥパケットを中継しながらＩｎｉｔｉａｔｏｒとＲｅｓｐｏｎｄｅｒの両方に依頼計算サービスが提供される。図９を参照しながら説明する。Ｉｎｉｔｉａｔｏｒ、Ｒｅｓｐｏｎｄｅｒ及びＩＫＥプロキシーは、図３のような構成を有する。図９においては、１回のデータ転送においてＩＫＥのデータと依頼計算のデータの両方が含まれるように表記してあるが、２つのプロトコルを同時並列に同期させながら実行しても同様の効果を得られるので、両方のデータが１回のデータ転送に含まれなくてもよい。
【０１５３】
ＩｎｉｔｉａｔｏｒとＲｅｓｐｏｎｄｅｒは、ＩＫＥ−Ｐｒｏｘｙ（ｓｅｒｖｅｒ）をＩＫＥ−Ｐｒｏｘｙ兼依頼計算サーバとして設定しておく。Ｉｎｉｔｉａｔｏｒは、Ｒｅｓｐｏｎｄｅｒのアドレスを知っているものとする。
【０１５４】
ステップＳ９０１でＩｎｉｔｉａｔｏｒは、依頼計算のパラメータＤ＿ｉとＦ＿ｉ、Ｄ＿ｉ’とＦ＿ｉ’を決定し、ＳＡのプロポーザルをＩＫＥ−ｐｒｏｘｙ経由でＲｅｓｐｏｎｄｅｒに送る。また、Ｄ＿ｉとＤ’＿ｉをＩＫＥ−Ｐｒｏｘｙに送る。
【０１５５】
ステップＳ９０２でＩＫＥ−Ｐｒｏｘｙは、ＳＡのプロポーザル（１つ以上のＳｅｃｕｒｉｔｙ  Ａｓｓｏｃｉａｔｉｏｎｓ）をＩｎｉｔｉａｔｏｒからＲｅｓｐｏｎｄｅｒに中継する。
【０１５６】
ステップＳ９０３でＲｅｓｐｏｎｄｅｒは、依頼計算のパラメータＤ＿ｒとＦ＿ｒ、Ｄ＿ｒ’とＦ＿ｒ’を決定する。また、使用するＳｅｃｕｒｉｔｙ  Ａｓｓｏｃｉａｔｉｏｎ（一つ）をプロポーザルの中から選択し、選択したＳｅｃｕｒｉｔｙ  ＡｓｓｏｃｉａｔｉｏｎをＩＫＥ−Ｐｒｏｘｙ経由でＩｎｉｔｉａｔｏｒに送る。また、Ｄ＿ｒとＤ＿ｒ’をＩＫＥ−Ｐｒｏｘｙに送る。
【０１５７】
ステップＳ９０４でＩＫＥ−Ｐｒｏｘｙは、図１のステップＳ１０４と同様に、選択されたＳｅｃｕｒｉｔｙ  Ａｓｓｏｃｉａｔｉｏｎ（ｐとｇが定まる）を用いて、Ｄ＿ｉからＺ＿ｉを、Ｄ＿ｒからＺ＿ｒを計算する。
【０１５８】
ステップＳ９０５でＩＫＥ−Ｐｒｏｘｙは、選択されたＳｅｃｕｒｉｔｙ  ＡｓｓｏｃｉａｔｉｏｎとＺ＿ｉをＩｎｉｔｉａｔｏｒに送る。ステップＳ９０６でＩｎｉｔｉａｔｏｒは、（Ｆ＿ｉと）Ｚ＿ｉからｙ＿ｉを計算する。このｙ＿ｉは、図１のステップＳ１０６のｙ＿Ａ（＝ｙ＿ｉｎｉｔ＊ｙ＿１ｓｔ  ｍｏｄ  ｐ）に相当する。
【０１５９】
ステップＳ９０７でＩｎｉｔｉａｔｏｒは、ｙ＿ｉとＮｏｎｃｅ  ＮｉをＩＫＥ−Ｐｒｏｘｙ経由でＲｅｓｐｏｎｄｅｒに送る。
【０１６０】
ステップＳ９０８でＩＫＥ−Ｐｒｏｘｙは、Ｉｎｉｔｉａｔｏｒから（Ｒｅｓｐｏｎｄｅｒに中継するために）受け取ったｙ＿ｉとＤ＿ｒ’とから、図１のステップＳ１０９と同様に、Ｚ＿ｒ’（ｚ＿ｒ’＝（ｙ＿ｉ）＾（ｄ＿ｒ’）ｍｏｄ  ｐ）を計算する。
【０１６１】
ステップＳ９０９でＩＫＥ−Ｐｒｏｘｙは、ｙ＿ｉとＮｉをＲｅｓｐｏｎｄｅｒに中継し、Ｚ＿ｒとＺ＿ｒ’をＲｅｓｐｏｎｄｅｒに送る。
【０１６２】
ステップＳ９１０でＲｅｓｐｏｎｄｅｒは、（Ｆ＿ｒと）Ｚ＿ｒからｙ＿ｒを計算する。このｙ＿ｒは、図１のステップＳ１０６のｙ＿Ａ（＝ｙ＿ｉｎｉｔ＊ｙ＿１ｓｔ  ｍｏｄ  ｐ）に相当する。
【０１６３】
ステップＳ９１１でＲｅｓｐｏｎｄｅｒは、ｙ＿ｒとＮｏｎｃｅ  ＮｒをＩＫＥ−Ｐｒｏｘｙ経由でＩｎｉｔｉａｔｏｒに送る。
【０１６４】
ステップＳ９１１とステップＳ９１７の間でＲｅｓｐｏｎｄｅｒは、（Ｆ＿ｒ’と）Ｚ＿ｒ’からｙ＿ｒｉを計算し、ｙ＿ｒｉを基にして暗号化の鍵を生成し、ＨＡＳＨ＿Ｒを求める。このｙ＿ｒｉは、図１のステップＳ１１１のｙ＿ＡＢと同様に求めることができる。
【０１６５】
ステップＳ９１２でＩＫＥ−Ｐｒｏｘｙは、Ｒｅｓｐｏｎｄｅｒから（Ｉｎｉｔｉａｔｏｒに中継するために）受け取ったｙ＿ｒとＤ＿ｉ’とからＺ＿ｉ’（ｚ＿ｉ’＝（ｙ＿ｒ）＾（ｄ＿ｉ’）ｍｏｄ  ｐ）を計算する。
【０１６６】
ステップＳ９１３でＩＫＥ−Ｐｒｏｘｙは、ｙ＿ｒとＮｏｎｃｅ  ＮｒをＩｎｉｔｉａｔｏｒに中継し、Ｚ＿ｉ’をＩｎｉｔｉａｔｏｒに送る。
【０１６７】
ステップＳ９１４でＩｎｉｔｉａｔｏｒは、Ｚ＿ｉ’からｙ＿ｉｒを求める。このｙ＿ｉｒは、図１のステップＳ１１１のｙ＿ＡＢと同様に求めることができる。ｙ＿ｉｒを基にして暗号化の鍵を生成し、ＨＡＳＨ＿Ｉを求める。ステップＳ９１５でＩｎｉｔｉａｔｏｒは、生成した鍵でｉｄｅｎｔｉｆｉｃａｔｉｏｎ  ｐａｙｌｏａｄ  ＩＤｉｉとＨＡＳＨ＿Ｉを暗号化したデータをＩＫＥ−Ｐｒｏｘｙ経由でＲｅｓｐｏｎｄｅｒに送る。
【０１６８】
ステップＳ９１６でＩＫＥ−Ｐｒｏｘｙは、ｉｄｅｎｔｉｆｉｃａｔｉｏｎ  ｐａｙｌｏａｄ  ＩＤｉｉとＨＡＳＨ＿Ｉが暗号化されたデータをＲｅｓｐｏｎｄｅｒに中継する。
【０１６９】
ステップＳ９１７でＲｅｓｐｏｎｄｅｒは、ｙ＿ｒｉを基に生成した鍵でｉｄｅｎｔｉｆｉｃａｔｉｏｎ  ｐａｙｌｏａｄ  ＩＤｉｒとＨＡＳＨ＿Ｒを暗号化したデータをＩｎｉｔｉａｔｏｒに送る。
【０１７０】
ステップＳ９１８でＩＫＥ−Ｐｒｏｘｙは、ｉｄｅｎｔｉｆｉｃａｔｉｏｎ  ｐａｙｌｏａｄ  ＩＤｉｒとＨＡＳＨ＿Ｒが暗号化されたデータをＩｎｉｔｉａｔｏｒに中継する。
【０１７１】
以上のプロトコルによって、計算能力の小さなＩＰｖ６装置２台がＩＫＥ−Ｐｒｏｘｙを依頼計算サーバとして利用しながら安全にＩＫＥを実行できる。なお、ＩＫＥ−Ｐｒｏｘｙがｍａｎ−ｉｎ−ｔｈｅ−ｍｉｄｄｌｅ−ａｔｔａｃｋを実行しようとしても、ＩＫＥの中で実行される（ｐｒｅ−ｓｈａｒｅｄ  ｋｅｙあるいはディジタル署名に基づく）認証方法によってその攻撃は検出され、攻撃が成功することはない。
【図面の簡単な説明】
【０１７２】
【図１】依頼計算プロトコル図である。
【図２】イーサネット（R)ＬＡＮの模式図である。
【図３】ノードの構成図である。
【図４】Ｄｉｆｆｉｅ−Ｈｅｌｌｍａｎ  Ｐｕｂｌｉｃ−ｋｅｙ  Ｄｉｓｔｒｉｂｕｔｉｏｎ  Ｓｃｈｅｍｅの図である。
【図５】Ｐｒｏｔｏｃｏｌ  ＲＳＡ−Ｓ１の図である。
【図６】抽象化ＩＫＥプロトコル（メイン・モード）図である。
【図７】統合ＩＫＥプロトコル（Ｒｅｓｐｏｎｄｅｒが依頼計算サーバを兼ねる場合）図である。
【図８】統合ＩＫＥプロトコル（ｇａｔｅｗａｙが依頼計算サーバを兼ねる場合）図である。
【図９】ＩＫＥ−Ｐｒｏｘｙプロトコル図である。
【図１０】ｐｒｅ−ｓｈａｒｅｄ  ｋｅｙを用いた認証方式を採用するメイン・モードのプロトコル図である。
【図１１】ディジタル署名を用いた認証方式を採用したメイン・モードのプロトコル図である。
【符号の説明】
【０１７３】
２０１  インターネット
２０２  ｄｅｆａｕｌｔ  ｇａｔｅｗａｙ
２０３  ＤＨＣＰサーバ
２０４  ホスト
２０５  ホスト
２０６  ホスト
【図１】
2005086330.tif 000003
【図２】
2005086330.tif 000004
【図３】
2005086330.tif 000005
【図４】
2005086330.tif 000006
【図５】
2005086330.tif 000007
【図６】
2005086330.tif 000008
【図７】
2005086330.tif 000009
【図８】
2005086330.tif 000010
【図９】
2005086330.tif 000011
【図１０】
2005086330.tif 000012
【図１１】
2005086330.tif 000013
【手続補正書】
【提出日】平成16年7月14日(2004.7.14)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
通信相手と第１のデータを共有するためのデータ共有方法であって、
第２のデータを第３のデータから依頼計算を用いて求め、
通信相手が第１のデータを求めるための第４のデータを、第２のデータ及び第５のデータから生成し、
通信相手と共有する第１のデータを、第３のデータ及び第７のデータから生成される第６のデータから、依頼計算を用いて求めることを特徴とするデータ共有方法。
【請求項２】
請求項１において、
第２のデータを第３のデータから依頼計算を用いて求めるステップにおいて、第１の変換により第３のデータから得られる第８のデータを元に、依頼計算により第９のデータを得て、第１の変換に対応する第２の変換を用いて第９のデータから第２のデータを生成し、
第１のデータを第６のデータから依頼計算を用いて求めるステップにおいて、第３の変換により第６のデータから得られる第１０のデータを元に、依頼計算により第１１のデータを得て、第３の変換に対応する第４の変換を用いて第１１のデータから第１のデータを生成することを特徴とするデータ共有方法。
【請求項３】
請求項１において、
第２のデータは、ｇの第３のデータ乗をｐで除算した剰余であり、
第４のデータは、第２のデータと第５のデータの乗算結果を、ｐで除算した剰余であり、
第１のデータは、第１２のデータの第６のデータ乗をｐで除算した剰余であり、
第６のデータは、第３のデータと第７のデータの加算結果であり、
第５のデータは、ｇの第７のデータ乗をｐで除算した剰余であることを特徴とするデータ共有方法。
【請求項４】
請求項１において、
第２のデータは、第３のデータと楕円曲線上の点Ｐとの乗算結果であり、
第４のデータは、楕円曲線上の第２のデータと楕円曲線上の第５のデータとの加算結果であり、
第１のデータは、第６のデータと楕円曲線上の第１２のデータとの乗算結果であり、
第６のデータは、第３のデータと第７のデータの加算結果であり、
第５のデータは、第７のデータと楕円曲線上の点Ｐとの乗算結果であることを特徴とするデータ共有方法。
【請求項５】
請求項１において、
第１の共有データを求めるための第２のデータ及び第３のデータを、第２の共有データを求めるための第５のデータ及び第７のデータとして用いることを特徴とするデータ共有方法。
【請求項６】
請求項１において、
第２のデータを第３のデータから求めるための依頼計算、及び、第１のデータを第６のデータから求めるための依頼計算を、通信相手に依頼することを特徴とするデータ共有方法。
【請求項７】
請求項１において、
第２のデータを第３のデータから求めるための依頼計算、及び、第１のデータを第６のデータから求めるための依頼計算を、通信相手との間に存在するサーバに依頼することを特徴とするデータ共有方法。
【請求項８】
請求項１において、
第１のデータを元に、通信相手との通信で用いる暗号化鍵を生成することを特徴とするデータ共有方法。
【請求項９】
請求項１から８のいずれか１項のデータ共有方法を実行するためのプログラム。
【請求項１０】
通信相手と第１のデータを共有するためのデータ共有装置であって、
第２のデータを第３のデータから依頼計算を用いて求める依頼計算手段と、
通信相手が第１のデータを求めるための第４のデータを、第２のデータ及び第５のデータから生成する生成手段を有し、
前記依頼計算手段は、通信相手と共有する第１のデータを、第３のデータ及び第７のデータから生成される第６のデータから、依頼計算を用いて求めることを特徴とするデータ共有装置。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】００３５
【補正方法】変更
【補正の内容】
【００３５】
前記第１の発明により、前述のような総当たり攻撃に対する耐性を高めることができる。
【手続補正３】
【補正対象書類名】明細書
【補正対象項目名】０１２４
【補正方法】変更
【補正の内容】
【０１２４】
ステップＳ７０６でＲｅｓｐｏｎｄｅｒは、ｙ＿ｒｉを求める。このｙ＿ｒｉは、図４のステップＳ４０４Ａ、Ｓ４０４Ｂと同様に求めることができる。ｙ＿ｒｉを基にして暗号化の鍵を生成し、ＨＡＳＨ＿Ｒを求める。ｉｄｅｎｔｉｆｉｃａｔｉｏｎ  ｐａｙｌｏａｄ  ＩＤｉｒとＨＡＳＨ＿Ｒを暗号化したデータをＩｎｉｔｉａｔｏｒに送る。
【手続補正４】
【補正対象書類名】明細書
【補正対象項目名】０１５４
【補正方法】変更
【補正の内容】
【０１５４】
ステップＳ９０１でＩｎｉｔｉａｔｏｒは、依頼計算のパラメータＤ＿ｉとＦ＿ｉ、Ｄ＿ｉ’とＦ＿ｉ’を決定し、ＳＡのプロポーザルをＩＫＥ−ｐｒｏｘｙ経由でＲｅｓｐｏｎｄｅｒに送る。また、Ｄ＿ｉとＤ＿ｉ’をＩＫＥ−Ｐｒｏｘｙに送る。