JP2006270363A - 秘密通信設定方法、および秘密通信設定システム - Google Patents

Abstract

【課題】 鍵情報の操作や認証サーバの利用等を行うことなく、通信装置間の認証関係の構築と、通信装置間の通信で用いられる共通秘密鍵の設定とが可能な秘密通信設定方法を提供する。
【解決手段】 イニシエータ１０ａは、自身の公開鍵を含む認証要求をレスポンダ１０ｂに送信する。イニシエータ１０ａ及びレスポンダ１０ｂのそれぞれの使用者は、イニシエータ１０ａ及びレスポンダ１０ｂにそれぞれ表示された認証要求の内容を、他の通信手段を用いて確認する。認証要求の内容が一致する場合、レスポンダ１０ｂの使用者は、認証を承認する。レスポンダ１０ｂは、自身の公開鍵を含む認証応答を送信する。イニシエータ１０ａ及びレスポンダ１０ｂは、それぞれの公開鍵で暗号化された共通秘密鍵生成用の情報を交換する。イニシエータ１０ａ及びレスポンダ１０ｂは、秘密通信の際に用いるＳＡパラメータの交換して、秘密通信の設定を行う。
【選択図】 図５

Description

本発明は、ネットワークを介して接続する通信装置間の通信を保護するための秘密通信設定方法及び通信装置に関し、より特定的には、通信装置間の認証関係の構築と秘密通信に用いられる共通秘密鍵の設定とを行う秘密通信設定方法及び通信設定システムに関する。

近年、インターネットに接続するために、ＡＤＳＬや、ＣＡＴＶ、ＦＴＴＨなどを用いたブロードバンド接続が各家庭に急速に普及している。このため、図１０に示すような家庭間のネットワーク化が、従来からの電話システムの他に、ＰＣなどの通信機器を用いてインターネットに接続することによっても実現されている。

しかし、通信機器をオープンな環境であるインターネットに接続するにあたり、以下のような問題が生じる。それは、なりすまし及び外部からの不正侵入などの不正アクセスによる情報漏洩等によって、ネットワークの安全性が脅かされる点である。ネットワークの安全性を高めるために、通信を行う通信機器同士は、初期接続時に相互認証を行うことによって、通信の秘密性を確保した秘密通信が必要となる。

インターネット上で秘密通信を行うための方法として、ＩＰｓｅｃ（Ｓｅｃｕｒｉｔｙ ａｒｃｈｉｔｅｃｔｕｒｅ ｆｏｒ ｔｈｅ Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）がある。ＩＰｓｅｃを用いることによって、限定された時間において有効なセキュアな通信路、または永久的に有効なセキュアな通信路を構築することが可能となる。ＩＰｓｅｃを実現するためには、通常、非特許文献１に開示されているＴｈｅ Ｉｎｔｅｒｎｅｔ Ｋｅｙ Ｅｘｃｈａｎｇｅ（ＩＫＥ）という認証及び鍵交換の方法が用いられる。

非特許文献１が開示するＩＫＥを用いた認証及び鍵交換の方法について、以下に詳しく説明する。ＩＫＥは、セキュリティアソシエーション（ＳＡ）パラメータの合意、鍵交換及び認証の３つのステップで構成される。ＳＡとは、秘密通信の際に用いられる暗号化アルゴリズム等を定めたセキュリティポリシー及びパラメータのことである。ＳＡパラメータとしては、使用される暗号アルゴリズム、ハッシュ関数、認証方法、及びＤｉｆｆｉｅ−Ｈｅｌｌｍａｎグループの情報などがある。ＩＫＥでは、事前鍵共有方式（Ｐｒｅ−Ｓｈａｒｅｄ Ｋｅｙ）、署名方式、公開鍵暗号方式、及び改良型公開鍵暗号方式の４つの認証方式を用いることができる。

ＩＫＥの認証方式として事前鍵共有方式を用いたＩＫＥによる認証及び鍵交換方法を説明する。図１１は、ＩＫＥを用いた認証及び鍵交換の方法を具体的に示すシーケンス図である。図１２は、ＩＫＥにおいて事前鍵共有方式を用いる場合の、イニシエータ９０ａとレスポンダ９０ｂとの間で送受信されるメッセージのフォーマットを示す図である。イニシエータとは、認証を要求する通信装置のことであり、レスポンダとは、認証の要求に対して応答する通信装置のことである。なお、以下に示す図面において、“Ｘ＿ｂ”とは、データＸのボディを表す。“＜Ｘ＞Ｋｅｙ”とは、Ｘが暗号鍵Ｋｅｙで暗号化されたものを表す。“［Ｘ］”とは、Ｘがオプションであることを表す。

以下に、各認証方式を用いた場合のＩＫＥの認証及び鍵交換方法を説明する。まず、認証方式として、事前共有鍵方式を用いる場合を説明する。ＳＡパラメータの合意は、図１１に示すＳＡパラメータの提案９１及びＳＡパラメータの選択９２が相当する。ＳＡパラメータの提案９１（図１２（ａ）参照）には、ＳＡパラメータのセットである複数のＳＡが格納されている。イニシエータ９０ａは、ＳＡパラメータの提案９１をレスポンダ９０ｂに送信する。レスポンダ９０ｂは、複数のＳＡの中からＳＡを一つ選択する。レスポンダ９０ｂは、選択したＳＡを格納したＳＡパラメータの選択９２（図１２（ｂ）参照）をイニシエータ９０ａに送信する。上記のメッセージの送受信により、ＳＡパラメータの合意が行われる。

鍵交換は、図１１に示すように、イニシエータ９０ａによるイニシエータの鍵情報９３の送信及びレスポンダ９０ｂによるレスポンダの鍵情報９４の送信が相当する。図１２（ｃ）及び（ｄ）に示すように、イニシエータ９０ａとレスポンダ９０ｂとは、自身の鍵生成用情報を含んだメッセージをそれぞれ送信することによって、共通秘密鍵を生成するための鍵生成用情報を得る。鍵生成用情報の交換後、イニシエータ９０ａとレスポンダ９０ｂとは、共通秘密鍵を生成する。

認証は、図１１に示すように、イニシエータ９０ａによるイニシエータの認証情報９５の送信及びレスポンダ９０ｂによるレスポンダの認証情報９６の送信が相当する。イニシエータ９０ａとレスポンダ９０ｂとは、図１２（ｅ）及び（ｆ）に示すように、それぞれの認証情報を送信する。イニシエータの認証情報９５とレスポンダの認証情報９６とは、共通秘密鍵によって暗号化される。イニシエータ９０ａは、計算したハッシュと、レスポンダの認証情報９６のハッシュとが一致するか否かを確認する。同様に、レスポンダ９０ｂは、計算したハッシュと、イニシエータの認証情報９５のハッシュとが一致するか否かを確認する。イニシエータ９０ａとレスポンダ９０ｂとは、それぞれハッシュを確認することによって、認証を行う。

イニシエータの認証情報９５のハッシュ（ＨＡＳＨｉ）は、次のように表される。ＨＡＳＨｉ＝ｐｒｆ（ＳＫＥＹＩＤ，ｇ＾ｘｉ｜ｇ＾ｘｒ｜ＣＫＹｉ｜ＣＫＹｒ｜ＳＡｉ＿ｂ｜ＩＤｉｉ＿ｂ）。ここで、ｐｒｆは、擬似乱数関数である。ｇ＾ｘｉ及びｇ＾ｘｒは、イニシエータ９０ａ及びレスポンダ９０ｂのＤｉｆｆｉｅ−Ｈｅｌｌｍａｎ公開値をそれぞれ表す。ＣＫＹｉ及びＣＫＹｒは、イニシエータ９０ａ及びレスポンダ９０ｂのクッキーをそれぞれ表す。ＳＡｉ＿ｂは、合意したＳＡパラメータである。ＩＤｉｉ＿ｂは、イニシエータ９０ａのＩＤである。ＳＫＥＹＩＤは、共有秘密鍵から生成される文字列である。ＳＫＥＹＩＤは、次のように表される。ＳＫＥＹＩＤ＝ｐｒｆ（ｐｒｅ−ｓｈａｒｅｄ−ｋｅｙ，Ｎｉ＿ｂ｜Ｎｒ＿ｂ）。ここで、Ｎｉ＿ｂ及びＮｒ＿ｂは、イニシエータ９０ａ及びレスポンダ９０ｂのｎｏｎｃｅ値をそれぞれ表す。また、レスポンダの認証情報９６のハッシュＨＡＳＨｒは、次のように表される。ＨＡＳＨｒ＝ｐｒｆ（ＳＫＥＹＩＤ，ｇ＾ｘｉ｜ｇ＾ｘｒ｜ＣＫＹｉ｜ＣＫＹｒ｜ＳＡｉ＿ｂ｜ＩＤｉｒ＿ｂ）。ここで、ＩＤｉｒ＿ｂは、レスポンダ９０ｂのＩＤである。Ｄｉｆｆｉｅ−Ｈｅｌｌｍａｎ公開値ｇ＿ｘｉ及びｇ＿ｘｒは、それぞれ第１及び第２の鍵生成用情報にそれぞれ含まれる。クッキーＣＫＹｉ及びＣＫＹｒは、それぞれＩＳＡＫＭＰヘッダに含まれる。ｐｒｅ−ｓｈａｒｅｄ−ｋｅｙは、事前共有鍵であり、使用者が事前に設定をする必要がある。

