JP3699618B2 - 暗号鍵取得方法及び暗号鍵交換装置 - Google Patents
暗号鍵取得方法及び暗号鍵交換装置 Download PDFInfo
- Publication number
- JP3699618B2 JP3699618B2 JP27042699A JP27042699A JP3699618B2 JP 3699618 B2 JP3699618 B2 JP 3699618B2 JP 27042699 A JP27042699 A JP 27042699A JP 27042699 A JP27042699 A JP 27042699A JP 3699618 B2 JP3699618 B2 JP 3699618B2
- Authority
- JP
- Japan
- Prior art keywords
- random number
- encryption key
- value
- generated
- new
- 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.)
- Expired - Fee Related
Links
Images
Description
【０００１】
【発明の属する技術分野】
この発明は、特にインターネット上で行う暗号通信に用いて好適な、共通鍵暗号方式を利用した暗号通信を行う際に用いる暗号鍵交換方法および暗号鍵交換装置に関する。
【０００２】
【従来の技術】
従来より、通信端末装置（クライアント）が電話網を介して最寄りのインターネット接続点に接続（いわゆるダイアルアップ接続）し、さらに、インターネットを介してサーバ側のネットワーク（例えば企業ＬＡＮ（Local Area Network））に接続する場合において、インターネット上を安全に通過するために仮想私設網（Virtual Private Network：ＶＰＮ）を構築するいわゆるダイアルアップＶＰＮが知られている。仮想私設網とは、暗号技術や、認証技術、トンネリング技術などを利用して、インターネット上においても専用線と同様の安全性および利便性を有する通信を実現する技術である。このような仮想私設網機能を実現するネットワークコンポーネントをセキュリティゲートウェイ（Security GateWay：ＳＧＷ）という。
【０００３】
暗号技術としては、公開鍵暗号方式と共通（秘密）鍵暗号方式が広く知られている。
公開鍵暗号方式は、暗号化と復号化で異なる鍵を使用する方式であり、鍵の一方を広く一般に公開し（公開鍵）、他方をクライアントが保有して秘密鍵として管理する。この方式では、公開鍵で暗号化された情報は秘密鍵でしか復号できず、秘密鍵で暗号化された情報は公開鍵でしか復号できないという特徴がある。代表的なものとしては、ＲＳＡなどが知られている。
一方、共通鍵暗号方式は、暗号化と復号化で共通の鍵を使用する方式であり、通信を行う２点間で共通鍵を秘密に管理する。
一般的に、公開鍵暗号方式は共通鍵暗号方式に比べて著しく処理負荷が高いので、共通鍵暗号方式が広く普及しているが、共通鍵暗号方式を用いた場合には、一定量のサンプルデータがあれば一定の時間をかけて解読することが可能であると、一般的に言われている。
すなわち、暗号を終端する２点間において共有する共通鍵として常に同じものを使用して暗号通信を行うと、一定の時間をかけて暗号を第三者に解読されてしまうおそれがある。従って、セキュリティゲートウェイ２１とクライアント３０間で新しいセッションを生成する際や、一定時間あるいは一定データ転送毎に新たな共通鍵を生成して交換する必要がある。
【０００４】
【発明が解決しようとする課題】
ところで、一般的に仮想私設網を終端するセキュリティゲートウェイの負荷としては、
▲１▼パケットルーティング処理や、暗号処理など転送パケット量に比例する負荷▲２▼共通鍵暗号方式の通信を行うために鍵交換を行う負荷
などが代表的なものである。
ここで、クライアント側がモバイル端末の場合には、移動網側がボトルネックとなって、１ユーザが送受するパケット量（スループット）は多くないという特徴がある。
従って、上述した▲１▼の負荷が問題とならず、セキュリティゲートウェイ１台に収容可能なユーザ数が増えることになる。しかしながら、鍵交換に伴う負荷は、収容ユーザ数に比例するので、クライアント側がモバイル端末の場合には、セキュリティゲートウェイ負荷は、相対的に鍵交換に伴う負荷比率が増加する。
【０００５】
ここで、従来の鍵交換技術としては、インターネット・キー・エクスチェンジ（Internet Key Exchange：ＩＫＥ）という、インターネット標準の鍵交換アルゴリズムがある。ＩＫＥは、ディフィーヘルマンの鍵交換法をベースにしており、次のような鍵交換を行う。
予め通信を行う２点間では、大きな素数ｎと生成元ｇを決定しておく。そして、一方はｎ未満の正の乱数ｒ１発生させ、他方はｎ未満の正の乱数ｒ２発生させる。
乱数ｒ１発生させた側は、ｇr1ｍｏｄ（ｎ）を計算し、乱数ｒ２発生させた側はｇr2ｍｏｄ（ｎ）を計算して、インターネット上で交換する。
そして、乱数ｒ１発生させた側は、自己で計算したｇr1ｍｏｄ（ｎ）と他方から受信したｇr2ｍｏｄ（ｎ）を用いてｇr1r2ｍｏｄ（ｎ）を計算し、乱数ｒ２発生させた側は、自己で計算したｇr2ｍｏｄ（ｎ）と他方から受信したｇr1ｍｏｄ（ｎ）を用いてｇr1r2ｍｏｄ（ｎ）を計算し、この両者が得たｇr1r2ｍｏｄ（ｎ）を合意した鍵とする。
【０００６】
しかしながら、上述したＩＫＥでは、ｇr1r2ｍｏｄ（ｎ）を取得するために膨大な量の計算が必要になるという問題がある。この演算で十分な暗号として強度の鍵を得るためには、ｎの値として、３００桁程度の素数を用いる必要があるからである。
特にセキュリティゲートウェイ側は、通常の暗号パケットの送信に加えて、全てのクライアントに対して、鍵交換に伴う計算を行わなければならないので、極めて負荷が大きいという問題がある。
また、ユーザにとっても、計算に時間がかかるので、暗号セッション設定時に数十秒を要するという問題がある。
【０００７】
一方、クライアントの公開鍵暗号で共有鍵を暗号化して配送するという方式も知られているが、クライアントの公開鍵を一元管理するサーバが必要になるという問題がある。この公開鍵を管理するサーバがクラッカーの攻撃対象となりやすく、厳重な防御手段が必要となって結果的にコストが高くなってしまうからである。
【０００８】
本発明は、上述した課題を解決するためになされたものであり、鍵管理サーバを必要とせず、かつ、計算量が少ない暗号鍵交換方法および暗号鍵交換装置を提供することを目的としている。
【０００９】
【課題を解決するための手段】
上述した課題を解決するために、請求項１に記載の発明は、複数種類の種値のセットを記憶した第１の装置と、前記第１の装置に記憶されているものと同じ種値のセットを記憶した第２の装置との間で共有される暗号鍵の取得方法であって、前記第１の装置が、暗号鍵を取得するための所定の一方向性関数の入力値とすべき１つの種値を、自装置に記憶された前記複数種類の種値のうちから選択すると共に、予め定められた規則に従って前記第２の装置との間でやり取りした情報を基に、前記一方向性関数を適用する回数を決定し、前記選択した種値を入力値として前記一方向性関数を前記決定した回数だけ適用することにより、前記第２の装置との間で最初に共有する暗号鍵を取得する初期暗号鍵取得段階と、前記第１の装置が、前記規則に従って前記第２の装置との間で再びやり取りした情報を基に、前記一方向性関数を適用する新たな回数を決定する新規回数決定段階と、前記第１の装置が、前記初期暗号鍵取得段階で選択しなかった種値の１つを自装置に記憶された複数種類の種値のうちから選択する新規種値選択段階と、前記第１の装置が、前記初期暗号鍵取得段階において前記一方向性関数を前記決定した回数よりも所定値少ない回数だけ適用した状態で得ていた適用結果と前記新規種値選択段階で選択した種値とを入力値として、前記一方向性関数を前記新規回数決定段階で決定した回数だけ適用することにより、前記第２の装置との間で新たに共有する暗号鍵を取得する新規暗号鍵取得段階とを有する。
【００１０】
請求項２に記載の発明は、請求項１に記載の暗号鍵取得方法において、前記第１の装置は、前記新規回数決定段階、新規種値選択段階、及び新規暗号鍵取得段階を繰返すことで新たに共有する暗号鍵を順次取得し、２回目以降に行われる各新規種値選択段階では、前記第１の装置が、直前に行った新規種値選択段階で選択しなかった種値の１つを自装置に記憶された複数種類の種値のうちから選択し、２回目以降に行われる各新規暗号鍵取得段階では、前記第１の装置が、直前に行った新規暗号鍵取得段階において前記一方向性関数を前記決定した回数よりも所定値少ない回数だけ適用した状態で得ていた適用結果と前記新規種値選択段階で選択した種値とを入力値として、前記一方向性関数を前記新規回数決定段階で決定した回数だけ適用する。
【００１１】
請求項３に記載の発明は、請求項２に記載の暗号鍵取得方法において、前記第１の装置は、２種類の異なる種値のセットを記憶し、前記繰返される各新規種値選択段階では、、前記第１の装置は、前記２種類の種値を交互に選択する。
請求項４に記載の発明は、請求項２に記載の暗号鍵取得方法において、前記初期暗号鍵取得段階では、前記第１の装置が、前記第２の装置との間で乱数を交換し、交換した乱数に所定の演算を行うことで前記一方向性関数を適用する回数を決定する。
請求項５に記載の発明は、請求項２に記載の暗号鍵取得方法において、前記新規回数決定段階では、前記第１の装置が、前記第２の装置との間で乱数を交換し、交換した乱数に所定の演算を行うことで前記前記一方向性関数を適用する新たな回数を決定する。
【００１２】
請求項６に記載の発明は、請求項１又は２に記載の暗号鍵取得方法において、前記初期暗号鍵取得段階は、前記第２の装置が、自ら発生した第２の乱数値に所定のハッシュ関数を適用して得た暗号化乱数を前記第１の装置へ送信する段階と、前記第１の装置が、前記第２の装置から暗号化乱数を受信した後、自ら発生した第１の乱数値を前記第２の装置へ送信する段階と、前記第２の装置が、前記第１の装置から第１の乱数値を受信した後、前記発生した第２の乱数値を前記第１の装置へ送信する段階と、前記第１の装置が、前記第２の装置から第２の乱数値を受信した後、受信した第２の乱数値に前記ハッシュ関数を適用して得た暗号化乱数が前記第２の装置から受信した暗号化乱数と一致するか判断し、両暗号化乱数が一致すると判断したとき、前記発生した第１の乱数値と前記受信した第２の乱数値とに所定のビット演算を行うことで前記一方向性関数を適用する回数を決定する段階とを有する。
請求項７に記載の発明は、請求項１又は２に記載の暗号鍵取得方法において、前記新規回数決定段階は、前記第２の装置が、自ら発生した第２の乱数値に所定のハッシュ関数を適用して得た暗号化乱数を前記第１の装置へ送信する段階と、前記第１の装置が、前記第２の装置から暗号化乱数を受信した後、自ら発生した第１の乱数値を前記第２の装置へ送信する段階と、前記第２の装置が、前記第１の装置から第１の乱数値を受信した後、前記発生した第２の乱数値を前記第１の装置へ送信する段階と、前記第１の装置が、前記第２の装置から第２の乱数値を受信した後、受信した第２の乱数値に前記ハッシュ関数を適用して得た暗号化乱数が前記第２の装置から受信した暗号化乱数と一致するか判断し、両暗号化乱数が一致すると判断したとき、前記発生した第１の乱数値と前記受信した第２の乱数値とに所定のビット演算を行うことで前記一方向性関数を適用する新たな回数を決定する段階とを有する。
【００１３】
請求項８に記載の発明は、他装置と鍵交換を行い共通鍵暗号方式を用いて情報を送受信する暗号鍵交換装置であって、前記他装置と共通する複数の種値を記憶する種値記憶手段と、一方向性関数の適用回数を前記他装置と鍵共有を行う毎に共通して決定する適用回数決定手段と、前記複数の種値のいずれかを入力値として、決定した前記回数だけ前記一方向性関数を適用した値を前記他装置との共通鍵とする鍵共有手段とを備え、前記鍵共有手段は、前記一方向性関数を直前に適用した回数から所定値減算した回数適用した値を第１の入力値とし、直前の鍵共有段階で用いられなかったいずれかの前記複数の種値から前記他装置との間において共通する規則に従って選択した値とを第２の入力値として、決定された前記適用回数だけ前記一方向性関数を適用した算出値を前記他装置との共通鍵とすることを特徴とする。
【００１４】
請求項９に記載の発明は、請求項８記載の暗号鍵交換装置において、前記複数の種値は２種類の異なる値であり、前記鍵共有手段は、前記２種類の種値を交互に選択することを前記他装置との間において共通する規則とすることを特徴とする。
請求項１０に記載の発明は、請求項８記載の暗号鍵交換装置において、前記適用回数決定手段は、自装置において発生させた乱数を前記他装置において発生させた乱数と交換し、自装置で発生させた乱数と他装置にて発生させた乱数とに所定の演算を行って前記一方向性関数の適用回数を決定することを特徴とする。
【００１５】
請求項１１に記載の発明は、請求項８記載の暗号鍵交換装置において、前記適用回数決定手段は、乱数を発生させる乱数発生手段と、前記乱数発生手段が発生させた乱数を入力値として前記一方向性関数を適用して生成した暗号化乱数を前記他装置に送信する暗号化乱数送信手段と、前記暗号化乱数の送信に応じて前記他装置から送信された乱数を受信する乱数受信手段と、前記乱数受信手段における受信に応じて、前記乱数発生手段が発生させた乱数を送信する乱数送信手段とを備え、前記乱数発生手段が発生させた乱数と前記乱数受信手段が受信した乱数とに所定の演算を行って前記一方向性関数の適用回数を決定することを特徴とする。
請求項１２に記載の発明は、請求項８記載の暗号鍵交換装置において、前記適用回数決定手段は、乱数を発生させる乱数発生手段と、前記他装置が発生させた乱数を入力値として前記一方向性関数を適用して生成した暗号化乱数を前記他装置から受信する暗号化乱数受信手段と、前記乱数発生手段が発生した乱数を前記暗号化乱数の受信に応じて前記他装置へ送信する乱数送信手段と、前記乱数の送信に応じて前記他装置が発信した乱数を受信する乱数受信手段とを備え、前記乱数受信手段が受信した乱数を入力値として前記一方向性関数を適用して生成した暗号化乱数が、前記暗号化乱数受信手段が受信した暗号化乱数と一致する場合に、前記乱数発生手段が発生した乱数と前記乱数受信手段が受信した乱数とに所定の演算を行って前記一方向性関数の適用回数を決定することを特徴とする。
【００１６】
【発明の実施の形態】
以下、図面を参照しながら本発明の実施の形態について説明する。
【００１７】
［１．実施形態の概要］
［１−１．実施形態の構成］
図１は実施形態の全体構成を示す図である。図１に示すように、本実施形態では、インターネット１０に仮想私設網１１が設定されており、企業ＬＡＮ２０に対してクライアント３０が接続できるようにようになっている。セキュリティゲートウェイ２１は、仮想私設網１１を終端するサーバである。
本実施形態では、クライアント３０はモバイル端末であり、図示を略した移動通信網やゲートウェイサーバなどを介してい１０に接続されている。
従来技術においても説明したように、インターネット１０におけるパケットの盗聴等を防止するために公開鍵暗号方式を用いると、共通鍵暗号方式用いた場合と比較して著しく処理負荷が高いので、本実施形態では、セキュリティゲートウェイ２１とクライアント３０との間の通信には共通鍵暗号方式を用いる。従って、セキュリティゲートウェイ２１とクライアント３０は、共通鍵を交換して共有する必要がある。
しかしながら、鍵を平文のままインターネット１０上で送信すると、鍵データそのものを盗聴される可能性があるので、本実施形態では、後に詳しく説明するように、セキュリティゲートウェイ２１とクライアント３０間で予め共有する種値を入力値とした一方向性関数を所定回数適用したものを共通鍵として共有するものとし、新たな共通鍵を生成する際には、一方向性関数の適用回数をインターネット１０上で交換するようにしている。
【００１８】
［１−２．一方向性関数］
次に、図２を参照しながら、本実施形態で用いる一方向性関数について説明する。
一方向性関数とは、関数値ｙ＝ｆ（ｘ）の逆関数ｘ＝ｆ-1（ｙ）を求めることが極めて困難な関数である。例えば、従来技術で説明したディフィーヘルマン法では、関数値ｇr1r2ｍｏｄ（ｎ）から、変数値ｒ１，ｒ２を求めることが極めて困難であるという、整数の特徴を基礎においている。
本実施形態では、一方向性関数として計算の容易なハッシュ関数を用いる。ハッシュ関数とは、任意長の入力データを圧縮して固定長のデータを出力する特殊な関数であり、主として改ざん防止や認証などに用いられている。
ハッシュ関数としては、インターネット標準の一方向性ハッシュ関数であるＭＤ５や、ＳＨＡ−１などが知られている。
【００１９】
本実施形態では、図２に示すように、任意の２入力型の一方向性ハッシュ関数を“Ｈｎ（Ｓ，ａ）”と表記する。ここで、２入力型ハッシュ関数“Ｈｎ（Ｓ，ａ）”とは、例えば、二つの種Ｓ，ａをｂｉｔ結合するなどの処理により、通常のハッシュ関数Ｈ（Ｘ）へ二つの入力値を利用可能としたものである。また、“ｎ”はハッシュ関数“Ｈ（Ｓ，ａ）”の適用回数を示し、“Ｓ”および“ａ”は入力値を示している。なお、このハッシュ関数は、図２に示すように、
Ｈｎ＋１（Ｓ，ａ）＝Ｈ（Ｈｎ（Ｓ，ａ），ａ）
Ｈｎ（Ｓ，ａ）＝Ｈ（Ｈｎ−１（Ｓ，ａ），ａ）
と表す。この場合に、一方向性は、Ｈｎ−１→Ｈｎの方向に作用し、Ｈｎ−１からＨｎを求めることは容易であるが、ＨｎからＨｎ−１を求めることは極めて困難となる。
本実施形態では、この一方向性を利用して、前回の共通鍵生成時に“Ｈｎ”を用いた場合には、新たな共通鍵を生成する際には“Ｈｎ−１”を用いることによって、仮に前回の共通鍵生成に用いた“Ｈｎ”が解読された場合であっても、次回の共通鍵を算出することを極めて困難にする。
【００２０】
［２．鍵交換アルゴリズム］
次に、上述した一方向性関数を用いた本実施形態における鍵交換アルゴリズムについて説明する。先に簡単に説明したように、セキュリティゲートウェイ２１とクライアント３０間で予め共有する種値を入力値とした一方向性関数を所定回数適用して共通鍵をそれぞれ生成し、その後インターネット１０上で新たに交換した回数をハッシュ関数に適用して共通鍵をそれぞれ生成する。
以下、セキュリティゲートウェイ２１とクライアント３０間でそれぞれ共通鍵を生成するアルゴリズムと、インターネット１０上で交換する一方向性関数適用回数を決定するアルゴリズムについて、それぞれ詳しく説明する。
【００２１】
［２−１．共通鍵生成アルゴリズム］
まず、図３を参照しながら、本実施形態における共通鍵生成アルゴリズムについて説明する。
セキュリティゲートウェイ２およびクライアント３０は、種となる２種類のデータ“ｓ１”および“ｓ２”をそれぞれ予め記憶している。この種“ｓ１”および“ｓ２”は、ハッシュ関数“Ｈｎ（Ｓ，ａ）”の入力値となるデータとなる。ハッシュ関数の適用回数“ｎ”は、セキュリティゲートウェイ２およびクライアント３０間でネゴシエーションによって決定するものとし、共通鍵を生成する度に新たに決定される値である。なお、ネゴシエーションについては、一方向性関数適用回数決定アルゴリズムとして後に詳しく説明する。
【００２２】
図３においては、１回目の共通鍵共有から３回目までの共通鍵共有までを例示している。図３中、“Ｋ１”は１回目の共通鍵であり、“Ｋ２”は２回目の共通鍵であり、“Ｋ３”は３回目の共通鍵である。また、“ｎ１”は１回目のハッシュ関数適用回数であり、“ｎ２”は２回目のハッシュ関数適用回数であり、“ｎ３”は３回目のハッシュ関数適用回数である。
まず、１回目の共通鍵“Ｋ１”は、次式によって決定される。
Ｋ１＝Ｈｎ１（ｓ１）
すなわち、種“ｓ１”を入力値としてハッシュ関数を“ｎ１”回適用することによって生成される。
【００２３】
次に、２回目の共通鍵“Ｋ２”は、次式によって決定される。
Ｋ２＝Ｈｎ２（Ｈｎ１−１（ｓ１）、ｓ２）
すなわち、前回（１回目）共通鍵を生成した際に用いた“Ｈｎ１”から求めることが極めて困難な“Ｈｎ１−１”を用いることによって、仮に前回の共通鍵Ｋ１（すなわちＨｎ１）が解読された場合であっても、新たな共通鍵生成には、“Ｈｎ１−１”を入力値として使用するので、Ｈｎ１から、Ｈｎ２（すなわちＫ２）算出されないようにしている（一方向性）。
なお、入力値のもう一つには、前回（１回目）共通鍵を生成した際に用いた種“ｓ１”とは異なる種“ｓ２”を用いている。仮に、入力値のもう一つに前回（１回目）共通鍵を生成した際に用いた種“ｓ１”と同じ種“ｓ１”を用いると、
となり、前回（１回目）の共通鍵“Ｋ１＝Ｈｎ１（ｓ１）”から容易に計算可能となってしまうからである。
また、ハッシュ関数の適用回数は、新たに生成した“ｎ２”が用いられ、後に説明するように適用回数自体もインターネット１０上では第三者が入手困難になっているので、更に共通鍵が第三者に解読される可能性が低くなる。
【００２４】
３回目の共通鍵“Ｋ３”は、次式によって決定される。
Ｋ３＝Ｈｎ３（Ｈｎ２−１（ｓ２）、ｓ１）
すなわち、ハッシュ関数の入力値には、前回（２回目）共通鍵を生成した際に用いた“Ｈｎ２”から求めることが極めて困難な“Ｈｎ２−１”および、前回（２回目）共通鍵を生成した際に用いた種“ｓ２”とは異なる種“ｓ１”を用い、ハッシュ関数の適用回数には、新たに生成した“ｎ３”が用いられる。
【００２５】
図３においては、１回目の共通鍵共有から３回目までの共通鍵共有までしか例示されていないが、以後同様に、ハッシュ関数の入力値には、前回共通鍵を生成した際に用いた“Ｈｎ”から求めることが極めて困難な“Ｈｎ−１”および、前回共通鍵を生成した際に用いた種とは異なる種を用い、ハッシュ関数の適用回数には、新たに生成した回数が用いられる。
従来技術で説明した関数値ｇr1r2ｍｏｄ（ｎ）を求める処理と比較すると、２入力型一方向ハッシュ関数を所定回数適用する処理は極めて軽いので、セキュリティゲートウェイ２１およびクライアント３０における処理負担が大幅に軽減される。
【００２６】
［２−２．一方向性関数適用回数決定アルゴリズム］
次に、図４〜図６を参照しながら、セキュリティゲートウェイ２１およびクライアント３０間でネゴシエーションを行って一方向性関数適用回数を決定するためのアルゴリズムについて説明する。なお、図４〜図６には、１回目の共通鍵生成時における例を示している。
【００２７】
［２−２−１．例１］
例１は、一方が適用回数“ｎ１”を生成して、他方に送信するものである。図４に示す例では、セキュリティゲートウェイ２１が適用回数“ｎ１”を生成している。セキュリティゲートウェイ２１は、乱数“Ｒｙ１”を発生し、この乱数“Ｒｙ１”に所定のビット演算を行うことによって、新たな適用回数“ｎ１”を生成してクライアント３０に送信する。
しかしながら、一方が常に新たな適用回数“ｎ”を生成することは、セキュリティ上の問題がある。使用されるすべての適用回数“ｎ１”“ｎ２”……を予めセキュリティゲートウェイ２１が所有することができるようになるからである。
【００２８】
［２−２−２．例２］
そこで、例２は、セキュリティゲートウェイ２１およびクライアント３０がそれぞれ乱数を発生させて、お互いに乱数を交換するようにしている。図５に示す例では、セキュリティゲートウェイ２１が乱数“Ｒｙ１”を発生させ、クライアント３０が乱数“Ｒｘ１”を発生させている。そして、インターネット１０上で乱数“Ｒｘ１”および“Ｒｙ１”を交換し、セキュリティゲートウェイ２１およびクライアント３０は、それぞれ、自己で発生させた乱数と他方から送信された乱数とに所定のビット演算を行って新たな適用回数“ｎ１”を生成する。
乱数“Ｒｘ１”および“Ｒｙ１”を交換することによって、セキュリティゲートウェイ２１およびクライアント３０は、いずれも乱数“Ｒｘ１”および“Ｒｙ１”を保有するので、共通する適用回数“ｎ１”を得ることができる。
【００２９】
この例では、セキュリティゲートウェイ２１およびクライアント３０は、それぞれ乱数を発生させているので、例１で示唆したような予め一方が適用回数を所有しうるという問題は解消できる。
しかしながら、乱数を交換する際に、一方が他方よりも先に送信する場合には、次のような問題がある。例えば、図５に示すように、まずクライアント３０が乱数“Ｒｘ１”をセキュリティゲートウェイ２１に送信し、セキュリティゲートウェイ２１は乱数“Ｒｘ１”を受信した後に乱数“Ｒｙ１”をクライアント３０に送信するような場合を考える。
仮にセキュリティゲートウェイ２１が、予め適用回数“ｎ１”を所有していたとすると、クライアント３０から送信された乱数“Ｒｘ１”と適用回数“ｎ１”とから乱数“Ｒｙ１”となるべき値を逆算して、クライアント３０に送信することが可能となる。
従って、例２においても、使用されるすべての適用回数“ｎ１”“ｎ２”……を予めセキュリティゲートウェイ２１が所有することができるようになってしまう。
【００３０】
［２−２−３．例３］
そこで、例３では、セキュリティゲートウェイ２１およびクライアント３０がそれぞれ乱数を発生させて、お互いに乱数を交換するのだが、まず一方が自己で発生させた乱数を他方に送信し、他方が発生させた乱数を受信した後に、再度自己で発生させた乱数を送信するようにしている。
このとき、乱数をすべて平文で送信すると、最初に乱数を他方に送信する側では、使用されるすべての適用回数“ｎ１”“ｎ２”……を予め所有することはできないが、後に乱数を他方に送信する側では、使用されるすべての適用回数“ｎ１”“ｎ２”……を予め所有することができることになってしまう。
そこで、例３では、先に送信する乱数にハッシュ関数を適用した暗号化乱数を他方に送信する。
図６に示す例では、セキュリティゲートウェイ２１が乱数“Ｒｙ１”を発生させ、乱数“Ｒｙ１”を入力値としてハッシュ関数を適用した暗号化乱数（図中、Ｈ（Ｒｙ１）と示している）をクライアント３０に送信する。この時点では、クライアント３０は、セキュリティゲートウェイ２１が発生させた乱数“Ｒｙ１”を暗号化乱数“Ｈ（Ｒｙ１）”から算出することができないので、予め所有している適用回数から算出した乱数をセキュリティゲートウェイ２１に送信することはできない。
クライアント３０は、発生させた乱数“Ｒｘ１”を、暗号化乱数“Ｈ（Ｒｙ１）”を受信した後に平文でセキュリティゲートウェイ２１に送信し、セキュリティゲートウェイ２１は、クライアント３０から乱数“Ｒｘ１”受信した後に、乱数“Ｒｙ１”を平文で送信する。
【００３１】
クライアント３０は、先に受信した暗号化乱数“Ｈ（Ｒｙ１）”と、２回目に受信した乱数“Ｒｙ１”を入力値としてハッシュ関数を適用した暗号化乱数“Ｈ（Ｒｙ１）”が一致した場合には、例２と同様に自己で発生させた乱数“Ｒｘ１”と他方から送信された乱数“Ｒｙ１”とに所定のビット演算を行って新たな適用回数“ｎ１”を生成する。
先に乱数を送信する側であるセキュリティゲートウェイ２１は、他方のクライアント３０から乱数“Ｒｘ１”を受信すると、自己で発生させた乱数“Ｒｙ１”と他方から送信された乱数“Ｒｘ１”とに所定のビット演算を行って新たな適用回数“ｎ１”を生成する。
例３においても、乱数“Ｒｘ１”および“Ｒｙ１”を交換することによって、セキュリティゲートウェイ２１およびクライアント３０は、いずれも乱数“Ｒｘ１”および“Ｒｙ１”を保有するので、共通する適用回数“ｎ１”を得ることができる。
さらに、一方は他方に先だって乱数を送信し、他方から乱数を受信した後に、先に送信した乱数を再度送信するので、例２において説明したような、予め一方が適用回数を所有しておくという可能性がなくなる。
また、最初に乱数を他方に送信する側は、発生させた乱数を暗号化した暗号化乱数を他方に送信することによって、後に乱数を送信する側は他方が発生させた乱数をその時点では算出することができないので、例２において説明したような、予め一方が適用回数を所有しておくという可能性がなくなる。
【００３２】
本実施形態で説明した共通鍵交換方法によれば、鍵そのものをインターネット１０上で交換するのではなく、ハッシュ関数の適用回数を交換するので、共通鍵そのものが盗聴される危険性が減少する。
適用回数につては、暗号通信を行う２点間でネゴシエーションして毎回新たに決定するので、一方が予め適用回数を決定しておこくとができず、第三者は、Ｒｘ１、Ｒｙ１を盗聴することにより、適用回数を取得することができたとしても、Ｓ１、Ｓ２の値を取得しない限り、適用回数から、暗号鍵を計算することはできない。
このように、ハッシュ関数の適用回数は毎回変更される上、一方向性を利用した値および、予め２点間で秘密に共有した複数の種を入力値として用いるので、一度共通鍵が解読されても、その後生成される共通鍵を解読するのは極めて困難となり、セキュリティが向上する。
しかも、暗号化の演算としては、ハッシュ関数やビット演算などの比較的軽い処理を用いて実現できるので、管理サーバを必要とせず、かつ、計算量が少ない暗号鍵交換が可能となる。
【００３３】
［３．変形例］
本発明は、上述した実施形態に限定されるものではなく、以下のような各種の変形が可能である。
【００３４】
上記実施形態では、本発明にかかる暗号鍵交換方法をモバイルＶＰＮに適用した場合を例として説明しているが、これに限らず、２点間で行う暗号通信に広く適用可能である。なお、暗号鍵交換装置としては、従来から用いられているコンピュータなどの演算装置を用いて実現可能であるので構成については詳細な説明を省略した。
【００３５】
上記実施形態では、一方向性関数としてハッシュ関数をあげて説明したが、逆関数を求めることが極めて困難な関数であればハッシュ関数に限らず他の関数を用いても良い。また、２入力型ハッシュ関数についても、上記実施形態で説明した例に限らず、他の方法で実現しても構わない。
【００３６】
また、適用回数のネゴシエーション例として上記実施形態では例１〜３をあげて説明したが、毎回新たな適用回数を生成できれば必ずしもこれらに限定されるものではない。
種についても、上記実施形態では２種類のデータをあげて説明しているが、複数であれば数は限定されない。また、一方向性関数の入力値として種を交互に使用することも限定されるものではなく、暗号通信を行う２点間で、前回と異なる種を用いるパターンの一致がなされていれば、どのようなパターンでも構わない。
【００３７】
【発明の効果】
以上説明したように、本発明によれば、鍵管理サーバを必要とせず、かつ、計算量が少ない暗号鍵交換が可能となる。
【図面の簡単な説明】
【図１】 実施形態の全体構成を示す図である。
【図２】 実施形態で用いるハッシュ関数について説明する図である。
【図３】 実施形態における鍵交換アルゴリズムを説明する図である。
【図４】 ハッシュ関数適用回数決定アルゴリズムの例を示す図である（例１）。
【図５】 ハッシュ関数適用回数決定アルゴリズムの例を示す図である（例２）。
【図６】 ハッシュ関数適用回数決定アルゴリズムの例を示す図である（例３）。
【符号の説明】
１０……インターネット、
１１……仮想私設網、
２０……企業ＬＡＮ、
２１……セキュリティゲートウェイ、
３０……クライアント。
【発明の属する技術分野】
この発明は、特にインターネット上で行う暗号通信に用いて好適な、共通鍵暗号方式を利用した暗号通信を行う際に用いる暗号鍵交換方法および暗号鍵交換装置に関する。
【０００２】
【従来の技術】
従来より、通信端末装置（クライアント）が電話網を介して最寄りのインターネット接続点に接続（いわゆるダイアルアップ接続）し、さらに、インターネットを介してサーバ側のネットワーク（例えば企業ＬＡＮ（Local Area Network））に接続する場合において、インターネット上を安全に通過するために仮想私設網（Virtual Private Network：ＶＰＮ）を構築するいわゆるダイアルアップＶＰＮが知られている。仮想私設網とは、暗号技術や、認証技術、トンネリング技術などを利用して、インターネット上においても専用線と同様の安全性および利便性を有する通信を実現する技術である。このような仮想私設網機能を実現するネットワークコンポーネントをセキュリティゲートウェイ（Security GateWay：ＳＧＷ）という。
【０００３】
暗号技術としては、公開鍵暗号方式と共通（秘密）鍵暗号方式が広く知られている。
公開鍵暗号方式は、暗号化と復号化で異なる鍵を使用する方式であり、鍵の一方を広く一般に公開し（公開鍵）、他方をクライアントが保有して秘密鍵として管理する。この方式では、公開鍵で暗号化された情報は秘密鍵でしか復号できず、秘密鍵で暗号化された情報は公開鍵でしか復号できないという特徴がある。代表的なものとしては、ＲＳＡなどが知られている。
一方、共通鍵暗号方式は、暗号化と復号化で共通の鍵を使用する方式であり、通信を行う２点間で共通鍵を秘密に管理する。
一般的に、公開鍵暗号方式は共通鍵暗号方式に比べて著しく処理負荷が高いので、共通鍵暗号方式が広く普及しているが、共通鍵暗号方式を用いた場合には、一定量のサンプルデータがあれば一定の時間をかけて解読することが可能であると、一般的に言われている。
すなわち、暗号を終端する２点間において共有する共通鍵として常に同じものを使用して暗号通信を行うと、一定の時間をかけて暗号を第三者に解読されてしまうおそれがある。従って、セキュリティゲートウェイ２１とクライアント３０間で新しいセッションを生成する際や、一定時間あるいは一定データ転送毎に新たな共通鍵を生成して交換する必要がある。
【０００４】
【発明が解決しようとする課題】
ところで、一般的に仮想私設網を終端するセキュリティゲートウェイの負荷としては、
▲１▼パケットルーティング処理や、暗号処理など転送パケット量に比例する負荷▲２▼共通鍵暗号方式の通信を行うために鍵交換を行う負荷
などが代表的なものである。
ここで、クライアント側がモバイル端末の場合には、移動網側がボトルネックとなって、１ユーザが送受するパケット量（スループット）は多くないという特徴がある。
従って、上述した▲１▼の負荷が問題とならず、セキュリティゲートウェイ１台に収容可能なユーザ数が増えることになる。しかしながら、鍵交換に伴う負荷は、収容ユーザ数に比例するので、クライアント側がモバイル端末の場合には、セキュリティゲートウェイ負荷は、相対的に鍵交換に伴う負荷比率が増加する。
【０００５】
ここで、従来の鍵交換技術としては、インターネット・キー・エクスチェンジ（Internet Key Exchange：ＩＫＥ）という、インターネット標準の鍵交換アルゴリズムがある。ＩＫＥは、ディフィーヘルマンの鍵交換法をベースにしており、次のような鍵交換を行う。
予め通信を行う２点間では、大きな素数ｎと生成元ｇを決定しておく。そして、一方はｎ未満の正の乱数ｒ１発生させ、他方はｎ未満の正の乱数ｒ２発生させる。
乱数ｒ１発生させた側は、ｇr1ｍｏｄ（ｎ）を計算し、乱数ｒ２発生させた側はｇr2ｍｏｄ（ｎ）を計算して、インターネット上で交換する。
そして、乱数ｒ１発生させた側は、自己で計算したｇr1ｍｏｄ（ｎ）と他方から受信したｇr2ｍｏｄ（ｎ）を用いてｇr1r2ｍｏｄ（ｎ）を計算し、乱数ｒ２発生させた側は、自己で計算したｇr2ｍｏｄ（ｎ）と他方から受信したｇr1ｍｏｄ（ｎ）を用いてｇr1r2ｍｏｄ（ｎ）を計算し、この両者が得たｇr1r2ｍｏｄ（ｎ）を合意した鍵とする。
【０００６】
しかしながら、上述したＩＫＥでは、ｇr1r2ｍｏｄ（ｎ）を取得するために膨大な量の計算が必要になるという問題がある。この演算で十分な暗号として強度の鍵を得るためには、ｎの値として、３００桁程度の素数を用いる必要があるからである。
特にセキュリティゲートウェイ側は、通常の暗号パケットの送信に加えて、全てのクライアントに対して、鍵交換に伴う計算を行わなければならないので、極めて負荷が大きいという問題がある。
また、ユーザにとっても、計算に時間がかかるので、暗号セッション設定時に数十秒を要するという問題がある。
【０００７】
一方、クライアントの公開鍵暗号で共有鍵を暗号化して配送するという方式も知られているが、クライアントの公開鍵を一元管理するサーバが必要になるという問題がある。この公開鍵を管理するサーバがクラッカーの攻撃対象となりやすく、厳重な防御手段が必要となって結果的にコストが高くなってしまうからである。
【０００８】
本発明は、上述した課題を解決するためになされたものであり、鍵管理サーバを必要とせず、かつ、計算量が少ない暗号鍵交換方法および暗号鍵交換装置を提供することを目的としている。
【０００９】
【課題を解決するための手段】
上述した課題を解決するために、請求項１に記載の発明は、複数種類の種値のセットを記憶した第１の装置と、前記第１の装置に記憶されているものと同じ種値のセットを記憶した第２の装置との間で共有される暗号鍵の取得方法であって、前記第１の装置が、暗号鍵を取得するための所定の一方向性関数の入力値とすべき１つの種値を、自装置に記憶された前記複数種類の種値のうちから選択すると共に、予め定められた規則に従って前記第２の装置との間でやり取りした情報を基に、前記一方向性関数を適用する回数を決定し、前記選択した種値を入力値として前記一方向性関数を前記決定した回数だけ適用することにより、前記第２の装置との間で最初に共有する暗号鍵を取得する初期暗号鍵取得段階と、前記第１の装置が、前記規則に従って前記第２の装置との間で再びやり取りした情報を基に、前記一方向性関数を適用する新たな回数を決定する新規回数決定段階と、前記第１の装置が、前記初期暗号鍵取得段階で選択しなかった種値の１つを自装置に記憶された複数種類の種値のうちから選択する新規種値選択段階と、前記第１の装置が、前記初期暗号鍵取得段階において前記一方向性関数を前記決定した回数よりも所定値少ない回数だけ適用した状態で得ていた適用結果と前記新規種値選択段階で選択した種値とを入力値として、前記一方向性関数を前記新規回数決定段階で決定した回数だけ適用することにより、前記第２の装置との間で新たに共有する暗号鍵を取得する新規暗号鍵取得段階とを有する。
【００１０】
請求項２に記載の発明は、請求項１に記載の暗号鍵取得方法において、前記第１の装置は、前記新規回数決定段階、新規種値選択段階、及び新規暗号鍵取得段階を繰返すことで新たに共有する暗号鍵を順次取得し、２回目以降に行われる各新規種値選択段階では、前記第１の装置が、直前に行った新規種値選択段階で選択しなかった種値の１つを自装置に記憶された複数種類の種値のうちから選択し、２回目以降に行われる各新規暗号鍵取得段階では、前記第１の装置が、直前に行った新規暗号鍵取得段階において前記一方向性関数を前記決定した回数よりも所定値少ない回数だけ適用した状態で得ていた適用結果と前記新規種値選択段階で選択した種値とを入力値として、前記一方向性関数を前記新規回数決定段階で決定した回数だけ適用する。
【００１１】
請求項３に記載の発明は、請求項２に記載の暗号鍵取得方法において、前記第１の装置は、２種類の異なる種値のセットを記憶し、前記繰返される各新規種値選択段階では、、前記第１の装置は、前記２種類の種値を交互に選択する。
請求項４に記載の発明は、請求項２に記載の暗号鍵取得方法において、前記初期暗号鍵取得段階では、前記第１の装置が、前記第２の装置との間で乱数を交換し、交換した乱数に所定の演算を行うことで前記一方向性関数を適用する回数を決定する。
請求項５に記載の発明は、請求項２に記載の暗号鍵取得方法において、前記新規回数決定段階では、前記第１の装置が、前記第２の装置との間で乱数を交換し、交換した乱数に所定の演算を行うことで前記前記一方向性関数を適用する新たな回数を決定する。
【００１２】
請求項６に記載の発明は、請求項１又は２に記載の暗号鍵取得方法において、前記初期暗号鍵取得段階は、前記第２の装置が、自ら発生した第２の乱数値に所定のハッシュ関数を適用して得た暗号化乱数を前記第１の装置へ送信する段階と、前記第１の装置が、前記第２の装置から暗号化乱数を受信した後、自ら発生した第１の乱数値を前記第２の装置へ送信する段階と、前記第２の装置が、前記第１の装置から第１の乱数値を受信した後、前記発生した第２の乱数値を前記第１の装置へ送信する段階と、前記第１の装置が、前記第２の装置から第２の乱数値を受信した後、受信した第２の乱数値に前記ハッシュ関数を適用して得た暗号化乱数が前記第２の装置から受信した暗号化乱数と一致するか判断し、両暗号化乱数が一致すると判断したとき、前記発生した第１の乱数値と前記受信した第２の乱数値とに所定のビット演算を行うことで前記一方向性関数を適用する回数を決定する段階とを有する。
請求項７に記載の発明は、請求項１又は２に記載の暗号鍵取得方法において、前記新規回数決定段階は、前記第２の装置が、自ら発生した第２の乱数値に所定のハッシュ関数を適用して得た暗号化乱数を前記第１の装置へ送信する段階と、前記第１の装置が、前記第２の装置から暗号化乱数を受信した後、自ら発生した第１の乱数値を前記第２の装置へ送信する段階と、前記第２の装置が、前記第１の装置から第１の乱数値を受信した後、前記発生した第２の乱数値を前記第１の装置へ送信する段階と、前記第１の装置が、前記第２の装置から第２の乱数値を受信した後、受信した第２の乱数値に前記ハッシュ関数を適用して得た暗号化乱数が前記第２の装置から受信した暗号化乱数と一致するか判断し、両暗号化乱数が一致すると判断したとき、前記発生した第１の乱数値と前記受信した第２の乱数値とに所定のビット演算を行うことで前記一方向性関数を適用する新たな回数を決定する段階とを有する。
【００１３】
請求項８に記載の発明は、他装置と鍵交換を行い共通鍵暗号方式を用いて情報を送受信する暗号鍵交換装置であって、前記他装置と共通する複数の種値を記憶する種値記憶手段と、一方向性関数の適用回数を前記他装置と鍵共有を行う毎に共通して決定する適用回数決定手段と、前記複数の種値のいずれかを入力値として、決定した前記回数だけ前記一方向性関数を適用した値を前記他装置との共通鍵とする鍵共有手段とを備え、前記鍵共有手段は、前記一方向性関数を直前に適用した回数から所定値減算した回数適用した値を第１の入力値とし、直前の鍵共有段階で用いられなかったいずれかの前記複数の種値から前記他装置との間において共通する規則に従って選択した値とを第２の入力値として、決定された前記適用回数だけ前記一方向性関数を適用した算出値を前記他装置との共通鍵とすることを特徴とする。
【００１４】
請求項９に記載の発明は、請求項８記載の暗号鍵交換装置において、前記複数の種値は２種類の異なる値であり、前記鍵共有手段は、前記２種類の種値を交互に選択することを前記他装置との間において共通する規則とすることを特徴とする。
請求項１０に記載の発明は、請求項８記載の暗号鍵交換装置において、前記適用回数決定手段は、自装置において発生させた乱数を前記他装置において発生させた乱数と交換し、自装置で発生させた乱数と他装置にて発生させた乱数とに所定の演算を行って前記一方向性関数の適用回数を決定することを特徴とする。
【００１５】
請求項１１に記載の発明は、請求項８記載の暗号鍵交換装置において、前記適用回数決定手段は、乱数を発生させる乱数発生手段と、前記乱数発生手段が発生させた乱数を入力値として前記一方向性関数を適用して生成した暗号化乱数を前記他装置に送信する暗号化乱数送信手段と、前記暗号化乱数の送信に応じて前記他装置から送信された乱数を受信する乱数受信手段と、前記乱数受信手段における受信に応じて、前記乱数発生手段が発生させた乱数を送信する乱数送信手段とを備え、前記乱数発生手段が発生させた乱数と前記乱数受信手段が受信した乱数とに所定の演算を行って前記一方向性関数の適用回数を決定することを特徴とする。
請求項１２に記載の発明は、請求項８記載の暗号鍵交換装置において、前記適用回数決定手段は、乱数を発生させる乱数発生手段と、前記他装置が発生させた乱数を入力値として前記一方向性関数を適用して生成した暗号化乱数を前記他装置から受信する暗号化乱数受信手段と、前記乱数発生手段が発生した乱数を前記暗号化乱数の受信に応じて前記他装置へ送信する乱数送信手段と、前記乱数の送信に応じて前記他装置が発信した乱数を受信する乱数受信手段とを備え、前記乱数受信手段が受信した乱数を入力値として前記一方向性関数を適用して生成した暗号化乱数が、前記暗号化乱数受信手段が受信した暗号化乱数と一致する場合に、前記乱数発生手段が発生した乱数と前記乱数受信手段が受信した乱数とに所定の演算を行って前記一方向性関数の適用回数を決定することを特徴とする。
【００１６】
【発明の実施の形態】
以下、図面を参照しながら本発明の実施の形態について説明する。
【００１７】
［１．実施形態の概要］
［１−１．実施形態の構成］
図１は実施形態の全体構成を示す図である。図１に示すように、本実施形態では、インターネット１０に仮想私設網１１が設定されており、企業ＬＡＮ２０に対してクライアント３０が接続できるようにようになっている。セキュリティゲートウェイ２１は、仮想私設網１１を終端するサーバである。
本実施形態では、クライアント３０はモバイル端末であり、図示を略した移動通信網やゲートウェイサーバなどを介してい１０に接続されている。
従来技術においても説明したように、インターネット１０におけるパケットの盗聴等を防止するために公開鍵暗号方式を用いると、共通鍵暗号方式用いた場合と比較して著しく処理負荷が高いので、本実施形態では、セキュリティゲートウェイ２１とクライアント３０との間の通信には共通鍵暗号方式を用いる。従って、セキュリティゲートウェイ２１とクライアント３０は、共通鍵を交換して共有する必要がある。
しかしながら、鍵を平文のままインターネット１０上で送信すると、鍵データそのものを盗聴される可能性があるので、本実施形態では、後に詳しく説明するように、セキュリティゲートウェイ２１とクライアント３０間で予め共有する種値を入力値とした一方向性関数を所定回数適用したものを共通鍵として共有するものとし、新たな共通鍵を生成する際には、一方向性関数の適用回数をインターネット１０上で交換するようにしている。
【００１８】
［１−２．一方向性関数］
次に、図２を参照しながら、本実施形態で用いる一方向性関数について説明する。
一方向性関数とは、関数値ｙ＝ｆ（ｘ）の逆関数ｘ＝ｆ-1（ｙ）を求めることが極めて困難な関数である。例えば、従来技術で説明したディフィーヘルマン法では、関数値ｇr1r2ｍｏｄ（ｎ）から、変数値ｒ１，ｒ２を求めることが極めて困難であるという、整数の特徴を基礎においている。
本実施形態では、一方向性関数として計算の容易なハッシュ関数を用いる。ハッシュ関数とは、任意長の入力データを圧縮して固定長のデータを出力する特殊な関数であり、主として改ざん防止や認証などに用いられている。
ハッシュ関数としては、インターネット標準の一方向性ハッシュ関数であるＭＤ５や、ＳＨＡ−１などが知られている。
【００１９】
本実施形態では、図２に示すように、任意の２入力型の一方向性ハッシュ関数を“Ｈｎ（Ｓ，ａ）”と表記する。ここで、２入力型ハッシュ関数“Ｈｎ（Ｓ，ａ）”とは、例えば、二つの種Ｓ，ａをｂｉｔ結合するなどの処理により、通常のハッシュ関数Ｈ（Ｘ）へ二つの入力値を利用可能としたものである。また、“ｎ”はハッシュ関数“Ｈ（Ｓ，ａ）”の適用回数を示し、“Ｓ”および“ａ”は入力値を示している。なお、このハッシュ関数は、図２に示すように、
Ｈｎ＋１（Ｓ，ａ）＝Ｈ（Ｈｎ（Ｓ，ａ），ａ）
Ｈｎ（Ｓ，ａ）＝Ｈ（Ｈｎ−１（Ｓ，ａ），ａ）
と表す。この場合に、一方向性は、Ｈｎ−１→Ｈｎの方向に作用し、Ｈｎ−１からＨｎを求めることは容易であるが、ＨｎからＨｎ−１を求めることは極めて困難となる。
本実施形態では、この一方向性を利用して、前回の共通鍵生成時に“Ｈｎ”を用いた場合には、新たな共通鍵を生成する際には“Ｈｎ−１”を用いることによって、仮に前回の共通鍵生成に用いた“Ｈｎ”が解読された場合であっても、次回の共通鍵を算出することを極めて困難にする。
【００２０】
［２．鍵交換アルゴリズム］
次に、上述した一方向性関数を用いた本実施形態における鍵交換アルゴリズムについて説明する。先に簡単に説明したように、セキュリティゲートウェイ２１とクライアント３０間で予め共有する種値を入力値とした一方向性関数を所定回数適用して共通鍵をそれぞれ生成し、その後インターネット１０上で新たに交換した回数をハッシュ関数に適用して共通鍵をそれぞれ生成する。
以下、セキュリティゲートウェイ２１とクライアント３０間でそれぞれ共通鍵を生成するアルゴリズムと、インターネット１０上で交換する一方向性関数適用回数を決定するアルゴリズムについて、それぞれ詳しく説明する。
【００２１】
［２−１．共通鍵生成アルゴリズム］
まず、図３を参照しながら、本実施形態における共通鍵生成アルゴリズムについて説明する。
セキュリティゲートウェイ２およびクライアント３０は、種となる２種類のデータ“ｓ１”および“ｓ２”をそれぞれ予め記憶している。この種“ｓ１”および“ｓ２”は、ハッシュ関数“Ｈｎ（Ｓ，ａ）”の入力値となるデータとなる。ハッシュ関数の適用回数“ｎ”は、セキュリティゲートウェイ２およびクライアント３０間でネゴシエーションによって決定するものとし、共通鍵を生成する度に新たに決定される値である。なお、ネゴシエーションについては、一方向性関数適用回数決定アルゴリズムとして後に詳しく説明する。
【００２２】
図３においては、１回目の共通鍵共有から３回目までの共通鍵共有までを例示している。図３中、“Ｋ１”は１回目の共通鍵であり、“Ｋ２”は２回目の共通鍵であり、“Ｋ３”は３回目の共通鍵である。また、“ｎ１”は１回目のハッシュ関数適用回数であり、“ｎ２”は２回目のハッシュ関数適用回数であり、“ｎ３”は３回目のハッシュ関数適用回数である。
まず、１回目の共通鍵“Ｋ１”は、次式によって決定される。
Ｋ１＝Ｈｎ１（ｓ１）
すなわち、種“ｓ１”を入力値としてハッシュ関数を“ｎ１”回適用することによって生成される。
【００２３】
次に、２回目の共通鍵“Ｋ２”は、次式によって決定される。
Ｋ２＝Ｈｎ２（Ｈｎ１−１（ｓ１）、ｓ２）
すなわち、前回（１回目）共通鍵を生成した際に用いた“Ｈｎ１”から求めることが極めて困難な“Ｈｎ１−１”を用いることによって、仮に前回の共通鍵Ｋ１（すなわちＨｎ１）が解読された場合であっても、新たな共通鍵生成には、“Ｈｎ１−１”を入力値として使用するので、Ｈｎ１から、Ｈｎ２（すなわちＫ２）算出されないようにしている（一方向性）。
なお、入力値のもう一つには、前回（１回目）共通鍵を生成した際に用いた種“ｓ１”とは異なる種“ｓ２”を用いている。仮に、入力値のもう一つに前回（１回目）共通鍵を生成した際に用いた種“ｓ１”と同じ種“ｓ１”を用いると、
また、ハッシュ関数の適用回数は、新たに生成した“ｎ２”が用いられ、後に説明するように適用回数自体もインターネット１０上では第三者が入手困難になっているので、更に共通鍵が第三者に解読される可能性が低くなる。
【００２４】
３回目の共通鍵“Ｋ３”は、次式によって決定される。
Ｋ３＝Ｈｎ３（Ｈｎ２−１（ｓ２）、ｓ１）
すなわち、ハッシュ関数の入力値には、前回（２回目）共通鍵を生成した際に用いた“Ｈｎ２”から求めることが極めて困難な“Ｈｎ２−１”および、前回（２回目）共通鍵を生成した際に用いた種“ｓ２”とは異なる種“ｓ１”を用い、ハッシュ関数の適用回数には、新たに生成した“ｎ３”が用いられる。
【００２５】
図３においては、１回目の共通鍵共有から３回目までの共通鍵共有までしか例示されていないが、以後同様に、ハッシュ関数の入力値には、前回共通鍵を生成した際に用いた“Ｈｎ”から求めることが極めて困難な“Ｈｎ−１”および、前回共通鍵を生成した際に用いた種とは異なる種を用い、ハッシュ関数の適用回数には、新たに生成した回数が用いられる。
従来技術で説明した関数値ｇr1r2ｍｏｄ（ｎ）を求める処理と比較すると、２入力型一方向ハッシュ関数を所定回数適用する処理は極めて軽いので、セキュリティゲートウェイ２１およびクライアント３０における処理負担が大幅に軽減される。
【００２６】
［２−２．一方向性関数適用回数決定アルゴリズム］
次に、図４〜図６を参照しながら、セキュリティゲートウェイ２１およびクライアント３０間でネゴシエーションを行って一方向性関数適用回数を決定するためのアルゴリズムについて説明する。なお、図４〜図６には、１回目の共通鍵生成時における例を示している。
【００２７】
［２−２−１．例１］
例１は、一方が適用回数“ｎ１”を生成して、他方に送信するものである。図４に示す例では、セキュリティゲートウェイ２１が適用回数“ｎ１”を生成している。セキュリティゲートウェイ２１は、乱数“Ｒｙ１”を発生し、この乱数“Ｒｙ１”に所定のビット演算を行うことによって、新たな適用回数“ｎ１”を生成してクライアント３０に送信する。
しかしながら、一方が常に新たな適用回数“ｎ”を生成することは、セキュリティ上の問題がある。使用されるすべての適用回数“ｎ１”“ｎ２”……を予めセキュリティゲートウェイ２１が所有することができるようになるからである。
【００２８】
［２−２−２．例２］
そこで、例２は、セキュリティゲートウェイ２１およびクライアント３０がそれぞれ乱数を発生させて、お互いに乱数を交換するようにしている。図５に示す例では、セキュリティゲートウェイ２１が乱数“Ｒｙ１”を発生させ、クライアント３０が乱数“Ｒｘ１”を発生させている。そして、インターネット１０上で乱数“Ｒｘ１”および“Ｒｙ１”を交換し、セキュリティゲートウェイ２１およびクライアント３０は、それぞれ、自己で発生させた乱数と他方から送信された乱数とに所定のビット演算を行って新たな適用回数“ｎ１”を生成する。
乱数“Ｒｘ１”および“Ｒｙ１”を交換することによって、セキュリティゲートウェイ２１およびクライアント３０は、いずれも乱数“Ｒｘ１”および“Ｒｙ１”を保有するので、共通する適用回数“ｎ１”を得ることができる。
【００２９】
この例では、セキュリティゲートウェイ２１およびクライアント３０は、それぞれ乱数を発生させているので、例１で示唆したような予め一方が適用回数を所有しうるという問題は解消できる。
しかしながら、乱数を交換する際に、一方が他方よりも先に送信する場合には、次のような問題がある。例えば、図５に示すように、まずクライアント３０が乱数“Ｒｘ１”をセキュリティゲートウェイ２１に送信し、セキュリティゲートウェイ２１は乱数“Ｒｘ１”を受信した後に乱数“Ｒｙ１”をクライアント３０に送信するような場合を考える。
仮にセキュリティゲートウェイ２１が、予め適用回数“ｎ１”を所有していたとすると、クライアント３０から送信された乱数“Ｒｘ１”と適用回数“ｎ１”とから乱数“Ｒｙ１”となるべき値を逆算して、クライアント３０に送信することが可能となる。
従って、例２においても、使用されるすべての適用回数“ｎ１”“ｎ２”……を予めセキュリティゲートウェイ２１が所有することができるようになってしまう。
【００３０】
［２−２−３．例３］
そこで、例３では、セキュリティゲートウェイ２１およびクライアント３０がそれぞれ乱数を発生させて、お互いに乱数を交換するのだが、まず一方が自己で発生させた乱数を他方に送信し、他方が発生させた乱数を受信した後に、再度自己で発生させた乱数を送信するようにしている。
このとき、乱数をすべて平文で送信すると、最初に乱数を他方に送信する側では、使用されるすべての適用回数“ｎ１”“ｎ２”……を予め所有することはできないが、後に乱数を他方に送信する側では、使用されるすべての適用回数“ｎ１”“ｎ２”……を予め所有することができることになってしまう。
そこで、例３では、先に送信する乱数にハッシュ関数を適用した暗号化乱数を他方に送信する。
図６に示す例では、セキュリティゲートウェイ２１が乱数“Ｒｙ１”を発生させ、乱数“Ｒｙ１”を入力値としてハッシュ関数を適用した暗号化乱数（図中、Ｈ（Ｒｙ１）と示している）をクライアント３０に送信する。この時点では、クライアント３０は、セキュリティゲートウェイ２１が発生させた乱数“Ｒｙ１”を暗号化乱数“Ｈ（Ｒｙ１）”から算出することができないので、予め所有している適用回数から算出した乱数をセキュリティゲートウェイ２１に送信することはできない。
クライアント３０は、発生させた乱数“Ｒｘ１”を、暗号化乱数“Ｈ（Ｒｙ１）”を受信した後に平文でセキュリティゲートウェイ２１に送信し、セキュリティゲートウェイ２１は、クライアント３０から乱数“Ｒｘ１”受信した後に、乱数“Ｒｙ１”を平文で送信する。
【００３１】
クライアント３０は、先に受信した暗号化乱数“Ｈ（Ｒｙ１）”と、２回目に受信した乱数“Ｒｙ１”を入力値としてハッシュ関数を適用した暗号化乱数“Ｈ（Ｒｙ１）”が一致した場合には、例２と同様に自己で発生させた乱数“Ｒｘ１”と他方から送信された乱数“Ｒｙ１”とに所定のビット演算を行って新たな適用回数“ｎ１”を生成する。
先に乱数を送信する側であるセキュリティゲートウェイ２１は、他方のクライアント３０から乱数“Ｒｘ１”を受信すると、自己で発生させた乱数“Ｒｙ１”と他方から送信された乱数“Ｒｘ１”とに所定のビット演算を行って新たな適用回数“ｎ１”を生成する。
例３においても、乱数“Ｒｘ１”および“Ｒｙ１”を交換することによって、セキュリティゲートウェイ２１およびクライアント３０は、いずれも乱数“Ｒｘ１”および“Ｒｙ１”を保有するので、共通する適用回数“ｎ１”を得ることができる。
さらに、一方は他方に先だって乱数を送信し、他方から乱数を受信した後に、先に送信した乱数を再度送信するので、例２において説明したような、予め一方が適用回数を所有しておくという可能性がなくなる。
また、最初に乱数を他方に送信する側は、発生させた乱数を暗号化した暗号化乱数を他方に送信することによって、後に乱数を送信する側は他方が発生させた乱数をその時点では算出することができないので、例２において説明したような、予め一方が適用回数を所有しておくという可能性がなくなる。
【００３２】
本実施形態で説明した共通鍵交換方法によれば、鍵そのものをインターネット１０上で交換するのではなく、ハッシュ関数の適用回数を交換するので、共通鍵そのものが盗聴される危険性が減少する。
適用回数につては、暗号通信を行う２点間でネゴシエーションして毎回新たに決定するので、一方が予め適用回数を決定しておこくとができず、第三者は、Ｒｘ１、Ｒｙ１を盗聴することにより、適用回数を取得することができたとしても、Ｓ１、Ｓ２の値を取得しない限り、適用回数から、暗号鍵を計算することはできない。
このように、ハッシュ関数の適用回数は毎回変更される上、一方向性を利用した値および、予め２点間で秘密に共有した複数の種を入力値として用いるので、一度共通鍵が解読されても、その後生成される共通鍵を解読するのは極めて困難となり、セキュリティが向上する。
しかも、暗号化の演算としては、ハッシュ関数やビット演算などの比較的軽い処理を用いて実現できるので、管理サーバを必要とせず、かつ、計算量が少ない暗号鍵交換が可能となる。
【００３３】
［３．変形例］
本発明は、上述した実施形態に限定されるものではなく、以下のような各種の変形が可能である。
【００３４】
上記実施形態では、本発明にかかる暗号鍵交換方法をモバイルＶＰＮに適用した場合を例として説明しているが、これに限らず、２点間で行う暗号通信に広く適用可能である。なお、暗号鍵交換装置としては、従来から用いられているコンピュータなどの演算装置を用いて実現可能であるので構成については詳細な説明を省略した。
【００３５】
上記実施形態では、一方向性関数としてハッシュ関数をあげて説明したが、逆関数を求めることが極めて困難な関数であればハッシュ関数に限らず他の関数を用いても良い。また、２入力型ハッシュ関数についても、上記実施形態で説明した例に限らず、他の方法で実現しても構わない。
【００３６】
また、適用回数のネゴシエーション例として上記実施形態では例１〜３をあげて説明したが、毎回新たな適用回数を生成できれば必ずしもこれらに限定されるものではない。
種についても、上記実施形態では２種類のデータをあげて説明しているが、複数であれば数は限定されない。また、一方向性関数の入力値として種を交互に使用することも限定されるものではなく、暗号通信を行う２点間で、前回と異なる種を用いるパターンの一致がなされていれば、どのようなパターンでも構わない。
【００３７】
【発明の効果】
以上説明したように、本発明によれば、鍵管理サーバを必要とせず、かつ、計算量が少ない暗号鍵交換が可能となる。
【図面の簡単な説明】
【図１】 実施形態の全体構成を示す図である。
【図２】 実施形態で用いるハッシュ関数について説明する図である。
【図３】 実施形態における鍵交換アルゴリズムを説明する図である。
【図４】 ハッシュ関数適用回数決定アルゴリズムの例を示す図である（例１）。
【図５】 ハッシュ関数適用回数決定アルゴリズムの例を示す図である（例２）。
【図６】 ハッシュ関数適用回数決定アルゴリズムの例を示す図である（例３）。
【符号の説明】
１０……インターネット、
１１……仮想私設網、
２０……企業ＬＡＮ、
２１……セキュリティゲートウェイ、
３０……クライアント。
Claims (12)
- 複数種類の種値のセットを記憶した第１の装置と、前記第１の装置に記憶されているものと同じ種値のセットを記憶した第２の装置との間で共有される暗号鍵の取得方法であって、
前記第１の装置が、暗号鍵を取得するための所定の一方向性関数の入力値とすべき１つの種値を、自装置に記憶された前記複数種類の種値のうちから選択すると共に、予め定められた規則に従って前記第２の装置との間でやり取りした情報を基に、前記一方向性関数を適用する回数を決定し、前記選択した種値を入力値として前記一方向性関数を前記決定した回数だけ適用することにより、前記第２の装置との間で最初に共有する暗号鍵を取得する初期暗号鍵取得段階と、
前記第１の装置が、前記規則に従って前記第２の装置との間で再びやり取りした情報を基に、前記一方向性関数を適用する新たな回数を決定する新規回数決定段階と、
前記第１の装置が、前記初期暗号鍵取得段階で選択しなかった種値の１つを自装置に記憶された複数種類の種値のうちから選択する新規種値選択段階と、
前記第１の装置が、前記初期暗号鍵取得段階において前記一方向性関数を前記決定した回数よりも所定値少ない回数だけ適用した状態で得ていた適用結果と前記新規種値選択段階で選択した種値とを入力値として、前記一方向性関数を前記新規回数決定段階で決定した回数だけ適用することにより、前記第２の装置との間で新たに共有する暗号鍵を取得する新規暗号鍵取得段階と
を有する暗号鍵取得方法。 - 請求項１に記載の暗号鍵取得方法において、
前記第１の装置は、前記新規回数決定段階、新規種値選択段階、及び新規暗号鍵取得段階を繰返すことで新たに共有する暗号鍵を順次取得し、
２回目以降に行われる各新規種値選択段階では、
前記第１の装置が、直前に行った新規種値選択段階で選択しなかった種値の１つを自装置に記憶された複数種類の種値のうちから選択し、
２回目以降に行われる各新規暗号鍵取得段階では、
前記第１の装置が、直前に行った新規暗号鍵取得段階において前記一方向性関数を前記決定した回数よりも所定値少ない回数だけ適用した状態で得ていた適用結果と前記新規種値選択段階で選択した種値とを入力値として、前記一方向性関数を前記新規回数決定段階で決定した回数だけ適用する
暗号鍵取得方法。 - 請求項２に記載の暗号鍵取得方法において、
前記第１の装置は、２種類の異なる種値のセットを記憶し、
前記繰返される各新規種値選択段階では、
前記第１の装置が、
前記２種類の種値を交互に選択することを特徴とする
暗号鍵交換方法。 - 請求項１又は２に記載の暗号鍵取得方法において、
前記初期暗号鍵取得段階では、
前記第１の装置が、
前記第２の装置との間で乱数を交換し、交換した乱数に所定の演算を行うことで前記一方向性関数を適用する回数を決定することを特徴とする
暗号鍵取得方法。 - 請求項１又は２に記載の暗号鍵取得方法において、
前記新規回数決定段階では、
前記第１の装置が、
前記第２の装置との間で乱数を交換し、交換した乱数に所定の演算を行うことで前記前記一方向性関数を適用する新たな回数を決定することを特徴とする
暗号鍵取得方法。 - 請求項１又は２に記載の暗号鍵取得方法において、
前記初期暗号鍵取得段階は、
前記第２の装置が、自ら発生した第２の乱数値に所定のハッシュ関数を適用して得た暗号化乱数を前記第１の装置へ送信する段階と、
前記第１の装置が、前記第２の装置から暗号化乱数を受信した後、自ら発生した第１の乱数値を前記第２の装置へ送信する段階と、
前記第２の装置が、前記第１の装置から第１の乱数値を受信した後、前記発生した第２の乱数値を前記第１の装置へ送信する段階と、
前記第１の装置が、前記第２の装置から第２の乱数値を受信した後、受信した第２の乱数値に前記ハッシュ関数を適用して得た暗号化乱数が前記第２の装置から受信した暗号化乱数と一致するか判断し、両暗号化乱数が一致すると判断したとき、前記発生した第１の乱数値と前記受信した第２の乱数値とに所定のビット演算を行うことで前記一方向性関数を適用する回数を決定する段階と
を有する暗号鍵取得方法。 - 請求項１又は２に記載の暗号鍵取得方法において、
前記新規回数決定段階は、
前記第２の装置が、自ら発生した第２の乱数値に所定のハッシュ関数を適用して得た暗号化乱数を前記第１の装置へ送信する段階と、
前記第１の装置が、前記第２の装置から暗号化乱数を受信した後、自ら発生した第１の乱数値を前記第２の装置へ送信する段階と、
前記第２の装置が、前記第１の装置から第１の乱数値を受信した後、前記発生した第２の乱数値を前記第１の装置へ送信する段階と、
前記第１の装置が、前記第２の装置から第２の乱数値を受信した後、受信した第２の乱数値に前記ハッシュ関数を適用して得た暗号化乱数が前記第２の装置から受信した暗号化乱数と一致するか判断し、両暗号化乱数が一致すると判断したとき、前記発生した第１の乱数値と前記受信した第２の乱数値とに所定のビット演算を行うことで前記一方向性関数を適用する新たな回数を決定する段階と
を有する暗号鍵取得方法。 - 他装置と鍵交換を行い共通鍵暗号方式を用いて情報を送受信する暗号鍵交換装置であって、
前記他装置と共通する複数の種値を記憶する種値記憶手段と、
一方向性関数の適用回数を前記他装置と鍵共有を行う毎に共通して決定する適用回数決定手段と、
前記複数の種値のいずれかを入力値として、決定した前記回数だけ前記一方向性関数を適用した値を前記他装置との共通鍵とする鍵共有手段と
を備え、
前記鍵共有手段は、
前記一方向性関数を直前に適用した回数から所定値減算した回数適用した値を第１の入力値とし、直前の鍵共有段階で用いられなかったいずれかの前記複数の種値から前記他装置との間において共通する規則に従って選択した値とを第２の入力値として、決定された前記適用回数だけ前記一方向性関数を適用した算出値を前記他装置との共通鍵とすることを特徴とする
暗号鍵交換装置。 - 請求項８記載の暗号鍵交換装置において、
前記複数の種値は２種類の異なる値であり、
前記鍵共有手段は、
前記２種類の種値を交互に選択することを前記他装置との間において共通する規則とすることを特徴とする
暗号鍵交換装置。 - 請求項８記載の暗号鍵交換装置において、
前記適用回数決定手段は、
自装置において発生させた乱数を前記他装置において発生させた乱数と交換し、自装置で発生させた乱数と他装置にて発生させた乱数とに所定の演算を行って前記一方向性関数の適用回数を決定することを特徴とする
暗号鍵交換装置。 - 請求項８記載の暗号鍵交換装置において、
前記適用回数決定手段は、
乱数を発生させる乱数発生手段と、
前記乱数発生手段が発生させた乱数を入力値として前記一方向性関数を適用して生成した暗号化乱数を前記他装置に送信する暗号化乱数送信手段と、
前記暗号化乱数の送信に応じて前記他装置から送信された乱数を受信する乱数受信手段と、
前記乱数受信手段における受信に応じて、前記乱数発生手段が発生させた乱数を送信する乱数送信手段と
を備え、
前記乱数発生手段が発生させた乱数と前記乱数受信手段が受信した乱数とに所定の演算を行って前記一方向性関数の適用回数を決定することを特徴とする
暗号鍵交換装置。 - 請求項８記載の暗号鍵交換装置において、
前記適用回数決定手段は、
乱数を発生させる乱数発生手段と、
前記他装置が発生させた乱数を入力値として前記一方向性関数を適用して生成した暗号化乱数を前記他装置から受信する暗号化乱数受信手段と、
前記乱数発生手段が発生した乱数を前記暗号化乱数の受信に応じて前記他装置へ送信する乱数送信手段と、
前記乱数の送信に応じて前記他装置が発信した乱数を受信する乱数受信手段と
を備え、
前記乱数受信手段が受信した乱数を入力値として前記一方向性関数を適用して生成した暗号化乱数が前記暗号化乱数受信手段が受信した暗号化乱数と一致する場合に、前記乱数発生手段が発生した乱数と前記乱数受信手段が受信した乱数とに所定の演算を行って前記一方向性関数の適用回数を決定することを特徴とする
暗号鍵交換装置。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP27042699A JP3699618B2 (ja) | 1999-09-24 | 1999-09-24 | 暗号鍵取得方法及び暗号鍵交換装置 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP27042699A JP3699618B2 (ja) | 1999-09-24 | 1999-09-24 | 暗号鍵取得方法及び暗号鍵交換装置 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2001094548A JP2001094548A (ja) | 2001-04-06 |
| JP3699618B2 true JP3699618B2 (ja) | 2005-09-28 |
Family
ID=17486120
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP27042699A Expired - Fee Related JP3699618B2 (ja) | 1999-09-24 | 1999-09-24 | 暗号鍵取得方法及び暗号鍵交換装置 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3699618B2 (ja) |
Families Citing this family (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2005236348A (ja) * | 2004-02-17 | 2005-09-02 | Matsushita Electric Ind Co Ltd | 無線システム、無線装置、無線通信方法、及びプログラム |
| JP2006121215A (ja) * | 2004-10-19 | 2006-05-11 | Fuji Electric Holdings Co Ltd | 鍵交換方法、及び、鍵交換処理装置 |
| KR101092543B1 (ko) * | 2004-11-12 | 2011-12-14 | 삼성전자주식회사 | 브로드캐스트 암호화를 위한 사용자 키 관리 방법 |
| JP2009284086A (ja) * | 2008-05-20 | 2009-12-03 | Tokai Rika Co Ltd | 暗号鍵更新システム及び暗号鍵更新方法 |
| US8971530B2 (en) | 2009-06-24 | 2015-03-03 | Intel Corporation | Cryptographic key generation using a stored input value and a stored count value |
-
1999
- 1999-09-24 JP JP27042699A patent/JP3699618B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2001094548A (ja) | 2001-04-06 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US5633933A (en) | Method and apparatus for a key-management scheme for internet protocols | |
| US7424615B1 (en) | Mutually authenticated secure key exchange (MASKE) | |
| US6754678B2 (en) | Securely and autonomously synchronizing data in a distributed computing environment | |
| US7221757B2 (en) | Method and system for accelerated data encryption | |
| CN110011795B (zh) | 基于区块链的对称群组密钥协商方法 | |
| JP4527358B2 (ja) | 鍵供託を使用しない、認証された個別暗号システム | |
| US6026167A (en) | Method and apparatus for sending secure datagram multicasts | |
| JP5544355B2 (ja) | 共有の秘密の確認の方法およびシステム | |
| JPH1155243A (ja) | 鍵管理方式におけるペア鍵の実装、閉ユーザグループにおける完全秘密転送の達成、及びデータグラムマルチキャスト送信のための方法、及び装置 | |
| JPH088895A (ja) | インターネット手順のキー管理のための方法ならびにその装置 | |
| US20230188325A1 (en) | Computer-implemented system and method for highly secure, high speed encryption and transmission of data | |
| JPH0918469A (ja) | 暗号通信装置、システム及び暗号装置 | |
| US10630476B1 (en) | Obtaining keys from broadcasters in supersingular isogeny-based cryptosystems | |
| CN111656728B (zh) | 一种用于安全数据通信的设备、系统和方法 | |
| JP3172396B2 (ja) | 暗号通信装置及び暗号通信システム | |
| JP3699618B2 (ja) | 暗号鍵取得方法及び暗号鍵交換装置 | |
| JP3854954B2 (ja) | データ共有装置 | |
| JP2002527992A (ja) | ｎ人の加入者用の共通の暗号用の鍵の確立方法 | |
| JP2006140743A (ja) | 共通鍵配送方法 | |
| US10880278B1 (en) | Broadcasting in supersingular isogeny-based cryptosystems | |
| Ahmedova et al. | Generation and distribution secret encryption keys with parameter | |
| AU2002323203B2 (en) | Method and system for accelerated data encryption | |
| WO1999049613A1 (en) | Cryptographic key-recovery mechanism | |
| Issad et al. | Secure Hybrid Crypto-system AES/RSA on FPGA for Data Communication | |
| CN114362926B (zh) | 基于密钥池的量子保密通信网络密钥管理通信系统及方法 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20050125 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20050328 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20050705 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20050708 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20080715 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090715 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090715 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100715 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110715 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110715 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120715 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120715 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130715 Year of fee payment: 8 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| LAPS | Cancellation because of no payment of annual fees |