(57)【要約】【課題】  セキュア通信におけるセキュリティポリシーの変更に対して円滑に対応するとともに、通信端末の負担を軽減することができるセキュア通信システムを実現する。【解決手段】  セキュア通信を行うグループに所属する複数の通信端末１と、通信端末１に設定すべきセキュリティポリシーを記憶するデータベース１０と、管理サーバ２とを有し、データベース１０は通信端末１のグループごとにセキュリティポリシーおよびマルチキャストアドレスを記憶し、管理サーバ２はデータベース１０中のセキュリティポリシーが変更された時に、当該変更情報を当該グループのマルチキャストアドレスを使用して送信し、通信端末１はマルチキャスト形式で受信したセキュリティポリシーの変更情報に基づき、自端末で保持するセキュリティポリシーを更新することを特徴とする。【選択図】    図１
2006019824.tif 000002
【特許請求の範囲】
【請求項１】
セキュア通信を行うグループに所属する複数の通信端末と、前記通信端末に設定すべきセキュリティポリシーを記憶するデータベースを有する管理装置とを有するセキュア通信システムであって、
前記データベースは、
前記通信端末のグループごとに、前記セキュリティポリシーおよびマルチキャストアドレスを記憶し、
前記管理装置は、
前記データベース中のセキュリティポリシーが変更された時に、当該変更情報を当該グループのマルチキャストアドレスを使用して送信する変更情報送信手段を有し、
前記通信端末は、
前記マルチキャストアドレスに基づき、ネットワークから情報を受信する受信手段と、
同一グループ内のセキュリティポリシーを記憶するグループ情報記憶手段と、
マルチキャスト形式で受信した前記セキュリティポリシーの変更情報に基づき、前記グループ情報記憶手段中のセキュリティポリシーを更新する更新手段とを有する
ことを特徴とするセキュア通信システム。
【請求項２】
前記通信端末は、
自端末がセキュア通信を受け入れる状態にあることを示すユーザ広告メッセージを前記マルチキャストアドレスを使用して送信するメッセージ送信手段と、
同一グループ内の他の通信端末ごとにセキュリティポリシーを記憶するセキュリティポリシーデータベース記憶手段と、
同一グループ内の他の通信端末からのユーザ広告メッセージの受信状態に基づき、前記セキュリティポリシーデータベース記憶手段に当該メッセージの送信元端末用のセキュリティポリシーを書き込み、或いは削除するセキュリティポリシー設定手段と、
を有することを特徴とする請求項１に記載のセキュア通信システム。
【請求項３】
セキュア通信を行うグループに所属する複数の通信端末に設定すべきセキュリティポリシーを記憶するデータベースを有する管理装置であって、
前記データベースは、
前記通信端末のグループごとに、前記セキュリティポリシーおよびマルチキャストアドレスを記憶し、
前記管理装置は、
前記データベース中のセキュリティポリシーが変更された時に、当該変更情報を当該グループのマルチキャストアドレスを使用して送信する変更情報送信手段を有する
ことを特徴とする管理装置。
【請求項４】
セキュア通信を行うグループに所属する通信端末であって、
前記グループのマルチキャストアドレスに基づき、ネットワークから情報を受信する受信手段と、
前記グループ内のセキュリティポリシーを記憶するグループ情報記憶手段と、
マルチキャスト形式で受信した前記セキュリティポリシーの変更情報に基づき、前記グループ情報記憶手段中のセキュリティポリシーを更新する更新手段とを有する
ことを特徴とする通信端末。
【請求項５】
自端末がセキュア通信を受け入れる状態にあることを示すユーザ広告メッセージを前記マルチキャストアドレスを使用して送信するメッセージ送信手段と、
同一グループ内の他の通信端末ごとにセキュリティポリシーを記憶するセキュリティポリシーデータベース記憶手段と、
同一グループ内の他の通信端末からのユーザ広告メッセージの受信状態に基づき、前記セキュリティポリシーデータベース記憶手段に当該メッセージの送信元端末用のセキュリティポリシーを書き込み、或いは削除するセキュリティポリシー設定手段と、
を有することを特徴とする請求項４に記載の通信端末。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、セキュア通信システム、管理装置および通信端末に関する。
【背景技術】
【０００２】
従来、ＩＰ（Internet Protocol）ネットワーク上でセキュアな通信を行うためのプロトコルとして、ＩＥＴＦ（Internet Engineering Task Force）のＲＦＣ２４０１（Security Architecture for the Internet Protocol）で規定されているＩＰｓｅｃと呼ばれる方式が知られている。ＩＥＴＦは、ＴＣＰ（Transmission Control Protocol）／ＩＰなどのインターネットで利用される技術の実質的な標準化組織として知られる。また、ＩＰｓｅｃを使用する際に必要となる秘密鍵の自動生成および管理プロトコルとして、ＩＫＥと呼ばれる方式がＩＥＴＦのＲＦＣ２４０９（The Internet Key Exchange）で規定されている。
【０００３】
上記したＩＰｓｅｃやＩＫＥを使用する際に必要な設定は一般的に複雑なものである。例えば、通信端末間でＩＰｓｅｃを用いてセキュア通信を行う場合、通信相手と事前にＩＰｓｅｃで通信を行うことの合意を取り、設定事項を交渉する必要がある。このため、一般のユーザがＩＰｓｅｃを使用することは困難となっている。また、専門知識を有するユーザであっても、セキュア通信を行いたい時に即時にＩＰｓｅｃで通信することは、通信相手との事前交渉が必要なために困難である。
【０００４】
上記した問題に対処する従来の技術として、通信端末が設定すべきＩＰｓｅｃ及びＩＫＥ設定情報などのセキュリティポリシーを記憶する通信管理サーバを備え、セキュア通信を行う通信端末は、随時又は定期的に、通信管理サーバにアクセスして、当該セキュア通信で設定すべき複数の通信相手に係るセキュリティポリシーを取得し、この取得したセキュリティポリシーを用いてＩＰｓｅｃ及びＩＫＥに係る設定を行い、セキュア通信を行うものが知られている（例えば、特許文献１参照）。
【特許文献１】特開２００４−４８４５８号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
しかし、上述した従来の技術では、通信端末はセキュア通信を行う度に随時、通信管理サーバから最新のセキュリティポリシーを取得しなければ、セキュリティポリシーの変更に対して円滑に対応することができない。このため、通信端末にかかる負荷が大きく、負担であるという問題がある。また、通信端末の負荷を軽減するために、定期的にしか通信管理サーバへアクセスしないようにすると、セキュリティポリシーが変更されていた場合、最新のセキュリティポリシーを未取得のままセキュア通信を行う可能性があり、セキュア通信の失敗を招くという事態が生じる。
【０００６】
また、セキュア通信を開始する際、通信相手の端末がセキュア通信を受け入れる準備が整っているか否かを知るためには、実際に通信相手に対してセキュア通信における接続要求をパケットで送信し、その応答の有無を判定する必要がある。このため、通信端末ではセキュア通信を開始する度に、通信相手の準備完了を確認するための負荷が発生し、負担となる。
【０００７】
本発明は、このような事情を考慮してなされたもので、その目的は、セキュア通信におけるセキュリティポリシーの変更に対して円滑に対応するとともに、通信端末の負担を軽減することができるセキュア通信システムを提供することにある。
【０００８】
また、本発明の他の目的は、本発明のセキュア通信システムに適用可能な管理装置および通信端末を提供することにある。
【課題を解決するための手段】
【０００９】
上記の課題を解決するために、本発明に係るセキュア通信システムは、セキュア通信を行うグループに所属する複数の通信端末と、前記通信端末に設定すべきセキュリティポリシーを記憶するデータベースを有する管理装置とを有するセキュア通信システムであって、前記データベースは、前記通信端末のグループごとに、前記セキュリティポリシーおよびマルチキャストアドレスを記憶し、前記管理装置は、前記データベース中のセキュリティポリシーが変更された時に、当該変更情報を当該グループのマルチキャストアドレスを使用して送信する変更情報送信手段を有し、前記通信端末は、前記マルチキャストアドレスに基づき、ネットワークから情報を受信する受信手段と、同一グループ内のセキュリティポリシーを記憶するグループ情報記憶手段と、マルチキャスト形式で受信した前記セキュリティポリシーの変更情報に基づき、前記グループ情報記憶手段中のセキュリティポリシーを更新する更新手段とを有することを特徴としている。
【００１０】
本発明に係るセキュア通信システムにおいては、前記通信端末は、自端末がセキュア通信を受け入れる状態にあることを示すユーザ広告メッセージを前記マルチキャストアドレスを使用して送信するメッセージ送信手段と、同一グループ内の他の通信端末ごとにセキュリティポリシーを記憶するセキュリティポリシーデータベース記憶手段と、同一グループ内の他の通信端末からのユーザ広告メッセージの受信状態に基づき、前記セキュリティポリシーデータベース記憶手段に当該メッセージの送信元端末用のセキュリティポリシーを書き込み、或いは削除するセキュリティポリシー設定手段とを有することを特徴とする。
【００１１】
本発明に係る管理装置は、セキュア通信を行うグループに所属する複数の通信端末に設定すべきセキュリティポリシーを記憶するデータベースを有する管理装置であって、前記データベースは、前記通信端末のグループごとに、前記セキュリティポリシーおよびマルチキャストアドレスを記憶し、前記管理装置は、前記データベース中のセキュリティポリシーが変更された時に、当該変更情報を当該グループのマルチキャストアドレスを使用して送信する変更情報送信手段を有することを特徴としている。
【００１２】
本発明に係る通信端末は、セキュア通信を行うグループに所属する通信端末であって、前記グループのマルチキャストアドレスに基づき、ネットワークから情報を受信する受信手段と、前記グループ内のセキュリティポリシーを記憶するグループ情報記憶手段と、マルチキャスト形式で受信した前記セキュリティポリシーの変更情報に基づき、前記グループ情報記憶手段中のセキュリティポリシーを更新する更新手段とを有することを特徴としている。
【００１３】
本発明に係る通信端末においては、自端末がセキュア通信を受け入れる状態にあることを示すユーザ広告メッセージを前記マルチキャストアドレスを使用して送信するメッセージ送信手段と、同一グループ内の他の通信端末ごとにセキュリティポリシーを記憶するセキュリティポリシーデータベース記憶手段と、同一グループ内の他の通信端末からのユーザ広告メッセージの受信状態に基づき、前記セキュリティポリシーデータベース記憶手段に当該メッセージの送信元端末用のセキュリティポリシーを書き込み、或いは削除するセキュリティポリシー設定手段とを有することを特徴とする。
【発明の効果】
【００１４】
本発明によれば、あるグループのセキュリティポリシーが変更された時、管理装置からマルチキャスト形式で当該グループ内の通信端末にセキュリティポリシーの変更情報が配信されるので、通信端末は、セキュリティポリシーの変更に対して円滑に対応することができるとともに、セキュリティポリシーの変更を問合せする負担が軽減される。
【００１５】
また、通信端末は、自分がセキュア通信を受け入れる状態にあることをマルチキャスト形式で同一グループ内の他の通信端末に通知するので、セキュア通信を開始する際、通信相手の端末がセキュア通信を受け入れる準備が整っているかを事前に知ることが可能となるので、通信相手の準備完了を確認する負担が軽減される。
【発明を実施するための最良の形態】
【００１６】
以下、図面を参照し、本発明の一実施形態について説明する。
図１は、本発明の一実施形態に係るセキュア通信システムの構成を示すブロック図である。図１において、通信端末１は、ＩＰｓｅｃ及びＩＫＥ方式を用いてセキュア通信を行う機能を有する。管理サーバ２は、セキュア通信者のグループ構成やセキュア通信時に通信端末１で設定すべきセキュリティポリシーなどを管理する。ＣＡ（認証）サーバ３は、公開鍵証明書の発行および管理を行う。ＩＰネットワーク４は、ＩＰバージョン６（ＩＰｖ６）またはＩＰバージョン４（ＩＰｖ４）プロトコルを用いたパケット通信ネットワークである。ＩＰネットワーク４は、マルチキャストアドレスを使用したマルチキャスト形式のパケット通信をサポートしている。通信端末１、管理サーバ２およびＣＡサーバ３は、各々ＩＰネットワーク４に接続し、ＩＰネットワーク４を介してパケット通信を行うことができる。
【００１７】
データベース１０は、セキュア通信者のグループ構成やセキュア通信時に通信端末１で設定すべきセキュリティポリシーなどを蓄積し、管理サーバ２からアクセスされる。図２は、データベース１０の構成例を示す図である。図２において、データベース１０は、セキュア通信者のグループごとにグループ情報を格納する。グループ情報は、セキュア通信者のグループを識別するグループ識別子（グループＩＤ）、グループに所属するユーザを識別するユーザ識別子（ユーザＩＤ）、グループに割り当てられたマルチキャストアドレス、グループ内で使用されるセキュリティポリシーおよびグループ内のユーザ間で共有するグループキーを含む情報である。セキュリティポリシーは、通信端末が設定すべきＩＰｓｅｃ及びＩＫＥ設定情報などからなる。例えばプロトコル種別や暗号化に使用するハッシュ関数種別などの情報を含む。
【００１８】
データベース１０に格納されるグループ情報は、管理サーバ２の管理者、または当該グループの管理者のみが変更可能となっている。あるグループのセキュリティポリシーが変更された時、管理サーバ２は、当該グループのマルチキャストアドレスを宛先アドレスに使用して、ＩＰネットワーク４を介してポリシー変更メッセージをマルチキャスト配信する。ポリシー変更メッセージは、セキュリティポリシーの変更部分の情報を有する。さらに、ＣＡサーバ３によって発行された管理サーバ２の公開鍵証明書と、管理サーバ２の秘密鍵を使用して作成された電子署名とを含む。これにより、ポリシー変更メッセージを受信した通信端末１は、受信したポリシー変更メッセージが正規の管理サーバ２から送信されたものか否かを判定することができる。管理サーバ２は、ポリシー変更メッセージを送信する際、当該グループのグループキーを使用して暗号化する。
【００１９】
図３は、図１に示す通信端末１の構成を示すブロック図である。図３において、管理サーバ通信部１１は、ＩＰネットワーク４を介して管理サーバ２とＳＳＬ（Secure Sockets Layer）或いはＴＬＳ（Transport Layer Security）などのセキュリティプロトコルを用いた通信を行い、管理サーバ２から所属グループのマルチキャストアドレス、セキュリティポリシーおよびグループキーを取得する。これら取得された情報は、グループデータベース（グループＤＢ）１２に格納される。グループＤＢ１２は、所属グループ内の全ユーザに共通の情報を記憶する。
【００２０】
マルチキャストメッセージ送信部１３は、グループＤＢ１２に格納されているマルチキャストアドレスを宛先アドレスに使用して、ＩＰネットワーク４を介してユーザ広告メッセージをマルチキャスト配信する。このユーザ広告メッセージの配信は、自端末がセキュア通信を受け入れる準備が整っている場合に行う。
【００２１】
図４はユーザ広告メッセージの構成例を示す図である。図４において、ユーザ広告メッセージはＵＤＰ（User Datagram Protocol）に基づき作成されている。ＵＡヘッダ部はシーケンス番号を有する。シーケンス番号は、ユーザ広告メッセージの配信ごとに１ずつ増やす。ＵＡデータ部は、グループＩＤ、自己のユーザＩＤ、自己のＩＰアドレス、ＣＡサーバ３によって発行された自己の公開鍵証明書および電子署名を有する。電子署名については、ＵＡヘッダ部のデータ、並びにＵＡデータ部中のグループＩＤ、ユーザＩＤ、ＩＰアドレスおよび公開鍵証明書のデータをハッシュ関数で変換し、このハッシュデータを自己の秘密鍵で暗号化して作成する。そして、ＵＡデータ部については、所属するグループのグループキーを使用して暗号化したデータを配信する。
上記電子署名の作成用のハッシュ関数および暗号化アルゴリズム、並びにユーザ広告メッセージの暗号化用のグループキーおよび暗号化アルゴリズムには、グループＤＢ１２に格納されているものを使用する。
【００２２】
マルチキャストメッセージ受信部１４は、グループＤＢ１２に格納されているマルチキャストアドレスに基づき、ＩＰネットワーク４からパケットを受信する。例えば、ポリシー変更メッセージを受信し、ポリシー変更メッセージ中のセキュリティポリシーの変更部分の情報を抽出し、この情報に基づき、グループＤＢ１２中のセキュリティポリシーを更新する。また、ユーザ広告メッセージを受信し、ユーザ広告メッセージ中のユーザ固有のデータ（ユーザＩＤ、ＩＰアドレス、シーケンス番号および公開鍵証明書）を抽出し、このデータをグループユーザデータベース（グループユーザＤＢ）１５に格納する。グループユーザＤＢ１５は、所属グループ内のユーザごとの情報を記憶する。
【００２３】
ＩＫＥ／ＩＰｓｅｃ設定部１６は、グループＤＢ１２中のセキュリティポリシーに基づき、ＩＰｓｅｃ及びＩＫＥに係る設定情報を設定情報記憶部１７に書き込む。設定情報記憶部１７は、所属グループ内のユーザごとに設定情報を記憶する。ＩＫＥ／ＩＰｓｅｃ設定部１６は、あるユーザからのユーザ広告メッセージを初めて受信したときに、当該ユーザ用の設定情報を設定情報記憶部１７に書き込む。そして、ユーザ広告メッセージの受信が継続している間は、書き込んだ設定情報を維持する。しかし、あるユーザからのユーザ広告メッセージの受信が一定期間途絶えたときには、当該ユーザ用の設定情報を設定情報記憶部１７から削除する。なお、設定情報記憶部１７で記憶しているＩＰｓｅｃ及びＩＫＥに係る設定情報は、セキュア通信を実行する機能部（図示せず）によって使用される。
【００２４】
ユーザ証明書記憶部１８は、ＣＡサーバ３によって発行された自己の公開鍵証明書、公開鍵および秘密鍵を記憶する。
【００２５】
次に、上述した図１のセキュア通信システムに係る動作を説明する。
図５は、図１に示すセキュア通信システムに係る処理の流れを示すシーケンス図である。
初めに、ユーザはＣＡサーバ３から自己の公開鍵証明書を発行してもらう。ここで、ユーザは公開鍵と秘密鍵の組を生成し、公開鍵をＣＡサーバ３に送信する。ＣＡサーバ３は、ユーザから受信した公開鍵に対して公開鍵証明書を作成し、返信する。ユーザは、ＣＡサーバ３から受信した公開鍵証明書、並びに公開鍵と秘密鍵の組を通信端末１内（ユーザ証明書記憶部１８）に保存する。
次いで、ユーザは、セキュア通信者のグループのいずれかに所属する申請を行う。この申請が許可されると、グループ管理者は、データベース１０に対して、当該ユーザのユーザＩＤを自グループ情報に含める更新を行う。
【００２６】
図５において、例えば図２のグループＩＤ“ｓｏｕｍｕ”に所属するユーザ“ａｂｃ”が通信端末１を用いて管理サーバ２にアクセスし、ＳＳＬ或いはＴＬＳなどのセキュアプロトコルによる通信接続を要求する（ステップＳ１）。次いで、通信端末１および管理サーバ２は、各々公開鍵証明書を提示して相互認証を行う（ステップＳ２）。この相互認証が成功すると、管理サーバ２は、当該ユーザが所属するグループ情報をデータベース１０から読み出して、通信端末１に送信する（ステップＳ３）。このグループ情報には、当該ユーザが所属するグループのマルチキャストアドレス、セキュリティポリシーおよびグループキーが含まれる。なお、相互認証が失敗した場合は、その時点で通信端末１と管理サーバ２間の通信を終了する。
【００２７】
次いで、通信端末１は、管理サーバ２からのグループ情報を受信すると、受信した情報をグループＤＢ１２に格納する。そして、グループ情報中のマルチキャストアドレスを宛先アドレスに使用してユーザ広告メッセージを定期的に送信する（ステップＳ４）。これにより、グループＩＤ“ｓｏｕｍｕ”に所属する他のユーザ“ｃｂａ”および“ｄｅｆ”は、ユーザ“ａｂｃ”からのユーザ広告メッセージをマルチキャストアドレスに基づき受信する。
【００２８】
また、通信端末１は、マルチキャストアドレスに基づき、他のユーザ“ｃｂａ”または“ｄｅｆ”からのユーザ広告メッセージを受信する（ステップＳ５）。図６は、通信端末１におけるユーザ広告メッセージ受信時の処理フロー図である。図６において、通信端末１は、あるユーザからのユーザ広告メッセージを受信すると（ステップＳ１０１）、ユーザ広告メッセージ中のシーケンス番号をグループユーザＤＢ１５中の当該ユーザの過去に受信したシーケンス番号に基づき検証する（ステップＳ１０２）。そして、今回受信したシーケンス番号が、過去に受信したシーケンス番号よりもＭ以上大きい場合（Ｍは自然数）、または過去に受信したシーケンス番号と同一である場合には、受信したユーザ広告メッセージを廃棄する（ステップＳ１０３）。
【００２９】
次いで、シーケンス番号の検証が成功すると、通信端末１は、グループＤＢ１２中のグループキーを使用してユーザ広告メッセージを復号化する（ステップＳ１０４）。次いで、復号されたユーザ広告メッセージについてフォーマットの検証を行い、メッセージの中身が理解可能か否かを判断する（ステップＳ１０５）。この検証が失敗した場合、当該ユーザ広告メッセージを廃棄する（ステップＳ１０３）。
【００３０】
次いで、ステップＳ１０４の検証が成功すると、通信端末１は、ユーザ広告メッセージ中の電子署名を検証する（ステップＳ１０６）。この検証では、先ず、グループユーザＤＢ１５中の当該ユーザの公開鍵証明書に基づき、ユーザ広告メッセージ中の公開鍵証明書を検証する。この検証の結果、公開鍵証明書が正当なものならば、ユーザ広告メッセージ中の電子証明書に含まれる公開鍵を使用して、ユーザ広告メッセージ中の電子署名を検証する。この電子署名の検証が失敗ならば（ステップＳ１０７がＮＯ）、当該ユーザ広告メッセージを廃棄する（ステップＳ１０３）。
【００３１】
一方、電子署名の検証が成功ならば（ステップＳ１０７がＹＥＳ）、ユーザ広告メッセージ中のデータ（ユーザＩＤ、ＩＰアドレス、シーケンス番号および公開鍵証明書）を抽出し、当該ユーザＩＤに関連付けて各データをグループユーザＤＢ１５に格納する（ステップＳ１０８）。次いで、通信端末１は、グループＤＢ１２中のセキュリティポリシーに基づき、当該ユーザ用のＩＰｓｅｃ及びＩＫＥに係る設定情報を設定情報記憶部１７に書き込む（ステップＳ１０９）。これにより、当該ユーザ用のセキュリティポリシーデータベースが設定情報記憶部１７内に生成される。ユーザ広告メッセージは、通信端末がセキュア通信を受け入れる準備が整っている場合に送信されるので、セキュリティポリシーデータベースの存在は、当該ユーザの通信端末においてセキュア通信を受け入れ可能なことを示す。
【００３２】
次いで、通信端末１は、セキュリティポリシーデータベースが生成されたユーザに関し、当該ユーザからのユーザ広告メッセージの受信の有無を監視する。そして、ユーザ広告メッセージの受信なしの状態が、所定期間継続した場合、当該ユーザの通信端末においてセキュア通信を受け入れ不可能な状態になったと判断し、当該ユーザのセキュリティポリシーデータベースを削除する。
【００３３】
これにより、通信端末１は、通信を開始する際、先ず、設定情報記憶部１７を探索し、当該通信相手用のセキュリティポリシーデータベースがあるか否か、つまり、当該通信相手の通信端末用のＩＰｓｅｃ及びＩＫＥに係る設定情報が設定済みであるか否かを確認する。この確認結果に基づき、当該通信相手の通信端末との間でＩＰｓｅｃ及びＩＫＥ方式によるセキュア通信が可能であるか否かを判断することができる。つまり、セキュリティポリシーデータベースが存在し、つまりＩＰｓｅｃ及びＩＫＥに係る設定情報が設定済みである場合、通信相手の通信端末との間でＩＰｓｅｃ及びＩＫＥ方式によるセキュア通信を行うことができると判断する。一方、セキュリティポリシーデータベースが存在せず、つまりＩＰｓｅｃ及びＩＫＥに係る設定情報が設定されていない場合、通信相手の通信端末との間でＩＰｓｅｃ及びＩＫＥ方式によるセキュア通信を行うことができないと判断する。
【００３４】
なお、セキュア通信を実行する際には、セキュアな通信路（ＳＡ）が既に確立している場合は、そのＳＡを利用してパケットを送信する。一方、ＳＡが未確立の場合には、ＩＫＥによりパケットの宛先の通信端末との間のＳＡを確立した後、当該ＳＡを利用してパケットを送信する。
【００３５】
上述したように本実施形態によれば、あるグループのセキュリティポリシーが変更された時、管理サーバからマルチキャスト形式で当該グループ内の通信端末にセキュリティポリシーの変更部分の情報が配信される。これにより、通信端末は、セキュリティポリシーの変更に対して円滑に対応することができるとともに、セキュリティポリシーの変更を問合せする負担が軽減される。
【００３６】
また、通信端末は、自分がセキュア通信を受け入れる状態にあることをマルチキャスト形式で同一グループ内の他の通信端末に通知するので、セキュア通信を開始する際、通信相手の端末がセキュア通信を受け入れる準備が整っているかを事前に知ることが可能となる。これにより、セキュア通信を開始する度に、通信相手の準備完了を確認するための試しのパケット送信および応答の有無判定が不要となり、通信端末の負荷が軽減される。
【００３７】
以上、本発明の実施形態を図面を参照して詳述してきたが、具体的な構成はこの実施形態に限られるものではなく、本発明の要旨を逸脱しない範囲の設計変更等も含まれる。
【図面の簡単な説明】
【００３８】
【図１】本発明の一実施形態に係るセキュア通信システムの構成を示すブロック図である。
【図２】データベース１０の構成例を示す図である。
【図３】図１に示す通信端末１の構成を示すブロック図である。
【図４】ユーザ広告メッセージの構成例を示す図である。
【図５】図１に示すセキュア通信システムに係る処理の流れを示すシーケンス図である。
【図６】通信端末１におけるユーザ広告メッセージ受信時の処理フロー図である。
【符号の説明】
【００３９】
１…通信端末、２…管理サーバ、３…ＣＡサーバ、４…ＩＰネットワーク、１０…データベース、１１…管理サーバ通信部、１２…グループデータベース（グループＤＢ）、１３…マルチキャストメッセージ送信部、１４…マルチキャストメッセージ受信部、１５…グループユーザデータベース（グループユーザＤＢ）、１６…ＩＫＥ／ＩＰｓｅｃ設定部、１７…設定情報記憶部、１８…ユーザ証明書記憶部。
【図１】
2006019824.tif 000003
【図２】
2006019824.tif 000004
【図３】
2006019824.tif 000005
【図４】
2006019824.tif 000006
【図５】
2006019824.tif 000007
【図６】
2006019824.tif 000008