ＩＫＥの認証方式として、署名方式を用いる場合を説明する。署名方式を用いる場合、ＳＡパラメータの合意と鍵交換とは、事前共有鍵方式と同じである。しかし、署名方式では、認証が、事前鍵共有方式の場合と異なる。図１３（ａ）は、署名方式を用いる場合の、イニシエータの認証情報９５のフォーマットを示す図である。図１３（ｂ）は、署名方式を用いる場合の、レスポンダの認証情報９６のフォーマットを示す図である。図１３（ａ）及び（ｂ）において、イニシエータの署名（ＳＩＧｉ）及びレスポンダの署名（ＳＩＧｒ）は、イニシエータ９０ａ及びレスポンダ９０ｂとが、ＳＡパラメータの合意によって決定された署名アルゴリズムを用いて、イニシエータのハッシュ（ＨＡＳＨｉ）とレスポンダのハッシュ（ＨＡＳＨｒ）とをそれぞれ署名した結果である。イニシエータ９０ａ及びレスポンダ９０ｂは、署名内容を確認することによって認証を行う。イニシエータの証明書（ＣＥＲＴｉ）及びレスポンダの証明書（ＣＥＲＴｒ）の交換は、オプションとなっている。しかし、証明書を交換しない場合、セキュリティは十分に保証されない。

認証方式として、公開鍵暗号方式を用いる場合を説明する。公開鍵暗号方式を用いる場合、ＳＡパラメータの合意は、事前共有鍵方式と同じである。しかし、イニシエータの鍵交換及び認証が、事前鍵共有方式の場合と異なる。図１４に、公開鍵暗号方式を用いる場合の各メッセージのフォーマットを示す。イニシエータの鍵情報９３は、鍵生成用情報（ＫＥｉ）と、ハッシュ１（ＨＡＳＨ１）と、レスポンダ９０ｂの公開鍵（ＰｕｂＫｅｙ＿ｒ）でボディだけが暗号化されたイニシエータ９０ａのＩＤ（ＩＤｉｉ）と、乱数（Ｎｉ）とを備える（図１４（ａ）参照）。ハッシュ１は、イニシエータ９０ａがＩＤｉｉとＮｉとを暗号化するために使用するハッシュ値である。レスポンダの鍵情報９４は、鍵生成用情報（ＫＥｒ）と、イニシエータ９０ａの公開鍵（ＰｕｂＫｅｙ＿ｉ）でボディだけが暗号化されたレスポンダ９０ｂのＩＤ（ＩＤｉｒ）及び乱数（Ｎｒ）とを備える（図１４（ｂ）参照）。イニシエータの認証情報９５は、鍵交換において生成した共通秘密鍵によって暗号化されたイニシエータのハッシュ（ＨＡＳＨｉ）を含む（図１４（ｃ）及び（ｄ）参照）。同様に、レスポンダの認証情報９６は、共通秘密鍵によって暗号化されたレスポンダのハッシュ（ＨＡＳＨｒ）を含む（図１４（ｄ）参照）。公開鍵暗号方式で用いられるイニシエータの公開鍵及びレスポンダの公開鍵は、イニシエータ９０ａ及びレスポンダ９０ｂが、それぞれ事前に入手しておく必要がある。

認証方式として、改良型公開鍵暗号方式を用いる場合を説明する。改良型公開鍵暗号方式を用いる場合、ＳＡパラメータの合意と鍵交換とは、公開鍵暗号方式と同じである。しかし、改良型公開鍵暗号方式は、認証が、公開鍵暗号方式の場合と異なる。図１５に、改良型公開鍵暗号方式を用いる場合の、イニシエータの認証情報９５及びレスポンダの認証情報９６のフォーマットを示す。図１５において、Ｋｅ＿ｉとＫｅ＿ｒとは、ＳＡパラメータの合意において交換される、共通鍵暗号化用の共通鍵である。イニシエータの認証情報９５において、イニシエータの鍵生成用情報（ＫＥｉ）のボディが、共通鍵（Ｋｅ＿ｉ）によって暗号化される（図１５（ａ）参照）。レスポンダの認証情報９６において、鍵生成用情報ＫＥｒのボディが、共通鍵（Ｋｅ＿ｒ）によって暗号化される（図１５（ｂ）参照）。このように、イニシエータの鍵生成用情報（ＫＥｉ）及びレスポンダの鍵生成用情報（ＫＥｒ）とが暗号化される点が、公開鍵暗号方式と異なる。なお、図１５（ａ）のイニシエータ９０ａの証明書は、オプションである。イニシエータの認証情報９５にイニシエータ９０ａの証明書を含む場合、レスポンダ９０ｂは、イニシエータ９０ａの証明書を確認するために認証局（図示せず）を利用する必要がある。

また、インターネット上で秘密通信を行うための方法として、特許文献１が開示する方法がある。特許文献１は、プライベートネットワークの外部に属する第１のネットワーク機器と、プライベートネットワークの内部に属する第２のネットワーク機器とが通信を行うためのネットワーク接続方法を開示している。第１のネットワーク機器は、プライベートネットワークのホームゲートウェイに接続要請を行う。ホームゲートウェイは、第１のネットワーク機器と第２のネットワーク機器との間に仮想プライベートネットワークトンネルを形成する。トンネル設定後、第１のネットワーク機器は、ホームゲートウェイにユーザ認証と関連情報とを送信する。ホームゲートウェイは、第１のネットワーク機器が接続承認されたか否かを確認する。接続承認された場合、ホームゲートウェイは、プライベートネットワークの内部で使用するプライベートＩＰアドレスを第１のネットワーク機器に付与する。これにより、第１のネットワーク機器は、ホームネットワーク内のネットワーク機器との通信を可能にする。このように、特許文献１は、セキュアな通信路を確立するために、トンネルの設定や認証情報の送信などを行っており、ＩＫＥと同等の技術を開示している。
特開２００４−７６７１号公報 Ｄ．ハーキンス（Ｄ．Ｈａｒｋｉｎｓ），Ｄ．キャレル（Ｄ．Ｃａｒｒｅｌ），「ザ インターネット キー エクスチェンジ（"Ｔｈｅ Ｉｎｔｅｒｎｅｔ Ｋｅｙ Ｅｘｃｈａｎｇｅ（ＩＫＥ））」 インターネット ワーキング グループ（Ｉｎｔｅｒｎｅｔ Ｗｏｒｋｉｎｇ Ｇｒｏｕｐ），アールエフシー２４０９（ＲＦＣ２４０９），１９９８年１１月

ＩＫＥを用いて通信を行う場合、通信装置に対して鍵生成用情報の設定を予め行う必要がある。さらに、事前鍵共有方式を用いる場合、通信装置に対して事前共有鍵の設定を行う必要がある。また、公開鍵暗号方式及び改良型公開鍵暗号方式は、イニシエータ及びレスポンダのそれぞれに対して、公開鍵と秘密鍵を設定するとともに、互いの公開鍵を事前に入手する必要がある。ＩＫＥを用いた通信を一般家庭において行う場合、事前共有鍵、公開鍵及び秘密鍵の設定や選択の操作は、一般家庭におけるユーザにとって複雑かつ困難である。

また、署名方式及び改良型公開鍵暗号方式は、認証サーバまたは認証局を利用する必要がある。認証サーバ及び認証局の利用は、利用コストの点で問題がある。さらに、認証サーバまたは認証局を利用するための設定が通信のインフラに依存するために、一般家庭におけるユーザは、認証サーバまたは認証局の利用が困難である。このため、一般家庭におけるユーザにとって、署名方式及び改良型公開鍵暗号方式は、事前鍵共有方式及び公開鍵暗号方式より設定が困難になるという問題がある。

また、図１１の鍵交換において、イニシエータ及びレスポンダの鍵生成用情報は、それぞれ暗号化されていない。このため、ＩＫＥの鍵交換は、なりすましや盗聴などの攻撃の対象となりやすい。一般家庭におけるユーザは、上記の攻撃に関する専門的知識や上記の攻撃に対する防御方法に関する知識に乏しい。このため、一般家庭においてＩＫＥの使用することは、セキュリティの面で問題がある。

本発明は、上記の課題を解決するためになされたものであり、本発明の第１の目的は、一般家庭におけるユーザが複雑な操作を必要としない、秘密通信の設定に必要な認証と鍵交換の方法とを提供することである。本発明の第２の目的は、認証サーバや認証局を利用せずに、即座に認証と鍵交換とが可能な秘密通信の設定に必要な認証と鍵交換の方法とを提供することである。本発明の第３の目的は、なりすましや盗聴などの攻撃が不可能な、セキュリティが向上した秘密通信の設定に必要な認証と鍵交換の方法とを提供することである。

