JP4296191B2 - サーバ装置、端末装置、通信方法、通信プログラムおよび通信システム - Google Patents

サーバ装置、端末装置、通信方法、通信プログラムおよび通信システム Download PDF

Info

Publication number
JP4296191B2
JP4296191B2 JP2006203628A JP2006203628A JP4296191B2 JP 4296191 B2 JP4296191 B2 JP 4296191B2 JP 2006203628 A JP2006203628 A JP 2006203628A JP 2006203628 A JP2006203628 A JP 2006203628A JP 4296191 B2 JP4296191 B2 JP 4296191B2
Authority
JP
Japan
Prior art keywords
terminal
terminal device
multicast
encryption key
communication
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
JP2006203628A
Other languages
English (en)
Other versions
JP2008034960A (ja
Inventor
佳道 谷澤
直紀 江坂
勉 柴田
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Toshiba Corp
Original Assignee
Toshiba Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Toshiba Corp filed Critical Toshiba Corp
Priority to JP2006203628A priority Critical patent/JP4296191B2/ja
Priority to US11/705,495 priority patent/US8140844B2/en
Publication of JP2008034960A publication Critical patent/JP2008034960A/ja
Application granted granted Critical
Publication of JP4296191B2 publication Critical patent/JP4296191B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/06Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/065Network architectures or network communication protocols for network security for supporting key management in a packet data network for group communications

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Computer Security & Cryptography (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Telephonic Communication Services (AREA)

Description

この発明は、SIP(Session Initiation Protocol)などのセッション制御プロトコルベースのシステムでIP(Internet Protocol)マルチキャスト通信を行うサーバ装置、端末装置、通信方法、通信プログラムおよび通信システムに関するものである。
近年、IPネットワーク上でのマルチメディアセッションの制御を行うプロトコルであるSIPを用いて、例えば、インターネット電話システムなどの通信システムが開発されている。
SIPベースの通信システムでIPマルチキャスト通信を行う場合、セキュリティ強化等のため、通信する端末相互間で事前に暗号化鍵を交換し、暗号化鍵でメッセージを暗号化して通信を行うことが望ましい。
非特許文献1では、SIPなどに適用しうる暗号化鍵の交換プロトコルとして標準化されたMIKEY(Multimedia Internet KEYing)と呼ばれる技術が開示されている。非特許文献1の方法をSIPに適用する場合、原則として暗号化通信を行う端末同士がオファーアンサーモデルに従って暗号化鍵の交換を行うことになる。
J. Arkko et al.、 "RFC 3830、 MIKEY: Multimedia Internet KEYing"、 [online]、 August 2004、 retrieved from the Internet: <URL: http://www.ietf.org/rfc/rfc3830.txt>
しかしながら、非特許文献1の方法では、端末同士が1対1で暗号化鍵の交換を行うため、IPマルチキャスト通信時の鍵交換のための処理負担が増大する場合があるという問題があった。
例えば、多数の端末がメンバとして登録されているIPマルチキャストグループとIPマルチキャスト通信を行う場合、すべてのメンバとの間で鍵交換を行い、鍵交換処理が完了してからIPマルチキャスト通信を開始する必要があるため、通信開始までの時間的コストが過大となる問題があった。
本発明は、上記に鑑みてなされたものであって、セキュアなIPマルチキャスト通信を行う際の処理負担を軽減することができるサーバ装置、端末装置、通信方法、通信プログラムおよび通信システムを提供することを目的とする。
上述した課題を解決し、目的を達成するために、本発明は、複数の端末装置の間のマルチキャスト通信で用いる暗号鍵を管理するサーバ装置であって、プレゼンス情報を記憶する第1の記憶手段と、前記複数の端末装置のそれぞれを識別するための端末識別子を、それぞれの端末装置が属するマルチキャストグループ内のマルチキャスト通信に用いる暗号鍵と対応付けて記憶する第2の記憶手段と、前記複数の端末装置のうちの第1の端末装置から、その第1の端末装置の端末識別子を含み、前記第1の記憶手段に記憶されたプレゼンス情報の購読を要求する購読要求メッセージを受信する受信手段と、受信した前記購読要求メッセージに含まれる前記第1の端末装置の端末識別子を用いて、前記第1の端末装置が属するマルチキャストグループ内のマルチキャスト通信に用いる暗号鍵を前記第2の記憶手段から取得する取得手段と、取得した暗号鍵を、購読要求のあったプレゼンス情報とともに前記第1の端末装置に送信する送信手段とを備えることを特徴とする。
また、本発明は、上記装置を実行することができる通信方法および通信プログラムである。
また、本発明は、複数の端末装置の間のマルチキャスト通信で用いる暗号鍵を管理するサーバ装置と、前記複数の端末装置と、をネットワークで接続した通信システムであって、前記サーバ装置は、プレゼンス情報を記憶する第1の記憶手段と、前記複数の端末装置のそれぞれを識別するための端末識別子を、それぞれの端末装置が属するマルチキャストグループ内のマルチキャスト通信に用いる暗号鍵と対応付けて記憶する第2の記憶手段と、前記複数の端末装置のうちの第1の端末装置から、その第1の端末装置の端末識別子を含み、前記第1の記憶手段に記憶されたプレゼンス情報の購読を要求する購読要求メッセージを受信する受信手段と、受信した前記購読要求メッセージに含まれる前記第1の端末装置の端末識別子を用いて、前記第1の端末装置が属するマルチキャストグループ内のマルチキャスト通信に用いる暗号鍵を前記第2の記憶手段から取得する取得手段と、取得した暗号鍵を、購読要求のあったプレゼンス情報とともに前記第1の端末装置に送信する送信手段と、を備え、前記端末装置は、前記購読要求メッセージを前記サーバ装置に送信する第2送信手段と、前記暗号鍵、購読を要求したプレゼンス情報とともに前記サーバ装置から受信する第2受信手段と、を備えたこと、を特徴とする。
本発明によれば、プレゼンスサーバ機能を用いてマルチキャスト通信で用いる鍵の交換を行うため、セキュアなIPマルチキャスト通信を行う際の処理負担を軽減することができるという効果を奏する。
以下に添付図面を参照して、この発明にかかるサーバ装置、端末装置、通信方法、通信プログラムおよび通信システムの最良な実施の形態を詳細に説明する。
(第1の実施の形態)
第1の実施の形態にかかるサーバ装置は、IPマルチキャスト通信とは無関係な存在であったプレゼンスサーバ機能を利用して、事前にIPマルチキャストのための鍵交換をIPマルチキャストグループのメンバ間で行うものである。これにより、SIPベースのシステムでセキュアなIPマルチキャスト通信を開始するまでにかかる時間的なコスト(オーバヘッド)を削減することができる。
また、本実施の形態にかかるサーバ装置は、鍵交換プロトコルのためのメッセージ送信とプレゼンス情報のためのメッセージ送信を統合することにより、システム構成を単純化し、ネットワークトラフィックを削減することができる。
なお、プレゼンス情報とは、端末が通信可能か否か(オフラインかオンラインか)や、ユーザの在席位置情報、あるいはアプリケーションの利用可能性などのような、端末やユーザ、ユーザが属するグループ、アプリケーションなどに関する状態を表す情報をいう。
図1は、第1の実施の形態にかかるサーバ装置であるプレゼンスサーバ100を含む通信システムの構成を示す概念図である。本通信システムはSIPベースのシステムであり、例えば、IPベースの企業向け内線電話システム、テレビ会議システム、チャットシステムなどが該当する。同図に示すように、本通信システムは、プレゼンスサーバ100と、複数の端末200a〜200hと、Proxy300とを含んでいる。
端末200a〜200hは、SIPのクライアント機能(SIP UA(ユーザエージェント))を有する装置である。なお、端末200a〜200hは同様の構成を備えているため、以下では単に端末200という場合がある。
Proxy300は、SIPメッセージの転送機能を持つ通常のSIP Proxyサーバであり、プレゼンスサーバ100や端末200間のSIPメッセージを転送するものである。
プレゼンスサーバ100は、本通信システムの各プレゼンティティのプレゼンス情報を管理するものである。なお、プレゼンティティとは、プレゼンス情報を提供するものをいう。一方、プレゼンティティのプレゼンス情報の通知を受けるものをウォッチャーという。なお、プレゼンティティやウォッチャーは、端末200に限られず、プレゼンス情報の提供や通知を受けるものであればあらゆるものが該当する。
図2は、第1の実施の形態にかかる端末200の構成を示すブロック図である。同図に示すように、端末200は、音声入出力部211と、データ入出力部212と、発行メッセージ処理部201と、購読メッセージ処理部202と、通知メッセージ処理部203と、送信部221と、受信部222とを備えている。
音声入出力部211は、ユーザの発話等の音声を入力するとともに、他の端末200等から送信された音声をユーザに対して出力するものである。音声入出力部211は、一般的に利用されているマイクとスピーカ、または電話機の受話器などにより構成することができる。
データ入出力部212は、音声以外の各種データの入出力を行うものであり、例えば、電話番号を入力するための操作ボタン、データを表示する液晶ディスプレイなどにより構成することができる。
なお、音声入出力部211と、データ入出力部212とにより、通常の電話端末のようなユーザインターフェース機能が実現される。
発行メッセージ処理部201は、プレゼンスサーバ100に対するプレゼンス情報の発行を行うメッセージである発行メッセージに関する処理を行うものである。具体的には、発行メッセージ処理部201は、SIP PUBLISHメッセージを発行メッセージとしてプレゼンスサーバ100に対してプレゼンス情報を発行する。メッセージの形式はこれに限られるものではなく、プレゼンス情報を発行できるものであればあらゆる形式のメッセージを用いることができる。
なお、この発行メッセージ処理部201の機能により、端末200は、プレゼンスサーバ100に対して、プレゼンス情報を提供するプレゼンティティとなることができる。
購読メッセージ処理部202は、プレゼンスサーバ100に対して他のプレゼンティティの情報の購読を要求するメッセージである購読要求メッセージに関する処理を行うものである。具体的には、購読メッセージ処理部202は、SIP SUBSCRIBEメッセージを購読要求メッセージとしてプレゼンスサーバ100に対して購読要求を行う。メッセージの形式はこれに限られるものではなく、購読要求を送信できるものであればあらゆる形式のメッセージを用いることができる。
なお、この購読メッセージ処理部202の機能により、端末200は、プレゼンスサーバ100から、他のプレゼンティティの情報に関する通知を受けるウォッチャーとなることができる。
通知メッセージ処理部203は、プレゼンスサーバ100から受信した他のプレゼンティティのプレゼンス情報などを通知するメッセージである情報通知メッセージに関する処理を行うものである。具体的には、通知メッセージ処理部203は、SIP NOTIFYメッセージを情報通知メッセージとして通知されたプレゼンス情報を受信し、その内容を取得する処理を行う。メッセージの形式はこれに限られるものではなく、他のプレゼンティティのプレゼンス情報などの通知を受けることができるものであればあらゆる形式のメッセージを用いることができる。
送信部221は、プレゼンスサーバ100または他の端末200に対して、各種メッセージや、音声・映像等のメディアデータを送信するものである。
受信部222は、プレゼンスサーバ100または他の端末200から、各種メッセージや、音声・映像等のメディアデータを受信するものである。
送信部221および受信部222は、SRTP(Secure Real-time Transport Protocol)によりセキュアなIPマルチキャスト通信によりメディアデータを送信する。このため、送信部221および受信部222は、暗号化および復号に使用する鍵情報を記憶部に複数保持する。
これにより、送信部221は、送信の際にそのうちの1つの暗号鍵を選択してメディアデータを暗号化して送信することができる。また、受信部222は、受信の際に、そのメディアデータの暗号化に使用されている暗号鍵を特定し、保持している複数の暗号鍵の中から対応する暗号鍵を選択し、メディアデータを復号して受信することができる。
図3は、第1の実施の形態にかかるプレゼンスサーバ100の構成を示すブロック図である。同図に示すように、プレゼンスサーバ100は、記憶部140と、受付部111と、認証部112と、取得部113と、生成部114と、登録部115と、発行メッセージ処理部101と、購読メッセージ処理部102と、通知メッセージ処理部103と、送信部121と、受信部122とを備えている。
記憶部140は、プレゼンスサーバ100による通信処理で利用する各種データを記憶するものであり、HDD(Hard Disk Drive)、光ディスク、メモリカード、RAM(Random Access Memory)などの一般的に利用されているあらゆる記憶媒体により構成することができる。
また、記憶部140は、各種データを記憶するテーブルとして、プレゼンティティ情報テーブル141と、プレゼンス情報テーブル142と、対応テーブル143と、定義情報テーブル144と、アドレステーブル145と、鍵情報テーブル146とを含んでいる。
プレゼンティティ情報テーブル141は、プレゼンティティに関する情報を格納するものである。図4は、プレゼンティティ情報テーブル141のデータ構造の一例を示す説明図である。
同図に示すように、プレゼンティティ情報テーブル141は、プレゼンティティ名と、Groupフラグと、プレゼンティティを識別する識別子としてURI(Uniform Resource Identifier)とを対応づけて格納している。
Groupフラグとは、プレゼンティティがマルチキャストグループであるか否かを表す情報をいい、マルチキャストグループであるときは、「○」が設定される。このように、本実施の形態にかかるプレゼンスサーバ100では、プレゼンティティとしてマルチキャストグループを指定することができる。
プレゼンス情報テーブル142は、各プレゼンティティの現在の状況を表すプレゼンス情報を格納するものである。図5は、プレゼンス情報テーブル142のデータ構造の一例を示す説明図である。
同図に示すように、プレゼンス情報テーブル142は、プレゼンティティ名と、プレゼンス情報とを対応づけて格納している。プレゼンス情報としては、メッセージの受入れ可否(「Open」または「Close」)を表すBasic要素と、位置に関する情報であるLocation要素とを格納している。なお、プレゼンス情報はこれに限られるものではなく、従来から用いられているプレゼンスに関するあらゆる情報を指定することができる。
対応テーブル143は、プレゼンティティごとに、当該プレゼンティティに対するウォッチャーを格納するものである。図6は、対応テーブル143のデータ構造の一例を示す説明図である。
同図に示すように、対応テーブル143は、プレゼンティティのURIと、ウォッチャーリストとを対応づけて格納している。プレゼンティティがマルチキャストグループの場合は、プレゼンティティのURIにはマルチキャストグループのURIが設定され、ウォッチャーリストに含まれるURIが、対応するマルチキャストグループを構成するメンバである端末200のリストを表す。
定義情報テーブル144は、マルチキャストグループを構成するメンバを定義する情報を格納するものである。図7は、定義情報テーブル144のデータ構造の一例を示す説明図である。
同図に示すように、定義情報テーブル144は、マルチキャストグループのURIと、グループメンバのURIのリストとを対応づけたグループ定義情報を格納している。また、定義情報テーブル144には、プレゼンス情報が満たす条件によって構成メンバを定義するグループ定義情報を格納することもできる。
例えば、同図の2レコード目のグループ定義情報では、グループメンバを「プレゼンス状態が着席中であり、且つ、その接続元情報がオフィスAとなっている端末」のように、プレゼンス情報の条件によって定義している。
すなわち、同図では、プレゼンス情報のBasic要素が「Open」であり、Location要素が「location−A」である端末200をグループメンバとするグループ定義情報が指定されている。
なお、同図の1レコード目のグループ定義情報のように、端末200のURIのリストによって定義されたマルチキャストグループのグループメンバは、対応テーブル143における当該マルチキャストグループをプレゼンティティとするウォッチャーリストと同一となる。
一方、プレゼンス情報により定義されたマルチキャストグループに対しては、プレゼンティティ情報テーブル141およびプレゼンス情報テーブル142を参照し、条件を満たすプレゼンス情報を有する端末200を選択することにより、任意のタイミングで当該マルチキャストグループのメンバとなる端末200のURIのリストを得ることができる。
このようにして得られた端末200のURIのリストは、対応テーブル143のウォッチャーリストに登録される。このようにして、現在のプレゼンス情報を反映したマルチキャストグループのメンバ構成を対応テーブル143に保持することができる。
アドレステーブル145は、マルチキャストグループのマルチキャストアドレスを格納するものである。図8は、アドレステーブル145のデータ構造の一例を示す説明図である。
同図に示すように、アドレステーブル145は、マルチキャストグループの識別子(URI)であるグループURIと、マルチキャストアドレスとを対応づけて格納している。
鍵情報テーブル146は、マルチキャストグループにおけるIPマルチキャスト通信で用いる暗号鍵の情報を格納するものである。図9は、鍵情報テーブル146のデータ構造の一例を示す説明図である。同図に示すように、鍵情報テーブル146は、グループURIと、鍵情報とを対応づけて格納している。
鍵情報には、暗号化通信に用いる鍵の情報を記憶する。本実施の形態では、鍵情報として、秘密鍵方式の暗号鍵などの従来から用いられているあらゆる暗号鍵を用いることができる。なお、鍵情報は、そのIDとともに複数保持することができる。
受付部111は、定義情報テーブル144に設定するグループ定義情報などの、ユーザにより入力される各種情報の入力を受付けるものである。受付部111は、キーボードなどのユーザインターフェースや、外部装置からネットワーク経由でグループ定義情報を受付ける方法などの従来から用いられているあらゆるデータ入力方法により実現される。
認証部112は、端末200などの外部装置の認証処理を行うものであり、ID/パスワードを用いた認証方法などの従来から用いられているあらゆる認証方法を適用できる。また、認証部112は、ネットワークを介して接続された外部の認証サーバ(図示せず)を利用して認証処理を行うように構成してもよい。
取得部113は、購読要求メッセージ等が送信されたマルチキャストグループの鍵情報を、鍵情報テーブル146から取得するものである。具体的には、取得部113は、購読要求メッセージ等に含まれる端末200のURIに対応するマルチキャストグループのURIを対応テーブル143から取得し、取得したURIに対応する鍵情報を鍵情報テーブル146から取得する。
また、取得部113は、購読要求メッセージ等が送信されたマルチキャストグループのマルチキャストアドレスを、アドレステーブル145から取得する。具体的には、取得部113は、対応テーブル143から取得したURIに対応するマルチキャストアドレスをアドレステーブル145から取得する。
生成部114は、マルチキャストグループの鍵情報の生成を行うものである。生成部114は、例えば、受付部111により新規グループの作成が受付けられたときに、乱数の発生などによって鍵情報を生成する。生成部114による鍵の生成では、用いる暗号鍵の種類に応じた従来から用いられているあらゆる鍵の生成方法を適用できる。
なお、マルチキャストグループを構成する端末200により生成された鍵情報を、例えばSIP PUBLISH REQUESTメッセージなどにより受信して利用するように構成してもよい。また、生成部114は、鍵情報を任意のタイミング、または周期的に更新するように構成してもよい。
登録部115は、上記各テーブルに対する情報の登録処理を行うものである。例えば、登録部115は、生成部114が生成した鍵情報を、鍵情報テーブル146に登録する。また、登録部115は、受付部111が受付けたグループ定義情報を、定義情報テーブル144に登録する。
発行メッセージ処理部101は、プレゼンティティである端末200などから受信した発行メッセージに関する処理を行うものである。例えば、発行メッセージ処理部101は、SIP PUBLISH REQUESTメッセージによってプレゼンス情報が変化したことを端末200から通知されたとき、SIP PUBLISH RESPONSEメッセージを返信する処理を行う。
また、発行メッセージ処理部101は、受信したプレゼンス情報をプレゼンス情報テーブル142に保存する。新規プレゼンティティのプレゼンス情報を受信したときは、発行メッセージ処理部101は、プレゼンティティ情報テーブル141に新たにプレゼンティティの情報を追加する。
購読メッセージ処理部102は、ウォッチャーである端末200などから受信した購読要求メッセージに関する処理を行うものである。例えば、購読メッセージ処理部102は、SIP SUBSCRIBEメッセージを受信したとき、対応するレスポンスとしてSIP SUBSCRIBE RESPONSEメッセージを返信する処理を行う。
また、購読メッセージ処理部102は、購読要求メッセージを受信した端末200を対応テーブル143のウォッチャーリストに追加する処理などを行う。
通知メッセージ処理部103は、端末200に送信するプレゼンス情報の変更などを通知する情報通知メッセージに関する処理を行うものである。例えば、通知メッセージ処理部103は、任意のプレゼンティティのプレゼンス情報が更新された場合に、当該プレゼンティティのウォッチャーである端末200に対して通知するSIP NOTIFY REQUESTメッセージを生成し、端末200に送信する処理を行う。なお、通知メッセージ処理部103は、対応するSIP NOTIFY RESPONSEの処理も行う。
ウォッチャーリストを更新した場合、通知メッセージ処理部103は、プレゼンス情報をウォッチャーリストに含まれる各端末200に対して、SIP NOTIFY REQUESTメッセージによって通知する。
送信部121は、端末200に対して各種メッセージを送信するものである。受信部122は、端末200から各種メッセージを受信するものである。
次に、このように構成された第1の実施の形態にかかるプレゼンスサーバ100による鍵交換処理について説明する。図10は、第1の実施の形態における鍵交換処理の全体の流れを示すシーケンス図である。同図は、端末200が起動したときの鍵交換処理のシーケンスを表している。
まず、端末200の送信部221は、マルチキャストグループを含む任意のプレゼンティティに対するウォッチャーとして登録を依頼する購読要求メッセージ(SIP SUBSCRIBE REQUESTメッセージ)をプレゼンスサーバ100に対して送信する(ステップS1001)。
なお、端末200は、事前にプレゼンスサーバ100のアドレスを取得しているものとする。また、SIP SUBSCRIBE REQUESTメッセージは、端末200の購読メッセージ処理部202によって作成される。SIP SUBSCRIBE REQUESTメッセージには、購読対象となるプレゼンティティを識別するためのURIが含まれる。なお、マルチキャストグループに含まれる端末200の情報はプレゼンスサーバ100の対応テーブル143で管理しているため、自装置が属するマルチキャストグループの購読要求を行うときはURIを含めなくてもよい。
次に、プレゼンスサーバ100の受信部122は、SIP SUBSCRIBE REQUESTメッセージを受信する(ステップS1002)。続いて、認証部112が、SIP SUBSCRIBE REQUESTメッセージに含まれる認証情報を用いて端末200の認証処理を行う(ステップS1003)。
端末200が認証された場合は、購読メッセージ処理部102は、購読が要求されたプレゼンティティに対するウォッチャーとして端末200を追加するように対応テーブル143を更新する(ステップS1004)。また、例えば、システム全体のマルチキャストグループに対応するプレゼンティティが存在する場合、当該プレゼンティティに対するウォッチャーとして端末200を追加するように構成してもよい。
次に、購読メッセージ処理部102は、SIP SUBSCRIBE RESPONSEメッセージを生成する(ステップS1005)。生成したメッセージは、送信部121が端末200に送信する(ステップS1006)。
端末200の受信部222は、送信されたSIP SUBSCRIBE RESPONSEメッセージを受信する(ステップS1007)。
次に、プレゼンスサーバ100の通知メッセージ処理部103は、端末200の購読対象はマルチキャストグループか否かを判断する(ステップS1008)。
具体的には、通知メッセージ処理部103は、まず、対応テーブル143を参照して端末200に通知すべきプレゼンティティを特定する。すなわち、通知メッセージ処理部103は、端末200がウォッチャーとして含まれるプレゼンティティ名を対応テーブル143から取得する。
ここで特定されるプレゼンティティとしては、端末200が明示的にウォッチャーとなることを要求して対応テーブル143に登録されているプレゼンティティと、端末200が含まれるマルチキャストグループとが該当しうる。
次に、通知メッセージ処理部103は、取得したプレゼンティティ名に対応するGroupフラグをプレゼンティティ情報テーブル141から取得し、取得したGroupフラグが「○」であるか否かにより、購読対象がマルチキャストグループか否かを判断する。
購読対象がマルチキャストグループである場合は(ステップS1008:YES)、取得部113は、受信したSIP SUBSCRIBE REQUESTメッセージに含まれるURIに対応する鍵情報を、鍵情報テーブル146から取得する(ステップS1009)。また、取得部113は、当該URIに対応するマルチキャストアドレスをアドレステーブル145から取得する。
次に、通知メッセージ処理部103は、取得した鍵情報を含むSIP NOTIFY REQUESTメッセージを生成する(ステップS1010)。なお、当該SIP NOTIFY REQUESTメッセージには、端末200に通知すべきプレゼンス情報と、マルチキャストグループ情報とが含まれる。マルチキャストグループ情報とは、マルチキャストアドレス情報と、鍵情報とを含む情報をいう。
このとき、通知メッセージ処理部103は、鍵情報を含むマルチキャストグループ情報を暗号化するように構成してもよい。例えば、通知メッセージ処理部103は、既存の鍵交換プロトコルであるMIKEYにしたがって暗号化した鍵情報を含むメッセージを生成するように構成することができる。
通知メッセージ処理部103は、対応テーブル143から取得したプレゼンティティ名に対応するプレゼンス情報をプレゼンス情報テーブル142から取得し、通知すべきプレゼンス情報とする。
次に、送信部121は、生成したSIP NOTIFY REQUESTメッセージを、SIP SUBSCRIBEメッセージに対応する最初のSIP NOTIFY REQUESTメッセージとして端末200に対して送信する(ステップS1011)。
なお、ステップS1008で、購読対象がマルチキャストグループでないと判断された場合は(ステップS1008:NO)、鍵交換を行う必要がないため、送信部121は、鍵情報を含まない通常のSIP NOTIFY REQUESTメッセージを端末200に対して送信する。
図11は、鍵情報を含むSIP NOTIFY REQUESTメッセージの形式の一例を示す説明図である。同図は、プレゼンス情報を表現する仕様であるPIDF(Presence Information Data Format)を拡張したメッセージ形式の一例を示している。
同図のメッセージ形式では、プレゼンティティである「alice@example.com」のプレゼンス情報とともに、MIKEY鍵交換プロトコルにより暗号鍵を交換するための情報を含む、プレゼンティティであるマルチキャストグループ「group-X@example.com」のプレゼンス情報が含まれている。
図10に戻り、端末200の受信部222は、SIP NOTIFY REQUESTメッセージを受信する(ステップS1012)。次に、端末200の通知メッセージ処理部203は、受信したSIP NOTIFY REQUESTメッセージに含まれる鍵情報を設定する(ステップS1013)。鍵情報を設定するとは、メッセージから鍵情報を抽出し、セキュアなIPマルチキャスト通信が可能となるように抽出した鍵情報を装置内に組み込むことをいう。なお、通知メッセージ処理部203は、メッセージに含まれるマルチキャストアドレスの設定等も同時に行う。
次に、通知メッセージ処理部203は、SIP NOTIFY REQUESTメッセージに対する応答である、SIP NOTIFY RESPONSEメッセージを生成する(ステップS1014)。
なお、通知メッセージ処理部203は、MIKEYなどの鍵交換に使用しているプロトコルに規定されるデータを含むメッセージを生成するように構成してもよい。例えば、端末200とプレゼンスサーバ100の間で相互認証を行うための、端末200のID情報などが含まれるかもしれない。
図12は、SIP NOTIFY RESPONSEメッセージの形式の一例を示す説明図である。同図は、PIDFを拡張したメッセージ形式の一例を示している。同図の例では、マルチキャストグループ「group-X@example.com」のためのMIKEY鍵交換プロトコルによる相互認証メッセージを含むメッセージ形式が示されている。
図10に戻り、送信部221は、生成したSIP NOTIFY RESPONSEメッセージをプレゼンスサーバ100に送信する(ステップS1015)。プレゼンスサーバ100の受信部122は、SIP NOTIFY RESPONSEメッセージを受信し(ステップS1016)、鍵交換処理を終了する。
以上の処理により、他の端末200すべてと相互に鍵交換を行うことなく、事前にプレゼンスサーバ100に保存された鍵情報の配布を受けることにより、効率的に鍵交換を行い、IPマルチキャスト通信時の処理負担を軽減することができる。
次に、端末200のプレゼンス情報の更新が行われた場合の鍵交換処理のシーケンスについて説明する。図13は、この場合の鍵交換処理の全体の流れを示すシーケンス図である。
まず、端末200の送信部221は、自装置のプレゼンス情報の発行メッセージ(SIP PUBLISH REQUESTメッセージ)をプレゼンスサーバ100に対して送信する(ステップS1301)。
なお、SIP PUBLISH REQUESTメッセージは、端末200の発行メッセージ処理部201によって作成される。
次に、プレゼンスサーバ100の受信部122は、SIP PUBLISH REQUESTメッセージを受信する(ステップS1302)。続いて、認証部112が、SIP PUBLISH REQUESTメッセージに含まれる認証情報を用いて端末200の認証処理を行う(ステップS1303)。
端末200が認証された場合は、発行メッセージ処理部101は、プレゼンティティ情報テーブル141を参照し、同テーブルに保存済みのプレゼンティティでない場合、すなわち、当該端末200から最初にSIP PUBLISH REQUESTメッセージを受信した場合には、当該メッセージに含まれる端末200のURIをプレゼンティティ情報テーブル141に追加する(ステップS1304)。
また、発行メッセージ処理部101は、受信したメッセージに含まれるプレゼンス情報をプレゼンス情報テーブル142に登録する。既にプレゼンティティとして登録済みの端末200の場合は、受信したメッセージに含まれるプレゼンス情報で対応するプレゼンティティのプレゼンス情報を更新する。
次に、発行メッセージ処理部101は、SIP PUBLISH RESPONSEメッセージを生成する(ステップS1305)。生成したメッセージは、送信部121が端末200に送信する(ステップS1306)。
端末200の受信部222は、送信されたSIP PUBLISH RESPONSEメッセージを受信する(ステップS1307)。
次に、発行メッセージ処理部101は、定義情報テーブル144でプレゼンス情報の条件で定義されたマルチキャストグループのメンバ(ウォッチャーリスト)を再構成する(ステップS1308)。プレゼンス情報を更新した場合、プレゼンス情報の条件で定義されたマルチキャストグループのメンバが変更される場合があるためである。
次に、発行メッセージ処理部101は、マルチキャストグループが更新されたか否かを判断する(ステップS1309)。更新されていない場合は(ステップS1309:NO)、鍵交換を行う必要がないため、鍵交換処理を終了する。
更新されている場合は(ステップS1309:YES)、取得部113は、更新したマルチキャストグループの鍵情報を、鍵情報テーブル146から取得する(ステップS1310)。また、取得部113は、更新したマルチキャストグループのマルチキャストアドレスをアドレステーブル145から取得する。
次に、通知メッセージ処理部103は、取得した鍵情報を含むSIP NOTIFY REQUESTメッセージを生成する(ステップS1311)。
次に、送信部121は、生成したSIP NOTIFY REQUESTメッセージを、更新したマルチキャストグループのウォッチャーである端末200に送信する(ステップS1312)。なお、送信する端末200は、対応テーブル143を参照して取得する。
ただし、マルチキャストグループのウォッチャーが単に新規に追加されただけであり、また、後述するような、現在該当のマルチキャストグループで使用している鍵を更新しない場合、新しく該当のマルチキャストグループに加わった端末(これは通常、上述のPUBLISH REQUESTを送信した端末である)に対してのみ、NOTIFY REQUESTを送信し、該当のマルチキャストグループを構成するその他の端末には送信しないことも可能である。
ステップS1313からステップS1317までの、SIP NOTIFY REQUESTメッセージ送受信処理、SIP NOTIFY RESPONSEメッセージ送受信処理は、図10のステップS1012からステップS1016までと同様の処理なのでその説明を省略する。
また、ステップS1318からステップS1321は、プレゼンス情報を通知する必要がある他の端末200上での処理を表し、ステップS1313からステップS1316と同様の処理なのでその説明を省略する。
なお、このSIP NOTIFY REQUESTメッセージ送信処理は、SIP PUBLISH RESPONSEメッセージの処理の直後に行う必要はない。例えば、その他のプレゼンティティの情報、マルチキャストグループ情報、またはグループ定義情報等が更新され、それに応じてSIP NOTIFY REQUESTメッセージを送信するときに同時に行うように構成してもよい。また、複数のSIP NOTIFY REQUESTメッセージを合わせて1つのSIP NOTIFY REQUESTメッセージとして送信するように構成してもよい。
これにより、鍵交換のためのメッセージ送信とプレゼンス情報通知のためのメッセージ送信を統合することができるため、システム構成を単純化し、ネットワークトラフィックを削減することができる。
さらに、ウォッチャーリストに含まれる各端末200に対し、同時のタイミングでメッセージ送信を行う必要はない。また、SIP NOTIFYメッセージ交換は、マルチキャストグループ情報を新規に通知する必要のある端末200との間のみで行うように構成してもよい。
以上の処理により、プレゼンス情報の更新が行われた場合にも、必要な端末200に鍵情報を事前に配布することが可能となる。
次に、プレゼンスサーバ100で鍵情報の更新が行われた場合の鍵交換処理のシーケンスについて説明する。図14は、この場合の鍵交換処理の全体の流れを示すシーケンス図である。
まず、プレゼンスサーバ100の生成部114は、任意のタイミング、例えば、周期的に、または、マルチキャストグループのメンバが変更された場合に、暗号鍵を新たに生成する(ステップS1401)。なお、上述のように、プレゼンスサーバ100自身が乱数を発生させて鍵を新たに生成してもよいし、端末200が生成し、任意のメッセージでプレゼンスサーバ100に通知するように構成してもよい。
次に、登録部115は、生成した暗号鍵を対応するマルチキャストグループの鍵情報として鍵情報テーブル146に登録する(ステップS1402)。
次に、通知メッセージ処理部103は、登録した鍵情報とマルチキャストアドレスを含むSIP NOTIFY REQUESTメッセージを生成する(ステップS1403)。
次に、送信部121は、生成したSIP NOTIFY REQUESTメッセージを、鍵情報を更新したマルチキャストグループのウォッチャーである端末200に送信する(ステップS1404)。なお、送信する端末200は、対応テーブル143を参照して取得する。
ステップS1405からステップS1413までの、SIP NOTIFY REQUESTメッセージ送受信処理、SIP NOTIFY RESPONSEメッセージ送受信処理は、図13のステップS1313からステップS1321までと同様の処理なのでその説明を省略する。
以上の処理により、プレゼンスサーバ100で鍵情報の更新が行われた場合にも、必要な端末200に鍵情報を適切に配布することが可能となる。
次に、プレゼンスサーバ100でマルチキャストグループの新規グループ定義、または、マルチキャストグループ定義の更新が行われた場合の鍵交換処理のシーケンスについて説明する。図15は、この場合の鍵交換処理の全体の流れを示すシーケンス図である。
まず、プレゼンスサーバ100の受付部111が、ユーザによるグループ定義情報の入力を受付ける(ステップS1501)。登録部115は、受付けたグループ定義情報を定義情報テーブル144に登録する(ステップS1502)。これにより、ユーザは、マルチキャストグループの定義の新規作成や更新を行うことができる。
プレゼンス情報の条件により定義されたグループ定義情報の場合は、通知メッセージ処理部103は、プレゼンス情報テーブル142を参照して条件を満たすプレゼンス情報を有する端末200の情報を取得することにより、対応テーブル143の対応するマルチキャストグループを再構成する(ステップS1503)。
なお、端末200のURIのリストによって定義されたグループ定義情報の場合は、当該リストがそのまま対応テーブル143のウォッチャーリストに反映される。また、対応テーブル143を更新した際、鍵情報を生成部114により生成し、生成した鍵情報により鍵情報テーブル146を更新するように構成してもよい。
次に、取得部113は、グループ定義情報を追加または更新したマルチキャストグループに対応する鍵情報を鍵情報テーブル146から取得する(ステップS1504)。また、取得部113は、グループ定義情報を追加または更新したマルチキャストグループのマルチキャストアドレスをアドレステーブル145から取得する。
次に、通知メッセージ処理部103は、取得した鍵情報を含むSIP NOTIFY REQUESTメッセージを生成する(ステップS1505)。
次に、送信部121は、生成したSIP NOTIFY REQUESTメッセージを、グループ定義情報を追加または更新したマルチキャストグループのウォッチャーである端末200に送信する(ステップS1506)。なお、送信する端末200は、対応テーブル143を参照して取得する。
ステップS1507からステップS1515までの、SIP NOTIFY REQUESTメッセージ送受信処理、SIP NOTIFY RESPONSEメッセージ送受信処理は、図13のステップS1313からステップS1321までと同様の処理なのでその説明を省略する。
以上の処理により、プレゼンスサーバ100で新規グループの追加またはグループ定義の更新が行われた場合にも、必要な端末200に鍵情報を適切に配布することが可能となる。
なお、以上で説明したすべての鍵交換シーケンスは、あるマルチキャストグループに対して、常に1種類の鍵の鍵交換しか行わない。よって、あるマルチキャストグループに対して、異なる鍵の鍵交換を同時に実行することはない。
次に、実際にセキュアなIPマルチキャスト通信が行われる際のデータ通信処理について説明する。まず、データ通信処理時の暗号化鍵の選択方法について説明する。
上述のシーケンスにより、任意のマルチキャストグループに含まれる端末200は、対応するアドレス情報および鍵情報を、例えばMIKEYなどのSIPメッセージ上で実行された鍵交換プロトコルにより取得する。
端末200は、マルチキャストグループごとに、少なくとも2つのアドレス情報および鍵情報を保持することができる。ここではその2つのアドレス情報および鍵情報を、それぞれ最新有効鍵情報と、有効鍵情報と呼ぶ。
最新有効鍵情報とは、上述の鍵交換シーケンスで取得したアドレス情報および鍵情報をいう。すなわち、端末200は、取得したアドレス情報および鍵情報を、対応するマルチキャストグループの最新有効鍵情報として保持する。
有効鍵情報とは、最新有効鍵情報の前に取得した鍵情報をいう。したがって、端末200は、鍵交換プロトコルなどにより新たに対応するマルチキャストグループのアドレス情報および鍵情報を取得した場合、現在保持している最新有効鍵情報を有効鍵情報にコピーし、新たに取得した鍵情報を最新有効鍵情報に保持する。
なお、有効鍵情報を保持していない場合、すなわち、最初にアドレス情報および鍵情報を鍵交換シーケンスで取得した場合は、最新有効鍵情報を有効鍵情報にコピーする。以後、端末200は、対応するマルチキャストグループに対し、常に、少なくとも最新有効鍵情報と有効鍵情報の2つを保持し、マルチキャスト通信用に設定する。
IPマルチキャストのためのネットワーク設定は、各端末200がIGMP(Internet Group Management Protocol)などのプロトコルを利用した従来と同様の方法によって行う。
このように、マルチキャストグループに含まれる端末200は、最新有効鍵情報と、有効鍵情報の少なくとも2つの暗号化鍵とそのIDを保持している。
暗号化されたマルチキャストデータを受信した場合、端末200は、受信部222で暗号化されたデータを含むパケットから、暗号化に使用されている鍵のIDを識別し、そのIDに対応する鍵が、最新有効鍵情報に含まれる暗号鍵であるか有効鍵情報に含まれる鍵であるかを判断し、該当する鍵を使ってデータを復号する。このような機能は、例えば、SRTPなどで実現可能である。
一方、マルチキャストデータを暗号化して送信する端末200は、暗号化に使用する鍵を選択する際、常に、対応するマルチキャストグループの有効鍵情報の暗号鍵を選択する。本実施の形態におけるプレゼンスサーバ100を含んだ通信システムは、対応するマルチキャストグループに関して、ある鍵に関する鍵交換が終了する前に、別の鍵に関する鍵交換を開始することはないことに注意が必要である。よって、常に有効鍵情報の暗号鍵を選択してこれによりマルチキャストデータを暗号化して送信すれば、マルチキャストグループを構成する端末200のすべてが、既に最新有効鍵情報または有効鍵情報として保持している鍵によって、マルチキャストデータを受信し復号化することができる。
この他、使用する鍵情報の決定方法としては、現在使用可能な暗号鍵のIDの情報をSIP NOTIFYメッセージなどを用いてプレゼンスサーバ100から通知を受け、通知された情報によりデータ送信に使用する方法も適用可能である。
次に、マルチキャストデータ通信の開始・終了に関する処理について説明する。通常のマルチキャストデータ通信のように、送信端末が、暗号化したメディアデータをマルチキャストアドレスに宛てて単純に送信するだけの構成も可能である。一方、端末200を、常にメディアデータ受信可能な状態に設定しておくことが難しく、マルチキャストデータ通信が開始される際にメディア受信状態を開始し、マルチキャストデータ通信が終了する際に、メディア受信状態を解除することが必要となる場合がある。
以下では、このような場合に、セキュアなマルチキャストデータ通信を開始するシーケンスについて説明する。図16は、第1の実施の形態におけるデータ通信開始処理の全体の流れを示すシーケンス図である。
まず、メディアデータ送信を開始する端末200(以下、送信端末200という。)の送信部221は、送信を開始するマルチキャストグループの情報を含んだSIP PUBLISH REQUESTメッセージを送信することにより、プレゼンスサーバ100に対してメディアデータ送信を開始することを通知する(ステップS1601)。なお、このメッセージは、発行メッセージ処理部201により生成する。
次に、プレゼンスサーバ100の受信部122は、SIP PUBLISH REQUESTメッセージを受信する(ステップS1602)。次に、認証部112が、当該メッセージに含まれる認証情報を用いて送信端末200の認証を行う(ステップS1603)。ここでは、送信端末200が送信対象となるマルチキャストグループに対して通信可能か否かの認証を行う。なお、認証処理を行わないように構成してもよい。また、外部の認証サーバ等を利用するように構成してもよい。
送信端末200が認証された場合は、通知メッセージ処理部103は、メディアデータ送信が開始されることを通知するため、対応するマルチキャストアドレス情報を含むSIP NOTIFY REQUESTメッセージを生成する(ステップS1604)。
この際、通知メッセージ処理部103は、当該マルチキャストグループのマルチキャストアドレスをアドレステーブル145から取得する。また、通知メッセージ処理部103は、受信したメッセージに含まれるマルチキャストグループの情報を参照し、当該マルチキャストグループを構成する端末200(以下、受信端末200という。)を対応テーブル143から取得する。
次に、通知メッセージ処理部103は、生成したSIP NOTIFY REQUESTメッセージを受信端末200に送信する(ステップS1605)。
受信端末200の受信部222は、SIP NOTIFY REQUESTメッセージを受信し(ステップS1606)、受信したメッセージから、送信が開始されるメディアのマルチキャストグループ情報を取得する。
次に、通知メッセージ処理部203が、メディアデータ受信状態を開始する(ステップS1607)。具体的には、通知メッセージ処理部203は、取得したマルチキャストグループ情報より、送信が開始されるメディアのマルチキャストグループを特定し、該当のマルチキャストグループ宛のデータの受信準備を行うよう、受信部222に通知する。この際、取得したマルチキャストグループ情報に含まれるマルチキャストアドレスからのメディアデータを、取得したマルチキャストグループ情報に含まれるマルチキャストアドレスや鍵のIDなどの鍵情報を用いて受信可能な状態に設定することも可能である。
次に、通知メッセージ処理部203は、SIP NOTIFY RESPONSEメッセージを生成する(ステップS1608)。生成したメッセージは、送信部221がプレゼンスサーバ100に対して送信する(ステップS1609)。
次に、プレゼンスサーバ100の受信部122は、SIP NOTIFY RESPONSEメッセージを受信する(ステップS1610)。
続いて、プレゼンスサーバ100の通知メッセージ処理部103が、SIP PUBLISH RESPONSEメッセージを生成し(ステップS1611)、送信部121が、生成したメッセージを送信端末200に送信する(ステップS1612)。
SIP PUBLISH RESPONSEメッセージの送信は、マルチキャストグループのすべての受信端末200からのSIP NOTIFY RESPONSEメッセージの受信を行った後に行う。なお、送信端末200からSIP PUBLISH REQUESTメッセージを受信した直後に行ってもよい。
また、この際、プレゼンスサーバ100は、複数の送信端末200によって同一のマルチキャストグループに対してデータ送信が行われないようにするため、現在メディアデータを送信している送信端末200の情報を、プレゼンティティ情報テーブル141などにて保持するように構成してもよい。
すなわち、ある送信端末200に対してマルチキャストグループへのデータ送信を認可している場合は、その他の送信端末200に対して、当該マルチキャストグループへのデータ送信を認可しないように構成してもよい。これにより、プレゼンスサーバ100は、送信端末200に対して、マルチキャストグループへのデータ送信を排他的に許可することが可能となる。
次に、送信端末200の受信部222は、SIP PUBLISH RESPONSEメッセージを受信する(ステップS1613)。このメッセージを受信した後、送信端末200は、実際のメディアデータの送信を行うことができる。
すなわち、送信端末200の送信部221が、メディアデータの送信を行い(ステップS1614)、受信端末200の受信部222が、当該メディアデータの受信を行う(ステップS1615)。
以上のような処理により、常にメディアデータ受信可能な状態に設定することなく、適切にメディアデータの送信処理を開始することが可能となる。
次に、このようにして開始したセキュアなマルチキャストデータ通信を終了するシーケンスについて説明する。図17は、第1の実施の形態におけるデータ通信終了処理の全体の流れを示すシーケンス図である。
送信端末200は、メディアデータ送信が終了すると、メディアデータ送信が終了したことを通知するためのSIP PUBLISH REQUESTメッセージを、プレゼンスサーバ100に対して送信する(ステップS1701)。
次に、プレゼンスサーバ100の受信部122は、SIP PUBLISH REQUESTメッセージを受信する(ステップS1702)。なお、排他制御のためプレゼンティティ情報テーブル141などに現在メディアデータを送信している送信端末200の情報を保存している場合は、当該情報を削除するように構成してもよい。
次に、通知メッセージ処理部103は、メディアデータ送信が終了されることを通知するため、対応するマルチキャストアドレス情報を含むSIP NOTIFY REQUESTメッセージを生成する(ステップS1703)。
この際、通知メッセージ処理部103は、当該マルチキャストグループのマルチキャストアドレスをアドレステーブル145から取得する。また、通知メッセージ処理部103は、受信したメッセージに含まれるマルチキャストグループの情報を参照し、当該マルチキャストグループを構成する受信端末200を対応テーブル143から取得する。
次に、通知メッセージ処理部103は、生成したSIP NOTIFY REQUESTメッセージを受信端末200に送信する(ステップS1704)。
受信端末200の受信部222は、SIP NOTIFY REQUESTメッセージを受信し(ステップS1705)、受信したメッセージから、送信が終了するメディアのマルチキャストグループ情報を取得する。
次に、通知メッセージ処理部203が、メディアデータ受信状態を解除する(ステップS1706)。具体的には、通知メッセージ処理部203は、取得したマルチキャストグループ情報に含まれるマルチキャストアドレスからのメディアデータを受信できない状態に設定する。
ステップS1707からステップS1712までの、SIP NOTIFY RESPONSEメッセージ送受信処理、SIP PUBLISH RESPONSEメッセージ送受信処理は、図16のステップS1608からステップS1613までと同様の処理なのでその説明を省略する。
以上のような処理により、適切にメディアデータの送信処理の終了を通知することができるため、常にメディアデータ受信可能な状態に設定する必要がなくなる。
次に、従来技術と比較した本実施の形態の鍵配布処理シーケンスの相違について説明する。図18は、従来技術におけるプレゼンスサーバを含む通信システムの構成を示す概念図である。
同図に示すように、従来の通信システムは、本実施の形態と同様にProxy1801、端末1802、およびプレゼンスサーバ1803を含むが、従来の通信システムでは、Proxy1801を介して各端末相互で鍵交換を行う必要がある。
図19は、従来の通信システムによる鍵交換処理のシーケンスの概要を示した説明図である。
まず、セキュアなIPマルチキャスト通信を所望する端末1802は、Proxy1801に対してINVITE−Requestを送信する(ステップS1901)。IPマルチキャストグループのメンバシップ情報は、端末1802が指定してもよいし、Proxy1801で保持してもよい。
INVITE−Requestを受信したProxy1801は、メッセージをフォークさせ、IPマルチキャストグループを構成する全メンバとなる端末に対してINVITE−Requestをコピーして転送する(ステップS1902)。
その後、IPマルチキャスト通信を所望する端末1802と、IPマルチキャストグループを構成するメンバ端末は、オファーアンサーモデルに従い、INVITE−Response(200OK)(ステップS1903、ステップS1904)、ACKのメッセージ(ステップS1905)を交換する。
これにより、IPマルチキャスト通信を所望する端末1802は、全グループメンバ端末との間でマルチキャストメッセージを暗号化するための暗号化鍵を交換する。これらの鍵交換がすべて終わった後、セキュアなIPマルチキャスト通信が実行される(ステップS1906)。
このように、従来の方法では、すべてのメンバ間での鍵交換が完了してからIPマルチキャスト通信を開始するため、通信開始までの時間的コストが過大となる場合があった。
なお、従来技術におけるプレゼンスサーバ1803は、端末に対して各種プレゼンス情報の通知を行うのみであり、SIPベースシステムにおけるIPマルチキャスト通信のための鍵交換とは無関係である。
図20は、本実施の形態における通信システムによる鍵交換処理のシーケンスの概要を示した説明図である。
詳細は上述したとおりであるので省略するが、同図に示すように、本実施の形態では、Proxyではなく、プレゼンスサーバ100により鍵交換処理を行うことができる。また、端末200が起動したときに、SIP SUBSCRIBE REQUESTメッセージ、SIP NOTIFY REQUESTメッセージ等を用いて、事前に登録されている鍵情報をプレゼンスサーバ100から取得できるため、他の端末200と相互に鍵情報を交換する必要がない。
このように、第1の実施の形態にかかるサーバ装置は、プレゼンスサーバ機能を利用して、事前にIPマルチキャストのための鍵交換を行うことができる。さらに、鍵交換プロトコルのためのメッセージ送信とプレゼンス情報送信のためのメッセージ送信を統合することができるため、SIPベースのシステムでセキュアなIPマルチキャスト通信を開始するまでにかかる時間的コストを削減することができる。
(第2の実施の形態)
従来、セキュアなIPマルチキャスト通信を行うグループに対して、グループメンバでない端末がデータ送信を行うことは許されておらず、そのためには、一時的に対象となるIPマルチキャスト通信を行うグループに参加することが必要であった。
第2の実施の形態にかかるサーバ装置は、セキュアなIPマルチキャストグループに対するデータ送信を所望する端末に対して、一時的に利用可能な暗号化鍵を送信するものである。これにより、端末がマルチキャストグループへ参加する処理などの特別な処理を必要とすることなく、セキュアなIPマルチキャスト通信を実現できる。
図21は、第2の実施の形態にかかるサーバ装置であるプレゼンスサーバ2300を含む通信システムの構成を示す概念図である。本通信システムでは、マルチキャストグループに属さないが当該グループに対してメディアデータの送信を所望する端末である送信端末2100zを含む点が、第1の実施の形態にかかる通信システムを表す図1と異なっている。
なお、受信端末2100a〜2100hと送信端末2100zは、同一のマルチキャストグループに属するか否かが異なる。なお、以下では、単に受信端末2100、送信端末2100という。
図22は、第2の実施の形態にかかる受信端末2100および送信端末2100の構成を示すブロック図である。同図に示すように、受信端末2100および送信端末2100は、音声入出力部211と、データ入出力部212と、発行メッセージ処理部201と、購読メッセージ処理部202と、通知メッセージ処理部203と、セッション制御メッセージ処理部2204と、送信部221と、受信部222とを備えている。
第2の実施の形態では、セッション制御メッセージ処理部2204を追加したことが第1の実施の形態と異なっている。その他の構成および機能は、第1の実施の形態にかかる端末200の構成を表すブロック図である図2と同様であるので、同一符号を付し、ここでの説明は省略する。
セッション制御メッセージ処理部2204は、プレゼンスサーバ2300から受信したセッション制御要求メッセージ(後述)に関する処理を行うものである。具体的には、セッション制御メッセージ処理部2204は、セッション制御要求メッセージに含まれる鍵情報を取得して設定する処理や、セッション制御要求メッセージに対する応答であるACKメッセージの生成を行う。
図23は、第2の実施の形態にかかるサーバ装置であるプレゼンスサーバ2300の構成を示すブロック図である。同図に示すように、プレゼンスサーバ2300は、記憶部140と、受付部111と、認証部112と、取得部113と、生成部114と、登録部115と、発行メッセージ処理部101と、購読メッセージ処理部102と、通知メッセージ処理部103と、セッション制御メッセージ処理部2304と、送信部121と、受信部122とを備えている。
第2の実施の形態では、セッション制御メッセージ処理部2304を追加したことが第1の実施の形態と異なっている。その他の構成および機能は、第1の実施の形態にかかるプレゼンスサーバ100の構成を表すブロック図である図3と同様であるので、同一符号を付し、ここでの説明は省略する。
セッション制御メッセージ処理部2304は、プレゼンスサーバ2300が管理するマルチキャストグループに対してマルチキャスト通信の開始を要求するセッション制御要求メッセージを処理するものである。セッション制御メッセージ処理部2304は、セッション制御要求メッセージとして、例えば、SIP INVITEメッセージを用いることができる。なお、セッション制御要求メッセージのメッセージ形式はこれに限られるものではなく、マルチキャスト通信の開始を要求できるものであればあらゆる形式のメッセージを用いることができる。
次に、このように構成された第2の実施の形態にかかるサーバ装置2300による鍵交換処理について説明する。図24は、第2の実施の形態における鍵交換処理の全体の流れを示すフローチャートである。
まず、送信端末2100の送信部221は、通信を行うマルチキャストグループを識別するURIを含むSIP INVITE REQUESTメッセージをプレゼンスサーバ2300に対して送信する(ステップS2401)。なお、SIP INVITE REQUESTメッセージは、セッション制御メッセージ処理部2204が生成する。
次に、プレゼンスサーバ2300の受信部122は、SIP INVITE REQUESTメッセージを受信する(ステップS2402)。
次に、認証部112が、送信端末2100によるマルチキャストグループに対するデータ送信の認可を確認する(ステップS2403)。この際、プレゼンスサーバ2300は、外部の認証サーバなどを利用するように構成してもよい。
認可された場合、取得部113は、SIP INVITE REQUESTメッセージに含まれるマルチキャストグループのURIを用いて、当該マルチキャストグループに対応する鍵情報を鍵情報テーブル146から取得する(ステップS2404)。また、取得部113は、当該URIに対応するマルチキャストアドレスをアドレステーブル145から取得する。
次に、セッション制御メッセージ処理部2304は、取得した鍵情報を含むSIP INVITE RESPONSEメッセージを生成する(ステップS2405)。具体的には、セッション制御メッセージ処理部2304は、マルチキャストアドレス情報と、鍵情報とを含むマルチキャストグループ情報を含むSIP INVITE RESPONSEメッセージを生成する。マルチキャストアドレス情報はアドレステーブル145から取得する。
このとき、セッション制御メッセージ処理部2304は、鍵情報を含むマルチキャストグループ情報を暗号化するように構成してもよい。例えば、セッション制御メッセージ処理部2304は、MIKEYにしたがって暗号化した鍵情報を含むメッセージを生成するように構成することができる。
次に、送信部121は、生成したSIP INVITE RESPONSEメッセージを送信端末2100に送信する(ステップS2406)。
なお、この際、プレゼンスサーバ2300は、複数の送信端末200によって同一のマルチキャストグループに対してデータ送信が行われないようにするため、現在鍵情報を保持している送信端末2100の情報を、プレゼンティティ情報テーブル141などにて保持するように構成してもよい。
すなわち、ある送信端末2100に対してマルチキャストグループへのデータ送信を認可している場合は、その他の送信端末2100に対して、当該マルチキャストグループへのデータ送信を認可しないように構成してもよい。これにより、プレゼンスサーバ2300は、送信端末2100に対して、マルチキャストグループへのデータ送信を排他的に許可することが可能となる。
次に、送信端末2100の受信部222は、SIP INVITE RESPONSEメッセージを受信する(ステップS2407)。次に、送信端末2100のセッション制御メッセージ処理部2204は、受信したSIP INVITE RESPONSEメッセージに含まれる鍵情報を設定する(ステップS2408)。
次に、セッション制御メッセージ処理部2204は、ACKメッセージを生成し(ステップS2409)、送信部221が、生成したACKメッセージをプレゼンスサーバ2300に送信する(ステップS2410)。次に、プレゼンスサーバ2300の受信部122は、ACKメッセージを受信する(ステップS2411)。
なお、セッション制御メッセージ処理部2204は、MIKEYなどの鍵交換に使用しているプロトコルに規定されるデータを含むACKメッセージを生成するように構成してもよい。例えば、送信端末2100とプレゼンスサーバ2300の間で相互認証を行うための、送信端末2100のID情報などが含まれるかもしれない。
また、この際、プレゼンスサーバ2300は、通知メッセージ処理部103によって、SIP NOTIFY REQUESTメッセージを受信端末2100に送信し、マルチキャストデータ送信が開始されること、またはマルチキャストデータ送信に関する送信端末2100の情報およびタイミングに関する情報などを通知してもよい(ステップS2412、ステップS2413)。
これに対応し、受信端末2100は、通知メッセージ処理部203により、受信したメッセージに含まれる情報から開始されるマルチキャストのデータ通信のタイミングなどの情報を取得し、メディア受信状態を開始するように構成してもよい(ステップS2414、ステップS2415)。
なお、これらの処理を表すステップS2412からステップS2418は、第1の実施の形態のおける図16のステップS1604からステップS1610までと同様の処理であるため、詳細な説明は省略する。
この後、送信端末2100はメディアデータの送信が可能となる。すなわち、送信部221が、メディアデータを送信し(ステップS2419)、受信端末2100の受信部222が、送信されたメディアデータを受信する(ステップS2420)。受信端末2100では、対応する暗号鍵を用いてメディアデータを復号して後続する処理を実行する。
次に、図16の処理で鍵を交換後に開始したセキュアなマルチキャストデータ通信を終了するシーケンスについて説明する。図25は、第2の実施の形態におけるデータ通信終了処理の全体の流れを示すシーケンス図である。
まず、送信端末2100は、メディアデータ送信が終了すると、メディアデータ送信が終了したことを通知するためのBYE REQUESTメッセージを、プレゼンスサーバ2300に対して送信する(ステップS2501)。なお、BYE REQUESTメッセージは、セッション制御メッセージ処理部2204によって生成される。
次に、プレゼンスサーバ2300の受信部122は、BYE REQUESTメッセージを受信する(ステップS2502)。なお、排他制御のためプレゼンティティ情報テーブル141などに現在鍵情報を保持している送信端末2100の情報を保存している場合は、当該情報を削除するように構成してもよい。
次に、セッション制御メッセージ処理部2304は、SIP BY RESPONSEメッセージを生成し(ステップS2503)、送信部121が、生成したメッセージを送信端末2100に送信する(ステップS2504)。また、送信端末2100の受信部222は、SIP BY RESPONSEメッセージを受信する(ステップS2505)。
プレゼンスサーバ2300は、対応するマルチキャストグループの鍵を新規作成あるいは更新し、以後任意のタイミングにて、対応するマルチキャストグループのリストに含まれる受信端末2100に対して鍵交換を行う。
すなわち、プレゼンスサーバ2300の通知メッセージ処理部103は、受信端末2100に対してプレゼンス情報などを通知するためのSIP NOTIFY REQUESTメッセージを生成する(ステップS2506)。
この際、通知メッセージ処理部103は、鍵情報を含むマルチキャストグループ情報を含むSIP NOTIFY REQUESTメッセージを生成する。なお、通知メッセージ処理部103は、マルチキャストグループ情報を暗号化してもよいし、マルチキャストデータ通信が終了したことを示す情報をメッセージに含めてもよい。
次に、送信部121は、生成されたSIP NOTIFY REQUESTメッセージを受信端末2100に送信する(ステップS2507)。
なお、このSIP NOTIFY REQUESTメッセージ送信処理は、BYE RESPONSEメッセージの処理の直後に行う必要はない。例えば、その他のプレゼンティティの情報、マルチキャストグループ情報、またはグループ定義情報等が更新され、それに応じてSIP NOTIFY REQUESTメッセージを送信するときに同時に行うように構成してもよい。また、複数のSIP NOTIFY REQUESTメッセージを合わせて1つのSIP NOTIFY REQUESTメッセージとして送信するように構成してもよい。
受信端末2100の受信部222は、SIP NOTIFY REQUESTメッセージを受信する(ステップS2508)。次に、通知メッセージ処理部203は、受信したSIP NOTIFY REQUESTメッセージに含まれる鍵情報およびマルチキャストアドレス情報を設定する(ステップS2509)。
なお、受信したメッセージにマルチキャストデータ通信が終了したことを示す情報が含まれている場合は、メディア受信状態を解除するように構成してもよい。
次に、通知メッセージ処理部203は、SIP NOTIFY REQUESTメッセージに対する応答である、SIP NOTIFY RESPONSEメッセージを生成する(ステップS2510)。
続いて、送信部221は、生成したSIP NOTIFY RESPONSEメッセージをプレゼンスサーバ2300に送信する(ステップS2511)。プレゼンスサーバ2300の受信部122は、SIP NOTIFY RESPONSEメッセージを受信し(ステップS2512)、データ通信終了処理が完了する。
なお、ステップS2507からステップS2512までの処理は、通信を終了するマルチキャストグループに含まれるすべての受信端末2100との間で実行される。前述の通り、この処理は、すべての受信端末2100で同時のタイミングで行われる必要はない。
このように、第2の実施の形態にかかるサーバ装置では、マルチキャストグループに属さない端末からIPマルチキャスト通信の要求を受信した場合に、当該グループのIPマルチキャスト通信で用いる鍵情報を当該端末に対して返信することができる。これにより、端末がマルチキャストグループへ参加する処理などの特別な処理を必要とすることなく、セキュアなIPマルチキャスト通信を実現することができる。
なお、本発明は、上述した第1実施形態および第2実施形態に限定されるものではなく、以下に例示するような種々の変形が可能である。
(変形例)
上述した第1の実施の形態および第2の実施の形態では、プレゼンスサーバが鍵交換に必要な機能をすべて備えるように構成していたが、一部の機能を端末側で実行するように構成してもよい。
例えば、記憶部140に格納されているプレゼンティティ情報テーブル141、プレゼンス情報テーブル142、対応テーブル143、定義情報テーブル144、アドレステーブル145、および鍵情報テーブル146の一部またはすべてを保持する端末と、当該端末で保持するテーブルを保持しないプレゼンスサーバとを備えたシステム構成をとりうる。
この場合、端末が保持する情報に変化が起きた場合、端末がプレゼンスサーバに対して、例えばSIP PUBLISHメッセージなどにより情報を送受信することで変化を通知するように構成する。このように、所定のメッセージで必要な情報を送受信することにより、上述の実施の形態と同様の機能を実現することができる。
図25は、第1または第2の実施の形態にかかるサーバ装置のハードウェア構成を示す説明図である。
第1または第2の実施の形態にかかるサーバ装置は、CPU(Central Processing Unit)51などの制御装置と、ROM(Read Only Memory)52やRAM53などの記憶装置と、ネットワークに接続して通信を行う通信I/F54と、HDD(Hard Disk Drive)、CD(Compact Disc)ドライブ装置などの外部記憶装置と、ディスプレイ装置などの表示装置と、キーボードやマウスなどの入力装置と、各部を接続するバス61を備えており、通常のコンピュータを利用したハードウェア構成となっている。
第1または第2の実施の形態にかかるサーバ装置で実行される通信プログラムは、インストール可能な形式又は実行可能な形式のファイルでCD−ROM(Compact Disk Read Only Memory)、フレキシブルディスク(FD)、CD−R(Compact Disk Recordable)、DVD(Digital Versatile Disk)等のコンピュータで読み取り可能な記録媒体に記録されて提供される。
また、第1または第2の実施の形態にかかるサーバ装置で実行される通信プログラムを、インターネット等のネットワークに接続されたコンピュータ上に格納し、ネットワーク経由でダウンロードさせることにより提供するように構成してもよい。また、第1または第2の実施の形態にかかるサーバ装置で実行される通信プログラムをインターネット等のネットワーク経由で提供または配布するように構成してもよい。
また、第1または第2の実施の形態の通信プログラムを、ROM等に予め組み込んで提供するように構成してもよい。
第1または第2の実施の形態にかかるサーバ装置で実行される通信プログラムは、上述した各部(受付部、認証部、取得部、生成部、登録部、発行メッセージ処理部、購読メッセージ処理部、通知メッセージ処理部、送信部、受信部)を含むモジュール構成となっており、実際のハードウェアとしてはCPU51(プロセッサ)が上記記憶媒体から通信プログラムを読み出して実行することにより上記各部が主記憶装置上にロードされ、上述した各部が主記憶装置上に生成されるようになっている。
以上のように、本発明にかかるサーバ装置、端末装置、通信方法、通信プログラムおよび通信システムは、SIPベースのシステムでセキュアなIPマルチキャスト通信を行うサーバ装置、端末装置、通信方法、通信プログラムおよび通信システムに適している。
第1の実施の形態にかかる通信システムの構成を示す概念図である。 第1の実施の形態にかかる端末装置の構成を示すブロック図である。 第1の実施の形態にかかるサーバ装置の構成を示すブロック図である。 プレゼンティティ情報テーブルのデータ構造の一例を示す説明図である。 プレゼンス情報テーブルのデータ構造の一例を示す説明図である。 対応テーブルのデータ構造の一例を示す説明図である。 定義情報テーブルのデータ構造の一例を示す説明図である。 アドレステーブルのデータ構造の一例を示す説明図である。 鍵情報テーブルのデータ構造の一例を示す説明図である。 第1の実施の形態における鍵交換処理の全体の流れを示すシーケンス図である。 SIP NOTIFY REQUESTメッセージの形式の一例を示す説明図である。 SIP NOTIFY RESPONSEメッセージの形式の一例を示す説明図である。 鍵交換処理の全体の流れを示すシーケンス図である。 鍵交換処理の全体の流れを示すシーケンス図である。 鍵交換処理の全体の流れを示すシーケンス図である。 第1の実施の形態におけるデータ通信開始処理の全体の流れを示すシーケンス図である。 第1の実施の形態におけるデータ通信終了処理の全体の流れを示すシーケンス図である。 従来技術におけるプレゼンスサーバを含む通信システムの構成を示す概念図である。 従来の通信システムによる鍵交換処理のシーケンスの概要を示した説明図である。 本実施の形態における通信システムによる鍵交換処理のシーケンスの概要を示した説明図である。 第2の実施の形態にかかる通信システムの構成を示す概念図である。 第2の実施の形態にかかる端末の構成を示すブロック図である。 第2の実施の形態にかかるサーバ装置の構成を示すブロック図である。 第2の実施の形態における鍵交換処理の全体の流れを示すフローチャートである。 第2の実施の形態におけるデータ通信終了処理の全体の流れを示すシーケンス図である。 サーバ装置のハードウェア構成を示す説明図である。
符号の説明
51 CPU
52 ROM
53 RAM
54 通信I/F
61 バス
100 プレゼンスサーバ
101 発行メッセージ処理部
102 購読メッセージ処理部
103 通知メッセージ処理部
111 受付部
112 認証部
113 取得部
114 生成部
115 登録部
121 送信部
122 受信部
140 記憶部
141 プレゼンティティ情報テーブル
142 プレゼンス情報テーブル
143 対応テーブル
144 定義情報テーブル
145 アドレステーブル
146 鍵情報テーブル
200 端末
201 発行メッセージ処理部
202 購読メッセージ処理部
203 通知メッセージ処理部
211 音声入出力部
212 データ入出力部
221 送信部
222 受信部
300 Proxy
1801 Proxy
1802 端末
1803 プレゼンスサーバ
2100 受信端末
2100 送信端末
2300 セッション制御メッセージ処理部
2300 2300 プレゼンスサーバ
2304 セッション制御メッセージ処理部

Claims (18)

  1. 複数の端末装置の間のマルチキャスト通信で用いる暗号鍵を管理するサーバ装置であって、
    プレゼンス情報を記憶する第1の記憶手段と、
    前記複数の端末装置のそれぞれを識別するための端末識別子を、それぞれの端末装置が属するマルチキャストグループ内のマルチキャスト通信に用いる暗号鍵と対応付けて記憶する第2の記憶手段と、
    前記複数の端末装置のうちの第1の端末装置から、その第1の端末装置の端末識別子を含み、前記第1の記憶手段に記憶されたプレゼンス情報の購読を要求する購読要求メッセージを受信する受信手段と、
    受信した前記購読要求メッセージに含まれる前記第1の端末装置の端末識別子を用いて、前記第1の端末装置が属するマルチキャストグループ内のマルチキャスト通信に用いる暗号鍵を前記第2の記憶手段から取得する取得手段と、
    取得した暗号鍵を、購読要求のあったプレゼンス情報とともに前記第1の端末装置に送信する送信手段と
    を備えることを特徴とするサーバ装置。
  2. 前記第2の記憶手段は、前記暗号鍵とともに、前記マルチキャストグループ内のマルチキャスト通信に用いるマルチキャストアドレスも前記端末識別子と対応づけて記憶し、
    前記取得手段は、前記暗号鍵とともに、前記マルチキャストアドレスも前記第2の記憶手段から取得し、
    前記送信手段は、前記暗号鍵および購読要求のあったプレゼンス情報とともに、前記取得したマルチキャストアドレスも、前記第1の端末装置に送信する
    ことを特徴とする請求項1に記載のサーバ装置。
  3. 前記マルチキャストグループを識別するグループ識別子と、プレゼンス情報に関する予め定められた条件とを対応づけたグループ定義情報を記憶する第3の記憶手段をさらに備え、
    前記受信手段は、さらに、前記端末装置のプレゼンス情報を含む情報通知メッセージを前記端末装置から受信し、
    前記取得手段は、さらに、受信した前記情報通知メッセージに含まれるプレゼンス情報が満たす前記条件に対応する前記グループ識別子を取得し、取得した前記グループ識別子に対応する前記暗号鍵を前記第2の記憶手段から取得し、
    前記送信手段は、さらに、取得した前記暗号鍵を、前記情報通知メッセージを送信した前記端末装置に送信すること、もしくは、前記グループ識別子で識別されるマルチキャストグループに含まれる前記端末装置に送信すること、
    を特徴とする請求項1に記載のサーバ装置。
  4. 前記マルチキャストグループの前記暗号鍵を生成する生成手段と、
    生成した前記暗号鍵を前記第2の記憶手段に登録する登録手段と、をさらに備え、
    前記送信手段は、さらに前記登録手段が前記暗号鍵を登録した場合に、前記暗号鍵を登録した前記マルチキャストグループに含まれる前記端末装置に、登録した前記暗号鍵を送信すること、
    を特徴とする請求項1に記載のサーバ装置。
  5. 前記マルチキャストグループを識別するグループ識別子と、プレゼンス情報に関する予め定められた条件とを対応づけたグループ定義情報を記憶する第3の記憶手段をさらに備え、
    前記グループ定義情報の入力を受付ける受付手段と、
    受付けた前記グループ定義情報を前記第3の記憶手段に登録する登録手段と、
    前記取得手段は、さらに、前記登録手段が前記グループ定義情報を登録した場合に、登録した前記グループ定義情報の前記条件に対応する前記グループ識別子を取得し、取得した前記グループ識別子に対応する前記暗号鍵を前記第2の記憶手段から取得し、
    前記送信手段は、さらに、取得した前記暗号鍵を、登録した前記グループ定義情報の前記条件を満たすプレゼンス情報を有する前記端末装置に対して送信すること、
    を特徴とする請求項1に記載のサーバ装置。
  6. 前記受信手段は、さらに、前記グループ定義情報を含み、前記グループ定義情報の登録を要求する登録要求メッセージを受信し、
    前記登録手段は、受信した前記登録要求メッセージに含まれる前記グループ定義情報を前記第3の記憶手段に登録すること、
    を特徴とする請求項に記載のサーバ装置。
  7. 前記登録要求メッセージを送信した前記端末装置の認証を行う認証手段をさらに備え、
    前記登録手段は、前記端末装置が認証された場合に、受信した前記登録要求メッセージに含まれる前記グループ定義情報を前記第3の記憶手段に登録すること、
    を特徴とする請求項に記載のサーバ装置。
  8. 前記受信手段は、さらに、前記暗号鍵を前記端末装置から受信し、
    受信した前記暗号鍵を前記第2の記憶手段に登録する登録手段をさらに備えたこと、
    を特徴とする請求項1に記載のサーバ装置。
  9. 前記暗号鍵を送信した前記端末装置の認証を行う認証手段をさらに備え、
    前記登録手段は、前記端末装置が認証された場合に、受信した前記暗号鍵を前記第2の記憶手段に登録すること、
    を特徴とする請求項に記載のサーバ装置。
  10. 前記受信手段は、さらに、マルチキャスト通信の開始を通知する開始メッセージを前記端末装置から受信し、
    前記送信手段は、さらに、前記開始メッセージを受信した場合に、マルチキャスト通信の対象となる前記マルチキャストグループに含まれる前記端末装置に、マルチキャスト通信の開始を要求する開始要求メッセージを送信すること、
    を特徴とする請求項1に記載のサーバ装置。
  11. 前記受信手段は、さらに、マルチキャスト通信の終了を通知する終了メッセージを前記端末装置から受信し、
    前記送信手段は、さらに、前記終了メッセージを受信した場合に、マルチキャスト通信の対象となる前記マルチキャストグループに含まれる前記端末装置に、マルチキャスト通信の終了を要求する終了要求メッセージを送信すること、
    を特徴とする請求項10に記載のサーバ装置。
  12. 前記送信手段は、さらに、前記開始メッセージを送信した前記端末装置と異なる前記端末装置がマルチキャスト通信を行っていない場合に、前記開始メッセージを送信した前記端末装置に対してマルチキャスト通信を許可する許可メッセージを送信すること、
    を特徴とする請求項に記載のサーバ装置。
  13. 前記端末装置の認証を行う認証手段をさらに備え、
    前記受信手段は、さらに、前記マルチキャストグループに含まれない前記端末装置から、前記グループ識別子を含み、前記マルチキャストグループへのマルチキャスト通信を要求する通信要求メッセージを受信し、
    前記認証手段は、前記通信要求メッセージを送信した前記端末装置を認証し、
    前記取得手段は、さらに、前記端末装置が認証された場合に、前記通信要求メッセージに含まれる前記グループ識別子に対応する前記暗号鍵を前記第2の記憶手段から取得し、
    前記送信手段は、さらに、取得した前記暗号鍵を、前記通信要求メッセージを送信した前記端末装置に送信すること、
    を特徴とする請求項1に記載のサーバ装置。
  14. 前記送信手段は、さらに、前記通信要求メッセージを送信した前記端末装置と異なる前記端末装置がマルチキャスト通信を行っていない場合に、前記通信要求メッセージを送信した前記端末装置に対してマルチキャスト通信を許可する許可メッセージを送信すること、
    を特徴とする請求項13に記載のサーバ装置。
  15. プレゼンス情報を管理するサーバ装置とネットワークを介して接続された端末装置であって、
    プレゼンス情報を提供するプレゼンティティであるマルチキャストグループのプレゼンス情報の購読を要求する購読要求メッセージを前記サーバ装置に送信する送信手段と、
    前記マルチキャストグループがマルチキャスト通信に用いる暗号鍵を、購読を要求したプレゼンス情報とともに前記サーバ装置から受信する受信手段と、
    を備えたことを特徴とする端末装置。
  16. 複数の端末装置の間のマルチキャスト通信で用いる暗号鍵を管理するサーバ装置における通信方法であって、
    前記複数の端末装置のうちの第1の端末装置から、その第1の端末装置の端末識別子を含み、プレゼンス情報を記憶する第1の記憶手段に記憶されたプレゼンス情報の購読を要求する購読要求メッセージを受信する受信ステップと、
    取得手段によって、受信した前記購読要求メッセージに含まれる前記第1の端末装置の端末識別子を用いて、前記複数の端末装置のそれぞれを識別するための端末識別子をそれぞれの端末装置が属するマルチキャストグループ内のマルチキャスト通信に用いる暗号鍵と対応付けて記憶する第2の記憶手段から、前記第1の端末装置が属するマルチキャストグループ内のマルチキャスト通信に用いる暗号鍵を取得する取得ステップと、
    取得した暗号鍵を、購読要求のあったプレゼンス情報とともに前記第1の端末装置に送信する送信ステップと
    を備えたことを特徴とする通信方法。
  17. 複数の端末装置の間のマルチキャスト通信で用いる暗号鍵を管理するサーバ装置に実行させるための通信プログラムであって、
    前記複数の端末装置のうちの第1の端末装置から、その第1の端末装置の端末識別子を含み、プレゼンス情報を記憶する第1の記憶手段に記憶されたプレゼンス情報の購読を要求する購読要求メッセージを受信する受信手順と、
    受信した前記購読要求メッセージに含まれる前記第1の端末装置の端末識別子を用いて、前記複数の端末装置のそれぞれを識別するための端末識別子をそれぞれの端末装置が属するマルチキャストグループ内のマルチキャスト通信に用いる暗号鍵と対応付けて記憶する第2の記憶手段から、前記第1の端末装置が属するマルチキャストグループ内のマルチキャスト通信に用いる暗号鍵を取得する取得手順と、
    取得した暗号鍵を、購読要求のあったプレゼンス情報とともに前記第1の端末装置に送信する送信手順と
    前記サーバ装置に実行させるための通信プログラム。
  18. 複数の端末装置の間のマルチキャスト通信で用いる暗号鍵を管理するサーバ装置と、前記複数の端末装置と、をネットワークで接続した通信システムであって、
    前記サーバ装置は、
    プレゼンス情報を記憶する第1の記憶手段と、
    前記複数の端末装置のそれぞれを識別するための端末識別子を、それぞれの端末装置が属するマルチキャストグループ内のマルチキャスト通信に用いる暗号鍵と対応付けて記憶する第2の記憶手段と、
    前記複数の端末装置のうちの第1の端末装置から、その第1の端末装置の端末識別子を含み、前記第1の記憶手段に記憶されたプレゼンス情報の購読を要求する購読要求メッセージを受信する受信手段と、
    受信した前記購読要求メッセージに含まれる前記第1の端末装置の端末識別子を用いて、前記第1の端末装置が属するマルチキャストグループ内のマルチキャスト通信に用いる暗号鍵を前記第2の記憶手段から取得する取得手段と、
    取得した暗号鍵を、購読要求のあったプレゼンス情報とともに前記第1の端末装置に送信する送信手段と、を備え、
    前記端末装置は、
    前記購読要求メッセージを前記サーバ装置に送信する第2送信手段と、
    前記暗号鍵、購読を要求したプレゼンス情報とともに前記サーバ装置から受信する第2受信手段と、を備えたこと、
    を特徴とする通信システム。
JP2006203628A 2006-07-26 2006-07-26 サーバ装置、端末装置、通信方法、通信プログラムおよび通信システム Expired - Fee Related JP4296191B2 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2006203628A JP4296191B2 (ja) 2006-07-26 2006-07-26 サーバ装置、端末装置、通信方法、通信プログラムおよび通信システム
US11/705,495 US8140844B2 (en) 2006-07-26 2007-02-13 Server apparatus, terminal device, and method for performing IP multicast communication

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2006203628A JP4296191B2 (ja) 2006-07-26 2006-07-26 サーバ装置、端末装置、通信方法、通信プログラムおよび通信システム

Publications (2)

Publication Number Publication Date
JP2008034960A JP2008034960A (ja) 2008-02-14
JP4296191B2 true JP4296191B2 (ja) 2009-07-15

Family

ID=38987791

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2006203628A Expired - Fee Related JP4296191B2 (ja) 2006-07-26 2006-07-26 サーバ装置、端末装置、通信方法、通信プログラムおよび通信システム

Country Status (2)

Country Link
US (1) US8140844B2 (ja)
JP (1) JP4296191B2 (ja)

Families Citing this family (29)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070201459A1 (en) * 2006-02-27 2007-08-30 Cisco Technology, Inc. System and method for providing status notification for conventional telephony devices in a session initiation protocol environment
US8374086B2 (en) * 2007-06-06 2013-02-12 Sony Computer Entertainment Inc. Adaptive DHT node relay policies
KR20080108048A (ko) * 2007-06-08 2008-12-11 삼성전자주식회사 컨텐츠 레벨 리액티브 권한부여를 위한 방법 및 시스템
JP2009232044A (ja) * 2008-03-21 2009-10-08 Toshiba Corp 通信の中継先を決定する通信システム、中継先の情報を通知する装置、方法、プログラム、およびip電話端末
JP4445559B2 (ja) * 2008-05-30 2010-04-07 株式会社東芝 プレゼンスサービス提供システムとそのサーバユニット
US8473733B2 (en) * 2008-10-14 2013-06-25 Research In Motion Limited Method for managing opaque presence indications within a presence access layer
US20100093328A1 (en) * 2008-10-15 2010-04-15 Research In Motion Limited Interworking Function with a Presence Access Layer to Provide Enhanced Presence Aspect Indications
US8103730B2 (en) 2008-10-15 2012-01-24 Research In Motion Limited Use of persistent sessions by a presence access layer
US20100093366A1 (en) * 2008-10-15 2010-04-15 Research In Motion Limited Incorporating Non-Presence Information in the Calculation of Presence Aspects by a Presence Access Layer
US20100099387A1 (en) * 2008-10-16 2010-04-22 Research In Motion Limited Controlling and/or Limiting Publication Through the Presence Access Layer
US8751584B2 (en) * 2008-10-16 2014-06-10 Blackberry Limited System for assignment of a service identifier as a mechanism for establishing a seamless profile in a contextually aware presence access layer
US8386769B2 (en) * 2008-11-21 2013-02-26 Research In Motion Limited Apparatus, and an associated method, for providing and using opaque presence indications in a presence service
EP2222057A1 (en) * 2009-02-24 2010-08-25 Research In Motion Limited Subscription management for a content-based presence service
US8452959B2 (en) * 2009-02-24 2013-05-28 Research In Motion Limited Method and system for registering a presence user with a presence service
US20100217614A1 (en) * 2009-02-24 2010-08-26 Research In Motion Limited Method and system for updating a virtual business card
US8606233B2 (en) * 2009-02-24 2013-12-10 Blackberry Limited Content-based publication-subscription system for presence information
US8885830B2 (en) * 2009-05-04 2014-11-11 Mitre Corporation Method and apparatus for dynamically establishing and joining an encrypted collaborative communication session
JP5811315B2 (ja) * 2010-02-12 2015-11-11 株式会社リコー 端末、端末用プログラム、及び、情報送信方法
KR101682243B1 (ko) * 2010-04-26 2016-12-13 삼성전자주식회사 메시지 제공 방법 및 이를 위한 단말 장치
US20130108045A1 (en) 2011-10-27 2013-05-02 Architecture Technology, Inc. Methods, networks and nodes for dynamically establishing encrypted communications
WO2014005317A1 (zh) * 2012-07-06 2014-01-09 华为技术有限公司 呈现服务器发现非呈现用户业务能力的方法和相应装置
US9853756B2 (en) * 2012-11-07 2017-12-26 Qualcomm Incorporated Multicast over wireless network with the assistance of power-efficient peer group discovery
US9338130B2 (en) * 2013-02-11 2016-05-10 Broadcom Corporation Apparatus and method to register Wi-Fi clients on a Wi-Fi network
FR3011414A1 (fr) * 2013-10-01 2015-04-03 Orange Procede d'abonnement a des flux en provenance de clients multicast
US20150319112A1 (en) * 2013-12-13 2015-11-05 Metaswitch Networks Limited Subscription management
US10282282B2 (en) * 2016-06-29 2019-05-07 Synopsys, Inc. Automated HTTP user flows simulator
JP6861285B2 (ja) * 2017-01-30 2021-04-21 テレフオンアクチーボラゲット エルエム エリクソン(パブル) 緊急アクセス中のパラメータ交換のための方法およびデバイス
US11297494B2 (en) * 2019-02-01 2022-04-05 T-Mobile Usa, Inc. Secure rich communication services multicast system
US11128485B2 (en) 2019-02-01 2021-09-21 T-Mobile Usa, Inc. Rich communication services multicast system

Family Cites Families (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7434046B1 (en) * 1999-09-10 2008-10-07 Cisco Technology, Inc. Method and apparatus providing secure multicast group communication
US7089211B1 (en) * 2000-01-12 2006-08-08 Cisco Technology, Inc. Directory enabled secure multicast group communications
JP4002380B2 (ja) * 2000-03-15 2007-10-31 日本電気株式会社 マルチキャストシステム、認証サーバ端末、マルチキャスト受信者端末管理方法、並びに記録媒体
US7454518B1 (en) * 2000-09-12 2008-11-18 Nortel Networks Limited System, device, and method for receiver access control in a multicast communication network
US6993327B2 (en) * 2001-10-29 2006-01-31 Motorola, Inc. Multicast distribution of presence information for an instant messaging system
DE10307403B4 (de) * 2003-02-20 2008-01-24 Siemens Ag Verfahren zum Bilden und Verteilen kryptographischer Schlüssel in einem Mobilfunksystem und Mobilfunksystem
JP2004336160A (ja) 2003-04-30 2004-11-25 Matsushita Electric Ind Co Ltd マルチキャスト通信方法
US7574528B2 (en) * 2003-08-27 2009-08-11 Cisco Technology, Inc. Methods and apparatus for accessing presence information
JP4641148B2 (ja) * 2004-01-19 2011-03-02 日本電信電話株式会社 個人情報開示システム、個人情報開示方法および個人情報開示プログラム
US20050210104A1 (en) * 2004-03-19 2005-09-22 Marko Torvinen Method and system for presence enhanced group management and communication
JP4352959B2 (ja) 2004-03-25 2009-10-28 日本電気株式会社 プレゼンス情報に基づくグループ通信方式およびクライアント装置
US7522548B2 (en) * 2004-12-08 2009-04-21 Motorola, Inc. Providing presence information in a communication network
JP4806278B2 (ja) * 2006-03-16 2011-11-02 富士通株式会社 マルチキャストシステム、通信装置、およびマルチキャスト方法
US8447340B2 (en) * 2007-04-04 2013-05-21 Telefonaktiebolaget L M Ericsson (Publ) Multicast push to talk groups, apparatus, and methods
US20100100626A1 (en) * 2008-09-15 2010-04-22 Allen Stewart O Methods and apparatus related to inter-widget interactions managed by a client-side master

Also Published As

Publication number Publication date
US20080028211A1 (en) 2008-01-31
US8140844B2 (en) 2012-03-20
JP2008034960A (ja) 2008-02-14

Similar Documents

Publication Publication Date Title
JP4296191B2 (ja) サーバ装置、端末装置、通信方法、通信プログラムおよび通信システム
CN101026456B (zh) 信息处理设备和控制方法
CN103503408B (zh) 用于提供访问凭证的系统和方法
JP7050354B2 (ja) 非同期メッセージシステムにおける単一アカウントに対する複数プロファイルを管理する方法、システムおよびコンピュータ読み取り可能媒体
JP5377295B2 (ja) Sipベースメッセージサービスにおけるグループ通知方法
KR20080034084A (ko) 사설 네트워크 시스템 및 그를 구현하는 방법
JP7133285B2 (ja) ユーザ端末、メッセージを送受信する方法及びコンピュータプログラム
US10404631B2 (en) Creating groups in a messaging system
CN105324976A (zh) 使用简单证书注册协议和相应的管理应用将证书注册到设备的方法
JP4703576B2 (ja) コネクションを維持する装置、方法およびプログラム
JP6169568B2 (ja) パッシブ通信サービスのためのシステムおよび方法
JP5180048B2 (ja) サービス提供システム、サービス提供方法およびサービス提供プログラム
CN102388631A (zh) 用于在满足特定条件时建立会话的系统和方法
WO2010119626A1 (ja) Id認証システム、方法及びプログラムが格納された非一時的なコンピュータ可読媒体
JP2007193462A (ja) 個人情報を保護した通信セッション確立仲介システムおよび方法
CN110971506B (zh) 一种去中心化实时集群通讯方法、装置、设备及系统
US20190215375A1 (en) Email notification system
JP5308527B2 (ja) プロキシサーバ、その制御方法、コンテンツサーバ、及びその制御方法
KR20170045786A (ko) 개인정보 보호 서비스 제공 시스템 및 그 방법
KR20220050863A (ko) 보안 인스턴트 메시징 방법 및 장치
Enge et al. An architectural framework for enabling secure decentralized P2P messaging using DIDComm and Bluetooth Low Energy
US10614423B2 (en) Email notification system
JP4137769B2 (ja) 通信システム、通信方法および通信プログラム
US10681163B2 (en) Email notification system
JP5296602B2 (ja) サービス提供システムおよびサービス提供方法

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20080327

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20080715

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20080910

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20090324

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20090413

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20120417

Year of fee payment: 3

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20120417

Year of fee payment: 3

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20130417

Year of fee payment: 4

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20140417

Year of fee payment: 5

LAPS Cancellation because of no payment of annual fees