(57)【要約】【課題】  端末が利用するルータやＤＨＣＰサーバが動的に変化する場合においても、端末がルータやＤＨＣＰサーバから送信されたメッセージの正当性を確認できるようにすることを目的とする。【解決手段】  端末が通信を要求した際に認証サーバが当該端末の認証に用いる暗号鍵を、認証サーバが当該端末へ配布するのと同時に、ルータやＤＨＣＰサーバにも配布することにより、当該端末が利用するルータやＤＨＣＰサーバが動的に変化した場合でも、当該端末とルータやＤＨＣＰサーバとの間での暗号鍵を共有することを特徴とする。またルータやＤＨＣＰサーバから端末へのＩＰインタフェース情報を送信するに際して、共有した暗号鍵を用いてＩＰインタフェース情報のメッセージダイジェストの生成やチャレンジ＆レスポンスを行うことにより、当該ＩＰインタフェース情報やその送信元の正当性を確認することを特徴とする。【選択図】      図１
2005080242.tif 000002
【特許請求の範囲】
【請求項１】
通信サービスを利用する端末と、
前記端末の認証を行なうアクセス認証装置と、
前記端末に対してＩＰインタフェース情報を付与するＩＰインタフェース情報付与装置と
から構成される通信ネットワークにおいて、
前記ＩＰインタフェース情報付与装置のＩＰアドレスが動的に変化する場合でも、
前記ＩＰインタフェース情報及び前記ＩＰインタフェース情報付与装置の正当性を保証するために、
前記アクセス認証装置は、認証装置受信部と認証装置送信部と認証装置処理部とを備え、
このアクセス認証装置は、
前記認証装置受信部が前記端末から通信要求信号を受信するステップと、
前記認証装置処理部が暗号鍵の生成又は取得を行うステップと、
前記認証装置送信部が前記暗号鍵を前記端末及び前記ＩＰインタフェース情報付与装置へ送信するステップとを行うこと
を特徴とするＩＰインタフェース情報の付与方法。
【請求項２】
前記ＩＰインタフェース情報付与装置は、付与装置受信部と付与装置送信部と付与装置処理部と付与装置記憶部とを備え、
このＩＰインタフェース情報付与装置は、
前記付与装置受信部が前記アクセス認証装置から前記暗号鍵を受信するステップと、
前記付与装置記憶部が受信した前記暗号鍵を記憶するステップと、
前記付与装置受信部が前記端末から前記ＩＰインタフェース情報の付与を要求する信号を受信するステップと、
前記付与装置処理部が前記暗号鍵を用いて前記ＩＰインタフェース情報のメッセージダイジェストを生成するステップと、
前記付与装置送信部が前記ＩＰインタフェース情報及び前記メッセージダイジェストを前記端末へ送信するステップとを行うこと、
を特徴とする請求項１に記載のＩＰインタフェース情報の付与方法。
【請求項３】
前記端末は、端末受信部と端末記憶部と端末処理部とを備え、
この端末は、
前記端末受信部が前記アクセス認証装置から前記暗号鍵を受信するステップと、
前記端末記憶部が受信した前記暗号鍵を記憶するステップと、
前記端末受信部が前記ＩＰインタフェース情報付与装置から前記ＩＰインタフェース情報及び前記メッセージダイジェストを受信するステップと、
前記端末処理部が前記暗号鍵を用いて前記ＩＰインタフェース情報のメッセージダイジェストを生成するステップと、
前記端末処理部が前記生成したメッセージダイジェスト及び前記受信したメッセージダイジェストを比較して、前記ＩＰインタフェース情報及び前記ＩＰインタフェース情報付与装置の正当性を判断するステップとを行うこと、
を特徴とする請求項２に記載のＩＰインタフェース情報の付与方法。
【請求項４】
前記ＩＰインタフェース情報付与装置は、付与装置受信部と付与装置送信部と付与装置処理部と付与装置記憶部とを備え、
このＩＰインタフェース情報付与装置は、
前記付与装置受信部が前記アクセス認証装置から前記暗号鍵を受信するステップと、
前記付与装置記憶部が受信した前記暗号鍵を記憶するステップと、
前記付与装置受信部が前記端末からＩＰインタフェース情報の付与を要求する信号をチャレンジデータと共に受信するステップと、
前記付与装置処理部が前記暗号鍵を用いてチャレンジデータのレスポンスデータを生成するステップと、
前記付与装置送信部が前記ＩＰインタフェース情報及び前記レスポンスデータを前記端末へ送信するステップとを行うこと、
を特徴とする請求項１に記載のＩＰインタフェース情報の付与方法。
【請求項５】
前記端末は、端末受信部と端末記憶部と端末処理部とを備え、
この端末は、
前記端末受信部が前記アクセス認証装置から前記暗号鍵を受信するステップと、
前記端末記憶部が受信した前記暗号鍵を記憶するステップと、
前記端末受信部が前記ＩＰインタフェース情報付与装置から前記ＩＰインタフェース情報及び前記レスポンスデータを受信するステップと、
前記端末処理部が前記暗号鍵を用いて前記端末記憶部に記憶しておいたチャレンジデータからレスポンスデータを生成するステップと、
前記端末処理部が前記生成したレスポンスデータ及び前記受信したレスポンスデータを比較して、前記ＩＰインタフェース情報付与装置の正当性を判断するステップとを行うこと、
を特徴とする請求項４に記載のＩＰインタフェース情報の付与方法
【請求項６】
通信サービスを利用する端末と、
前記端末の認証を行うアクセス認証装置と、
前記端末に対してＩＰインタフェース情報を付与するＩＰインタフェース情報付与装置と
から構成される通信ネットワークにおいて、
前記ＩＰインタフェース情報付与装置のＩＰアドレスが動的に変化する場合でも、
前記ＩＰインタフェース情報及び前記ＩＰインタフェース情報付与装置の正当性を保証するために用いられるアクセス認証装置であって、
このアクセス認証装置は、
前記端末から通信要求信号を受信する認証装置受信部と、
暗号鍵を生成又は取得する認証装置処理部と、
前記暗号鍵を前記端末及び前記ＩＰインタフェース情報付与装置へ送信する認証装置送信部とを備えること
を特徴とするＩＰインタフェース情報の付与のためのアクセス認証装置。
【請求項７】
通信サービスを利用する端末と、
前記端末の認証を行うアクセス認証装置と、
前記端末に対してＩＰインタフェース情報を付与するＩＰインタフェース情報付与装置と
から構成される通信ネットワークにおいて、
前記ＩＰインタフェース情報付与装置のＩＰアドレスが動的に変化する場合でも、
前記ＩＰインタフェース情報及び前記ＩＰインタフェース情報付与装置の正当性を保証するために用いられるＩＰインタフェース情報付与装置であって、
このＩＰインタフェース情報付与装置は、
前記アクセス認証装置から前記暗号鍵及び前記端末から前記ＩＰインタフェース情報の付与を要求する信号を受信する付与装置受信部と、
前記アクセス認証装置から受信した暗号鍵を記憶する付与装置記憶部と、
前記暗号鍵を用いて前記ＩＰインタフェース情報の暗号化を行う付与装置処理部と、
前記ＩＰインタフェース情報及び前記暗号化ＩＰインタフェース情報を前記端末へ送信する付与装置送信部とを備えること
を特徴とするＩＰインタフェース情報の付与のためのＩＰインタフェース情報付与装置。
【請求項８】
通信サービスを利用する端末と、
前記端末の認証を行うアクセス認証装置と、
前記端末に対してＩＰインタフェース情報を付与するＩＰインタフェース情報付与装置と
から構成される通信ネットワークにおいて、
前記ＩＰインタフェース情報付与装置のＩＰアドレスが動的に変化する場合でも、
前記ＩＰインタフェース情報及び前記ＩＰインタフェース情報付与装置の正当性を保証するために用いられる端末用のプログラムであって、
端末受信部と端末記憶部と端末処理部とを備える前記端末の前記端末処理部に、
前記端末受信部が前記アクセス認証装置から受信した暗号鍵を前記端末記憶部に記憶する機能、
前記端末受信部が前記ＩＰインタフェース情報付与装置から受信した前記ＩＰインタフェース情報を、前記暗号鍵を用いて暗号化する機能、
前記暗号化ＩＰインタフェース情報と前記ＩＰインタフェース情報付与装置から受信した暗号化ＩＰインタフェース情報との比較を行ない、前記ＩＰインタフェース情報及び前記ＩＰインタフェース情報付与装置の正当性を判断する機能、
を実行させることを特徴とする端末用プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信ネットワークにおける装置及び通信データの正当性の確認方法，その確認のための装置及びプログラムに関する。
【背景技術】
【０００２】
ＩＰネットワークにおいて、端末が通信の開始を要求するに際して、ＩＰアドレスやネットワークプレフィックス，ＤＮＳ（Domain Name System）アドレス，ＳＩＰ（Session Initiation Protocol）サーバアドレス，ホスト名のうち少なくとも一つを含むＩＰインタフェース情報が、端末に対して動的に付与されることがある。その際に利用される代表的なプロトコルに、Ｎｅｉｇｈｂｏｒ  ＤｉｓｃｏｖｅｒｙとＤＨＣＰｖ６（Dynamic Host Configuration Protocol for IPv6）がある。
【０００３】
Ｎｅｉｇｈｂｏｒ  Ｄｉｓｃｏｖｅｒｙでは、ＩＰｖ６におけるＩＰアドレスの一部であるネットワークプレフィックスを、ルータからＲｏｕｔｅｒ  Ａｄｖｅｒｔｉｓｅｍｅｎｔメッセージを用いて、当該ルータに所属する端末に対して付与する。通常、Ｒｏｕｔｅｒ  Ａｄｖｅｒｔｉｓｅｍｅｎｔメッセージは、マルチキャスト機能を利用して、ルータから各端末に対して、定期的に通知されているが、端末がルータに対してＲｏｕｔｅｒ  Ｓｏｌｉｃｉｔａｔｉｏｎメッセージを送信して、Ｒｏｕｔｅｒ  Ａｄｖｅｒｔｉｓｅｍｅｎｔメッセージを要求することも可能である。この場合、端末は要求すべきルータのＩＰアドレスがわからないため、Ｒｏｕｔｅｒ  Ｓｏｌｉｃｉｔａｔｉｏｎメッセージをマルチキャスト機能を利用して送信する。その際、当該端末を特定するためのインタフェースＩＤは、端末のＭＡＣ(Media Access Control)アドレス等から生成される（非特許文献１，２を参照）。
【０００４】
ＤＨＣＰｖ６では、次のようなサーバ−クライアント型の形態での手続を用いて、端末に対してＩＰインタフェース情報が付与される。端末は、マルチキャスト機能を利用して、ＤＨＣＰＳＯＬＩＣＩＴメッセージにより、ＩＰネットワーク内で利用可能なＤＨＣＰサーバの探索を行う。ＤＨＣＰサーバは、端末からのＤＨＣＰＳＯＬＩＣＩＴメッセージを受信すると、ＤＨＣＰＯＦＦＥＲメッセージを送信して、当該端末に対してＤＨＣＰサーバの存在を通知する。次に端末は、ＤＨＣＰＲＥＱＵＥＳＴメッセージを用いてＩＰインタフェース情報の送信を要求し、ＤＨＣＰサーバは、ＤＨＣＰＡＣＫメッセージを用いて、ＩＰインタフェース情報を端末に対して付与する（非特許文献３を参照）。
【非特許文献１】Ｔ．Ｎａｒｔｅｎ  外２名、”ＲＦＣ２４６１：Ｎｅｉｇｈｂｏｒ  Ｄｉｓｃｏｖｅ    ｒｙ  ｆｏｒ  ＩＰ  Ｖｅｒｓｉｏｎ６（ＩＰｖ６）”、[online]、１９９８年１２    月、ＩＥＴＦ、[平成１５年８月２５日検索]、インターネット＜ftp://ftp.rfc-ed    itor.org/in-notes/rfc2461.txt＞
【非特許文献２】Ｓ．Ｔｈｏｍｓｏｎ  外１名、”ＲＦＣ２４６２：ＩＰｖ６  Ｓｔａｔｅｌｅｓｓ      Ａｄｄｒｅｓｓ  Ａｕｔｏｃｏｎｆｉｇｕｒａｔｉｏｎ”、[online]、１９９８年１    ２月、ＩＥＴＦ、[平成１５年８月２５日検索]、インターネット＜ftp://ftp.rfc-    editor.org/in-notes/rfc2462.txt＞
【非特許文献３】Ｒ．Ｅｒｏｍｓ  外５名、”ＲＦＣ３３１５：Ｄｙｎａｍｉｃ  Ｈｏｓｔ  Ｃｏｎｆ    ｉｇｕｒａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ  ｆｏｒ  ＩＰｖ６  （ＤＨＣＰｖ６）”、    [online]、２００３年６月、ＩＥＴＦ、[平成１５年８月２５日検索]、インターネ    ット＜ftp://ftp.rfc-editor.org/in-notes/rfc3315.txt＞
【０００５】
ＮｅｉｇｈｂｏｒＤｉｓｃｏｖｅｒｙとＤＨＣＰｖ６では、手順やメッセージの形式はそれぞれ異なるが、端末がＩＰインタフェース情報を付与するルータやＤＨＣＰサーバを探索するに際して、いずれもマルチキャスト機能を利用することが共通している。
【発明の開示】
【発明が解決しようとする課題】
【０００６】
しかしながらマルチキャスト機能を利用した場合、ある端末が送信したＩＰインタフェース情報を要求するメッセージを、同一のネットワーク内に存在する他の端末が受信することは、原理的に可能である。この場合、同一ネットワーク内に存在する悪意を持つ端末や誤ってルータやＤＨＣＰサーバとして設定されている端末が、ＩＰインタフェース情報を要求した端末に対し、不正なＩＰインタフェース情報を送信してくる可能性がある。
【０００７】
これに対して、端末と正当なルータやＤＨＣＰサーバとの間で、事前に暗号鍵を共有しておくことにより、端末が認証を行ない、当該ルータやＤＨＣＰサーバの正当性及びそれらから送信されたメッセージの正当性を確認することは可能である。
【０００８】
しかし端末が利用するルータやＤＨＣＰサーバが動的に変化する場合には、端末とルータやＤＨＣＰサーバとの間で、暗号鍵を事前に共有しておく方法では、ルータやＤＨＣＰサーバが変わる都度に暗号鍵を、再度、共有しなくてはならず、運用が困難になるという問題があった。
【０００９】
そこで本発明では、暗号鍵の共有を容易にし、それを用いて端末がルータやＤＨＣＰサーバの正当性及びそれら送信されたメッセージの正当性を確認できるようにすることを目的とする。
【課題を解決するための手段】
【００１０】
前記課題を解決するため、本発明では、端末が通信を要求した際に認証サーバが配布する当該端末の暗号鍵を、同時にルータやＤＨＣＰサーバにも配布することにより、端末の利用するルータやＤＨＣＰサーバが動的に変化した場合でも、当該端末とルータやＤＨＣＰサーバとの間での暗号鍵を共有できることを特徴とする。
【００１１】
さらにルータやＤＨＣＰサーバから端末へのＩＰインタフェース情報を送信するに際して、共有した暗号鍵を用いてメッセージダイジェストの生成やチャレンジ＆レスポンスを行うことにより、当該ＩＰインタフェース情報の改ざんや送信元のなりすましを発見でき、ルータやＤＨＣＰサーバ及びＩＰインタフェース情報の正当性を確認できることを特徴とする。
【発明の効果】
【００１２】
以上説明したように、請求項１に記載の発明によれば、暗号鍵を端末及びルータ，ＤＨＣＰサーバへ配布することにより、端末とルータ，ＤＨＣＰサーバとの間での暗号鍵の共有を実現する。
【００１３】
請求項２，３の発明によれば、請求項１で共有した暗号鍵を用いたメッセージダイジェストにより、ルータ，ＤＨＣＰサーバ及びＩＰインタフェース情報の正当性を確認することができる。
【００１４】
請求項４，５の発明によれば、請求項１で共有した暗号鍵を用いたチャレンジ＆レスポンスにより、ルータ，ＤＨＣＰサーバ及びＩＰインタフェース情報の正当性を確認することができる。
【００１５】
請求項６の発明によれば、請求項１の発明で利用されるアクセス認証装置を実現できる。
【００１６】
請求項７の発明によれば、請求項２，４の発明で利用されるＩＰインタフェース情報付与装置を実現できる。
【００１７】
請求項８の発明によれば、請求項３，５の発明で利用される端末用プログラムを実現できる。
【発明を実施するための最良の形態】
【００１８】
次に本発明の実施形態について、適宜図面を参照しながら詳細に説明する。図１は、本発明の実施形態例を示すネットワーク構成図である。当該実施形態例を示すネットワークは、端末１１，ネットワーク接続装置１２，パケット転送装置１３，通信ネットワーク１４，認証クライアント１５，アクセス認証装置１６，ＩＰインタフェース情報付与装置１７，暗号鍵管理データベース１８，サブネット１９とを備えて構成される。
【００１９】
図１において端末１１は、通信開始の要求及びＩＰインタフェース情報の要求を行う。ネットワーク接続装置１２は、端末１１からの通信要求を受け付け、端末１１と他の装置との通信を中継する機能を有する。パケット転送装置１３は、端末１１から送信されたＩＰパケットを、端末１１が所望する端末または装置へ転送する、またはその逆の転送をする機能を有する。通信ネットワーク１４は、パケット転送装置１３，アクセス認証装置１６，ＩＰインタフェース情報付与装置１７，暗号鍵管理データベース１８から構成される。認証クライアント１５は、ネットワーク接続装置１２に組み込まれており、通信開始時に端末１１より通知されたユーザＩＤやパスワード，電子証明書を含む認証情報と、ＭＡＣアドレスを含む端末識別子を、アクセス認証装置１６へ通知する機能を有する。アクセス認証装置１６は、認証クライアント１５より通知された端末１１の認証情報と、事前に保持していた端末１１の認証情報とを比較することにより、端末１１がネットワーク接続装置１２を利用可能か否かを判断する機能を有する。またアクセス認証装置１６は、前記において利用可能と判断した場合に、端末１１に対して暗号鍵を配布し、自身と端末１１との間で暗号鍵を共有する機能、及びＩＰインタフェース情報付与装置１７に対して、端末１１の端末識別子と共に同じ暗号鍵を配布し、端末１１とＩＰインタフェース情報付与装置１７との間で暗号鍵を共有する機能を有する。ＩＰインタフェース情報付与装置１７は、ＩＰインタフェース情報を、端末１１の通知する機能を有する。暗号鍵管理データベース１８は、アクセス認証装置１６が管理する暗号鍵を記憶する。サブネット１９は、端末１１，ネットワーク接続装置１２，認証クライアント１５から構成される。
【００２０】
図１６は、アクセス認証装置１６の構成を示す。図１６において受信部１６１は、認証クライアント１５からの端末１１の認証情報を受信し、処理部１６３が受信した認証情報に基づいて端末１１の正当性の確認を行なった後に、送信部１６２が暗号鍵を端末１１に対して送信する。さらに送信部はＩＰインタフェース情報付与装置１７へも暗号鍵を送信する。
【００２１】
図１７は、ＩＰインタフェース情報付与装置１７の構成を示す。図１７において、受信部１７１はアクセス認証装置１６から端末１１の暗号鍵を受信する。また受信部１７１は、端末１１からＩＰインタフェース情報の付与を要求する信号、さらに必要な場合には乱数を受信する。処理部１７３は、受信した暗号鍵を用いて、ＩＰインタフェース情報または受信した乱数の暗号化を行う。送信部１７２は、ＩＰインタフェース情報と共に、当該暗号化ＩＰインタフェース情報または当該暗号化乱数を送信する。
【００２２】
図１８は、端末１１の構成を示す。図１８において、受信部１８１はアクセス認証装置１６から暗号鍵を受信する。また受信部１８１はＩＰインタフェース情報付与装置からＩＰインタフェース情報及び暗号化ＩＰインタフェース情報または暗号化乱数を受信する。処理部１８３は、必要に応じて乱数の生成を行う。また処理部１８３は、受信した暗号鍵を用いた受信したＩＰインタフェース情報の暗号化及び当該暗号化ＩＰインタフェース情報と受信した暗号化ＩＰインタフェース情報との比較を行ない、受信したＩＰインタフェース情報およびＩＰインタフェース情報付与装置の正当性の確認を行う。また処理部１８３は、受信した暗号鍵を用いた生成した乱数の暗号化及び当該暗号化乱数と受信した暗号化乱数の比較を行ない、受信したＩＰインタフェース情報の正当性の確認を行う。
【００２３】
図２は、端末１１による通信開始要求から、アクセス認証装置１６により端末１１が認証されて端末１１に対して暗号鍵が配布されるのと同時に、ＩＰインタフェース情報付与装置１７に対しても、暗号鍵が配布されるまでのシーケンスを示している。
【００２４】
端末１１はネットワーク接続装置１２に対して通信要求を行ない（Ｓ２０１）、ネットワーク接続装置１２内の認証クライアント１５からの認証情報要求を受ける（Ｓ２０２）。その後、端末１１は、認証クライアント１５を介してアクセス認証装置１６へ端末識別子を送信し（Ｓ２０３）、アクセス認証装置１６により正当な端末であると判断された場合、暗号鍵の配布を受ける（Ｓ２０４）。この結果、端末１１とアクセス認証装置１６は暗号鍵を共有したこととなる。その後、アクセス認証装置１６は、ＩＰインタフェース情報付与装置１７に対して、端末１１の端末識別子と共に、暗号鍵を配布する（Ｓ２０５）。これにより端末１１とＩＰインタフェース情報付与装置１７は、暗号鍵を共有したこととなる。その後、アクセス認証装置１６は、認証クライアント１５を介して、端末１１に対して認証が成功したことを通知する（Ｓ２０６）。ここではアクセス認証装置１６は、端末１１の暗号鍵をＩＰインタフェース情報付与装置１７に対して配布した後に、端末１１に対して認証が成功したことを通知したが、アクセス認証装置１６が、端末１１に対して認証が成功したことを通知した後に、ＩＰインタフェース情報付与装置１７に対して、暗号鍵を配布してもよい。また前記説明では、暗号鍵はアクセス認証装置１６から端末１１に対して配布されるものとしたが、先に共有する情報を元にして、それぞれが同一の暗号鍵を生成することにより、暗号鍵を共有する方法としてもよい。以下、各方法の説明において、暗号鍵の共有は同様の方法で実現可能である。
【００２５】
図３では、まず端末１１による通信開始要求から、アクセス認証装置１６により端末１１が認証され、端末１１に対して暗号鍵が配布された後に、端末１１からのＩＰインタフェース情報付与装置１７の探索が行なわれたのを契機として、アクセス認証装置１６からＩＰインタフェース情報付与装置１７に対して、暗号鍵が配布されるまでのシーケンスを示している。
【００２６】
端末１１はネットワーク接続装置１２に対して通信要求を行ない（Ｓ３０１）、ネットワーク接続装置１２内の認証クライアント１５からの認証情報要求を受ける（Ｓ３０２）。その後、端末１１は、認証クライアント１５を介してアクセス認証装置１６へ端末識別子を送信し（Ｓ３０３）、アクセス認証装置１６により正当な端末であると判断された場合、暗号鍵の配布を受ける（Ｓ３０４）。この結果、端末１１とアクセス認証装置１６は暗号鍵を共有したこととなる。その後、アクセス認証装置１６は、認証クライアント１５を介して、端末１１に対して認証が成功したことを通知する（Ｓ３０５）。端末１１からのＩＰインタフェース情報付与装置１７の探索が行なわれたのを契機として（Ｓ３０６）、ＩＰインタフェース情報付与装置１７からアクセス認証装置１６に対して暗号鍵が要求され（Ｓ３０７）、アクセス認証装置１６は、ＩＰインタフェース情報付与装置１７に対して、端末１１の端末識別子と共に暗号鍵を配布する（Ｓ３０８）。これにより端末１１とＩＰインタフェース情報付与装置１７は、暗号鍵を共有したこととなる。
【００２７】
図４は、アクセス認証装置１６からＩＰインタフェース情報付与装置１７に対して暗号鍵が配布された後であり、端末１１によるＩＰインタフェース情報付与の要求を行うメッセージの送信から、ＩＰインタフェース情報付与装置１７が、ＩＰインタフェース情報を送信するまでの、メッセージダイジェストによる認証を用いた場合のシーケンスを示している。
【００２８】
端末１１は、ＩＰネットワークにおけるマルチキャスト機能を用いて、ＩＰインタフェース情報付与装置１７に対して、ＩＰインタフェース情報の付与を要求するメッセージを、自分の端末識別子を付加して送信する（Ｓ４０１）。これを受信したＩＰインタフェース情報付与装置１７は、端末識別子から端末１１の暗号鍵を選択した後（Ｓ４０２）、端末１１に付与するＩＰインタフェース情報を作成し（Ｓ４０３）、当該暗号鍵を用いてＩＰインタフェース情報のメッセージダイジェスト（ＭＤと呼ぶ）を作成する（Ｓ４０４）。その後、ＩＰインタフェース情報とＭＤをＩＰインタフェース情報回答メッセージとして、ＩＰｖ６のセキュリティプロトコルであるＩＰｓｅｃの認証ヘッダ（ＡＨヘッダと呼ぶ）を利用して、端末１１に対して送信する（Ｓ４０５）。端末１１では、自分の暗号鍵と送られてきたＩＰインタフェース情報からＭＤを作成し（Ｓ４０６）、これと送られてきたＭＤが一致するか否かを比較する（Ｓ４０７）。一致した場合、ＩＰインタフェース情報付与装置１７の正当性とＩＰインタフェース情報の改ざんがないことを確認できる。その後、端末１１は、得たＩＰインタフェース情報を今後の通信に利用する。ここで（Ｓ４０２）と（Ｓ４０３）は、順序が逆になっても差し支えない。
【００２９】
前記において（Ｓ４０１）を実施する際に、ＩＰインタフェース情報付与装置１７は、端末１１が送信したＩＰインタフェース情報付与要求メッセージが改ざんされる、または他の端末がなりすますことを防止するために、共有する暗号鍵を用いて、（Ｓ４０４）から（Ｓ４０７）までで行なったものと同様の手順で、端末１１の認証を行うことも可能である。その際、ＭＤの作成の元となるデータには、任意のデータを利用し、この任意のデータと作成したＭＤをＩＰインタフェース情報付与装置１７に送付する。
【００３０】
図５は、アクセス認証装置１６からＩＰインタフェース情報付与装置１７に対して暗号鍵が配布された後であり、端末１１によるＩＰインタフェース情報付与の要求を行うメッセージの送信から、ＩＰインタフェース情報付与装置１７が、ＩＰインタフェース情報を送信するまでの、チャレンジ＆レスポンスによる認証を用いた場合のシーケンスを示している。
【００３１】
端末１１は、チャレンジデータとなる乱数を生成した上で（Ｓ５０１）、ＩＰネットワークにおけるマルチキャスト機能を用いて、ＩＰインタフェース情報付与装置１７に対して、ＩＰインタフェース情報の付与を要求するメッセージを、自分の端末識別子とチャレンジデータを付加して送信する（Ｓ５０２）。これを受信したＩＰインタフェース情報付与装置１７は、端末識別子から端末１１の暗号鍵を選択し（Ｓ５０３）、選択した暗号鍵でチャレンジデータを暗号化して、レスポンスデータを生成する（Ｓ５０４）。その後、ＩＰインタフェース情報付与装置１７は、端末１１に対して付与するＩＰインタフェース情報を作成し（Ｓ５０５）、レスポンスデータと共に、ＩＰインタフェース情報回答メッセージとして、端末１１に対して送信する（Ｓ５０６）。端末１１では、自分の暗号鍵でチャレンジデータを暗号化し（Ｓ５０７）、その結果とＩＰインタフェース情報付与装置１７から送られたレスポンスデータが一致するか否かを比較する（Ｓ５０８）。一致した場合、端末１１は、ＩＰインタフェース情報付与装置１７の正当性を確認する。その後、端末１１は、得たＩＰインタフェース情報を今後の通信に利用する。ここで（Ｓ５０３），（Ｓ５０４）と（Ｓ５０５）は、順序が逆になっても差し支えない。
【００３２】
（実施形態例１）
次に、本発明の具体的な実施形態例について説明する。（実施形態例１）は、ＩＰインタフェース情報を取得するためのプロトコルとしてＮｅｉｇｈｂｏｒ  Ｄｉｓｃｏｖｅｒｙを用い、端末とネットワーク接続装置である無線ＬＡＮアクセスポイントが、ＩＥＥＥ８０２．１ｘによる認証機能を備えた無線ＬＡＮで接続され、アクセス認証装置にはＲＡＤＩＵＳサーバ、パケット転送装置にはルータが使用されたネットワーク構成において本発明を実施した場合を、図６〜１０を用いて説明している。
【００３３】
図６は、本発明の実施例を示すネットワーク構成図である。当該実施例を示すネットワークは、端末６１，無線ＬＡＮアクセスポイント６２，ルータ６３，ＲＡＤＩＵＳサーバ６４，通信ネットワーク６５，サブネットワーク６６とを備えて構成される。
【００３４】
図６において端末６１は、通信の開始に際して、ＩＰインタフェース情報を要求する。無線ＬＡＮアクセスポイント６２は、ネットワーク接続装置に相当する。無線ＬＡＮアクセスポイント６２には、認証クライアントに相当するＲＡＤＩＵＳクライアント６７が組み込まれている。ルータ６３は、パケット転送装置に相当する。ＲＡＤＩＵＳサーバ６４は、アクセス認証装置に相当する。通信ネットワーク６５、ＲＡＤＩＵＳサーバ６４とルータ６３により構成される。サブネットワーク６６は、端末６１と無線ＬＡＮアクセスポイント６２により構成される。
【００３５】
図７は、端末６１による通信開始要求から、ＲＡＤＩＵＳサーバ６４により端末６１が認証され、端末６１に対して暗号鍵が配布されるのと同時に、ルータ６３に対しても、暗号鍵が配布されるまでのシーケンスを示している。またＲＡＤＩＵＳサーバ６４による端末６１の認証と暗号鍵の配布は、ＬＡＮの認証プロトコルであるＩＥＥＥ８０２．１ｘを用いて行なわれる。
【００３６】
端末６１は、無線ＬＡＮアクセスポイント６２に対して通信要求を行ない（Ｓ７０１）、無線ＬＡＮアクセスポイント６２内のＲＡＤＩＵＳクライアント６７からの認証情報要求を受ける（Ｓ７０２）。その後、端末６１から、ＲＡＤＩＵＳクライアント６７を介して、ＲＡＤＩＵＳサーバ６４に対して、ユーザＩＤやパスワード，電子証明書，ＭＡＣアドレスが通知され（Ｓ７０３）、端末６１の正当性が確認される（Ｓ７０４）。ＲＡＤＩＵＳサーバ６４が、端末６１は正当であると判断した場合、ＲＡＤＩＵＳサーバ６４は、生成した暗号鍵をＲＡＤＩＵＳクライアント６７と端末６１へ配布する（Ｓ７０５）。この結果、端末６１とＲＡＤＩＵＳサーバ６４は、暗号鍵を共有したこととなる。ＲＡＤＩＵＳクライアント６７は、暗号鍵を端末６１のＭＡＣアドレスと共に無線ＬＡＮアクセスポイント６２に記憶させ（Ｓ７０６）、当該暗号鍵は、端末６１と無線ＬＡＮアクセスポイント６２との間の無線ＬＡＮ区間の通信データの暗号化に利用される。その後、ＲＡＤＩＵＳサーバ６４は、ＲＡＤＩＵＳクライアント６７を介して、端末６１に対して認証が成功したことを通知する（Ｓ７０７）。次にＲＡＤＩＵＳサーバ６４は、ルータ６３に対して、端末６１のＭＡＣアドレスと共に、暗号鍵を配布する（Ｓ７０８）。これにより端末６１とルータ６３は、暗号鍵を共有したこととなる。
【００３７】
図８では、まず端末６１による通信開始要求から、ＲＡＤＩＵＳサーバ６４により端末６１が認証され、端末６１に対して暗号鍵が配布された後、端末６１からＩＰインタフェース情報が要求された際に、ＲＡＤＩＵＳサーバ６４からルータ６３に対して、暗号鍵が配布されるシーケンスを示している。
【００３８】
端末６１の通信要求から認証成功までが、図７に示す（Ｓ７０１）から（Ｓ７０７）と同様に行なわれた後、端末６１からＲｏｕｔｅｒＳｏｌｉｃｉｔｉａｔｉｏｎメッセージによりＩＰインタフェース情報が要求され（Ｓ８０１）、それを契機としてルータ６３からＲＡＤＩＵＳサーバ６４に対して暗号鍵が要求され（Ｓ８０２）、その後、ＲＡＤＩＵＳサーバ６４からルータ６３に対して暗号鍵が配布される（Ｓ８０３）。これにより端末６１とルータ６３は、暗号鍵を共有したこととなる。
【００３９】
図９は、ＲＡＤＩＵＳサーバ６４からルータ６３に対して暗号鍵が配布された後であり、端末６１によるＩＰインタフェース情報付与要求メッセージの送信から、端末６１がＩＰインタフェース情報の正当性を検証するまでの、ＩＰｓｅｃによる認証技術を用いた場合のシーケンスを示している。
【００４０】
端末６１はＲｏｕｔｅｒＳｏｌｉｃｉｔｉａｔｉｏｎメッセージを送信することにより、ルータ６３に対して、ＲｏｕｔｅｒＡｄｖｅｒｔｉｓｅｍｅｎｔメッセージを利用したＩＰインタフェース情報の付与を要求する（Ｓ９０１）。ＲｏｕｔｅｒＳｏｌｉｃｉｔｉａｔｉｏｎメッセージを受信したルータ６３は、端末６１のＭＡＣアドレスを元にして、端末６１の暗号鍵を選択する（Ｓ９０２）。ルータ６３は、ＩＰインタフェース情報を作成した後（Ｓ９０３）、選択した暗号鍵を用いてメッセージダイジェスト生成の一方法であるＭＤ５を利用してＩＰインタフェース情報のＭＤを作成し（Ｓ９０４）、それをＩＰｓｅｃのＡＨヘッダに付加して、ＩＰインタフェース情報と共に、端末６１に対して、ＲｏｕｔｅｒＡｄｖｅｒｔｉｓｅｍａｎｔメッセージとして送信する（Ｓ９０５）。端末６１は、受信したＲｏｕｔｅｒＡｄｖｅｒｔｉｓｅｍａｎｔメッセージからＩＰインタフェース情報を取り出し、自分の暗号鍵を用いてＭＤ５（Ｍｅｓｓａｇｅ  Ｄｉｇｅｓｔ  ５）によりＭＤを作成する（Ｓ９０６）。端末６１は、作成したＭＤとルータ６３より送られたＭＤが一致するか否かを比較し（Ｓ９０７）、一致した場合、ルータ６３は正当なルータであり、ＩＰインタフェース情報の改ざんはないと判断する。その後、端末６１は付与されたＩＰインタフェース情報を用いて通信を行う。
【００４１】
図１０は、ＲＡＤＩＵＳサーバ６４からルータ６３に対して暗号鍵が配布された後であり、端末６１によるＩＰインタフェース情報付与要求メッセージの送信から、端末６１がＩＰインタフェース情報の正当性を検証するまでの、チャレンジ＆レスポンスによる認証技術を用いた場合のシーケンスを示している。
【００４２】
端末６１は、チャレンジデータとなる乱数を生成した上で（Ｓ１００１）、ＩＰネットワークにおけるマルチキャスト機能を用いて、ルータ６３に対して、ＩＰインタフェース情報の付与を要求するＲｏｕｔｅｒＳｏｌｉｃｉｔａｔｉｏｎメッセージを、自分のＭＡＣアドレスとチャレンジデータを付加して送信する（Ｓ１００２）。その際、チャレンジデータは、ＲｏｕｔｅｒＳｏｌｉｃｉｔａｔｉｏｎメッセージのＯｐｔｉｏｎフィールドに収納する。これを受信したルータ６３は、ＭＡＣアドレスから端末６１の暗号鍵を選択し（Ｓ１００３）、当該暗号鍵でチャレンジデータを暗号化することにより、レスポンスデータを生成する（Ｓ１００４）。その後、ルータ６３は、端末６１に対して付与するＩＰインタフェース情報を作成し（Ｓ１００５）、レスポンスデータと共に、ＲｏｕｔｅｒＡｄｖｅｒｔｉｓｅｍｅｎｔメッセージとして、端末６１に対して送信する（Ｓ１００６）。端末６１は、自分の暗号鍵を用いてチャレンジデータを暗号化し（Ｓ１００７）、その結果とルータ６３から送られたレスポンスデータが一致するか否かを比較する（Ｓ１００８）。一致した場合、ルータ６３は正当であると判断する。その後、端末６１は、得たＩＰインタフェース情報を今後の通信に利用する。
【００４３】
（実施形態例２）
（実施形態例２）は、ＩＰインタフェース情報を取得するためのプロトコルとしてＤＨＣＰｖ６を用い、実施例１と同じネットワーク構成において（ただしルータはＤＨＣＰサーバとなる）本発明を実施した場合を、図１１〜１５を用いて説明している。
【００４４】
図１１は、本発明の実施例を示すネットワーク構成図である。当該実施例を示すネットワークは、端末１１１，無線ＬＡＮアクセスポイント１１２，ルータ１１３，ＲＡＤＩＵＳサーバ１１４，通信ネットワーク１１５，サブネットワーク１１６とを備えて構成される。
【００４５】
端末１１１は、通信の開始に際して、ＩＰインタフェース情報を要求する。無線ＬＡＮアクセスポイント１１２は、ネットワーク接続装置に相当する。無線ＬＡＮアクセスポイント１１２には、認証クライアントに相当するＲＡＤＩＵＳクライアント１１７が組み込まれている。ルータ１１３は、パケット転送装置に相当し、ＤＨＣＰサーバが組み込まれている。ＲＡＤＩＵＳサーバ１１４は、アクセス認証装置に相当する。通信ネットワーク１１５、ＲＡＤＩＵＳサーバ１１４とルータ１１３により構成される。サブネットワーク１１６は、端末１１１と無線ＬＡＮアクセスポイント１１２により構成される。
【００４６】
図１２及び図１３は、図７及び図８と、ルータ１１３がＤＨＣＰサーバ機能を有することを除き、同一のシーケンスである。
【００４７】
図１４は、ＲＡＤＩＵＳサーバ１１４からルータ１１３に対して暗号鍵が配布された後であり、端末１１１によるＩＰインタフェース情報付与要求メッセージの送信から、端末１１１がＩＰインタフェース情報の正当性を検証するまでの、ＩＰｓｅｃによる認証技術を用いた場合のシーケンスを示している。
【００４８】
端末１１１はＤＨＣＰＳＯＬＩＣＩＴメッセージを送信することにより、ルータ１１３に対して、ＩＰインタフェース情報の付与を要求する（Ｓ１４０１）。ＤＨＣＰＳＯＬＩＣＩＴメッセージを受信したルータ１１３は、端末１１１のＭＡＣアドレスを元にして、端末１１１の暗号鍵を選択する（Ｓ１４０２）。ルータ１１３は、ＩＰインタフェース情報を作成した後（Ｓ１４０３）、選択した暗号鍵を用いたＭＤ５によりＩＰインタフェース情報のＭＤを作成し（Ｓ１４０４）、それをＩＰｓｅｃのＡＨヘッダに付加して、ＩＰインタフェース情報と共に、端末１１１に対して、ＤＨＣＰＯＦＦＥＲメッセージとして送信する（Ｓ１４０５）。端末１１１は、受信したＤＨＣＰＯＦＦＥＲメッセージからＩＰインタフェース情報を取り出し、自分の暗号鍵を用いたＭＤ５によりＭＤを作成する（Ｓ１４０６）。端末１１１は、作成したＭＤとルータ１１３より送られたＭＤが一致するか否かを比較し（Ｓ１４０７）、一致した場合、ルータ１１３は正当なルータであり、ＩＰインタフェース情報の改ざんはないと判断する。その後、端末１１１は付与されたＩＰインタフェース情報を用いて通信を行う。
【００４９】
図１５は、ＲＡＤＩＵＳサーバ１１４からルータ１１３に対して暗号鍵が配布された後であり、端末１１１によるＩＰインタフェース情報付与要求メッセージの送信から、端末１１１がＩＰインタフェース情報の正当性を検証するまでの、チャレンジ＆レスポンスによる認証技術を用いた場合のシーケンスを示している。
【００５０】
端末１１１は、チャレンジデータとなる乱数を生成した上で（Ｓ１５０１）、ＩＰネットワークにおけるマルチキャスト機能を用いて、ルータ１１３に対して、ＩＰインタフェース情報の付与を要求するＤＨＣＰＳＯＬＩＣＩＴメッセージを、自分のＭＡＣアドレスとチャレンジデータを付加して送信する（Ｓ１５０２）。その際、チャレンジデータは、ＤＨＣＰＳＯＬＩＣＩＴメッセージのＯｐｔｉｏｎフィールドに収納する。これを受信したルータ１１３は、ＭＡＣアドレスから端末１１１の暗号鍵を選択し（Ｓ１５０３）、当該暗号鍵でチャレンジデータを暗号化することにより、レスポンスデータを生成する（Ｓ１５０４）。その後、ルータ１１３は、端末１１１に対して付与するＩＰインタフェース情報を作成し（Ｓ１５０５）、レスポンスデータと共に、ＤＨＣＰＯＦＦＥＲメッセージとして、端末１１１に対して送信する（Ｓ１５０６）。端末１１１は、自分の暗号鍵を用いてチャレンジデータを暗号化し（Ｓ１５０７）、その結果とルータ１１３から送られたレスポンスデータが一致するか否かを比較する（Ｓ１５０８）。一致した場合、ルータ１１３は正当であると判断する。その後、端末１１１は、得たＩＰインタフェース情報を今後の通信に利用する。
【図面の簡単な説明】
【００５１】
【図１】ネットワーク構成を示す。
【図２】端末へ暗号鍵を配布するのと同時にＩＰインタフェース情報付与装置にも暗号鍵を配布する場合のシーケンスを示す。
【図３】端末からＩＰインタフェース情報付与要求がなされた後にＩＰインタフェース情報付与装置へ暗号鍵を配布する場合のシーケンスを示す。
【図４】端末がＩＰｓｅｃの認証ヘッダによる認証を用いてＩＰインタフェース情報付与装置の認証を行う場合のシーケンスを示す。
【図５】端末がチャレンジ＆レスポンスによる認証を用いてＩＰインタフェース情報付与装置の認証を行う場合のシーケンスを示す。
【図６】ＮｅｉｇｈｂｏｒＤｉｓｃｏｖｅｒｙプロトコルを用いた場合のネットワーク構成を示す。
【図７】ＮｅｉｇｈｂｏｒＤｉｓｃｏｖｅｒｙプロトコルを用いたネットワークにおいて、端末へ暗号鍵を配布するのと同時にルータにも暗号鍵を配布する場合のシーケンスを示す。
【図８】ＮｅｉｇｈｂｏｒＤｉｓｃｏｖｅｒｙプロトコルを用いたネットワークにおいて、端末からＩＰインタフェース情報付与要求がなされた後にルータへ暗号鍵を配布する場合のシーケンスを示す。
【図９】ＮｅｉｇｈｂｏｒＤｉｓｃｏｖｅｒｙプロトコルを用いたネットワークにおいて、端末がＩＰｓｅｃの認証ヘッダによる認証を用いてルータの認証を行う場合のシーケンスを示す。
【図１０】ＮｅｉｇｈｂｏｒＤｉｓｃｏｖｅｒｙプロトコルを用いたネットワークにおいて、端末がチャレンジ＆レスポンスによる認証を用いてルータの認証を行う場合のシーケンスを示す。
【図１１】ＤＨＣＰｖ６プロトコルを用いた場合のネットワーク構成を示す。
【図１２】ＤＨＣＰｖ６プロトコルを用いたネットワークにおいて、端末へ暗号鍵を配布するのと同時にルータ（ＤＨＣＰサーバ）にも暗号鍵を配布する場合のシーケンスを示す。
【図１３】ＤＨＣＰｖ６プロトコルを用いたネットワークにおいて、端末からＩＰインタフェース情報付与要求がなされた後にルータ（ＤＨＣＰサーバ）へ暗号鍵を配布する場合のシーケンスを示す。
【図１４】ＤＨＣＰｖ６プロトコルを用いたネットワークにおいて、端末がＩＰｓｅｃの認証ヘッダによる認証を用いてルータ（ＤＨＣＰサーバ）の認証を行う場合のシーケンスを示す。
【図１５】ＤＨＣＰｖ６プロトコルを用いたネットワークにおいて、端末がチャレンジ＆レスポンスによる認証を用いてルータ（ＤＨＣＰサーバ）の認証を行う場合のシーケンスを示す。
【図１６】アクセス認証装置の構成を示す。
【図１７】ＩＰインタフェース情報付与装置の構成を示す。
【図１８】端末の構成を示す。
【符号の説明】
【００５２】
１１      端末
１２      ネットワーク接続装置
１３      パケット転送装置
１４      通信ネットワーク
１５      認証クライアント
１６      アクセス認証装置
１７      ＩＰインタフェース情報付与装置
１８      暗号鍵管理データベース
１９      サブネット
６１      端末
６２      無線ＬＡＮアクセスポイント
６３      ルータ
６４      ＲＡＤＩＵＳサーバ
６５      通信ネットワーク
６６      サブネット
６７      ＲＡＤＩＵＳクライアント
１１１      端末
１１２      無線ＬＡＮアクセスポイント
１１３      ルータ（ＤＨＣＰサーバ）
１１４      ＲＡＤＩＵＳサーバ
１１５      通信ネットワーク
１１６      サブネット
１１７      ＲＡＤＩＵＳクライアント
１６１      認証装置受信部
１６２      認証装置送信部
１６３      認証装置処理部
１６４      認証装置記憶部
１７１      付与装置受信部
１７２      付与装置送信部
１７３      付与装置処理部
１７４      付与装置記憶部
１８１      端末受信部
１８２      端末送信部
１８３      端末処理部
１８４      端末記憶部
【図１】
2005080242.tif 000003
【図２】
2005080242.tif 000004
【図３】
2005080242.tif 000005
【図４】
2005080242.tif 000006
【図５】
2005080242.tif 000007
【図６】
2005080242.tif 000008
【図７】
2005080242.tif 000009
【図８】
2005080242.tif 000010
【図９】
2005080242.tif 000011
【図１０】
2005080242.tif 000012
【図１１】
2005080242.tif 000013
【図１２】
2005080242.tif 000014
【図１３】
2005080242.tif 000015
【図１４】
2005080242.tif 000016
【図１５】
2005080242.tif 000017
【図１６】
2005080242.tif 000018
【図１７】
2005080242.tif 000019
【図１８】
2005080242.tif 000020