本発明は、本発明は、ネットワークを介して接続する通信装置間の通信を保護するための秘密通信設定方法及び通信装置に向けられている。そして上記目的を達成させるために、本発明に係る秘密通信設定方法には、第１の通信装置が、第２の通信装置と認証を行うための認証要求を送信するステップと、第１の通信装置が、所定の第１の表示部に認証要求の内容を表示させるステップと、第２の通信装置が、所定の第２の表示部に受信した認証要求の内容を表示させるステップと、第１の通信装置の使用者と第２通信装置の使用者とが、第１の表示部に表示された認証要求の内容と、第２の表示部に表示された認証要求の内容とが一致するか否かを、通信の通信経路と異なる通信経路を用いて確認するステップと、一致すると判断された場合、第２の通信装置の使用者が、認証の承認を指示するステップと、承認の処理に基づいて、第２の通信装置が、認証応答を送信するステップと、第１の通信装置と第２の通信装置とが、第１の通信装置が保持する第１の鍵生成用情報と、第２の通信装置が保持する第２の鍵生成用情報とを交換するステップと、第１の通信装置及び第２の通信装置のそれぞれが、第１の鍵生成用情報と第２の鍵生成用情報との両方を用いて、共通秘密鍵を生成して設定するステップとを備えさせる。

好ましくは、認証要求は、第１の通信装置が予め保持する第１の公開鍵を含み、認証応答は、第１の公開鍵によって暗号化された第２の通信装置が予め保持する第２の公開鍵を含むとよい。また、認証要求は、第１の通信装置が生成した電子署名をさらに含み、電子署名は、第１の通信装置が予め保持する第１の秘密鍵によって暗号化されていてもよい。

好ましくは、鍵生成用情報を交換するステップは、第１の通信装置が、第２の公開鍵によって暗号化された第１の鍵生成用情報を共通秘密鍵生成要求として送信するステップと、第２の通信装置が、共通秘密鍵生成要求を受信すると、第１の公開鍵によって暗号化された第２の鍵生成用情報を共通秘密鍵生成応答として送信するステップとを含むとよい。

好ましくは、認証応答は、第１の公開鍵で暗号化された第２の鍵生成用情報を含み、鍵生成用情報を交換するステップは、第１の通信装置が、第２の公開鍵によって暗号化された第１の鍵生成用情報を共通秘密鍵生成要求として送信するとよい。

好ましくは、第１の鍵生成用情報及び第２の鍵生成用情報は、共通秘密鍵を生成するための共通秘密鍵生成アルゴリズムを含むとよい。また、第１の鍵生成用情報と第２の鍵生成用情報は、共通秘密鍵を生成するための乱数をさらに含んでもよい。

好ましくは、第１の通信装置と第２の通信装置とが、秘密通信を行うために、共通秘密鍵によって暗号化されたパラメータを交換するステップをさらに備えるとよい。

また、第１の通信装置が、秘密通信を行うためのパラメータを、第２の公開鍵によって暗号化して送信し、第２の通信装置が、パラメータを、第１の公開鍵によって暗号化して返信するステップをさらに備えてもよい。

また、鍵生成用情報を交換するステップとパラメータを交換するステップとを、同時に行ってもよい。

好ましくは、第１の通信装置は、第１の表示部を内蔵し、第２の通信装置は、第２の表示部を内蔵するとよい。

また、認証要求を表示するステップにおいて、第１の表示部は、第１の通信装置に接続する第３の通信装置の表示部であり、受信した認証要求を表示するステップにおいて、第２の表示部は、第２の通信装置に接続する第４の通信装置の表示部であり、確認するステップにおいて、第１の通信装置の使用者と第２の通信装置の使用者とは、それぞれ第３の通信装置と第４の通信装置とを用いて、第３の通信装置の表示部に表示された認証要求と第４の通信装置の表示部に表示された認証要求とが一致するか否かの確認を行い、承認するステップにおいて、第２の通信装置の使用者は、第４の通信装置を介して、第２の通信装置に対して承認の処理を行ってもよい。一例として、第３の通信装置及び第４の通信装置は、それぞれ携帯電話であってもよい。

また、本発明は、ネットワークに接続された二つの通信機器の間で行われる通信を保護するために、認証関係の構築と、当該通信に用いる共通秘密鍵の設定とを行う秘密通信システムに向けられている。そして、本発明は、認証を要求する第１の通信装置と、認証を要求された場合に、認証の応答を行う第２の通信装置とを備え、第１の通信装置は、第２の通信装置と通信を行う第１の送受信部と、認証を要求するための認証要求を生成するとともに、第２の通信機器から送信された、認証が承認されたことを通知するための認証応答を処理する第１の認証処理部と、予め保持する共通秘密鍵を生成するための第１の鍵生成用情報を第２の通信装置に送信するとともに、第２の通信装置が予め保持する共通秘密鍵を生成するための第２の鍵生成用情報の送信を第２の通信装置に要求するための共通秘密鍵生成要求を生成する第１の鍵処理部と、第１の鍵生成用情報と第２の鍵生成用情報とを用いて、共通秘密鍵を生成する第１の鍵生成部とを含み、第２の通信装置は、第１の通信装置と通信を行う第２の送受信部と、受信した認証要求を処理するとともに、第２の通信装置の使用者が行う認証の承認処理に応じて、認証応答を生成する第２の認証処理部と、共通秘密鍵生成要求に応じて、第２の鍵生成用情報を送信するための共通秘密鍵生成応答を生成する第２の鍵処理部と、第１の鍵生成用情報と第２の鍵生成用情報とを用いて、共通秘密鍵を生成する第２の鍵生成部とを含み、第１の通信装置の使用者は、所定の第１の表示部を用いて認証要求の内容を確認し、第２の通信装置の使用者は、所定の第２の表示部を用いて受信した認証要求の内容を確認し、第１の通信装置の使用者と第２の通信装置の使用者とは、通信の通信経路と異なる通信経路を用いて、第１の表示部に表示された認証要求の内容と第２の表示部に表示された認証要求とが一致するか否か確認し、一致すると判断された場合、第２の通信装置の使用者は、第２の通信装置に対して認証の承認を指示することを特徴とする。

好ましくは、認証要求は、第１の通信機器が予め保持する第１の公開鍵を含み、認証応答は、第２の通信機器が予め保持する第２の公開鍵で含むとよい。また、第１の通信機器は、電子署名を生成するための電子署名部をさらに備え、認証要求は、第１の通信機器が予め保持する第１の秘密鍵で暗号化された電子署名をさらに含んでもよい。

好ましくは、共通秘密鍵生成要求は、第２の公開鍵によって暗号化された第１の鍵生成用情報を含み、共通秘密鍵生成応答は、第１の公開鍵によって暗号化された第２の鍵生成用情報を含むとよい。

好ましくは、第１の通信装置は、共通秘密鍵で暗号化された秘密通信に必要なパラメータを秘密通信確立要求として生成する第１の接続管理部をさらに含み、第２の通信装置は、秘密通信確立要求を受信した場合、共通秘密鍵で暗号化されたパラメータを秘密通信確立応答として生成する第２の接続管理部を含むとよい。
また、第１の通信装置は、第２の公開鍵で暗号化された秘密通信に必要なパラメータを秘密通信確立要求として生成する第１の接続管理部をさらに含み、第２の通信装置は、秘密通信確立要求を受信した場合、第１の公開鍵で暗号化されたパラメータを秘密通信確立応答として生成する第２の接続管理部を含んでもよい。

また、第１の通信装置は、共通秘密鍵生成要求と秘密通信確立要求とを同時に送信し、第２の通信装置は、共通秘密鍵生成応答と秘密通信確立応答とを同時に送信してもよい。

好ましくは、第１の鍵生成用情報及び第２の鍵生成用情報は、共通秘密鍵を生成するための共通秘密鍵生成アルゴリズムを含むとよい。また、第１の鍵生成用情報及び第２の鍵生成用情報は、共通秘密鍵を生成するための乱数をさらに含んでもよい。

本発明の秘密通信設定方法及び秘密通信設定システムよれば、ネットワークに接続する第１の通信装置は、認証要求を第２の通信装置に送信する。第１の通信装置は、認証要求の内容を第１の表示部に表示させ、第２の通信装置は、受信した認証要求の内容を第２の表示部に表示させる。第１の通信装置の使用者と第２の通信装置の使用者とは、第１の通信装置と第２の通信装置とが用いる通信経路と異なる通信経路を用いて表示された認証要求が一致するか否か確認する。一致する場合、第２の通信装置の使用者は、認証承認を指示する。そして、第２の通信装置は、認証応答を送信する。これにより、それぞれの使用者が他の通信経路を用いて音声通話による相手の認識や、認証要求の内容を確認することによって認証が行われるため、相手が間違いないことを確認でき、また、第１の通信装置が送信した認証要求が盗聴・改竄されたとしても、確実に認証を実施することが可能となる。また、第１の通信装置の使用者と第２の通信装置の使用者とは、それぞれの通信装置に対して、認証局の設定や鍵情報の入力などの複雑な操作を行う必要がないため、負担が軽減される。

また、認証要求は、第１の通信装置の公開鍵を含み、認証応答は、第２の通信装置の公開鍵を含むことによって、それぞれの鍵生成用情報を暗号化して交換することができる。これにより、鍵生成用情報の交換時の通信の秘匿性を確保することができる。
さらに、本発明は、ホームネットワーク間のＩＰｓｅｃやＶＰＮ（Ｖｉｒｔｕａｌ Ｐｒｉｖａｔｅ Ｎｅｔｗｏｒｋ）に適用することができる。他のネットワークに適用することも可能である。

