(57)【要約】【課題】  サーバと端末が、お互いの秘密情報を知らない状態を保ったまま、相互認証付き鍵交換と秘密情報更新を行なう。【解決手段】  サーバと端末とが互いを認証しながら鍵交換を行なう鍵交換装置であって、サーバは、マスター鍵を格納するマスター鍵格納部と、端末と共有する共通鍵を生成する種である第１の共通鍵種情報を暗号化して端末に送信し、端末から送信される第１の通信データと第１の共通鍵種情報とを、端末と共有する共通パラメータを用いて照合して端末を認証するサーバ演算部とを備え、端末は、マスター鍵と鍵導出関数とを用いて生成された端末秘密鍵を格納する端末秘密鍵格納部と、サーバと共有する共通鍵を生成する種である第２の共通鍵種情報を暗号化してサーバに送信し、サーバから送信された第２の通信データと第２の共通鍵種情報とを共通パラメータを用いて照合してサーバを認証する端末演算部とを備える。【選択図】        図１
2015186101.tif 000002
【特許請求の範囲】
【請求項１】
サーバと端末とが互いを認証しながら鍵交換を行なう鍵交換装置であって、
前記サーバは、
マスター鍵を格納するマスター鍵格納部と、
前記端末と共有する共通鍵を生成する種である第１の共通鍵種情報を暗号化して前記端末に送信し、前記端末から送信される第１の通信データと前記第１の共通鍵種情報とを、前記端末と共有する共通パラメータを用いて照合して前記端末を認証するサーバ演算部とを備え、
前記端末は、
前記マスター鍵と鍵導出関数とを用いて生成された端末秘密鍵を格納する端末秘密鍵格納部と、
前記サーバと共有する共通鍵を生成する種である第２の共通鍵種情報を暗号化して前記サーバに送信し、前記サーバから送信された第２の通信データと前記第２の共通鍵種情報とを前記共通パラメータを用いて照合して前記サーバを認証する端末演算部とを備えた
鍵交換装置。
【請求項２】
前記サーバ演算部は、前記端末を認証した場合、前記鍵導出関数により導出した共通鍵を共通鍵暗号に使用し、
前記端末演算部は、前記サーバを認証した場合、前記鍵導出関数により導出した共通鍵を共通鍵暗号に使用する
請求項１記載の鍵交換装置。
【請求項３】
前記サーバ演算部は、前記マスター鍵を更新し、更新された前記マスター鍵と前記鍵導出関数とを用いて前記端末秘密鍵を更新して、更新前の前記端末秘密鍵を失効させる請求項１記載の鍵交換装置。
【請求項４】
前記サーバは、
失効させる前記端末の識別子を失効識別子として格納する失効識別子格納部を備え、
前記サーバ演算部は、前記端末から送信された端末の識別子を前記失効識別子と照合し、前記識別子と一致する前記失効識別子が存在した場合、前記端末の前記端末秘密鍵を失効させる請求項１記載の鍵交換装置。
【請求項５】
前記サーバは、
失効させる前記端末の識別子を失効識別子として格納する失効識別子格納部を備え、
前記サーバ演算部は、
前記端末から送信された端末の識別子を前記失効識別子と照合し、前記識別子と一致する前記失効識別子が存在した場合、前記端末の前記端末秘密鍵を失効させる処理と、前記マスター鍵を更新し、更新された前記マスター鍵と前記鍵導出関数とを用いて前記端末秘密鍵を更新して、更新前の前記端末秘密鍵を失効させる処理とを切り替える請求項１記載の鍵交換装置。
【請求項６】
サーバと端末とが互いを認証しながら鍵交換を行なう鍵交換装置の鍵交換方法であって、
前記サーバは、
マスター鍵格納部が、マスター鍵を格納するマスター鍵格納ステップと、
サーバ演算部が、前記端末と共有する共通鍵を生成する種である第１の共通鍵種情報を暗号化して前記端末に送信し、前記端末から送信される第１の通信データと前記第１の共通鍵種情報とを、前記端末と共有する共通パラメータを用いて照合して前記端末を認証するサーバ演算ステップとを備え、
前記端末は、
端末秘密鍵格納部が、前記マスター鍵と前記鍵導出関数とを用いて生成された端末秘密鍵を格納する端末秘密鍵格納ステップと、
端末演算部が、前記サーバと共有する共通鍵を生成する種である第２の共通鍵種情報を暗号化して前記サーバに送信し、前記サーバから送信された第２の通信データと前記第２の共通鍵種情報とを前記共通パラメータを用いて照合して前記サーバを認証する端末演算ステップとを備えた
鍵交換方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、サーバと端末が、安全でない通信路を介して互いを認証しながら、同一の鍵情報を共有する鍵交換装置に関する。鍵の共有はその後の暗号通信のために行われる。サーバ１台に対し端末は複数存在するが、鍵の共有を含めて暗号通信はサーバと端末の間で行われるものとする。
【背景技術】
【０００２】
インターネットの普及により、顔や名前を知らない相手と、信頼性や秘匿性を必要とする通信を行なう機会が増大している。このような通信は暗号技術を用いて実現され、暗号通信のための暗号鍵をユーザ間で共有する方法は、鍵交換（または、鍵共有や鍵配布）と呼ばれる。鍵交換は、ユーザ間であらかじめ何らかの情報を共有しておくなどして、共有した情報に基づいたデータをやりとりすることによって、両者の間で情報の共有を可能にする方法である。特に、鍵を共有しようとしている相手が、確かに自分が意図した人物であり、第三者になりすまされた存在ではないことを保証する場合の鍵交換を、認証付き鍵交換方式と呼ぶ。認証付き鍵交換方式を利用すると、ネットワーク上で通信を行なっている相手を認証しながら、同一の暗号鍵を共有することができる。
【０００３】
相手を認証するには、例えば、パスワードを用いる方式がある。このパスワード方式では、事前にお互いに秘密のパスワードを共有することによって相手を認証する。具体的には、パスワード方式は、鍵交換を行なう際に、相手にパスワードを要求し、それが自分の知っているパスワードと一致するかどうかを確かめる方式である。この方式は、非常に単純である一方で、あらかじめ二人が顔を合わせるなどして、秘密のパスワードを共有しておく必要がある。また、相手毎、あるいは、グループ毎のパスワードが必要になるため、それらのパスワードの管理が煩雑になり、大規模なシステムには向かないといった問題がある。
【０００４】
相手を認証する方法として、公開鍵暗号を利用することもできる（非特許文献１）。公開鍵暗号は、その名の通り、公開可能な鍵（公開鍵）を用いて暗号化を行なうことができる方式である。公開鍵には、ペアとなる秘密鍵が存在し、秘密鍵から公開鍵を計算することは簡単だが、公開鍵から秘密鍵を計算することは困難であるような非対称な関係にある。二つの鍵のうち、片方で暗号化した暗号文は、対応するもう片方の鍵でのみ復号が可能である。この性質を利用し、例えば、ユーザＡが、秘密鍵ＫＡで、あるデータＤを暗号化したものを署名データＤＳとし、通信相手であるユーザＢにデータＤと署名データＤＳを送付する。秘密鍵ＫＡはユーザＡが厳重に保管しておき、秘密鍵ＫＡに対応した公開鍵ＰＡを公開する。ユーザＢはこの公開鍵ＰＡを入手し、署名データＤＳを復号して、復号したデータがデータＤと合致するか検証することで、署名データＤＳを生成したのが確かにユーザＡであることを認証する。
【０００５】
先に述べた公開鍵暗号方式を利用すると、あらかじめ通信相手と会うなどしてパスワードを秘密裏に共有しておく必要はなくなる。しかし、公開鍵ＰＡが確かにユーザＡの公開鍵であることを保証しながら、ユーザＢは、公開鍵ＰＡを入手しなければならない。そのため、実運用として、公開鍵暗号を用いるには、各ユーザの公開鍵が確かにそのユーザのものであることを、それを必要とするユーザが検証できるような枠組みが必要になる。これがＰＫＩ（Ｐｕｂｌｉｃ  Ｋｅｙ  Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ）である（非特許文献２）。 実際には、認証局と呼ばれる機関を置き、公開鍵ＰＡが確かにユーザＡの公開鍵であることを保証する証明書を認証局が発行する。この証明書を公開鍵ＰＡとともに配布し、それをユーザＢが入手して公開鍵ＰＡがユーザＡの公開鍵であることを検証する。この証明書の正当性は、認証局が担保する。この方式を用いることで、インターネットのように、通信が初めての人物との暗号通信が可能になる。相手の「正当な」公開鍵で暗号化鍵を暗号化し配送すると、二者間で暗号化鍵が共有できる。しかし、この方式は、認証局の設置など実運用面ではコストがかかるという問題もある。
【０００６】
ユーザが公開する公開鍵を、どのように信頼するかを解決すると期待されているのがＩＤベース暗号である（非特許文献３など）。ＩＤとは、個人が一意に特定できるような情報を指す（例えばメールアドレスなど）。各個人のＩＤに対応した秘密鍵を生成し、各々が自分の秘密鍵を厳重に保管する。一方で、ＩＤは公開し、公開鍵暗号のときと同様に、持ち主が自身のＩＤに紐づいた秘密鍵で生成した署名データを、通信相手が公開されたＩＤを使って検証する。あとは相手のＩＤを用いて暗号化し配送することで、共通鍵を共有することができる。この方式であれば、ユーザの公開鍵の身許を保証する認証機関は必要ないとされている。しかし実際には、公開鍵の信頼性をＩＤの信頼性に置き換えていることになり、認証局の代わりにＩＤと秘密鍵の紐づけを担保する機関である鍵生成機関（ＰＫＧ：Ｐｕｂｌｉｃ  Ｋｅｙ  Ｇｅｎｅｒａｔｏｒ）が必要になる。
【先行技術文献】
【非特許文献】
【０００７】
【非特許文献１】公開鍵暗号技術の標準化規格  ＰＫＣＳ＃１：ＲＳＡ  ＣＲＹＰＴＯＧＲＡＰＨＹ  ＳＴＡＮＤＡＲＤ
【非特許文献２】ＩＴＵ−Ｔ  ＰＫＩの標準化規格  Ｉｎｔｅｒｎｅｔ  Ｘ．５０９  Ｐｕｂｌｉｃ  Ｋｅｙ  Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ  Ｃｅｒｔｉｆｉｃａｔｅ  ａｎｄ  ＣＲＬ  Ｐｒｏｆｉｌｅ（ＲＦＣ２４５９）
【非特許文献３】ＩＥＴＦ  ＩＤベース暗号の標準化規格  Ｉｄｅｎｔｉｔｙ−Ｂａｓｅｄ  Ｃｒｙｐｔｏｇｒａｐｈｙ  Ｓｔａｎｄａｒｄ  （ＩＢＣＳ）＃１：Ｓｕｐｅｒｓｉｎｇｕｌａｒ  Ｃｕｒｖｅ  Ｉｍｐｌｅｍｅｎｔａｔｉｏｎｓ  ｏｆ  ｔｈｅ  ＢＦ  ａｎｄ  ＢＢ１  Ｃｒｙｐｔｏｓｙｓｔｅｍｓ（ＲＦＣ５０９１）
【発明の概要】
【発明が解決しようとする課題】
【０００８】
ユーザ間で認証付き鍵交換を行なう際、非対称な情報を用いて実現する方法としてＩＤベースに基づいたものがあるが、これは鍵生成機関（ＰＫＧ）の存在を必要とする。ＰＫＧは、全ユーザの秘密鍵を知っており、それに基づいてユーザ間で確立される共通鍵も知ることが理論上可能である。この問題は、キーエスクロー（鍵供託）と呼ばれる。
【０００９】
更に、ユーザの秘密鍵を更新するとき、ＰＫＧに依頼して新しいＩＤと秘密鍵を生成してもらう必要がある。すなわち、ＰＫＧは、全ユーザの秘密鍵を完全にコントロールすることができる。よって、キーエスクローにより、ＰＫＧもユーザと同じ共通鍵を持つことができるため、ＰＫＧが不正を行なえる可能性が残る。
【００１０】
本発明は、サーバと端末が、安全でない通信路を介して、互いを認証しながら鍵交換を行なう枠組みを提案するものである。サーバと端末は、事前に秘密情報を共有するが、互いの秘密情報は非対称で（同一でなく）、各々が持つ秘密情報から相手の秘密情報を計算することはできない。
【００１１】
本発明は、サーバ１台に対し、端末が複数存在するようなネットワークを想定し、本発明が提案する認証と鍵交換の方式は、サーバと端末の間で実施される。各端末は、固有の秘密情報を持つが、サーバは、全端末との通信に共通して使用できる秘密情報を１つのみ持つ。従って、各端末毎に固有な鍵管理は必要ない。
【００１２】
本発明は、各端末の秘密情報の更新機能も備える。我々の想定状況では、秘密情報の更新時にサーバとの通信を必要とするが、ＩＤベースの認証付き鍵交換におけるＰＫＧのように、サーバが端末の秘密情報を完全にコントロールすることはできないため、サーバが端末の秘密情報を知らない性質は保たれたまま、端末の秘密情報の更新が可能である。
【課題を解決するための手段】
【００１３】
上記で述べた課題を解決するため、本発明の鍵交換装置は、サーバと端末とが互いを認証しながら鍵交換を行なう鍵交換装置であって、前記サーバは、マスター鍵を格納するマスター鍵格納部と、前記端末と共有する共通鍵を生成する種である第１の共通鍵種情報を暗号化して前記端末に送信し、前記端末から送信される第１の通信データと前記第１の共通鍵種情報とを、前記端末と共有する共通パラメータを用いて照合して前記端末を認証するサーバ演算部とを備え、前記端末は、前記マスター鍵と鍵導出関数とを用いて生成された端末秘密鍵を格納する端末秘密鍵格納部と、前記サーバと共有する共通鍵を生成する種である第２の共通鍵種情報を暗号化して前記サーバに送信し、前記サーバから送信された第２の通信データと前記第２の共通鍵種情報とを前記共通パラメータを用いて照合して前記サーバを認証する端末演算部とを備える。
【００１４】
また、本発明の鍵交換方法は、サーバと端末とが互いを認証しながら鍵交換を行なう鍵交換装置の鍵交換方法であって、前記サーバは、マスター鍵格納部が、マスター鍵を格納するマスター鍵格納ステップと、サーバ演算部が、前記端末と共有する共通鍵を生成する種である第１の共通鍵種情報を暗号化して前記端末に送信し、前記端末から送信される第１の通信データと前記第１の共通鍵種情報とを、前記端末と共有する共通パラメータを用いて照合して前記端末を認証するサーバ演算ステップとを備え、前記端末は、端末秘密鍵格納部が、前記マスター鍵と前記鍵導出関数とを用いて生成された端末秘密鍵を格納する端末秘密鍵格納ステップと、端末演算部が、前記サーバと共有する共通鍵を生成する種である第２の共通鍵種情報を暗号化して前記サーバに送信し、前記サーバから送信された第２の通信データと前記第２の共通鍵種情報とを前記共通パラメータを用いて照合して前記サーバを認証する端末演算ステップとを備える。
【発明の効果】
【００１５】
本発明によれば、サーバと端末は、お互いの秘密情報を知らない状態を保ったまま、相互認証付き鍵交換と秘密情報更新が行なえ、サーバ・端末ともに、自分のみが知る状態を保ったまま、自身の秘密情報を更新できるようになる。これにより、例えば、端末のみが知る秘密情報を使ったサービス（端末のみが知る秘密情報を使った課金処理、例えば、端末が有料情報をダウンロードしたという署名や、特定のゲートを通過したことの証明など）において、秘密情報を知った他の端末が、自身のサービス利用行為を否認して、課金を免れるといった不正行為を防止できるようになるという効果がある。
【図面の簡単な説明】
【００１６】
【図１】実施の形態１に係る鍵交換装置の一構成例を示す構成図である。
【図２】相互認証と共通鍵共有を行なう手順の流れを示すフローチャートである。
【図３】相互認証と端末秘密鍵更新を行なう手順の流れを示すフローチャートである。
【発明を実施するための形態】
【００１７】
実施の形態１．
図１は、実施の形態１に係る鍵交換装置の一構成例を示す構成図である。
以下、図１を参照しながら、実施の形態１の鍵交換装置を説明する。
【００１８】
鍵交換装置は、端末０００とサーバ１００により構成される。ただし、サーバ１００の持つサーバ機能・性能についてはここでは言及しないため、１００と同様の機能を持った計算機であれば、サーバ１００として使用することができる。端末０００は、通信部００２で、サーバ１００は、通信部１０２で、互いにデータをやりとりする。
【００１９】
端末０００は、端末秘密鍵格納部００１に、端末秘密鍵を格納する。サーバは、マスター鍵格納部１０１に、マスター鍵を格納する。端末秘密鍵格納部００１、マスター鍵格納部１０１は、データが漏洩しないように適切な方法で保護されているとし、その具体的な方法は問わない。
【００２０】
端末秘密鍵は、マスター鍵を元に生成される。例えば、端末出荷時に、工場作業者や委託業者によって、適切に管理されたマスター鍵と端末の固有情報（端末ＩＤ）から端末秘密鍵を生成し、端末秘密鍵格納部００１に格納される。マスター鍵自身は、端末に格納しない。
【００２１】
端末０００の演算部００３（端末演算部）とサーバ００１の演算部１０３（サーバ演算部）は、ＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）であり、鍵交換のための認証処理や照合処理を行なう。
また、端末０００とサーバ００１は、ともに乱数を生成する擬似乱数生成部００４を備えており、認証処理に用いる乱数を生成する。
【００２２】
端末０００の共通鍵格納部００５は、サーバと共有する共通鍵を格納する。格納された共通鍵は、端末とサーバで、共通鍵暗号に使用する。
端末ＩＤ００６は、端末を一意に識別する識別子（端末識別子）を格納する。
また、サーバ００１の失効ＩＤリスト１０６（失効識別子格納部）は、失効させる端末の識別子を格納する。
【００２３】
以下に、本実施の形態１を実施するための共通パラメータを示す。これらは、いずれも公開して良い情報であり、端末０００、サーバ１００が共通に使用するパラメータである。
【００２４】
まず、システム利用者は、対称ペアリング群Ｇ１×Ｇ１→ＧＴを生成する。Ｇ１の生成元を、ｇとする。
次に、以下の４種類のハッシュ関数（Ｈ１、Ｈ２、Ｈ３、Ｈ４）と鍵導出関数（ＫＤＦ）を用意する。具体的な写像の構成法は何でも良く、ここでは説明を省略する。
Ｈ１：｛０、１｝*→Ｇ１、
Ｈ２：ＧＴ→｛０、１｝*、
Ｈ３：ＧＴ→Ｇ１、
Ｈ４：ＧＴ→｛０、１｝*、
ＫＤＦ：ＧＴ→｛０、１｝＾ｋ
ここで、｛０、１｝*  は、０、または１の０回以上の繰り返しを意味し、｛０、１｝＾ｋ  は、０、または１のｋ回の繰り返し（ｋは、鍵の長さ）を意味する。
【００２５】
サーバ１００は、まず、０からｑ−１までの整数の集合Ｚｑからランダムに値を選び、マスター鍵ｓとする。
次に、マスター鍵ｓと端末の固有情報ＩＤから、端末秘密鍵ｃｋを生成する方法を説明する。ここでは、委託業者がサーバ保有者から端末秘密鍵生成を委託し、必要な情報は提供されるとする。委託業者は、前述の共通パラメータ（Ｇ１×Ｇ１→ＧＴ、ｇ、Ｈ１、Ｈ２、Ｈ３、Ｈ４）とサーバのマスター鍵ｓを入力とし、以下の計算を行なう。
ＩＤ←｛０、１｝*、
ｘ←Ｚｑ、
ｓｋｃ:＝（Ｈ１（ＩＤ||ｇ＾ｘ）＾ｓ）＾ｘ  ＝  Ｈ１（ＩＤ||ｇ＾ｘ）＾（ｓｘ）
ここで、||  は、文字列の連結を意味し、ｓｋｃは、秘密鍵の構成要素（ｓｅｃｒｅｔ  ｋｅｙ  ｃｌｉｅｎｔ）を意味する。
【００２６】
端末０００は、上記で計算した（ＩＤ、ｇ＾ｘ、ｓｋｃ）の組を端末秘密鍵ｃｋとし、端末秘密鍵格納部００１に格納する。
【００２７】
以下では、出荷後、サーバ１００と端末０００間で通信を行ない、相互認証と共通鍵共有を行なう手順を説明する。
図２は、相互認証と共通鍵共有を行なう手順の流れを示すフローチャートである。
【００２８】
まず、ステップＳ２００において、端末０００は、ＩＤとｇ＾ｘをサーバ１００に送信する。
【００２９】
次に、ステップＳ２０１において、サーバ１００は、端末０００から送信されたＩＤを、失効ＩＤリスト１０６に格納されている失効ＩＤと照合し、ＩＤが失効ＩＤでないことを確認する。照合の結果、一致するＩＤが失効リスト１０６に格納されている場合は、処理を中断する。ＩＤが失効ＩＤでなければ処理を続ける。
次に、ステップＳ２０２において、サーバ１００は、Ｚｑからｒを、ＧＴからｍをランダムに選択する。
次に、ステップＳ２０３において、サーバ１００は、以下を計算する。
Ｃ０:＝ｇ＾ｒ、
Ｃ１:＝ｍ・ｅ（ｇ＾(ｘｓ)、Ｈ１（ＩＤ||ｇ＾ｘ））＾ｒ
ｌ:＝Ｈ４（ｍ）
ここでｅとは、Ｇ１×Ｇ１→ＧＴのペアリング演算を指す。
次に、ステップＳ２０４において、サーバ１００は、端末０００に（Ｃ０、Ｃ１、ｌ）を送信する。
このようにして、サーバは、マスター鍵ｓと、端末から送信されたＩＤとｇ＾ｘ（第１の通信データ）と、端末と共有する鍵導出関数を用いて、共通鍵の種ｍを暗号化し、暗号化した情報（Ｃ０、Ｃ１、ｌ）を端末に送信する。
【００３０】
次に、ステップＳ２０５において、端末０００は、サーバ１００から受け取った（Ｃ０、Ｃ１、ｌ）から、以下を計算する。
ｍ’:＝Ｃ１/ｅ（Ｃ０、ｓｋｃ）、
ｔ’:＝Ｈ２（ｍ’）、
Ｋｃ:＝ＫＤＦ（ｍ’）
次に、ステップＳ２０６において、端末０００は、ｍ’からＨ４（ｍ’）を計算し、それがｌと一致するかどうか照合する。（Ｃ０、Ｃ１、ｌ）が、サーバ００１によって、確かにステップＳ２０３で生成されたものであれば、ｍ’はｍと一致し、ｌとＨ４（ｍ’）も一致する。もし、一致しなければ、処理を中断する。
次に、ステップＳ２０７において、端末０００は、ｌとＨ４（ｍ’）が一致した場合、端末０００は、ｔ’をサーバ１００に送信する。
このようにして、端末は、サーバと共有する鍵導出関数を用いて、サーバから送信された（Ｃ０、Ｃ１、ｌ）（第２の通信データ）を復号した結果と、共通鍵の種ｍとが一致するか照合し、一致した場合、共通鍵の種情報ｔ’をサーバに送信する。
【００３１】
次に、ステップＳ２０８において、サーバ００１は、ｔ’がＨ２（ｍ）と一致するかを確認し、一致しなければ処理を中断する。
最後に、ステップＳ２０９において、サーバ００１は、ｔ’がＨ２（ｍ）と一致した場合、ＫＤＦ（ｍ）を計算し、その結果を共通鍵Ｋｃとして、共通鍵格納部００５に格納する。
【００３２】
以上で述べた各ステップにおいて、通信路に流れる情報は、ＩＤ、ｇ＾ｘ、Ｃ０、Ｃ１、ｌのみであり、マスター鍵ｓに関する情報は存在しない。よって、通信路を監視しているのみの受動的攻撃者は、サーバのマスター鍵ｓを知ることは困難である。
【００３３】
また、ｍは、サーバ１００が選択するランダムなパラメータであるが、ｓｋｃを持たない攻撃者が、ｍを計算することも、ハッシュ関数の一方向性から困難である。
【００３４】
さらに、サーバのマスター鍵ｓを持つ攻撃者に対しても、ｓｋｃは計算困難である。なぜなら、この攻撃者がサーバになりすましたとしても（サーバ自身が悪意を持っていたとしても）、得られるのは、Ｈ１（ＩＤ||ｇ＾ｘ）＾ｓであり、これと公開情報ＩＤ、ｇ＾ｘからｘを知ることは、暗号分野で知られているＤＨ仮定から困難とされている。
【００３５】
また、端末０００でない他の端末を端末１１１とする。端末１１１は、固有の端末秘密鍵を持っている。これを（ＩＤ’’、ｇ＾ｘ’’、ｓｋｃ’’＝Ｈ１（ＩＤ’’||ｇ＾ｘ’’）＾（ｓｘ’’））とする。端末１１１が得られるのは、自信の端末秘密鍵と、端末０００とサーバ１００の通信によるＩＤとｇ＾ｘのみである。これらからｓｋｃを計算するためにはｘが必要となるが、ｘを知ることは、同様にＤＨ仮定から困難である。
【００３６】
以下では、出荷後、サーバ１００と端末０００間で通信を行ない、相互認証と端末秘密鍵更新を行なう手順を説明する。
図３は、相互認証と端末秘密鍵更新を行なう手順の流れを示すフローチャートである。
【００３７】
まず、ステップＳ３０１において、端末０００は、新しい端末固有情報ＩＤ’を生成し、また、Ｚｑからｘ’とａをランダムに選択する。
次に、ステップＳ３０２において、端末０００は、以下を計算する。
ｈ:＝Ｈ１（ＩＤ||ｇ＾ｘ）ａ、
ｈ’:＝Ｈ１（ＩＤ’||ｇ＾ｘ’）
次に、ステップＳ３０３において、端末０００は、サーバ１００に（ｇ＾ｘ、ｈ、ｈ’）を送信する。
【００３８】
次に、ステップＳ３０４において、サーバ１００は、Ｚｑからｕを、ＧＴからＹをランダムに選択する。
次に、ステップＳ３０５において、サーバ１００は、以下を計算する。
Ｒ１:＝ｇ＾ｒ
Ｒ２:＝Ｙ・ｅ(ｇ＾ｓ、ｈ)
Ｒ３:＝ｈ’＾ｓ・Ｈ３(Ｙ)
次に、ステップＳ３０６において、サーバ１００は、端末０００に（Ｒ１、Ｒ２、Ｒ３）を送信する。
【００３９】
次に、ステップＳ３０７において、端末０００は、サーバ１００から受け取った（Ｒ１、Ｒ２、Ｒ３）から、以下を計算する。
Ｙ’:＝Ｒ２/ｅ（Ｒ１、ｓｋｃ＾ａ）、
ｓｋｃ’:＝（Ｒ３/Ｈ３（Ｙ’））＾ｘ’
最後に、ステップＳ３０８において、端末０００は、それまで保有していたｓｋｃを破棄し、ｃｋ:＝（ＩＤ’、ｇ＾ｘ’、ｓｋｃ’）を新しい端末秘密鍵とし、端末秘密鍵格納部００１に格納する。
【００４０】
以上で述べた各ステップにおいて、通信路に流れる情報は、ｇ＾ｘ、ｈ、ｈ’、Ｒ１、Ｒ２、Ｒ３であり、共通鍵共有のときと同様に、通信路を眺めているのみの受動的攻撃者は、サーバのマスター鍵を知ることは困難である。
【００４１】
また、サーバのマスター鍵ｓを持つ攻撃者に対しても、ｓｋｃ’は計算困難である。なぜなら、この攻撃者がサーバになりすましたとしても（サーバ自身が悪意を持っていたとしても）、共通鍵共有のときと同様に、ｘ’を知ることはＤＨ仮定から困難である。
【００４２】
また、端末０００の更新前の端末秘密鍵の一部であるｓｋｃを不正に得た攻撃者が、更新後の鍵ｓｋｃ’を知るためには、Ｙ’の計算によってＲ２が得られる必要があるが、これが行なえるのはａを持ったもののみである。このａは、端末０００が一時的にランダムに選択したものであり、かつ、通信路を流れる情報からａを復元するのは、ＤＨ仮定により困難である。
【００４３】
以上のように、本実施の形態１の発明は、サーバと端末は、お互いの秘密情報を知らない状態を保ったまま、相互認証付き鍵交換と秘密情報更新が行なえ、サーバ・端末ともに、自分のみが知る状態を保ったまま、自身の秘密情報を更新できるようになる。
【００４４】
実施の形態２．
実施形態１では、サーバ１００が失効ＩＤリスト１０６を備えて、端末０００から送信されたＩＤが失効ＩＤに該当すれば、処理を中断したが、実施の形態２では、サーバ１００が備える失効ＩＤリスト１０６を除去することで、煩雑な失効ＩＤリストの管理を不要にする実施の形態を説明する。
【００４５】
失効ＩＤリスト１０６は、端末のＩＤが失効するたびに追記され、失効ＩＤのデータが膨らんでいく。例えば、ＩＤが漏洩した際に失効させるだけでなく、ＩＤの有効性を時限式にするなどの運用にした場合、失効リストの管理が煩雑になる。そこで、失効ＩＤリスト１０６を除去し、実施の形態１の共通鍵共有および端末秘密鍵更新の手順を次のように変更する。
【００４６】
まず、図２の共通鍵共有の手順において、全てのＩＤを受理するようにする。
【００４７】
次に、図３の端末秘密鍵更新の手順において、ステップＳ３０４で、さらに新しいマスター鍵ｓ’をＺｑから選択する。そして、ステップＳ３０５において、Ｒ３の計算に、ｓの代わりにｓ’を使用する。これにより、更新後の端末秘密鍵ｓｋｃ’には新しいマスター鍵ｓ’の情報が組み込まれ、ｓｋｃ’を持った端末０００と、マスター鍵ｓ’を持ったサーバ１００が通信可能になる。古い端末秘密鍵ｓｋｃは古いＩＤと紐づいており、古い端末秘密鍵ｓｋｃを利用不可にすることによって古いＩＤを失効させることができる。
なお、複数の端末が存在する場合は、全ての端末に対し、端末秘密鍵更新を実行させるようにする。
【００４８】
以上のように、本実施の形態２の発明は、ＩＤを失効させる場合は、端末秘密鍵更新の際に新しいマスター鍵を用いて端末秘密鍵を更新し、新しいマスター鍵で端末とサーバが通信可能になるようにすることで、管理が煩雑な失効ＩＤリストを使用することなく、ＩＤの失効が容易になるという効果がある。
【００４９】
実施の形態３．
実施の形態１においては、サーバ１００は、失効ＩＤリスト１０６を利用することで、正規でない端末との不必要な通信を避けることができる。また、実施の形態２においては、サーバ１００は、端末が端末秘密鍵を更新すると同時にマスター鍵を更新することができ、かつ、そのマスター鍵は、端末には知られないようにすることができる。本実施の形態３は、この両方の機能を兼ね備える。すなわち、通常は、失効ＩＤリスト１０６により正規端末の照合を行ない、失効ＩＤリスト１０６のサイズが増大してくると、マスター鍵を更新することで、失効ＩＤリストをクリアすることができる。
【符号の説明】
【００５０】
０００  端末、００１  端末秘密鍵格納部、００２  通信部、００３  演算部、００４  擬似乱数生成部、００５  共通鍵格納部、００６  端末ＩＤ、１００  サーバ、１０１  マスター鍵格納部、１０３  演算部、１０４  擬似乱数生成部、１０５  共通鍵格納部、１０６  失効ＩＤリスト。
【図１】
2015186101.tif 000003
【図２】
2015186101.tif 000004
【図３】
2015186101.tif 000005