(57)【特許請求の範囲】
【請求項１】
公開鍵暗号のドメインパラメータおよび秘密鍵、公開鍵を端末毎に生成するパラメータ生成手段を有するパラメータ生成装置と、サーバと、前記端末間とで秘密情報を共有する鍵共有システムにおいて、
前記パラメータ生成装置は、前記ドメインパラメータから成るビット列に対してのハッシュ値を計算するハッシュ値計算手段を有し、
前記サーバは、前記端末毎に前記パラメータ生成装置が生成する公開鍵暗号のドメインパラメータおよび秘密鍵を含むリストを保持する第1の保持手段を備え、
前記端末は、前記パラメータ生成装置が生成する前記公開鍵および前記ハッシュ値の組から成るリストを保持する第２の保持手段を備えることを特徴とする鍵共有システム。
【請求項２】
前記パラメータ生成装置は、ドメインパラメータから成る前記ビット列と同一長の乱数を生成して、前記ハッシュ値との排他的論理和を求める排他的論理和生成手段を有し、
前記サーバは、前記第1の保持手段により、前記パラメータ生成手段が生成する前記ドメインパラメータ、前記秘密鍵および前記排他的論理和を求めた結果を含むリストを保持し、
前記端末は、前記第２の保持手段により、前記パラメータ生成手段が生成する前記ハッシュ値と前記公開鍵に前記乱数を追加した組から成るリストを保持することを特徴とする請求項１記載の鍵共有システム。
【請求項３】
前記パラメータ生成装置は、有限体上の離散対数問題に基づくアルゴリズムを利用し、パラメータを生成することを特徴とする請求項１又は２に記載の鍵共有システム。
【請求項４】
前記パラメータ生成装置は、有限体係数の楕円曲線上の離散対数問題に基づくアルゴリズムを利用し、パラメータを生成することを特徴とする請求項１から３のいずれか１項に記載の鍵共有システム。
【請求項５】
前記サーバ及び前記端末は、回線装置の暗号化のための補助手段として動作することを特徴とする請求項１から４のいずれか１項に記載の鍵共有システム。
【請求項６】
前記サーバは、前記第1の保持手段により、前記回線装置に付随するパスワードデータを保持し、
前記端末は、前記回線装置に対するパスワードを外部から取り込むパスワード入力手段を備え、前記パスワードを含むデータを用いてセッション鍵を導出することを特徴とする請求項５記載の鍵共有システム。
【請求項７】
前記パラメータ生成装置は、前記サーバ上に組み込まれていることを特徴とする請求項１から６のいずれか1項に記載の鍵共有システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、公開鍵暗号を用いて２エンティティ間において秘密情報を共有する鍵共有システムに関する。
【背景技術】
【０００２】
近年、通信による情報交換が盛んに行われており、通信秘匿のための暗号化は必須の技術である。現代暗号では、アルゴリズムを公開しても暗号の鍵を秘密にすることによって通信秘匿を実現している。そのため、暗号を用いた通信ではデータを暗号化するための鍵を、通信を行う両者でどのように共有するのかが課題となる。
【０００３】
現代暗号は、主に対称鍵暗号と公開鍵暗号に分類される。前者はＤＥＳやＡＥＳなどのブロック暗号が代表的で、送信側と受信側が予め同一の鍵を持っていることを前提とする。後者はＲＳＡ暗号が代表的で、暗号化と復号で使用する鍵が異なり、暗号化で使用する鍵は公開鍵、復号で使用する鍵は秘密鍵と呼ばれる。秘密鍵から公開鍵を生成することは容易だが、その逆は非常に困難という性質を持つ。このため、公開鍵は公開してあっても秘密鍵の漏洩がなければ公開鍵で暗号化した情報は秘密鍵を持つ者のみが復号可能である。
【０００４】
しかしながら、公開鍵暗号は対称暗号よりも非常に大きな計算量が必要であるため、公開鍵暗号を用いて対称鍵暗号で使用する鍵（セッション鍵と呼ばれる）を共有し、実際のデータは対称鍵暗号を用いて暗号化処理を行うことが多い。
【０００５】
公開鍵暗号を使用する際には、公開鍵暗号で使用する演算を定義するドメインパラメータや公開鍵が正しいことを保証する必要がある。有限体上の離散対数を用いる方式の場合には、ドメインパラメータは剰余系演算を定める素数pと離散対数問題の生成元となるmod  pの元g（mod  p）からなり、秘密鍵x（mod  q）に対して公開鍵はy=gx（mod  p）と一般に定められる。ここで、qはgの位数、すなわちga=1（mod  p）となる最小の自然数aである。
【０００６】
ここでは、ドメインパラメータと公開鍵を併せて公開情報と呼ぶことにする。公開情報の正当性は、認証局による公開鍵証明書に基づく方式がよく知られている。その一方で、閉じたシステムでは、信頼できる機関から公開情報を直接入手するようにすることによって信頼性を確保することが可能となる。
【０００７】
例えば、図８に示すような暗号通信システムのモデルはパラメータ生成手段１０１、サーバ１０２および端末１０３から構成される。サーバ1台に対して端末は複数存在する。各端末は直接的にはサーバとのみ通信を行う。パラメータ生成手段は端末配布時に公開鍵暗号のパラメータ、鍵情報を生成し、サーバと端末に必要な情報を設定してから、端末をユーザに渡す。パラメータ生成手段１０１とサーバ１０２は同一の装置で実現される場合もある。
【０００８】
Diffie-Hellmanアルゴリズムに基づく鍵共有方式では、十分大きな素数ｑに対して（ｐ−１）がｑで割り切れるような素数ｐを生成する。このときgq=1（mod  ｐ）となる1ではない元gが存在する。エンティティＡ、Ｂ間のDiffie-Hellman鍵共有は次の表１に示すように行われる。
【０００９】
【表１】
0005125682.tif 000002
【００１０】
表１におけるｒ、ｓが秘密鍵、gr（mod  ｐ）、gs（mod  ｐ）が公開鍵となる。両者は共通の秘密g(rs)（mod  ｐ）を共有することができ、gr（mod  ｐ）とgs（mod  ｐ）からg(rs)（mod  ｐ）を求めることは離散対数問題と同程度に難しいと考えられている。
【００１１】
しかしながら、Diffie-Hellmanアルゴリズムは、gr（mod  ｐ）やgs（mod  ｐ）を盗聴して秘密情報を求める受動的な攻撃には強いが、なりすましなどの能動的な攻撃に弱いことが知られている。そこで、Diffie-Hellmanアルゴリズムを用いる際には通信相手を認証することが必須となる。
【００１２】
そこで、認証付鍵共有に関しては、例えば非特許文献１に記載されている方法が知られている。
【００１３】
以下、非特許文献1に記載されている認証付鍵共有の方法を述べる。認証付鍵共有では主に認証で使用する固定鍵と、セッション鍵生成のためのみに使用する一時鍵が存在する。固定鍵はエンティティ間で事前に保持しておく秘密鍵と公開鍵で、長期にわたって保持する鍵であり、固定公開鍵を用いて相手が固定秘密鍵を持っていることを検証することが可能となり、認証を実現することができる。一方、一時鍵はDiffie-Hellmanアルゴリズムにおいてセッション鍵生成時に発生させる乱数を用いて生成する秘密鍵と公開鍵である。
【００１４】
固定秘密鍵が一方のみに存在する場合の鍵共有方法として、非特許文献１ではC(1,1)という方法が述べられている。C(1,1)の最初の‘１’は一時鍵の個数であり、2番目の‘１’が固定鍵の個数を表している。
【００１５】
図９はC(1,1)におけるパラメータ生成手段の処理およびサーバと端末が持つ固定鍵に関する情報の例を示している。端末に設定する固定鍵のインデックスi=1,2,…,Lに対して次の処理を行う。
【００１６】
パラメータ生成手段１０１によって、(p(i),q(i),g(i),x(i),y(i))の組が生成され、サーバ１０２は、生成された (p(i),q(i),g(i),x(i),y(i))の組のリスト２０１を保持する。また、端末１０３は(p(i),g(i),y(i))の組のリスト２０２を保持する。
【００１７】
このように端末でサーバに対しての固定公開鍵を設定することによって、端末ではサーバのなりすましを検証することが可能となる。
【００１８】
以下、図１０に基づき端末１０３とサーバ１０２とを有する通信モデルにC(1,1)を適用した場合の認証付き鍵共有の手続きを述べる。端末１０３はサーバ１０２に対して端末ＩＤを送信する（ステップＳ１００１）。サーバ１０２は端末１０３に対してのパラメータリストの中で使用するパラメータのインデックスiを決定し（ステップＳ１００２）、端末１０３に送信する（ステップＳ１００３）。ここで、事前に使用するパラメータのインデックスに関しての取り決めがある場合にはこれらのステップは省略することができる。
【００１９】
端末１０３は乱数r(1<r<q(i))を生成し（ステップＳ１００４）、一時公開鍵w=g(i)r（mod  p(i)）を求めて（ステップＳ１００５）、サーバ１０２に送信する（ステップＳ１００６）。通常は、ここでサーバ１０２は一時公開鍵ｗの正当性をチェックする処理を行う。すなわち、ｗは0,1ではなく、wq(i)=１（mod  p(i)）が成り立つことを検証する。
【００２０】
端末１０３はrと固定公開鍵y(i)を用いてz=y(i)r（mod  p(i)）=g(rx(i))（mod  p(i)）を計算する（ステップＳ１００７）。生成されたzと端末−サーバ間の共有情報（公開情報でよい）であるotherinfoを入力とする鍵導出関数kdfを用いてセッション鍵k=kdf(w,otherinfo)を生成する（ステップＳ１００８）。鍵導出関数にはハッシュ関数を適用することが望ましい。otherinfoは端末ＩＤなど、端末固有の情報を含むようにする。ハッシュ関数を使用する場合はｗとotherinfoを連接したビット列をハッシュ関数の入力とする。ハッシュ関数に関しては、例えば非特許文献２に述べられている。
【００２１】
サーバ１０２では受信したｗを用いてZ=wx(i)（mod  p(i)）=grx(i)（mod  p(i)）を計算する（ステップＳ１００９）。正しく処理を行えていれば端末１０３とサーバ１０２でZ=zを共有することができる。サーバ１０２では端末１０３と同一のotherinfoとZを用いて鍵導出関数kdfを用いてセッション鍵K=kを導出する（ステップＳ１０１０）。
【００２２】
図１１は、サーバＳでも一時秘密鍵を生成する方法を示しており、もし仮に、サーバの固定秘密鍵が漏洩した場合でも、過去のセッション鍵を求めることはできないようにすることが可能である。以下、図１０と対比しての差異部分を示す。
【００２３】
サーバ１０２でインデックスi送信後、乱数aを生成し（ステップＳ１１０４）、一時公開鍵b=g(i)a（mod  p(i)）を生成し（ステップＳ１１０５）、端末１０３に送信する（ステップＳ１１０８）。サーバ１０２ではC=wa（mod  p(i)）=g(ra)（mod  p(i)）を生成し（ステップＳ１１１０）、端末１０３はc=g(ar)（mod  p(i)）を生成する（ステップＳ１１１４）。正しく処理を行えていればサーバ１０２と端末１０３でC=cを共有することができる。サーバ１０２ではZ,Cとotherinfoを用いてセッション鍵ｋを導出する（ステップＳ１１１２）。同様に端末１０３ではz,cとotherinfoを用いてセッション鍵Ｋ＝ｋを導出する（ステップＳ１１１５）。
【００２４】
また、安全な鍵共有を行うためには図１２に示すような同一のセッション鍵を共有していることを双方で確認するステップが欠かせない。この確認には、メッセージ認証を使用することができる。メッセージ認証に関しては、例えば非特許文献３に述べられている共通鍵暗号を利用する方法が適用できる。
【００２５】
図１２に示す、サーバ１０２におけるセッション鍵の確認手続きについて以下に説明する。セッション鍵Ｋの一部を共通鍵暗号用の秘密鍵Ｋ１に、残りをメッセージ認証用の秘密鍵Ｋ２に割り当てる（ステップＳ１２０１）。Ｋ２を秘密鍵として、メッセージ認証用データMac_Data_S_Tのメッセージ認証子Ｍを生成し（ステップＳ１２０２）、端末１０３に送信する（ステップＳ１２０５）。Mac_Data_S_Tはサーバ１０２と端末１０３で共有可能な公開データ、一時公開鍵やＩＤなどから成るデータで構成する。
【００２６】
端末１０３から送られてきたメッセージ認証子mを鍵Ｋ２とメッセージ認証用データMac_Data_T_Sを用いて検証する（ステップＳ１２０７）。また、端末１０３では、上記サーバ１０２と同様の手順により、Mac_Data_T_Sのメッセージ認証子ｍを生成後、送信し、サーバ１０２より送られてきたメッセージ認証子Ｍの検証を行う。Mac_Data_T_SはMac_Data_S_Tと同様のデータであるが、両者は異なる必要がある。
【００２７】
以上、有限体上の離散対数問題を用いた鍵共有方式を説明したが、非特許文献１が示すように有限体上の楕円曲線の有理点のなす加群を用いても同様の鍵共有を行うことができる。楕円曲線を用いることによってパラメータを小さく設定しても安全性を保つことができ、処理速度を上げることが可能となる。
【００２８】
また、特許文献１では、楕円曲線上の離散対数問題に基づく暗号化方式を採用することで、鍵長サイズを削減するとともに、端末間でやり取りしたデータの正当性の検証を行う発明が記載されている。
【特許文献１】特開２００７−１３５６４号公報
【非特許文献１】NIST Special Publication (SP) 800-56A,「Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography」、2006年
【非特許文献２】NIST Federal Information Processing Standards (FIPS) Publication 180-2, 「Specifications for the ECURE HASH STANDARD」2002年
【非特許文献３】NIST Special Publication (SP) 800-38B 「Recommendation for Block Cipher Modes of Operation: the CMAC Mode for Authentication」2005年
【発明の開示】
【発明が解決しようとする課題】
【００２９】
しかしながら、ドメインパラメータや公開鍵を端末に事前に設定しておく場合、その端末は比較的長期にわたってその設定を利用することになる。そのために、攻撃者が端末のそれらの情報を入手した際には比較的長期にわたってそのドメインパラメータに対しての攻撃機会を与えることになる。
【００３０】
特許文献１においては、正当性検証により、保護はされるが、高強度セキュリティを要求されるアプリケーションにおいてはそのような状況は望ましくなく、攻撃者が端末から得られる情報は極力小さくすることが望まれる。そのためには端末には何の鍵情報も事前に格納せずに、セッション開始時に公開情報をサーバが端末に送付する方法が考えられる。
【００３１】
しかし、このときサーバのなりすましが容易に行えてしまうという課題がある。また、不正なサーバが不正なドメインパラメータを送付した場合には固定秘密鍵がたとえ漏洩していなくても安全性が損なわれる場合がある。
【００３２】
本発明は、上記問題点に鑑みてなされたもので、端末の情報が漏洩してもドメインパラメータの情報を得ることが不可能な高強度セキュリティを実現する。
【課題を解決するための手段】
【００３３】
上記課題を解決するため、本発明における鍵共有システムは、公開鍵暗号のドメインパラメータおよび秘密鍵、公開鍵を端末毎に生成するパラメータ生成手段を有するパラメータ生成装置と、サーバと、端末間とで秘密情報を共有する鍵共有システムにおいて、パラメータ生成装置は、ドメインパラメータから成るビット列に対してのハッシュ値を計算するハッシュ値計算手段を有し、サーバは、端末毎にパラメータ生成装置が生成する公開鍵暗号のドメインパラメータおよび秘密鍵を含むリストを保持する第1の保持手段を備え、端末は、パラメータ生成装置が生成する公開鍵およびハッシュ値の組から成るリストを保持する第２の保持手段を備えることを特徴とする。
【００３４】
パラメータ生成装置は、ドメインパラメータから成る前記ビット列と同一長の乱数を生成して、ハッシュ値との排他的論理和を求める排他的論理和生成手段を有し、サーバは、第1の保持手段により、パラメータ生成手段が生成するドメインパラメータ、秘密鍵および排他的論理和を求めた結果を含むリストを保持し、端末は、第２の保持手段により、パラメータ生成手段が生成するハッシュ値と公開鍵に乱数を追加した組から成るリストを保持することを特徴とする。
【００３５】
パラメータ生成装置は、有限体上の離散対数問題に基づくアルゴリズムを利用し、パラメータを生成することを特徴とする。
【００３６】
パラメータ生成装置は、有限体係数の楕円曲線上の離散対数問題に基づくアルゴリズムを利用し、パラメータを生成することを特徴とする。
【００３７】
サーバ及び端末は、回線装置の暗号化のための補助手段として動作することを特徴とする。
【００３８】
サーバは、第1の保持手段により、回線装置に付随するパスワードデータを保持し、端末は、回線装置に対するパスワードを外部から取り込むパスワード入力手段を備え、パスワードを含むデータを用いてセッション鍵を導出することを特徴とする。
【００３９】
パラメータ生成装置は、サーバ上に組み込まれていることを特徴とする。
【発明の効果】
【００４０】
本発明により、端末の情報が漏洩しても攻撃者はドメインパラメータの情報を得ることができないため、事前の攻撃は不可能である。さらに、端末がドメインパラメータのハッシュ値を持つことによって不正なサーバから不正なパラメータを送付された場合でもチェックすることが可能となる。また、端末が公開鍵を予め格納しておくことにより、共有セッション鍵を検証する過程において固定秘密鍵を持たない不正なサーバをチェックすることが可能となる。さらに、サーバと端末間でドメインパラメータを分散保持し、セッション開始時にはサーバは分散情報のみを送ることによって通信路上の情報のみからはドメインパラメータを求めることは不可能となる。また、既存の回線装置やそれに付随するパスワードを組み合わせることによって端末（ユーザ）の識別を可能にすることができる。
【発明を実施するための最良の形態】
【００４１】
本発明ではサーバと端末の安全性は大きく異なる状況を想定する。つまり、サーバは安全な場所にあり、秘密情報の漏洩や不正な処理などのリスクは非常に小さいと仮定する一方、端末は盗難や情報流出の危険性が高いと仮定する。このようなモデルでは端末に固定秘密鍵を設定しても有効性は低いため、サーバのみに固定秘密鍵を設定する方法が適している。
【００４２】
図１は、本発明の実施形態におけるパラメータ生成手段１０１の動作と、サーバ１０２および端末１０３が保持する情報を示している。パラメータ生成手段１０１は端末が与えられたときに公開鍵パラメータリストのインデックスi=1,2,..,Lに対して次の処理を行う。ここでＬはその端末に対するパラメータの個数の上限である。
【００４３】
ドメインパラメータp(i),g(i)およびq(i),秘密鍵x(i),公開鍵y(i)を生成する。次に、p(i)とg(i)を連接したビット列であるp(i)||g(i)を入力データとするハッシュ値h(i)=Hash(p(i)||g(i))を求める。サーバ１０２は従来技術と同様にp(i),g(i),q(i),x(i),y(i)を格納する。端末１０３にはハッシュ値h(i)と公開鍵y(i)のみを格納する。
【００４４】
次に図２を用いて、本発明の実施形態におけるサーバ１０２と端末１０３の間での鍵共有の手続きを示す。従来技術と同様に、端末１０３はサーバ１０２に対して端末ＩＤを送信し（ステップＳ１００１）、サーバ１０２は１０３に対してのパラメータリストの中で使用するパラメータのインデックスiを決定する（ステップＳ１００２）。
【００４５】
サーバ１０２は、インデックスiと対応するp=p(i)およびg=g(i)を連接したビット列p||gを求め、送信する（ステップＳ２０１、Ｓ２０２）。端末１０３では受信したp||gに対してハッシュ値Hash(p||g)を計算し、格納しているh(i)と比較する（ステップＳ２０３）。一致していない場合は不正なパラメータが送付されたとして鍵共有処理を終了する。p,gの正当性が確認できたら従来通りの鍵共有処理を行う（図１０におけるステップＳ１００３からステップＳ１００９と同様の処理を実行）。
【００４６】
本発明のようにp,gを端末に格納しないことによって、端末が盗難されて情報が漏洩したとしてもハッシュ値h(i)と公開鍵y(i)のみが漏洩するだけで攻撃者はp(i)やg(i)の情報を得ることは無いため特定パラメータの離散対数問題の攻撃の機会を与えることはない。また、不正なサーバがなりすまして不正なパラメータを送付した場合にはハッシュ値h(i)によって確かめることができる。また、不正なサーバが一度送付されたインデックスi,p(i),g(i)をコピーしておき再度送信する応答攻撃に対しては不正なサーバは秘密鍵x(i)を保有していないため、Diffie-Hellmanのアルゴリズムにおいて端末と同一のセッション鍵を生成することができないため、図１に示したようなセッション鍵の共有確認処理によって安全性を保つことができる。
【００４７】
図３は、図１１にて説明した、サーバでも一時秘密鍵を生成する鍵共有方式に対して本発明を組み合わせた動作を示す図である。本発明によって図１１に示したサーバの固定秘密鍵x(i)漏洩時でも過去のセッション鍵の秘匿と、端末情報漏洩時の安全性向上を実現可能となる。処理手順については、インデックスi決定後（ステップＳ１１０２）、上記で説明したステップＳ２０１からＳ２０３を行い、その後の動作は、図１１で説明したステップＳ１１０４からＳ１１１５と同様である。
【００４８】
図４は、本発明の他の実施形態であり、p(i)||g(i)を乱数でバーナム暗号化（秘密分散）した形で送付することによって、通信路を盗聴しただけではp(i)とg(i)の情報を得ることができないようにした方法である。以下、パラメータ生成手段１０１の処理について詳細に説明する。
【００４９】
従来と同様にドメインパラメータp(i),g(i),q(i)および秘密鍵x(i)と公開鍵y(i)を生成後、図１と同様にハッシュ値h(i)=Hash(p(i)||g(i))を生成する。次に、p(i)||g(i)と同一長の乱数R(i)を生成し、U(i)=R(i)+(p(i)||g(i))を計算する。ここで、‘＋’は排他的論理和を示す。このとき、パラメータ生成手段１０１はサーバ１０２には公開情報と秘密鍵に加えてU(i)を、端末１０３にはh(i),y(i)とR(i)を設定する。
【００５０】
図５は、図１１で示した鍵共有方式に対して、本実施形態を適用した場合の鍵共有処理の手続きを示している。以下、図１０にしたがって鍵共有処理の説明を行う。
【００５１】
まず、従来と同様に端末１０３は端末ＩＤをサーバ１０２に送信し（ステップＳ１１０１）、サーバ１０２はパラメータのインデックスiを決定する（ステップＳ１１０２）。サーバ１０２はインデックスiとU(i)を端末１０３に送信する（ステップＳ５０１）。端末１０３は受信したU(i)と格納しているR(i)からR(i)＋U(i)を計算し、p||gに割り当て（ステップＳ５０２）、端末１０３はハッシュ値h=Hash(p||g)を計算し、格納しているh(i)と比較する（ステップＳ５０３）。一致していない場合は不正なパラメータが送付されたとして鍵共有処理を終了する。p,gの正当性が確認できたら従来通りの鍵共有処理を行う（図１１におけるステップＳ１１０４からステップＳ１１１５と同様の処理を実行）。
【００５２】
本実施形態における方法を用いることによって、通信路上のデータを取得するだけではp(i), g(i)を得ることは不可能となり、安全性を高めることが可能となる。
【００５３】
以上、本発明は有限体上の離散対数問題を用いた鍵共有方式を説明したが、非特許文献１が示すように有限体上の楕円曲線の有理点のなす加群を用いても同様の鍵共有を行うことができる。楕円曲線を用いることによってパラメータを小さく設定しても安全性を保つことができ、処理速度を上げることが可能となる。
【００５４】
また、本発明で想定するような端末に格納した情報が漏洩するリスクが高いことを想定するモデルでは端末のなりすましに対して防御することは困難となる。そこで端末側の安全性を高めるためには他の手段を併用する必要がある。
【００５５】
図６は、例えば本発明を電話などの従来の回線装置の補助手段として利用する形態を示している。図６でサーバ１０２および端末１０３は本発明における鍵共有を行う端末で、通信を行う電話機などの回線端末６０１、６０２の補助手段として機能する。端末１０３に付属する回線装置は、例えば携帯電話が利便性に優れている。
【００５６】
図６に示すように回線装置の補助手段と本発明を利用することで、従来の回線システムによって回線装置が特定できるため、端末側で利用できる電話機を特定しておくことによって、端末自体のなりすましの防止は難しいが不特定の電話機での使用はできなくなるために安全性の向上を図ることが可能となる。
【００５７】
図６の回線装置を併用した方式の安全性を更に向上させることは、回線装置（電話機）とユーザを対応づけてユーザによるパスワード認証を行うことによって実現できる。この場合、図７に示すように、サーバ１０２は公開鍵暗号のドメインパラメータや鍵情報等の他に端末側の回線装置のＩＤ（電話番号）と対応するパスワードリスト７０２を保持する。端末側ではユーザは利用時にパスワード７０１を入力する必要がある。パスワードの認証は、図１１に示した鍵導出関数の入力となるサーバ-端末間の共有情報otherinfoに含めることで実現可能である。パスワードが一致しない場合は導出されるセッション鍵は一致しないため、通常のセッション鍵共有の確認過程に含める形でユーザ認証が可能になる。
【００５８】
また、例えばNIST Special Publication (SP) 800-57, 「Recommendati for Key Management」2006年を参考に高度な安全性を実現するためのパラメータ設定が可能である。非特許文献３によると、２０３０年まで利用する場合に推奨される離散対数のパラメータの値pが２０４８ビット、qが２２４ビットとなる。また、使用するハッシュ関数は非特許文献２に記載されているＳＨＡ−２２４、ＳＨＡ−２５６、ＳＨＡ−３８４、ＳＨＡ−５１２のいずれかとなる。本実施形態については、ＳＨＡ−２５６を用いることとする。
【００５９】
共通鍵暗号は鍵長１２８ビットのＡＥＳ、セッション鍵共有確認のためのメッセージ認証も１２８ビットのＡＥＳを用いて非特許文献３の方式を適用すると、図１１の鍵導出関数kdf()は２０４８ビットのDiffie-Hellmanアルゴリズムによる共有情報とotherinfoを連接したビット列をＳＨＡ−２５６に入力してハッシュ値を求めることになる。
【００６０】
図７のようにユーザのパスワードも利用する場合には、更にパスワードを連接したビット列をＳＨＡ−２５６の入力とする。ＳＨＡ−２５６の出力の２５６ビットに対して、前半１２８ビットをデータ暗号化に利用するＡＥＳの秘密鍵Ｋ１に、後半１２８ビットをメッセージ認証用の秘密鍵Ｋ２として利用する。図１で示した、本発明におけるp||gに対するハッシュ値の生成にも前述のＳＨＡ−２５６を利用することができる。
【００６１】
パラメータのリストのサイズは、例えば２年間毎日変更する場合、図１の端末が保持するデータ量はハッシュ値２５６ビットと公開鍵２０４８ビットのペアが７１２個となり、約１．６４メガビットのデータ量となる。
【００６２】
以上、本発明の好適な実施の形態により本発明を説明した。ここでは特定の具体例を示して本発明を説明したが、特許請求の範囲に定義された本発明の広範囲な趣旨および範囲から逸脱することなく、これら具体例に様々な修正および変更を加えることができることは明らかである。
【図面の簡単な説明】
【００６３】
【図１】本発明の実施形態におけるパラメータ生成手段の処理およびサーバと端末が保持する情報を示す図である。
【図２】本発明の実施形態における鍵共有処理を示す図である。
【図３】本発明の実施形態においるサーバ側で一時秘密鍵を利用する場合の処理を示す図である。
【図４】本発明の別の実施形態におけるパラメータ生成手段の処理およびサーバと端末が保持する情報を示す図である。
【図５】本発明の別の実施形態における鍵共有処理を示す図である。
【図６】本発明の適用例を示す図である。
【図７】本発明の適用例を示す図である。
【図８】通信モデルを示す図である。
【図９】従来技術におけるパラメータ生成手段の処理およびサーバと端末が保持する情報を示す図である。
【図１０】従来技術における鍵共有処理を示す図である。
【図１１】従来技術におけるサーバ側で一時秘密鍵を利用する場合の処理を示す図である。
【図１２】従来技術における共有セッション鍵を相互で検証する過程を示す図である。
【符号の説明】
【００６４】
１０１    パラメータ生成手段
１０２    サーバ
１０３    端末
１０４、１０５    回線装置
７０１    パスワード
【図１】
0005125682.tif 000003
【図２】
0005125682.tif 000004
【図３】
0005125682.tif 000005
【図４】
0005125682.tif 000006
【図５】
0005125682.tif 000007
【図６】
0005125682.tif 000008
【図７】
0005125682.tif 000009
【図８】
0005125682.tif 000010
【図９】
0005125682.tif 000011
【図１０】
0005125682.tif 000012
【図１１】
0005125682.tif 000013
【図１２】
0005125682.tif 000014