（第１の実施形態）
図１は、本発明の第１の実施形態に係る秘密通信の設定方法において用いられる、秘密ネットワークの構成の一例を示す図である。ネットワーク１は、第１の通信機器１０ａと、第２の通信機器１０ｂと、第１の電話機２０ａと、第２の電話機２０ｂとを備える。第１の通信機器１０ａ及び第１の電話機２０ａは、宅Ａ２ａに配置される。第２の通信機器１０ｂ及び第２の電話機２０ｂは、宅Ｂ２ｂに配置される。第１の通信機器１０ａと第２の通信機器１０ｂとは、インターネット３を介して接続する。第１の電話機２０ａと第２の電話機２０ｂとは、固定電話網を介して接続する。

以下の説明では、第１の通信機器１０ａがイニシエータであり、第２の通信機器１０ｂがレスポンダであるとして説明を行う。図１に示す第１の通信機器１０ａ及び第２の通信機器１０ｂは、どちらもイニシエータ及びレスポンダとしての動作することができる。なお、ネットワーク１において、イニシエータ１０ａ及びレスポンダ１０ｂは、公開鍵暗号方式を用いて通信を行う。

図２は、イニシエータ１０ａの機能的構成を示すブロック図である。イニシエータ１０ａは、表示部１１１と、入力部１１２と、送信部１１３と、受信部１１４と、認証処理部１１５と、鍵交換部１１６と、接続管理部１１７と、擬似ランダム関数部１１８と、暗号アルゴリズム部１１９と、電子署名部１２０と、公開鍵記憶部１２１と、鍵生成部１２２と、暗号鍵記憶部１２３とを備える。なお、レスポンダ１０ｂも、イニシエータ１０ａと同様の構成を備える。

表示部１１１は、認証要求を受信した際に、イニシエータ１０ａの公開鍵情報またはイニシエータ１０ａの署名を表示する。入力部１１２は、イニシエータ１０ａとして動作する場合、使用者がレスポンダ１０ｂのＩＰアドレスを入力するための入力手段である。また、入力部１１２は、レスポンダ１０ｂとして動作する場合、使用者が後述する認証要求に対して承認を与えるための入力手段である。送信部１１３は、インターネット３にデータを出力するためのインターフェースである。受信部１１４は、インターネット３から入力されるデータを受信するためのインターフェースである。

認証処理部１１５は、イニシエータ１０ａとレスポンダ１０ｂとの間で行われる認証の制御を行う。鍵交換部１１６は、イニシエータ１０ａとレスポンダ１０ｂとが秘密通信を行うための共有秘密鍵を生成するために必要な鍵生成用情報の交換の制御を行う。接続管理部１１７は、秘密通信確立後のイニシエータ１０ａとレスポンダ１０ｂとの秘密通信の制御を行う。

擬似ランダム関数部１１８は、擬似ランダム関数を発生し、認証処理部１１５に入力する。暗号アルゴリズム部１１９は、データの暗号化を行う。電子署名部１２０は、イニシエータとして動作する際に署名を作成する。公開鍵記憶部１２１は、イニシエータ１０ａの公開鍵と秘密鍵とを記憶する。鍵生成部１２２は、イニシエータ１０ａとレスポンダ１０ｂとが秘密通信を行うために用いる共通秘密鍵を生成する。暗号鍵記憶部１２３は、鍵生成部１１９が生成した共通秘密鍵を記憶する。

次に、第１の実施形態に係る秘密通信の設定方法について説明する。第１の実施形態において、秘密通信の設定は、認証、共通秘密鍵生成、及び秘密通信確立の３つの段階に分けることができる。認証では、秘密通信の際に用いられる共通秘密鍵の生成に先立ち、イニシエータ１０ａとレスポンダ１０ｂとの間で認証を行うとともに、共通秘密鍵生成用の情報を交換するためにイニシエータ１０ａの公開鍵の確認を行う。共通秘密鍵生成では、イニシエータ１０ａ及びレスポンダ１０ｂのそれぞれの公開鍵を用いて暗号化した共通秘密鍵生成用の情報の交換を行う。秘密通信確立では、秘密通信の際に用いるＳＡの設定を行う。

図３は、イニシエータ１０ａが秘密通信を設定する際に行う処理を示すフローチャートである。秘密通信の設定を開始すると、イニシエータ１０ａの使用者は、レスポンダ１０ｂのアドレスを入力する（ステップＳ１０１）。アドレスの入力は、イニシエータ１０ａの使用者が入力部１１３用いることによって行われてもよい。また、イニシエータ１０ａが、レスポンダのアドレスを予め保持しておいてもよい。イニシエータ１０ａは、レスポンダ１０ｂに認証を要求するための認証要求を生成して（ステップＳ１０２）、レスポンダ１０ｂに認証要求を送信する（ステップＳ１０３）。イニシエータ１０ａは、電子署名部１２０が生成する電子署名または暗号鍵記憶部１１８が保持する公開鍵を表示部１１４に表示する（ステップＳ１０４）。そして、イニシエータ１０ａは、認証を承認することを示す認証応答の受信待ち状態に入る（ステップＳ１０５）。

イニシエータ１０ａは、認証応答をレスポンダ１０ｂから受信した場合（ステップＳ１０６、Ｙｅｓ）、共通秘密鍵生成要求を生成する（ステップＳ１０７）。イニシエータ１０ａは、共通秘密鍵生成要求をレスポンダ１０ｂに送信して（ステップＳ１０８）、共通秘密鍵生成応答の受信待ち状態に入る（ステップＳ１０９）。一方、イニシエータ１０ａは、認証応答を指定時間内に受信しない、もしくは、認証応答に失敗のメッセージが含まれていた場合（ステップＳ１０６、Ｎｏ）、秘密通信の設定が失敗したと判断して（ステップＳ１１７）、処理を終了する。

イニシエータ１０ａは、共通秘密鍵生成応答をレスポンダ１０ｂから受信した場合（ステップＳ１１０、Ｙｅｓ）、共通秘密鍵を生成して（ステップＳ１１１）、秘密通信確立要求を生成する（ステップＳ１１２）。イニシエータ１０ａは、秘密通信確立要求をレスポンダ１０ｂに送信して（ステップＳ１１３）、秘密通信確立応答の受信待ち状態に入る（ステップＳ１１４）。一方、イニシエータ１０ａは、共通秘密鍵生成応答を受信しない場合（ステップＳ１１０、Ｎｏ）、秘密通信の設定が失敗したと判断して（ステップＳ１１７）、処理を終了する。

イニシエータ１０ａは、秘密通信確立応答をレスポンダ１０ｂから受信した場合（ステップＳ１１５、Ｙｅｓ）、秘密通信のパラメータ設定を行い（ステップＳ１１６）、処理を終了する。一方、イニシエータ１０ａは、秘密通信確立応答を受信しない場合（ステップＳ１１５、Ｎｏ）、秘密通信の設定が失敗したと判断して（ステップＳ１１７）、処理を終了する。

図３に示すイニシエータ１０ａのフローチャートにおいて、認証はステップＳ１０１〜Ｓ１０６が相当する。共通秘密鍵生成は、ステップＳ１０７〜Ｓ１１１が相当する。秘密通信確立は、ステップＳ１１２〜Ｓ１１６が相当する。

図４は、レスポンダ１０ｂが秘密通信を設定する際に行う処理を示すフローチャートである。秘密通信の設定を開始すると、レスポンダ１０ｂは、イニシエータ１０ａから送信される認証要求の受信待ち状態に入る（ステップＳ２０１）。レスポンダ１０ｂは、認証要求を受信すると（ステップＳ２０２、Ｙｅｓ）、表示部１１４に認証要求に含まれるイニシエータ１０ａの公開鍵または電子署名を表示して（ステップＳ２０３）、認証要求の承認の入力の待ち状態に入る（ステップＳ２０４）。一方、レスポンダ１０ｂは、認証要求を受信しない場合（ステップＳ２０２、Ｎｏ）、秘密通信の設定が失敗したと判断して（ステップＳ２１８）、処理を終了する。

レスポンダ１０ｂは、承認された場合（ステップＳ２０５、Ｙｅｓ）、認証応答を生成する（ステップＳ２０６）。レスポンダ１０ｂは、認証応答をイニシエータ１０ａに返信して（ステップＳ２０７）、共通秘密鍵生成要求の受信待ち状態に入る（ステップＳ２０８）。一方、レスポンダ１０ｂは、承認されない場合（ステップＳ２０５、Ｎｏ）、秘密通信の設定が失敗したと判断して（ステップＳ２１８）、処理を終了する。

レスポンダ１０ｂは、イニシエータ１０ａから共通秘密鍵生成要求を受信した場合（ステップＳ２０９、Ｙｅｓ）、共通秘密鍵生成応答を生成する（ステップＳ２１０）。レスポンダ１０ｂは、共通秘密鍵生成応答を返信する（ステップＳ２１１）。レスポンダ１０ｂは、共通秘密鍵を生成して（ステップＳ２１２）、秘密通信確立要求の受信待ち状態に入る（ステップＳ２１３）。一方、レスポンダ１０ｂは、共通秘密鍵生成要求を受信しない場合（ステップＳ２０９、Ｎｏ）、秘密通信の設定が失敗したと判断して（ステップＳ２１８）、処理を終了する。

レスポンダ１０ｂは、イニシエータ１０ａから秘密通信確立要求を受信した場合（ステップＳ２１４、Ｙｅｓ）、秘密通信確立応答を生成する（ステップＳ２１５）。レスポンダ１０ｂは、秘密通信確立応答を返信して（ステップＳ２１６）、秘密通信用のパラメータ設定を行い（ステップＳ２１７）、処理を終了する。一方、レスポンダ１０ｂは、秘密通信確立要求を受信しない場合（ステップＳ２１４、Ｎｏ）、秘密通信の設定が失敗したと判断して（ステップＳ２１８）、処理を終了する。

図４に示すレスポンダ１０ｂのフローチャートにおいて、認証はステップＳ２０１〜Ｓ２０７が相当する。共通秘密鍵生成は、ステップＳ２０８〜Ｓ２１２が相当する。秘密通信確立は、ステップＳ２１３〜Ｓ２１７が相当する。

図５は、図３及び図４に示した処理シーケンスを示す図である。図６は、イニシエータ１０ａとレスポンダ１０ｂとの間で送受信されるメッセージのフォーマットを示す図である。図６（ａ）は、認証要求２１のフォーマットを示す図である。図６（ｂ）は、認証応答２２のフォーマットを示す図である。図６（ｃ）は、共通秘密鍵生成要求２３のフォーマットを示す図である。図６（ｄ）は、共通秘密鍵生成応答２４のフォーマットを示す図である。図６（ｅ）は、秘密通信確立要求２５のフォーマットを示す図である。図６（ｆ）は、秘密通信確立応答２６のフォーマットを示す図である。

まず、認証について説明する。図５に示すように、秘密通信の設定を開始するとイニシエータ１０ａは、認証要求２１をレスポンダ１０ｂに送信する。

認証要求２１は、図６（ａ）に示すように、ヘッダ（ＨＤＲｉ）２１０と、第１のイニシエータのＳＡ（ＳＡｉ１）２１１と、イニシエータのＩＤ（ＩＤｉ）２１２と、イニシエータの公開鍵（ＰｕｂＫｅｙ＿ｉ）２１３と、イニシエータの署名（ＳＩＧｉ）２１４とを備える。ヘッダ２１０は、認証要求２１のヘッダである。ヘッダ２１０は、ＩＫＥのメッセージの形式に従ってもよいし、従わなくてもよい。第１のイニシエータのＳＡ２１１は、認証を行うために必要なイニシエータ１０ａの公開鍵暗号化アルゴリズムと、イニシエータの署名２１４の生成に用いる署名方法（ハッシュ関数及び暗号アルゴリズム）とを含む。

イニシエータのＩＤ２１２は、イニシエータ１０ａのＩＤであり、ＩＫＥで規定される各種ＩＤの生成方法によって生成される。なお、イニシエータ１０ａは、なりすましを防止するために、イニシエータのＩＤ２１２をランダムに生成することが望ましい。例えば、イニシエータのＩＤ２１２は、イニシエータ１０ａの固有ＩＤと現在時刻とを用いて生成することができる。すなわち、ＩＤｉ＝ｐｒｆ（イニシエータ１０ａの固有ＩＤ、現在時刻）となる。イニシエータの公開鍵２１３は、イニシエータ１０ａがレスポンダ１０ｂの認証時に使用する公開鍵である。

イニシエータの署名２１４はオプションであるため、認証要求２１は、備えていなくてもよい。なお、イニシエータの署名２１４は、以下のようにして生成される。まず、イニシエータ１０ａは、ヘッダ２１０と、第１のイニシエータのＳＡ２１１と、イニシエータのＩＤ２１２と、イニシエータの公開鍵２１３とに対して、第１のイニシエータのＳＡ２１１で指定されたハッシュ関数をかけてハッシュ値を得る。ハッシュ値に対して、第１のイニシエータのＳＡ２１１で指定された暗号化アルゴリズムと、イニシエータの公開鍵２１３に対応する秘密鍵（ＰｒｉＫｅｙ＿ｉ）とによって暗号化されることによって、イニシエータの署名２１４は生成される。

レスポンダ１０ｂは、認証要求２１を受信すると、イニシエータの公開鍵２１３を取り出す。そして、レスポンダ１０ｂは、認証要求２１にイニシエータの署名２１４があるか否かを確認する。イニシエータの署名２１４がない場合、レスポンダ１０ｂは、認証要求２１をそのまま受け取る。イニシエータの署名２１４がある場合、レスポンダ１０ｂは、イニシエータの公開鍵２１３を用いて、イニシエータの署名２１４を復号する。レスポンダ１０ｂは、上述したイニシエータの署名２１４の生成と同様の手順で得た結果と、イニシエータの署名２１４とを比較する。比較結果が一致した場合、レスポンダ１０ｂは、認証要求２１の整合性を確認することができるため、認証要求２１をイニシエータ１０ａからのメッセージであると信用して、正式に受け取る。

レスポンダ１０ｂが認証要求２１を受信した後、イニシエータ１０ａとレスポンダ１０ｂとは、イニシエータの公開鍵２１３の確認を行う。イニシエータ１０ａとレスポンダ１０ｂとは、自身の表示部１１４に、イニシエータの公開鍵２１３をそれぞれ表示する。認証要求２１にイニシエータの署名２１４がある場合、イニシエータ１０ａとレスポンダ１０ｂは、自身の表示部１１４に、イニシエータの署名２１４をそれぞれ表示する。

イニシエータ１０ａの使用者ａとレスポンダ１０ｂの使用者ｂとは、第１の電話機２０ａ及び第２の電話機２０ｂをそれぞれ用いて、イニシエータ１０ａ及びレスポンダ１０ｂの表示部１１４にそれぞれ表示されているイニシエータの公開鍵２１３またはイニシエータの署名２１４が一致しているか否かを確認する。レスポンダ１０ｂの使用者ｂとの電話による通話により、イニシエータ１０ａの使用者ａは認証しようとしている相手（レスポンダ１０ｂの使用者ｂ）が間違いないことが確認でき、表示内容が一致していることをイニシエータ１０ａの使用者ａとレスポンダ１０ｂの使用者ｂとが通話により確認することで、認証する相手（レスポンダ１０ｂ）が間違いないことを確認できる。一致している場合、レスポンダ１０ｂの使用者ｂは、レスポンダ１０ｂの入力部１１３を用いて承認処理を行う。一致していない場合、秘密通信の設定の処理を終了する。

なお、イニシエータの公開鍵２１３のデータ量が大きいため、表示部１１４にイニシエータの公開鍵２１３を一度に表示しきれない場合、イニシエータの公開鍵２１３の一部を表示してもよいし、所定の処理を行って、イニシエータの公開鍵２１３を短縮したものを表示してもよい。また、入力部１１４にロール機能を持たせてもよい。イニシエータの署名２１４のデータ量が多い場合も同様の処理が可能である。

また、イニシエータ１０ａの使用者ａは、イニシエータの公開鍵２１３を、事前にレスポンダ１０ｂの使用者ｂに連絡しておいてもよい。これにより、認証要求２１を受信した際の確認作業を省略することができる。さらに、イニシエータ１０ａの使用者ａは、電話以外の通信手段を用いてもよい。例えば、ＦＡＸを用いて、イニシエータの公開鍵２１３をレスポンダ１０ｂの使用者ｂに通知することなどが考えられる。

レスポンダ１０ｂは、使用者ｂによる承認が行われると、認証応答２２をイニシエータ１０ａへ返信する。図６（ｂ）に示すように、認証応答２２は、ヘッダ（ＨＤＲｒ）２２０と、暗号化された第１のレスポンダのＳＡ（＜ＳＡｒ１＿ｂ＞ＰｕｂＫｅｙ＿ｉ）２２１と、暗号化されたレスポンダのＩＤ（＜ＩＤｒ＿ｂ＞ＰｕｂＫｅｙ＿ｉ）２２２と、暗号化されたレスポンダの公開鍵（＜ＰｕｂＫｅｙ＿ｒ＿ｂ＞ＰｕｂＫｅｙ＿ｉ）２２３とを備える。図６（ｂ）に示すように、第１のレスポンダのＳＡ（ＳＡｒ１）、レスポンダのＩＤ（ＩＤｒ）、及びレスポンダの公開鍵（ＰｕｂＫｅｙ＿ｒ）のボディは、イニシエータの公開鍵（ＰｕｂＫｅｙ＿ｉ）によってそれぞれ暗号化されている。第１のレスポンダのＳＡ（ＳＡｒ１）は、第１のイニシエータのＳＡ２１１と同様に、認証時に用いる暗号化アルゴリズムなどを含む。レスポンダのＩＤ（ＩＤｒ）は、イニシエータのＩＤ２１２と同様の手順で生成される。レスポンダの公開鍵（ＰｕｂＫｅｙ＿ｒ）は、イニシエータ１０ａが認証の際に用いるレスポンダ１０ｂの公開鍵である。このように、レスポンダ１０ｂに関する情報は、イニシエータの公開鍵２１３によって暗号化されているため、第三者による解読が不可能となっている。このため、認証の後で行われる共通秘密鍵生成の際に行われる通信をセキュアに保つことが可能となる。

イニシエータ１０ａは、認証応答２２を受信すると、認証応答２２の暗号化された各データを復号し、自身の秘密鍵（ＰｒｉＫｅｙ＿ｉ）を用いて、第１のレスポンダのＳＡと、レスポンダのＩＤと、レスポンダの公開鍵（ＰｕｂＫｅｙ＿ｒ）を得る。これにより、イニシエータ１０ａとレスポンダ１０ｂとは、お互いのＩＤと公開鍵とを共有することができる。なお、認証応答２２は、認証要求２１と同様に、レスポンダの署名を含んでもよい。この場合、レスポンダのＩＤ及び公開鍵を、イニシエータ１０ａ及びレスポンダ１０ｂのそれぞれの表示部１１４に表示し、再度、イニシエータ１０ａの使用者ａとレスポンダ１０ｂの使用者ｂとによる確認と、イニシエータ１０ａの使用者ａによる承認とを行う必要がある。

次に、共通秘密鍵生成について説明する。認証終了後、イニシエータ１０ａとレスポンダ１０ｂとは、秘密通信を行うための共通秘密鍵（Ｋｅｙ＿ｉｒ）の生成を行う。以下、共通秘密鍵生成の手順について詳しく説明する。イニシエータ１０ａは、レスポンダ１０ｂに共通秘密鍵生成要求２３を送信する。図６（ｃ）に示すように、共通秘密鍵生成要求２３は、ヘッダ（ＨＤＲｉ）２３０と、レスポンダの公開鍵で暗号化された第２のイニシエータのＳＡ（＜ＳＡｉ２＿ｂ＞ＰｕｂＫｅｙ＿ｒ）２３１と、第１の鍵生成用情報（＜ＡＬＧｉ＿ｂ＞ＰｕｂＫｅｙ＿ｒ［，＜Ｎｉ＿ｂ＞ＰｕｂＫｅｙ＿ｒ］２３２とを備える。第２のイニシエータのＳＡ（ＳＡｉ２＿ｂ）は、後述する秘密通信確立の際に必要な情報であり、共通秘密鍵暗号アルゴリズムなどを含む。第１の鍵生成用情報（ＡＬＧｉ［，Ｎｉ＿ｂ］）は、共通秘密鍵を生成するための情報を含む。ここで、ＡＬＧｉは、イニシエータ１０ａが保持する第１の共通鍵生成アルゴリズムである。Ｎｉ＿ｂは、イニシエータ１０ａが擬似ランダム関数部１２２で生成した第１の乱数である。

レスポンダ１０ｂは、共通秘密鍵生成要求２３を受信すると、自身の秘密鍵（ＰｒｉＫｅｙ＿ｒ）を用いて、ボディがレスポンダ１０ｂの公開鍵で暗号化された第２のイニシエータのＳＡ２３１及び第１の鍵生成用情報２３２を、第２のイニシエータのＳＡ（ＳＡｉ２＿ｂ）と第１の鍵生成用情報（ＡＬＧｉ＿ｂ［，Ｎｉ＿ｂ］）とにそれぞれ復号する。そして、レスポンダ１０ｂは、共通秘密鍵生成応答２４を生成してイニシエータ１０ａに送信する。図６（ｄ）に示すように、共通秘密鍵生成応答２４は、ヘッダ（ＨＤＲｒ）２４０と、ボディがイニシエータの公開鍵で暗号化された第２のレスポンダのＳＡ（＜ＳＡｒ２＿ｂ＞ＰｕｂＫｅｙ＿ｉ）２４１と、第２の鍵生成用情報（＜ＡＬＧｒ＿ｂ＞ＰｕｂＫｅｙ＿ｉ［，＜Ｎｒ＿ｂ＞ＰｕｂＫｅｙ＿ｉ］２４２とを備える。第２のレスポンダのＳＡ（ＳＡｒ２）は、秘密通信確立の際に必要なＳＡパラメータの返答情報を含む。ＡＬＧｒは、レスポンダ１０ｂが保持する第２の共通鍵生成アルゴリズムである。Ｎｒ＿ｂは、レスポンダ１０ｂが擬似ランダム関数部１２２で生成した第２の乱数である。

イニシエータ１０ａは、共通秘密鍵生成応答２４を受信すると、自身の秘密鍵（ＰｒｉＫｅｙ＿ｉ）を用いて、ボディがイニシエータの公開鍵で暗号化された第２のレスポンダのＳＡ２４１及び第２の鍵生成用情報２４２を、第２のレスポンダのＳＡ（ＳＡｒ２＿ｂ）と第２の鍵生成用情報（ＡＬＧｒ＿ｂ［，Ｎｒ＿ｂ］）とにそれぞれ復号する。このように、イニシエータ１０ａとレスポンダ１０ｂとは、第１の鍵生成用情報と第２の鍵生成用情報とを交換することによって、共通秘密鍵生成アルゴリズム（ＡＬＧ）について合意する。

イニシエータ１０ａとレスポンダ１０ｂとは、認証及び共通秘密鍵で交換したパラメータであるイニシエータのＩＤと、レスポンダのＩＤと、第１の鍵生成用情報と、第２の鍵生成用情報と、第１の乱数と、第２の乱数とに基づいて、それぞれ共通秘密鍵を生成する。共通秘密鍵の生成式は、以下のように表すことができる。Ｋｅｙ＿ｉｒ＝ＡＬＧ（ＩＤｉ＿ｂ｜ＩＤｒ＿ｂ［，Ｎｉ＿ｂ｜Ｎｒ＿ｂ］）。なお、共通秘密鍵の生成は、上記以外の生成式を用いてもよい。これにより、イニシエータ１０ａとレスポンダ１０ｂとは、秘密通信に用いられる共通秘密鍵を生成する。

次に、秘密通信確立について説明する。共通秘密鍵を生成すると、イニシエータ１０ａとレスポンダ１０ｂとは、秘密通信確立を行う。イニシエータ１０ａは、レスポンダ１０ｂに秘密通信確立要求２５を送信する。図６（ｅ）に示すように、秘密通信確立要求２５は、ヘッダ（ＨＤＲｉ）２５０と、ボディが共通秘密鍵で暗号化された第３のイニシエータ１０ａのＳＡ（＜ＳＡｉ３＿ｂ＞Ｋｅｙ＿ｉｒ）２５１とを備える。第３のイニシエータ１０ａのＳＡ（ＳＡｉ３）は、秘密通信確立後に行われる通信で用いられるＳＡに関する情報（有効期限や更新方法など）を含む。

レスポンダ１０ｂは、秘密通信確立要求２５を受信すると、共通秘密鍵で暗号化された第３のイニシエータのＳＡ２５１を、共通秘密鍵で復号する。レスポンダ１０ｂは、秘密通信確立応答２６を生成してイニシエータ１０ａに送信する。図６（ｆ）に示すように、秘密通信確立応答２６は、ヘッダ（ＨＤＲｒ）２６０と、ボディが共通秘密鍵で暗号化された第３のレスポンダのＳＡ（＜ＳＡｒ３＿ｂ＞Ｋｅｙ＿ｉｒ）２６１とを備える。第３のレスポンダのＳＡ（ＳＡｒ３）は、第３のイニシエータのＳＡで指定されたＳＡに関する情報（有効期限や更新方法など）を含む。イニシエータ１０ａは、秘密通信確立応答２６を受信すると、ボディが共通秘密鍵で暗号化された第３のレスポンダのＳＡを、共通秘密鍵を用いて復号する。イニシエータ１０ａとレスポンダ１０ｂとは、共通秘密鍵を用いて、秘密通信に必要なＳＡパラメータの合意を行うことによって、セキュアな通信を行うことが可能になる。

このように、イニシエータとレスポンダとは、公開鍵暗号方式を用いて認証を行い、セキュアな状態を作った後で、共通秘密鍵の生成及び秘密通信の確立を行う。これにより、共通秘密鍵の生成及び秘密通信の確立の際に、なりすましや盗聴などの攻撃が行われることを防ぐことが可能となる。また、第１の実施形態で説明した秘密通信設定方法は、イニシエータ１０ａ及びレスポンダ１０ｂのＩＰアドレスに依存しない。このため、イニシエータ１０ａ及びレスポンダ１０ｂのＩＰアドレスが変更されても、引き続き認証済みの状態として秘密通信を行うことが可能となるため、再設定を行う必要がなくなる。また、イニシエータ１０ａ及びレスポンダ１０ｂのそれぞれの使用者が認証の承認を行うために、イニシエータ１０ａとレスポンダ１０ｂとは、認証要求及び認証応答の確認処理及びそのための回路等を必要としない。これにより、イニシエータ１０ａ及びレスポンダ１０ｂの小型化が可能となるため、イニシエータ１０ａ及びレスポンダ１０ｂの機能を各家庭で使用される家電機器に搭載することが可能となる。

なお、秘密通信確立時のＳＡパラメータの交換において、イニシエータ１０ａとレスポンダ１０ｂとは、共通秘密鍵を用いてＳＡの暗号化及び復号化を行うものとして説明をした。しかし、イニシエータ１０ａとレスポンダ１０ｂとは、相手の公開鍵を用いてＳＡを暗号化し、暗号化されたＳＡを自身の秘密鍵を用いて復号してもよい。

また、秘密通信確立時のＳＡパラメータの交換において、ＳＡのペイロードが第三者に盗聴されないことが明らかな場合、または盗聴されてもセキュリティに影響がない場合、イニシエータ１０ａは、認証要求２１の第１のイニシエータのＳＡに、第３のイニシエータのＳＡを含めてもよい。

さらに、イニシエータ１０ａとレスポンダ１０ｂとは、共通秘密鍵を、所定の不揮発性メモリ（図示せず）で保持してもよい。これにより、イニシエータ１０ａとレスポンダ１０ｂとは、再起動などを行うことによって電源がＯＦＦになった場合でも、認証済み状態として、共通秘密鍵を再利用することが可能である。これにより、秘密通信の設定を再度行う手間を省略することが可能になる。

なお、レスポンダ１０ｂは、認証応答２２として図６（ｇ）に示すフォーマットを用いてもよい。図６（ｇ）に示す認証応答２２は、共通秘密鍵生成応答２４に含まれる、ボディがイニシエータ１０ａの公開鍵で暗号化された第２の鍵生成用情報２４２を含む。これにより、レスポンダ１０ｂは、共通秘密鍵生成応答２４の送信を省略することが可能になる。

（第２の実施形態）
図７は、本発明の第２の実施形態に係る秘密通信の設定方法のシーケンス図である。第２の実施形態に係る秘密通信方法において、ネットワーク構成と、イニシエータ１０ａ及びレスポンダ１０ｂのブロック構成とは、第１の実施形態と同様である。また、第２の実施形態に係る秘密通信方法において、認証は第１の実施形態と同様である。第１の実施形態と同様の点については、その説明を省略する。以下では、第１の実施形態と第２の実施形態との差異を中心に説明する。

第２の実施形態は、共通秘密鍵生成及び秘密通信確立を同時に行う点が、第１の実施形態と異なる。図７に示すように、認証終了後、イニシエータ１０ａは、レスポンダ１０ｂに共通秘密鍵生成及び秘密通信確立要求３１を送信する。図８（ａ）に、共通秘密鍵生成及び秘密通信確立要求３１のフォーマットを示す。共通秘密鍵生成及び秘密通信確立要求３１は、ヘッダ（ＨＤＲｉ）３１０と、ボディがレスポンダの公開鍵で暗号化された第４のイニシエータのＳＡ３１１（＜ＳＡｉ４＿ｂ＞ＰｕｂＫｅｙ＿ｒ）と、ボディがレスポンダの公開鍵で暗号化された第１の鍵生成用情報２３２とを備える。第４のイニシエータのＳＡ（ＳＡｉ４）は、共通秘密鍵生成と秘密通信確立との関係に関する情報や秘密通信確立後に用いるＳＡに関する情報などを含む。

レスポンダ１０ｂは、共通秘密鍵生成及び秘密通信確立要求３１を受信すると、イニシエータ１０ａに共通秘密鍵生成及び秘密通信確立応答３２を返信する。図８（ｂ）に、共通秘密鍵生成及び秘密通信確立応答３２を示す。共通秘密鍵生成及び秘密通信確立応答３２は、ヘッダ（ＨＤＲｒ）３２０と、ボディがイニシエータの公開鍵で暗号化された第４のレスポンダのＳＡ３２１（＜ＳＡｒ４＿ｂ＞ＰｕｂＫｅｙ＿ｉ）と、ボディがイニシエータの公開鍵で暗号化された第２の鍵生成用情報２４２とを備える。第４のレスポンダのＳＡ３２１（ＳＡｒ４）は、第４のイニシエータのＳＡに含まれた共通秘密鍵と秘密通信確立との関係に関する情報や秘密通信確立後に用いるＳＡに対する応答情報を含む。

このように、第２の実施形態に係る秘密通信方法は、共通秘密鍵生成及び秘密通信確立に関する情報を一つのメッセージにまとめて送受信する。これにより、第１の実施形態と比較して、秘密通信の設定処理を早く行うことが可能となる。

なお、レスポンダ１０ｂは、共通秘密鍵生成及び秘密通信確立応答３２に含まれる、ボディをイニシエータの公開鍵で暗号化された第４のレスポンダのＳＡ３２１と、ボディをイニシエータの公開鍵で暗号化された第２の鍵生成用情報２４２とを、予め認証応答２２に含めて返信してもよい。これにより、秘密通信の設定処理をさらに早く行うことが可能となる。

（第３の実施形態）
図９は、本発明の第３の実施形態に係る秘密通信の設定方法において用いられる、ネットワークの構成の一例を示す図である。図９に示すように、秘密通信システム２は、第１の電話機２０ａ及び第２の電話機２０ｂに代えて、外部通信装置である第１の携帯電話３０ａ及び第２の携帯電話３０ｂを備える点が、図１に示すネットワーク１と異なる。イニシエータ１０ａとレスポンダ１０ｂとの間で行われるメッセージの送受信は、第１の実施形態と同じである。以下、秘密通信システム１と異なる点を中心に、第３の実施形態に係る秘密通信システム２について説明する。

イニシエータ１０ａは、図４に示す入力部１１３及び表示部１４に代えて、図示しないインターフェース部を備える。インターフェース部は、第１の携帯電話３０ａと接続する。このように、図９に示すネットワーク２は、イニシエータ１０ａ及びレスポンダ１０ｂと携帯電話とをそれぞれ接続することによって、イニシエータ１０ａ及びレスポンダ１０ｂの遠隔操作することができる。また、イニシエータ１０ａ及びレスポンダ１０ｂを、それぞれの使用者宅ではなく、屋外等で使用することが可能となる。

認証を行う前に、イニシエータ１０ａと第１の携帯電話３０ａとは、セキュアな通信路４０ａを確立する。レスポンダ１０ｂと第２の携帯電話３０ｂとは、セキュアな通信路４０ｂを確立する。そして、イニシエータ１０ａとレスポンダ１０ｂとは、図５に示す認証を開始する。

イニシエータ１０ａがレスポンダ１０ｂに認証要求２１を送信した後、イニシエータ１０ａは、第１の携帯電話３０ａの表示画面にイニシエータの公開鍵２１３を表示する。同様に、レスポンダ１０ｂは、第２の携帯電話３０ｂの表示画面にイニシエータの公開鍵２１３を表示する。イニシエータ１０ａの使用者ａとレスポンダ１０ｂの使用者ｂとは、第１の携帯電話３０ａと第２の携帯電話３０ｂとを用いて通話し、イニシエータの公開鍵２１３が一致しているか確認する。第１の携帯電話３０ａと第２の携帯電話３０ｂとの間の通信は、通常秘密通信とされているため、イニシエータの公開鍵２１３が外部に漏れることはない。続いて、レスポンダ１０ｂの使用者ｂは、第２の携帯電話３０ｂを介して、レスポンダ１０ｂに対して承認を行う。レスポンダ１０ｂは、イニシエータ１０ａに認証応答２２を送信して、認証の手順を完了する。なお、第１の携帯電話３０ａと第２の携帯電話３０ｂとに表示するデータは、イニシエータの署名２１４であってもよい。

なお、図９では、イニシエータ１０ａ及びレスポンダ１０ｂが両者とも屋外にいる場合を示しているが、どちらかが使用者宅にあってもよい。この場合、使用者宅にある通信装置は、固定電話を用いてもよい。また、外部通信装置は、携帯電話に限られず、他の通信装置を用いてもよい。

本発明に係る秘密通信設定方法及び通信装置は、鍵情報等の設定や操作を行わないためにユーザへの負担を軽減するとともに、共通秘密鍵を生成するための情報を通信装置間で交換する際になりすましや盗聴などの攻撃を防ぐ効果を有し、通信装置間の認証関係の構築と秘密通信に用いられる共通秘密鍵の設定とを行う秘密通信設定方法及び通信装置として有用である。

第１の実施形態に係るネットワークの構成の一例を示す図 イニシエータ１０ａの機能的構成を示すブロック図 秘密通信を設定する際のイニシエータの処理を示すフローチャート 秘密通信を設定する際のレスポンダの処理を示すフローチャート 第１の実施形態に係る秘密通信の設定方法のシーケンス図 第１の実施形態に係る秘密通信設定時のメッセージのフォーマットを示す図 第２の実施形態に係る秘密通信の設定方法のシーケンス図 第２の実施形態に係る秘密通信設定時のメッセージのフォーマットを示す図 第３の実施形態に係るネットワークの構成の一例を示す図 家庭間のネットワークの構成の一例を示す図 ＩＫＥを用いた認証及び鍵交換の方法を具体的に示すシーケンス図 事前鍵共有方式におけるメッセージのフォーマットを示す図 署名方式におけるメッセージのフォーマットを示す図 公開鍵暗号方式におけるメッセージのフォーマットを示す図 改良型公開鍵暗号方式におけるメッセージのフォーマットを示す図

符号の説明

１０ａ イニシエータ
１０ｂ レスポンダ
１１１ 表示部
１１２ 入力部
１１３ 送信部
１１４ 受信部
１１５ 認証処理部
１１６ 鍵交換部
１１７ 接続管理部
１１８ 擬似ランダム関数部
１１９ 暗号アルゴリズム部
１２０ 電子署名部
１２１ 公開鍵記憶部
１２２ 鍵生成部
１２３ 暗号鍵記憶部

Claims (22)

1. ネットワークを介して接続する第１の通信装置と第２の通信装置との間の通信を保護するために、当該第１通信装置と当該第２の通信装置との認証関係の構築と、当該通信のために当該第１の通信装置及び当該第２の通信装置が用いる共通秘密鍵の設定とを行う秘密通信設定方法であって、
   前記第１の通信装置が、前記第２の通信装置と認証を行うための認証要求を送信するステップと、
   前記第１の通信装置が、所定の第１の表示部に前記認証要求の内容を表示させるステップと、
   前記第２の通信装置が、所定の第２の表示部に受信した認証要求の内容を表示させるステップと、
   前記第１の通信装置の使用者と前記第２通信装置の使用者とが、前記第１の表示部に表示された認証要求の内容と、前記第２の表示部に表示された認証要求の内容とが一致するか否かを、前記通信の通信経路と異なる通信経路を用いて確認するステップと、
   一致すると判断された場合、前記第２の通信装置の使用者が、認証の承認を指示するステップと、
   前記承認の処理に基づいて、前記第２の通信装置が、認証応答を送信するステップと、
   前記第１の通信装置と前記第２の通信装置とが、前記第１の通信装置が保持する第１の鍵生成用情報と、前記第２の通信装置が保持する第２の鍵生成用情報とを交換するステップと、
   前記第１の通信装置及び前記第２の通信装置のそれぞれが、前記第１の鍵生成用情報と前記第２の鍵生成用情報との両方を用いて、共通秘密鍵を生成して設定するステップとを備える、秘密通信設定方法。
2. 前記認証要求は、前記第１の通信装置が予め保持する第１の公開鍵を含み、
   前記認証応答は、前記第１の公開鍵によって暗号化された前記第２の通信装置が予め保持する第２の公開鍵を含む、請求項１に記載の秘密通信設定方法。
3. 前記認証要求は、前記第１の通信装置が生成した電子署名をさらに含み、
   前記電子署名は、前記第１の通信装置が予め保持する第１の秘密鍵によって暗号化されていることを特徴とする、請求項２に記載の秘密通信設定方法。
4. 前記鍵生成用情報を交換するステップは、
   前記第１の通信装置が、前記第２の公開鍵によって暗号化された前記第１の鍵生成用情報を共通秘密鍵生成要求として送信するステップと、
   前記第２の通信装置が、前記共通秘密鍵生成要求を受信すると、前記第１の公開鍵によって暗号化された前記第２の鍵生成用情報を共通秘密鍵生成応答として送信するステップとを含む、請求項２または３に記載の秘密通信設定方法。
5. 前記認証応答は、前記第１の公開鍵で暗号化された第２の鍵生成用情報を含み、
   前記鍵生成用情報を交換するステップは、
   前記第１の通信装置が、前記第２の公開鍵によって暗号化された前記第１の鍵生成用情報を共通秘密鍵生成要求として送信することを特徴とする、請求項１に記載の秘密通信設定方法。
6. 前記第１の鍵生成用情報及び前記第２の鍵生成用情報は、前記共通秘密鍵を生成するための共通秘密鍵生成アルゴリズムを含む、請求項１に記載の秘密通信定方法。
7. 前記第１の鍵生成用情報と前記第２の鍵生成用情報は、前記共通秘密鍵を生成するための乱数をさらに含む、請求項６に記載の秘密通信設定方法。
8. 前記第１の通信装置と前記第２の通信装置とが、秘密通信を行うために、前記共通秘密鍵によって暗号化されたパラメータを交換するステップをさらに備える、請求項１に記載の秘密通信設定方法。
9. 前記第１の通信装置が、秘密通信を行うためのパラメータを、前記第２の公開鍵によって暗号化して送信し、前記第２の通信装置が、前記パラメータを、前記第１の公開鍵によって暗号化して返信するステップをさらに備える、請求項１に記載の秘密通信設定方法。
10. 前記鍵生成用情報を交換するステップと前記パラメータを交換するステップとを、同時に行うことを特徴とする、請求項８または９に記載の秘密通信設定方法。
11. 前記第１の通信装置は、前記第１の表示部を内蔵し、
    前記第２の通信装置は、前記第２の表示部を内蔵することを特徴とする、請求項１に記載の秘密通信設定方法。
12. 前記認証要求を表示するステップにおいて、前記第１の表示部は、前記第１の通信装置に接続する第３の通信装置の表示部であり、
    前記受信した認証要求を表示するステップにおいて、前記第２の表示部は、前記第２の通信装置に接続する第４の通信装置の表示部であり、
    前記確認するステップにおいて、前記第１の通信装置の使用者と前記第２の通信装置の使用者とは、それぞれ前記第３の通信装置と前記第４の通信装置とを用いて、前記第３の通信装置の表示部に表示された認証要求と前記第４の通信装置の表示部に表示された認証要求とが一致するか否かの確認を行い、
    前記承認するステップにおいて、前記第２の通信装置の使用者は、前記第４の通信装置を介して、前記第２の通信装置に対して承認の処理を行うことを特徴とする、請求項１に記載の秘密通信設定方法。
13. 前記第３の通信装置及び前記第４の通信装置は、それぞれ携帯電話であることを特徴とする、請求項１２に記載の秘密通信設定方法。
14. ネットワークに接続された二つの通信機器の間で行われる通信を保護するために、認証関係の構築と、当該通信に用いる共通秘密鍵の設定とを行う秘密通信システムであって、
    認証を要求する第１の通信装置と、
    認証を要求された場合に、認証の応答を行う第２の通信装置とを備え、
    前記第１の通信装置は、
    前記第２の通信装置と通信を行う第１の送受信部と、
    認証を要求するための認証要求を生成するとともに、前記第２の通信機器から送信された、認証が承認されたことを通知するための認証応答を処理する第１の認証処理部と、
    予め保持する前記共通秘密鍵を生成するための第１の鍵生成用情報を前記第２の通信装置に送信するとともに、前記第２の通信装置が予め保持する前記共通秘密鍵を生成するための第２の鍵生成用情報の送信を前記第２の通信装置に要求するための共通秘密鍵生成要求を生成する第１の鍵処理部と、
    前記第１の鍵生成用情報と前記第２の鍵生成用情報とを用いて、前記共通秘密鍵を生成する第１の鍵生成部とを含み、
    前記第２の通信装置は、
    前記第１の通信装置と通信を行う第２の送受信部と、
    受信した認証要求を処理するとともに、前記第２の通信装置の使用者が行う認証の承認処理に応じて、前記認証応答を生成する第２の認証処理部と、
    前記共通秘密鍵生成要求に応じて、前記第２の鍵生成用情報を送信するための共通秘密鍵生成応答を生成する第２の鍵処理部と、
    前記第１の鍵生成用情報と前記第２の鍵生成用情報とを用いて、前記共通秘密鍵を生成する第２の鍵生成部とを含み、
    前記第１の通信装置の使用者は、所定の第１の表示部を用いて前記認証要求の内容を確認し、
    前記第２の通信装置の使用者は、所定の第２の表示部を用いて受信した前記認証要求の内容を確認し、
    前記第１の通信装置の使用者と前記第２の通信装置の使用者とは、前記通信の通信経路と異なる通信経路を用いて、前記第１の表示部に表示された認証要求の内容と前記第２の表示部に表示された認証要求とが一致するか否か確認し、
    一致すると判断された場合、前記第２の通信装置の使用者は、前記第２の通信装置に対して認証の承認を指示することを特徴とする、秘密通信システム。
15. 前記認証要求は、前記第１の通信機器が予め保持する第１の公開鍵を含み、
    前記認証応答は、前記第２の通信機器が予め保持する第２の公開鍵を含む、請求項１４に記載の秘密通信システム。
16. 前記第１の通信機器は、
    電子署名を生成するための電子署名部をさらに備え、
    前記認証要求は、前記第１の通信機器が予め保持する第１の秘密鍵で暗号化された前記電子署名をさらに含む、請求項１５に記載の秘密通信システム。
17. 前記共通秘密鍵生成要求は、前記第２の公開鍵によって暗号化された前記第１の鍵生成用情報を含み、
    前記共通秘密鍵生成応答は、前記第１の公開鍵によって暗号化された前記第２の鍵生成用情報を含む、請求項１５または１６に記載の秘密通信システム。
18. 前記第１の通信装置は、
    前記共通秘密鍵で暗号化された秘密通信に必要なパラメータを秘密通信確立要求として生成する第１の接続管理部をさらに含み、
    前記第２の通信装置は、
    前記秘密通信確立要求を受信した場合、共通秘密鍵で暗号化された前記パラメータを前記秘密通信確立応答として生成する第２の接続管理部をさらに含む、請求項１４に記載の秘密通信システム。
19. 前記第１の通信装置は、
    前記第２の公開鍵で暗号化された秘密通信に必要なパラメータを秘密通信確立要求として生成する第１の接続管理部をさらに含み、
    前記第２の通信装置は、
    前記秘密通信確立要求を受信した場合、前記第１の公開鍵で暗号化された前記パラメータを秘密通信確立応答として生成する第２の接続管理部をさらに含む、請求項１４に記載の秘密通信システム。
20. 前記第１の通信装置は、前記共通秘密鍵生成要求と秘密通信確立要求とを同時に送信し、
    前記第２の通信装置は、前記共通秘密鍵生成応答と秘密通信確立応答とを同時に送信することを特徴とする、請求項１４に記載の秘密通信システム。
21. 前記第１の鍵生成用情報及び前記第２の鍵生成用情報は、前記共通秘密鍵を生成するための共通秘密鍵生成アルゴリズムを含む、請求項１７記載の秘密通信システム。
22. 前記第１の鍵生成用情報及び前記第２の鍵生成用情報は、前記共通秘密鍵を生成するための乱数をさらに含む、請求項２１に記載の秘密通信システム。

Images