(57)【特許請求の範囲】
【請求項１】
第１クライアント部と少なくとも１つの第２クライアント部とを含む複数のクライアント部が出版／購読型モデルに従って通信するデータ配信システムであって、
前記第１クライアント部は、
メッセージの宛先を特定するトピックに対応付けられ、前記トピックを宛先とする前記メッセージを暗号化／復号するトピック共通鍵を前記第２クライアント部に供給するトピック共通鍵管理部と、
前記トピックに宛てて前記メッセージを送信する場合に前記トピックに対応付けられた前記トピック共通鍵で暗号化した前記メッセージを送信し、前記トピックを宛先とした前記メッセージを受信した場合に受信した前記メッセージを前記トピックに対応付けられた前記トピック共通鍵で復号するメッセージ管理部と、
を備え、
前記第２クライアント部は、
前記第１クライアント部から供給された前記トピック共通鍵を、前記トピックを識別する識別情報と対応付けて記憶する記憶部と、
前記トピックに宛てて前記メッセージを送信する場合に前記トピック共通鍵で暗号化した前記メッセージを送信し、前記トピックを宛先とした前記メッセージを受信した場合に受信した前記メッセージを前記トピック共通鍵で復号するメッセージ管理部と、
を備える、
データ配信システム。
【請求項２】
前記第１クライアント部は、
前記トピック共通鍵を、前記トピックを識別する前記識別情報と対応付けて記憶するトピック共通鍵記憶部、
を備える請求項１に記載のデータ配信システム。
【請求項３】
前記第１クライアント部の前記トピック共通鍵管理部は、前記トピックのパブリッシャとして設定されている前記第２クライアント部及び前記トピックのサブスクライバとして設定されている前記第２クライアント部に、前記トピック共通鍵を供給する、
請求項２に記載のデータ配信システム。
【請求項４】
前記トピックの前記パブリッシャとして設定されている前記第２クライアント部の前記メッセージ管理部は、前記トピックに向けて前記メッセージを出版する場合、前記トピックに対応付けられた前記トピック共通鍵で前記メッセージを暗号化し、暗号化した前記メッセージを送信する、
請求項３に記載のデータ配信システム。
【請求項５】
前記トピックの前記サブスクライバとして設定されている前記第２クライアント部の前記メッセージ管理部は、購読する前記トピックを宛先とした前記メッセージを受信した場合、前記トピックに対応付けられた前記トピック共通鍵で前記メッセージを復号する、
請求項４に記載のデータ配信システム。
【請求項６】
前記第２クライアント部は、
前記第２クライアント部が正当な前記クライアント部であることを証明するクライアント証明書を前記第１クライアント部に送信するクライアント証明書送信手段、
を備え、
前記第１クライアント部は、
前記第２クライアント部の前記クライアント証明書送信手段から受信した前記クライアント証明書を検証するクライアント証明書検証部、
を備え、
前記クライアント証明書検証部が前記第２クライアント部の前記クライアント証明書送信手段から受信した前記クライアント証明書の検証に成功した場合に、前記第１クライアント部の前記トピック共通鍵管理部は、前記第２クライアント部が出版または購読する前記トピックに対応付けられた前記トピック共通鍵を供給する、
請求項３から５のいずれか１項に記載のデータ配信システム。
【請求項７】
前記クライアント証明書は、認証局により署名されたものであり、
前記第１クライアント部の前記クライアント証明書検証部は、前記認証局の公開鍵で前記クライアント証明書の署名を検証する、
請求項６に記載のデータ配信システム。
【請求項８】
前記クライアント証明書検証部が前記クライアント証明書の前記署名の検証に成功した場合に、前記第１クライアント部の前記トピック共通鍵管理部は、前記第２クライアント部の公開鍵であるクライアント公開鍵で前記トピック共通鍵を暗号化し、暗号化した前記トピック共通鍵をその前記第２クライアント部に供給する、
請求項７に記載のデータ配信システム。
【請求項９】
前記クライアント証明書は、前記第２クライアント部の前記クライアント公開鍵を含み、
前記第１クライアント部の前記トピック共通鍵管理部は、前記クライアント証明書検証部が前記クライアント証明書の前記署名の検証に成功した場合に、前記クライアント証明書から取得した前記クライアント公開鍵で前記トピック共通鍵を暗号化する、
請求項８に記載のデータ配信システム。
【請求項１０】
前記トピックのパブリッシャとして設定されている前記第１クライアント部または前記第２クライアント部が前記トピックに向けて出版した前記メッセージを受信し、前記メッセージを前記トピックのサブスクライバとして設定されている前記第１クライアント部または前記第２クライアント部に配信する仲介手段、
をさらに備える、
請求項２から９のいずれか１項に記載のデータ配信システム。
【請求項１１】
前記第１クライアント部の前記トピック共通鍵記憶部は、１つの前記トピックに対応付けた１つの前記トピック共通鍵を、前記トピックを識別する前記識別情報と対応付けて記憶する、
請求項２から１０のいずれか１項に記載のデータ配信システム。
【請求項１２】
前記第１クライアント部の前記トピック共通鍵記憶部は、２以上の前記トピックに対応づけられた１つの前記トピック共通鍵を、前記トピックを識別する前記識別情報と対応付けて記憶する、
請求項２から１０のいずれか１項に記載のデータ配信システム。
【請求項１３】
前記トピック共通鍵管理部は、前記トピック共通鍵を生成し、生成した前記トピック共通鍵を前記トピック共通鍵記憶部に格納する、
請求項２から１２のいずれか１項に記載のデータ配信システム。
【請求項１４】
第１クライアント部と少なくとも１つの第２クライアント部とを含む複数のクライアント部を有し、前記複数のクライアント部が出版／購読型モデルに従って通信するデータ処理装置であって、
前記第１クライアント部は、
メッセージの宛先を特定するトピックに対応付けられ、前記トピックを宛先とする前記メッセージを暗号化／復号するトピック共通鍵を前記第２クライアント部に供給するトピック共通鍵管理部と、
前記トピックに宛てて前記メッセージを送信する場合に前記トピックに対応付けられた前記トピック共通鍵で暗号化した前記メッセージを送信し、前記トピックを宛先とした前記メッセージを受信した場合に受信した前記メッセージを前記トピックに対応付けられた前記トピック共通鍵で復号するメッセージ管理部と、
を備え、
前記第２クライアント部は、
前記第１クライアント部から供給された前記トピック共通鍵を、前記トピックを識別する識別情報と対応付けて記憶する記憶部と、
前記トピックに宛てて前記メッセージを送信する場合に前記トピック共通鍵で暗号化した前記メッセージを送信し、前記トピックを宛先とした前記メッセージを受信した場合に受信した前記メッセージを前記トピック共通鍵で復号するメッセージ管理部と、
を備える、
データ処理装置。
【請求項１５】
複数のクライアント部が出版／購読型モデルに従って通信するデータ配信システムにおいて、前記クライアント部として機能するコンピュータに実行させるプログラムであって、
前記コンピュータに、
メッセージの宛先を特定するトピックに宛ててメッセージを送信する場合には、前記メッセージを前記トピックに対応付けられたトピック共通鍵で暗号化させ、暗号化した前記メッセージを前記トピックに宛てて送信させ、
前記トピックを宛先とした前記メッセージを受信した場合には、受信した前記メッセージを前記トピックに対応付けられた前記トピック共通鍵で復号させる、
プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データ配信システム、データ処理装置、及びプログラムに関する。
【背景技術】
【０００２】
特許文献１には、情報提供装置が仲介サーバを経由して端末にコンテンツデータを送信することが記載されている。仲介手段である仲介サーバからデータが漏出することを防止するため、情報処理装置と端末との間では暗号化されたデータが受け渡しされる。具体的には、情報処理装置と端末とはそれぞれ共通鍵を有しており、情報提供装置は、送信するデータを共通鍵でデータを暗号化し、暗号化したデータを仲介サーバに送信する。仲介サーバは、情報提供装置から受信したデータを端末に送信する。端末は、仲介サーバから受信したデータをトピック共通鍵で復号する。【０００３】
また、仲介手段を介した通信として、出版／購読型モデルを採用することがある。出版／購読型モデルを採用することで、システムの拡張性を向上させることができるからである。出版／購読型モデルに従った通信では、仲介手段であるブローカがパブリッシャが出版したメッセージを、メッセージを購読するサブスクライバに配信する。出版／購読型モデルに従った通信においても、メッセージは、ブローカを介してやり取りされるため、メッセージの暗号化が必要となることがある。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２０１３−１１８４２７号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
特許文献１に記載された構成では、情報処理装置と端末との組み合わせ毎に共通鍵を用意する必要がある。例えば、端末の数が増えることにより、データの供給先が増加すると、増加した端末の数に応じて、共通鍵を用意する必要がある。このように、データの供給先である端末の数が増えた場合、共通鍵の生成、共通鍵の配布等の処理の負荷が大きくなる。【０００６】
出版／購読型モデルに従った通信においても、特許文献１と同様に、サブスクライバの数が増えた場合には、共通鍵の生成、共通鍵の配布等の処理の負荷が大きくなることが予想される。【０００７】
本発明は、上記実情に鑑みてなされたものであり、出版／購読型モデルに従って通信を行うときに、データの供給先が増えた場合であっても、暗号化通信のための処理負担を軽減することを目的とする。
【課題を解決するための手段】
【０００８】
上記目的を達成するため、本発明に係るデータ配信システムにおいては、第１クライアント部と少なくとも１つの第２クライアント部とを含む複数のクライアント部が出版／購読型モデルに従って通信する。第１クライアント部が備えるトピック共通鍵管理部は、メッセージの宛先を特定するトピックに対応付けられ、トピックを宛先とするメッセージを暗号化／復号するトピック共通鍵を第２クライアント部に供給する。第１クライアント部が備えるメッセージ管理部は、トピックに宛ててメッセージを送信する場合にトピックに対応付けられたトピック共通鍵で暗号化したメッセージを送信し、トピックを宛先としたメッセージを受信した場合に受信したメッセージをトピックに対応付けられたトピック共通鍵で復号する。第２クライアント部が備える記憶部は、第１クライアント部から供給されたトピック共通鍵を、トピックを識別する識別情報と対応付けて記憶する。第２クライアント部が備えるメッセージ管理部は、トピックに宛ててメッセージを送信する場合にトピック共通鍵で暗号化したメッセージを送信し、トピックを宛先としたメッセージを受信した場合に受信したメッセージをトピック共通鍵で復号する。
【発明の効果】
【０００９】
本発明に係るデータ配信システムにおいては、第１クライアント部と少なくとも１つの第２クライアント部とを含む複数のクライアント部が出版／購読型モデルに従って通信する。第１クライアント部は、メッセージの宛先を特定するトピックに対応付けられ、トピックを宛先とするメッセージを暗号化／復号するトピック共通鍵を第２クライアント部に供給する。第２クライアント部は、トピックに宛ててメッセージを送信する場合にトピック共通鍵で暗号化したメッセージを送信し、トピックを宛先としたメッセージを受信した場合に受信したメッセージをトピック共通鍵で復号する。このように、複数のクライアント部は、トピックに対応付けられたトピック共通鍵によりメッセージを暗号化／復号する。よって、データの供給元とデータの供給先との組み合わせ毎に鍵を用意する必要がなく、データの供給先が増えた場合であっても、暗号化通信のための処理負担を軽減することができる。
【図面の簡単な説明】
【００１０】
【図１】本発明の実施の形態に係るデータ処理システムの構成を示すブロック図
【図２】実施の形態に係るデータ処理装置のハードウェア構成を示すブロック図
【図３】実施の形態に係るデータ処理装置の機能構成を示すブロック図
【図４】実施の形態に係る出版／購読型モデルに従ったメッセージングを説明するための図
【図５】実施の形態に係るトピック共通鍵記憶部に格納されるデータの一例を示す図
【図６】実施の形態に係るメッセージの一例を示す図
【図７】実施の形態に係るクライアント公開鍵記憶部に格納されるデータの一例を示す図
【図８】実施の形態に係る購読設定記憶部に格納されるデータの一例を示す図
【図９】実施の形態に係るトピック共通鍵管理部の機能構成を示すブロック図
【図１０】実施の形態に係るトピック共通鍵記憶部に格納されるデータの一例を示す図
【図１１】実施の形態に係るクライアントの送受信処理のフローチャート
【図１２】実施の形態に係るプラットフォームの送受信処理のフローチャート
【図１３】変形例１に係るデータ処理装置の機能構成を示すブロック図
【図１４】変形例２に係るデータ処理装置の機能構成を示すブロック図
【図１５】階層化構造を有するデータの例を示す図
【発明を実施するための形態】
【００１１】
（実施の形態）
以下、本発明の実施の形態に係るデータ処理装置について、図面を参照しつつ詳細に説明する。
【００１２】
実施の形態に係るデータ処理装置１０は、例えば、図１に示すように、ネットワーク７０１を介してＦＡ機器６０１及び６０２と接続されて、データ処理システム１を構成する。実施の形態においては、データ処理装置１０は、例えば、ＦＡ機器６０１及び６０２と同じ工場内に配置されているＩＰＣ（Industrial Personal Computer）である。
【００１３】
データ処理装置１０は、ＦＡ機器６０１及び６０２が備えるセンサが取得したデータを収集する。ＦＡ機器６０１及び６０２が備えるセンサは、例えば、振動センサ、温度センサ、圧力センサ、流量センサである。データ処理装置１０は、例えば、ＦＡ機器６０１及び６０２からデータを収集し、収集したデータに、加工処理、解析処理等の決められた処理を実行する。以下、ＦＡ機器６０１及び６０２をＦＡ機器６００と称することがある。
【００１４】
図２に示すように、データ処理装置１０は、ハードウェア構成として、データ処理装置１０全体を制御するＣＰＵ（Central Processing Unit）１１と、各種のプログラム及びデータを記憶するメモリ１２と、ネットワーク７０１を介して他の装置と通信する通信インタフェース１３と、ユーザインタフェースである入力デバイス１４及び出力デバイス１５と、を有する。メモリ１２と通信インタフェース１３と入力デバイス１４と出力デバイス１５とは、バス１９を介してＣＰＵ１１と接続されており、それぞれＣＰＵ１１と通信する。
【００１５】
ＣＰＵ１１は、メモリ１２に記憶されているプログラムを実行することにより、後述する処理を実行する。
【００１６】
メモリ１２は、揮発性メモリと不揮発性メモリとを含む。メモリ１２は、データ処理装置１０の各種機能を実現するためのプログラムを格納する。さらに、メモリ１２はＣＰＵ１１のワークメモリとして用いられる。
【００１７】
通信インタフェース１３は、ネットワークインタフェース回路を含み、ＣＰＵ１１の制御の下、ネットワーク７０１を介してＦＡ機器６００と通信する。ネットワーク７０１は、例えば、フィールドネットワークの規格に則ったネットワークである。
【００１８】
入力デバイス１４は、入力キー、ポインティングデバイス等を含む。入力デバイス１４は、ユーザからの操作入力を受け付け、ユーザの操作入力を示す信号をＣＰＵ１１に出力する。ユーザは、例えば、データ処理装置１０の管理者である。
【００１９】
出力デバイス１５は、ディスプレイ、スピーカ等を含む。出力デバイス１５は、ＣＰＵ１１から供給された信号に基づく画像をディスプレイに表示する。出力デバイス１５は、ＣＰＵ１１から供給された信号に基づく音をスピーカから出力する。
【００２０】
図３に示すように、データ処理装置１０は、決められたデータ処理を実行するクライアント１０１及び１０２と、一連のデータ処理の制御を行うプラットフォーム２００と、データのやり取りを仲介するデータ配信部３００とを含む。図３では、クライアント１０２の機能構成の図示を省略しているが、クライアント１０２は、クライアント１０１と同様の機能を備えるものとする。以下、クライアント１０１及び１０２をまとめてクライアント１００と称することがある。クライアント１００は、本発明の第２クライアント部の一例である。プラットフォーム２００は、本発明の第１クライアント部の一例である。データ配信部３００は、本発明の仲介手段の一例である。
【００２１】
クライアント１００は決められた処理を行う。例えば、クライアント１０１は、ＦＡ機器６００からデータを収集する処理を実行し、クライアント１０２は、収集されたデータの解析処理を実行する。
【００２２】
複数のクライアント１００が連携したデータ処理を行う場合、プラットフォーム２００はデータ処理のフローを制御する。例えば、プラットフォーム２００は、クライアント１００にデータ処理の順序について設定する。
【００２３】
データ配信部３００は、クライアント１００とプラットフォーム２００との間のデータのやり取りを仲介する。さらに、データ配信部３００は、クライアント１００間のデータのやり取りを仲介する。実施の形態では、クライアント１０１及び１０２、プラットフォーム２００、データ配信部３００は、それぞれの機能を備えるアプリケーションにより実現される。
【００２４】
実施の形態において、データ処理装置１０の各部は、出版／購読型モデルに従ってデータを授受する。出版／購読型モデルにおいて、メッセージを送信する側のアプリケーションをパブリッシャといい、メッセージを受信する側のアプリケーションをサブスクライバという。パブリッシャとサブスクライバとのデータ交換を仲介するアプリケーションをブローカという。
【００２５】
図４に出版／購読型モデルに従ったメッセージングの一例を示す。パブリッシャＰ１、Ｐ２は、メッセージを生成し、生成したメッセージをブローカＢ１に送信する。パブリッシャＰ１、Ｐ２がメッセージを送信することを、出版ということがある。パブリッシャＰ１、Ｐ２はトピックＴ１、Ｔ２、Ｔ３のいずれかを指定してメッセージを出版することができる。トピックＴ１、Ｔ２、Ｔ３は、パブリッシャが出版するメッセージに含まれる情報の主題を表す。サブスクライバＳ１、Ｓ２は、トピックＴ１、Ｔ２、Ｔ３のいずれかを指定してメッセージの配信をブローカに要求する。サブスクライバＳ１、Ｓ２が出版されたメッセージを受信することを、購読ということがある。ブローカＢ１は、サブスクライバＳ１、Ｓ２に、それぞれが購読しているトピックのメッセージを送信する。このように、各トピックのメッセージは、トピックのサブスクライバに配信される。よって、トピックは、メッセージの宛先を特定するものとなる。
【００２６】
図４に示す例では、パブリッシャＰ２は、トピックＴ２を指定してメッセージＭ２をブローカＢ１に送信する。サブスクライバＳ１、Ｓ２は、トピックＴ２を指定して購読をブローカＢ１に要求している。この場合、ブローカＢ１は、パブリッシャＰ１から受信したトピックＴ２のメッセージＭ２を、サブスクライバＳ１、Ｓ２に送信する。
【００２７】
出版／購読型モデルに従ったメッセージングでは、パブリッシャは、自身が送信するメッセージをだれが受信するかを知る必要はない。また、サブスクライバも、受信したメッセージをだれが送信したかを知る必要はない。パブリッシャとサブスクライバとの結合度が低いため、出版／購読型モデルに従ったメッセージングを使用する場合、システムのスケーラビリティが高くなる。
【００２８】
図３に示すデータ処理装置１０において、クライアント１００は、サブスクライバまたはパブリッシャとして動作する。プラットフォーム２００は、パブリッシャまたはサブスクライバとして動作する。データ配信部３００は、ブローカとして動作する。クライアント１００と、プラットフォーム２００とはいずれも、任意のトピックについてパブリッシャかつサブスクライバとして動作することもできる。例えば、クライアント１０１は、ＦＡ機器６００からデータを収集し、クライアント１０２は、収集されたデータを加工するとする。この場合、クライアント１０１は、パブリッシャとして動作し、クライアント１０２は、サブスクライバとして動作すればよい。クライアント１０１は、収集したデータを、ブローカであるデータ配信部３００に送信する。データ配信部３００は、サブスクライバであるクライアント１０２にデータを配信する。クライアント１０２は、受信したデータを加工する。
【００２９】
実施の形態では、プラットフォーム２００は、メッセージの配信に先だって、例えば、ユーザが予め設定した購読の設定に基づいて、ブローカとして動作するデータ配信部３００にトピックを設定する。例えば、プラットフォーム２００は、データ配信部３００の起動時に、トピックを設定する。さらに、プラットフォーム２００は、例えば、クライアント１００の起動時に、クライアント１００に、購読対象のトピックを指定するパラメータを設定する。クライアント１００は、設定されたパラメータに基づいて、データ配信部３００にトピックの購読を要求する。
【００３０】
実施の形態に特徴的な構成として、パブリッシャとして動作するクライアント１００またはプラットフォーム２００は、暗号化したデータを含むメッセージを送信する。サブスクライバとして動作するクライアント１００またはプラットフォーム２００は、受信したメッセージに含まれるデータを復号する。同一トピックについてのデータの暗号化、復号には同じ鍵が使用される。プラットフォーム２００は、メッセージの送受信に先立って、トピックに対応付けられた鍵をトピックのパブリッシャとサブスクライバとに配信する。以下、トピックに対応付けられた鍵をトピック共通鍵という。トピックのパブリッシャは、出版するトピックに対応付けられたトピック共通鍵で、トピックのメッセージを暗号化する必要がある。トピックのサブスクライバは、受信したメッセージをトピックに対応付けられたトピック共通鍵で復号する必要がある。
【００３１】
パブリッシャが、データを暗号化して送信するのは次のような理由による。例えば、不正なクライアント１００が、データ処理装置１０に追加され、データ配信部３００のトピック毎のメッセージの配信先の設定が変更されたとする。この場合、不正なクライアント１００がメッセージを受信し、あるいは、不正なクライアント１００がメッセージを送信することができてしまう。このため、プラットフォーム２００は、メッセージの送受信に先立ってクライアント１００を検証し、正当なクライアント１００にトピック共通鍵を供給する。例えば、プラットフォーム２００は、トピック共通鍵で暗号化したデータを含むメッセージを送信する。データ配信部３００を介して暗号化されたデータを含むメッセージを受信したクライアント１００は、そのトピックに対応するトピック共通鍵を有している場合のみ、メッセージに含まれているデータを復号することができる。不正なクライアント１００は、トピック共通鍵を有していないため、データの暗号化、復号を行うことができない。
【００３２】
続いて、上記の処理を行うため、クライアント１００、プラットフォーム２００がそれぞれ備える機能を説明する。
【００３３】
図３に示すように、クライアント１００は、メッセージ送受信Ｉ／Ｆ（Interface）部１１０と、クライアント鍵記憶部１２０と、クライアント証明書管理部１３０と、クライアント証明書送信部１４０と、トピック共通鍵記憶部１５０と、トピック共通鍵取得部１６０と、メッセージ管理部１７０とを有する。
【００３４】
メッセージ送受信Ｉ／Ｆ部１１０は、データ配信部３００とメッセージを送受信するインタフェースである。メッセージ送受信Ｉ／Ｆ部１１０の機能は、図２に示すＣＰＵ１１により実現される。
【００３５】
図３に示すクライアント鍵記憶部１２０は、クライアント１００の公開鍵と秘密鍵とを記憶する。クライアント１００は、例えば、起動された直後に決められた方法でクライアント１００の公開鍵と秘密鍵とを生成し、公開鍵と秘密鍵とをクライアント鍵記憶部１２０に格納する。詳しくは後述するが、クライアント１００の公開鍵は、プラットフォーム２００がトピック共通鍵をクライアント１００に供給するときに使用される。クライアント鍵記憶部１２０の機能は、図２に示すメモリ１２により実現される。
【００３６】
図３に示すクライアント証明書管理部１３０は、認証局から発行されたクライアント証明書を保管する。クライアント証明書は、クライアント１００が正当なクライアントであることを証明するものであり、認証局が発行した電子証明書である。認証局は、監査法人の審査をクリアしたパブリック認証局であってもよいし、データ処理装置１０の提供元といったプライベ−ト認証局であってもよい。クライアント証明書は、クライアント１００の機能を実現するアプリケーションに予め組み込まれているものとする。クライアント証明書管理部１３０の機能は、図２に示すＣＰＵ１１、メモリ１２により実現される。
【００３７】
図３に示すクライアント証明書送信部１４０は、クライアント証明書管理部１３０が保管するクライアント証明書を、メッセージ送受信Ｉ／Ｆ部１１０を介してデータ配信部３００に送信する。例えば、クライアント証明書送信部１４０は、購読対象のトピックを指定してクライアント証明書を含むメッセージをデータ配信部３００に送信する。クライアント証明書を含むメッセージは、例えば、決められたフォーマットで生成されるものとする。
【００３８】
クライアント証明書を含むメッセージは、データ配信部３００を介してプラットフォーム２００に送信される。例えば、クライアント証明書をプラットフォーム２００に供給するためのトピックが設定されてもよい。この場合、クライアント１００は、このトピックに向けて、クライアント証明書を含むメッセージを出版すればよい。あるいは、プラットフォーム２００は、クライアント証明書を取得するのに十分なトピックのサブスクライバとして設定されていてもよい。例えば、プラットフォーム２００は、各クライアント１００が購読するトピックのうち少なくとも１つのトピックのサブスクライバとして設定されていてもよい。
【００３９】
クライアント１００の購読対象のトピックが２つ以上の場合もあるが、クライアント１００は、プラットフォーム２００にクライアント証明書を１回送信すれば十分である。例えば、クライアント証明書送信部１４０は、プラットフォーム２００から指定された購読対象のトピックのうち、例えば、一番目のトピックを宛先として、クライアント証明書を送信してもよい。クライアント証明書送信部１４０は、本発明のクライアント証明書送信手段の一例である。クライアント証明書送信部１４０の機能は、図２に示すＣＰＵ１１により実現される。
【００４０】
図３に示すトピック共通鍵記憶部１５０は、プラットフォーム２００から供給されたトピック共通鍵を記憶する。図５に示すように、トピック共通鍵記憶部１５０は、トピック共通鍵をトピックを識別する情報と対応付けて記憶する。トピック共通鍵記憶部１５０の機能は、図２に示すメモリ１２により実現される。
【００４１】
図３に示すトピック共通鍵取得部１６０は、メッセージ送受信Ｉ／Ｆ部１１０を介してデータ配信部３００から受信したメッセージがトピック共通鍵を含む場合、トピック共通鍵をトピック共通鍵記憶部１５０に格納する。トピック共通鍵取得部１６０は、受信したメッセージがトピック共通鍵を含むものであるか否かを、例えば、メッセージのフォーマットから判別することができるものとする。トピック共通鍵はクライアント１００の公開鍵で暗号化されているため、トピック共通鍵取得部１６０は、受信したトピック共通鍵を、クライアント鍵記憶部１２０に格納されているクライアント１００の秘密鍵で復号して、トピック共通鍵を取得する。トピック共通鍵取得部１６０は、トピック共通鍵をトピックを特定する情報とともにトピック共通鍵記憶部１５０に格納する。
【００４２】
なお、同一のトピックを購読しているクライアント１００が２以上存在する場合がある。詳しくは後述するが、プラットフォーム２００は、クライアント１００それぞれの公開鍵でトピック共通鍵を暗号化し、暗号化したトピック共通鍵を含むメッセージを、そのトピックを宛先としてデータ配信部３００に送信する。よって、クライアント１００のトピック共通鍵取得部１６０は、他のクライアント１００のためのトピック共通鍵を含むメッセージを受信することがある。しかし、トピック共通鍵取得部１６０は、他のクライアント１００のためのトピック共通鍵を、自身の公開鍵で復号できないため、そのメッセージを破棄する。トピック共通鍵取得部１６０の機能は、図２に示すＣＰＵ１１により実現される。
【００４３】
図３に示すメッセージ管理部１７０は、メッセージの送受信を管理する。具体的には、メッセージ管理部１７０は、メッセージ送受信Ｉ／Ｆ部１１０を介してデータ配信部３００からメッセージを受信すると、トピック共通鍵記憶部１５０が記憶するトピック共通鍵でメッセージに含まれるデータを復号する。メッセージ管理部１７０が受信するメッセージは、図６に示すように、メッセージのあて先を示す情報と、メッセージ本文とを含む。あて先には、トピックを識別する情報が指定されている。例えば、メッセージ管理部１７０は、復号したデータをクライアント１００が有する不図示のデータ処理部に供給する。データ処理部は、復号されたデータに決められた加工処理を実行する。
【００４４】
メッセージ管理部１７０は、決められたフォーマットのメッセージのみ処理する。例えば、メッセージ管理部１７０は、同一のトピックを購読する他のクライアント１００が送信したクライアント証明書を含むメッセージを受信することがあるが、このような場合、メッセージ管理部１７０は、そのメッセージを破棄する。メッセージ管理部１７０は、本発明の第２メッセージ管理手段の一例である。メッセージ管理部１７０の機能は、図２に示すＣＰＵ１１により実現される。
【００４５】
図３に示すクライアント１００がパブリッシャとして動作する場合には、メッセージ管理部１７０は、不図示のデータ処理部から供給された加工済みのデータをトピック共通鍵記憶部１５０が記憶するトピック共通鍵で暗号化する。メッセージ管理部１７０は、暗号化したデータを含むメッセージを生成し、メッセージをメッセージ送受信Ｉ／Ｆ部１１０を介してデータ配信部３００に送信する。
【００４６】
図３に示すように、プラットフォーム２００は、メッセージ送受信Ｉ／Ｆ部２１０と、認証局公開鍵記憶部２２０と、クライアント証明書検証部２３０と、クライアント公開鍵記憶部２４０と、購読設定記憶部２５０と、トピック共通鍵管理部２６０と、メッセージ管理部２７０とを有する。
【００４７】
メッセージ送受信Ｉ／Ｆ部２１０は、データ配信部３００とメッセージを送受信するインタフェースである。メッセージ送受信Ｉ／Ｆ部２１０の機能は、図２に示すＣＰＵ１１により実現される。
【００４８】
図３に示す認証局公開鍵記憶部２２０は、認証局が公開している認証局の公開鍵を記憶する。認証局の公開鍵は、プラットフォーム２００の機能を実現するアプリケーションに予め組み込まれている。認証局公開鍵記憶部２２０の機能は、図２に示すメモリ１２により実現される。
【００４９】
図３に示すクライアント証明書検証部２３０は、メッセージ送受信Ｉ／Ｆ部２１０を介してデータ配信部３００から受信したメッセージがクライアント証明書を含む場合、クライアント証明書の署名を検証する。クライアント証明書検証部２３０は、受信したメッセージがクライアント証明書を含むものであるか否かを、例えば、メッセージのフォーマットから判別することができるものとする。
【００５０】
具体的には、クライアント証明書検証部２３０は、認証局公開鍵記憶部２２０に格納されている認証局の公開鍵を用いて、クライアント証明書に含まれている認証局の署名を復号し、ハッシュ値を取得する。さらに、クライアント証明書検証部２３０は、クライアント証明書に含まれているクライアント１００の公開鍵及び識別情報からハッシュ値を生成する。クライアント証明書検証部２３０は、認証局の署名から取得したハッシュ値と、クライアント１００の公開鍵及び識別情報から生成したハッシュ値とが一致するか否かを判別する。クライアント証明書検証部２３０は、２つのハッシュ値が一致すると判別すると、クライアント証明書の署名の検証に成功したと判別し、クライアント証明書に含まれているクライアント１００の公開鍵を識別情報と対応付けてクライアント公開鍵記憶部２４０に格納する。クライアント証明書検証部２３０は、クライアント証明書の署名の検証に成功すると、トピック共通鍵管理部２６０にその旨を通知する。クライアント証明書検証部２３０の機能は、図２に示すＣＰＵ１１により実現される。
【００５１】
図３に示すクライアント公開鍵記憶部２４０は、クライアント１００の公開鍵を記憶する。図７に示すように、クライアント公開鍵記憶部２４０は、クライアント１００の公開鍵を識別情報と対応付けて記憶する。クライアント公開鍵記憶部２４０の機能は、図２に示すメモリ１２により実現される。
【００５２】
図３に示す購読設定記憶部２５０は、トピックの購読が許可されているクライアント１００の情報を記憶する。図８に示すように、購読設定記憶部２５０は、トピックを特定する情報と、クライアント１００を識別する識別情報とを対応付けて記憶する。図示する例では、トピックＴ１のメッセージを購読することが許可されているのは、クライアント１０１、１０２である。トピックＴ２のメッセージを購読することが許可されているのは、クライアント１０１である。ユーザが予め必要なデータを購読設定記憶部２５０に格納しているものとする。購読設定記憶部２５０の機能は、図２に示すメモリ１２により実現される。
【００５３】
図３に示すトピック共通鍵管理部２６０は、トピック共通鍵をメッセージの送受信に先立って生成し、クライアント１００にトピック共通鍵を供給する。トピック共通鍵管理部２６０は、図９に示すように、トピック共通鍵生成部２６１と、トピック共通鍵記憶部２６２と、トピック共通鍵送信部２６３とを含む。トピック共通鍵管理部２６０の機能は、図２に示すＣＰＵ１１、メモリ１２により実現される。
【００５４】
トピック共通鍵生成部２６１は、トピック毎にトピック共通鍵を生成する。鍵の生成方法は任意である。例えば、トピック共通鍵生成部２６１は、トピック共通鍵を生成する日付及び時刻の情報からハッシュ値を算出し、さらに乱数を生成し、ハッシュ値と乱数とを組み合わせた値をトピック共通鍵としてもよい。あるいは、トピック共通鍵生成部２６１は、トピックを識別する情報と日付及び時刻の情報とからハッシュ値を算出し、さらに乱数を生成し、ハッシュ値と乱数とを組み合わせた値をトピック共通鍵としてもよい。あるいは、トピック共通鍵生成部２６１は、暗号化アルゴリズムを使用してトピック共通鍵を生成してもよい。
【００５５】
トピック共通鍵生成部２６１は、生成したトピック共通鍵をトピックを識別する情報と対応付けてトピック共通鍵記憶部２６２に格納する。トピック共通鍵生成部２６１は、例えば、プラットフォーム２００の起動直後にトピック共通鍵をトピック毎に生成する。また、トピック共通鍵生成部２６１は、ユーザにより新たなトピックが作成されると、対応するトピック共通鍵を生成する。作成されたトピックの識別情報を含むトピックに関する情報は、ユーザが予めメモリ１２に格納するものとする。
【００５６】
トピック共通鍵記憶部２６２は、トピック共通鍵生成部２６１が生成したトピック共通鍵をトピック毎に記憶する。トピック共通鍵記憶部２６２は、図１０に示すように、トピック共通鍵をトピックを識別する情報と対応付けて記憶する。プラットフォーム２００のトピック共通鍵記憶部２６２には、データ処理装置１０内におけるすべてのトピックについてのトピック共通鍵が格納されている。トピックＴ１のトピック共通鍵は、本発明の第１共通鍵の一例である。トピックＴ２のトピック共通鍵は、本発明の第２共通鍵の一例である。
【００５７】
図９に示すトピック共通鍵送信部２６３は、トピック共通鍵記憶部２６２に格納されているトピック共通鍵を、トピックの購読が許可されているクライアント１００に供給する。
【００５８】
具体的には、トピック共通鍵送信部２６３は、図３に示すクライアント証明書検証部２３０から、クライアント証明書の署名の検証に成功した旨の通知を受けると、購読設定記憶部２５０に格納されているデータに基づいて、そのクライアント１００が購読しているトピックを特定する。図９に示すように、トピック共通鍵送信部２６３は、特定したトピックのトピック共通鍵をトピック共通鍵記憶部２６２から取得する。トピック共通鍵送信部２６３は、そのクライアント１００のクライアント公開鍵をクライアント公開鍵記憶部２４０から取得する。トピック共通鍵送信部２６３は、トピック共通鍵をクライアント公開鍵で暗号化し、暗号化したトピック共通鍵を含むメッセージを生成し、トピックを指定してメッセージをメッセージ送受信Ｉ／Ｆ部１１０を介して、図３に示すデータ配信部３００に送信する。
【００５９】
クライアント１００が複数のトピックを購読している場合、トピック共通鍵送信部２６３は、次のようにトピック共通鍵を配信する。例えば、図８に示すように、クライアント１０１がトピックＴ１、トピックＴ２を購読しているとする。この場合、トピック共通鍵送信部２６３は、図５に示すトピック共通鍵記憶部２６２からトピックＴ１、トピックＴ２のトピック共通鍵を取得し、図７に示すクライアント公開鍵記憶部２４０からクライアント１０１の公開鍵を取得する。
【００６０】
トピック共通鍵送信部２６３は、トピックＴ１のトピック共通鍵をクライアント１０１の公開鍵で暗号化し、暗号化したトピックＴ１のトピック共通鍵を含むメッセージを、トピックＴ１を宛先としてデータ配信部３００に送信する。さらに、トピック共通鍵送信部２６３は、トピックＴ２のトピック共通鍵をクライアント１０１の公開鍵で暗号化し、暗号化したトピックＴ２のトピック共通鍵を含むメッセージを、トピックＴ２を宛先としてデータ配信部３００に送信する。
【００６１】
あるいは、トピック共通鍵送信部２６３は、同一のクライアント１００にまとめてトピック共通鍵を送信してもよい。トピック共通鍵送信部２６３は、トピックＴ１のトピック共通鍵とトピックＴ２のトピック共通鍵とをクライアント１０１の公開鍵で暗号化し、暗号化したデータを含むメッセージを、データ配信部３００に送信してもよい。例えば、トピック共通鍵送信部２６３は、複数のトピックのうち、トピックの識別情報の値が一番小さいトピック、例えば、トピックＴ１、を指定して、トピック共通鍵を含むメッセージをデータ配信部３００に送信してもよい。
【００６２】
図３に示すメッセージ管理部２７０は、メッセージの送受信を管理する。具体的には、メッセージ管理部２７０は、メッセージ送受信Ｉ／Ｆ部２１０を介してデータ配信部３００からメッセージを受信すると、トピック共通鍵管理部２６０が記憶するトピック共通鍵でメッセージに含まれるデータを復号する。例えば、メッセージ管理部２７０は、復号したデータを、プラットフォーム２００が有する不図示のデータ処理部に供給する。データ処理部は、データに決められた処理を実行する。
【００６３】
また、メッセージ管理部２７０は、発行するデータをトピック共通鍵管理部２６０が記憶するトピック共通鍵で暗号化する。メッセージ管理部２７０は、暗号化したデータを含むメッセージを生成し、メッセージをメッセージ送受信Ｉ／Ｆ部２１０を介してデータ配信部３００に送信する。メッセージ管理部２７０は、本発明の第１メッセージ管理手段の一例である。メッセージ管理部２７０の機能は、図２に示すＣＰＵ１１により実現される。
【００６４】
図３に示すデータ配信部３００は、任意のトピックを宛先としたメッセージを受信すると、そのトピックのサブスクライバにメッセージを送信する。
【００６５】
続いて、クライアント１００がメッセージを送受信する一連の処理を説明する。クライアント１００は起動されると、図１１に示す送受信処理を実行する。例えば、クライアント１００は、ユーザが入力デバイス１４を操作することにより起動される。なおクライアント１００は予めクライアント証明書を有しているものとする。
【００６６】
クライアント証明書送信部１４０は、クライアント証明書管理部１３０が保管するクライアント証明書を含むメッセージをデータ配信部３００に送信する（ステップＳ１１）。メッセージ送受信Ｉ／Ｆ部１１０を介して、データ配信部３００からメッセージを受信すると（ステップＳ１２；Ｙｅｓ）、トピック共通鍵取得部１６０は、受信したメッセージがトピック共通鍵を含むか否かを判別する（ステップＳ１３）。トピック共通鍵取得部１６０は、受信したメッセージがトピック共通鍵を含むと判別すると（ステップＳ１３；Ｙｅｓ）、メッセージに含まれている暗号化されたトピック共通鍵をクライアント鍵記憶部１２０に格納されているクライアント１００の秘密鍵で復号する（ステップＳ１４）。トピック共通鍵取得部１６０は、復号が成功すると（ステップＳ１５；Ｙｅｓ）、復号したトピック共通鍵をトピックの識別情報とともにトピック共通鍵記憶部１５０に格納する（ステップＳ１６）。一方、トピック共通鍵取得部１６０は、ステップＳ１５で復号に失敗すると（ステップＳ１５；Ｎо）、そのメッセージを破棄して、再びステップＳ１２の処理を行う。
【００６７】
ステップＳ１３で、トピック共通鍵取得部１６０が、受信したメッセージがトピック共通鍵を含まないと判別すると（ステップＳ１３；Ｎｏ）、メッセージ管理部１７０は、受信したメッセージのトピックについてのトピック共通鍵を有しているか否かを判別する（ステップＳ１７）。メッセージ管理部１７０は、トピック共通鍵記憶部１５０にトピック共通鍵が格納されている場合、トピック共通鍵を有していると判別し（ステップＳ１７；Ｙｅｓ）、メッセージに含まれているデータをトピック共通鍵で復号し（ステップＳ１８）、受信したデータに決められた処理を行う（ステップＳ１９）。
【００６８】
また、クライアント１００がパブリッシャとして動作している場合、メッセージ管理部１７０は、データ配信部３００からメッセージを受信していない場合であっても（ステップＳ１２；Ｎｏ）、データを出版するタイミングとなると（ステップＳ２０；Ｙｅｓ）、トピック共通鍵記憶部１５０にトピック共通鍵が格納されているか否かを判別する（ステップＳ２１）。メッセージ管理部１７０は、トピック共通鍵がトピック共通鍵記憶部１５０に格納されている場合（ステップＳ２１；Ｙｅｓ）、送信するデータをトピック共通鍵で暗号化し（ステップＳ２２）、メッセージ送受信Ｉ／Ｆ部１１０を介して、暗号化したデータを含むメッセージをデータ配信部３００に送信する（ステップＳ２３）。以上が、クライアント１００の送受信処理である。
【００６９】
続いて、プラットフォーム２００が行うトピック共通鍵の配信及びメッセージの送受信に係る処理を説明する。プラットフォーム２００は起動されると、図１２に示す送受信処理を実行する。例えば、プラットフォーム２００は、ユーザが入力デバイス１４を操作することにより起動される。なお、プラットフォーム２００の認証局公開鍵記憶部２２０には、予め認証局の公開鍵が格納されているものとする。さらに、プラットフォーム２００は、各トピックのトピック共通鍵を生成して、トピック共通鍵記憶部１５０に格納しているものとする。
【００７０】
図１２に示すように、メッセージ送受信Ｉ／Ｆ部２１０を介して、データ配信部３００からメッセージを受信すると（ステップＳ３１；Ｙｅｓ）、クライアント証明書検証部２３０は、受信したメッセージがクライアント証明書を含むか否かを判別する（ステップＳ３２）。
【００７１】
クライアント証明書検証部２３０は、受信したメッセージがクライアント証明書を含むと判別すると（ステップＳ３２；Ｙｅｓ）、メッセージに含まれているクライアント証明書の署名を検証する（ステップＳ３３）。具体的には、クライアント証明書検証部２３０は、認証局公開鍵記憶部２２０に格納されている認証局の公開鍵で、クライアント証明書に含まれている認証局の署名を復号し、ハッシュ値を取得する。さらに、クライアント証明書検証部２３０は、クライアント証明書に含まれているクライアント１００の公開鍵及び識別情報からハッシュ値を生成する。クライアント証明書検証部２３０は、認証局の署名から取得したハッシュ値と、クライアント１００の公開鍵及び識別情報から生成したハッシュ値とが一致する場合、クライアント証明書の署名の検証に成功したと判別する。
【００７２】
クライアント証明書検証部２３０は、クライアント証明書の署名の検証に成功すると（ステップＳ３４；Ｙｅｓ）、クライアント証明書から取得したクライアント公開鍵をクライアント公開鍵記憶部２４０に格納する（ステップＳ３５）。
【００７３】
続いて、トピック共通鍵管理部２６０のトピック共通鍵送信部２６３は、クライアント１００に送信するトピック共通鍵をクライアント公開鍵で暗号化する（ステップＳ３６）。具体的には、トピック共通鍵送信部２６３は、購読設定記憶部２５０に格納されているデータに基づいてクライアント１００が購読を許可されているトピックを特定し、そのトピックのトピック共通鍵をトピック共通鍵記憶部２６２から取得する。トピック共通鍵送信部２６３は、クライアント公開鍵記憶部２４０からクライアント１００の公開鍵を取得し、クライアント１００の公開鍵でトピック共通鍵を暗号化する。
【００７４】
トピック共通鍵送信部２６３は、暗号化したトピック共通鍵を含めたメッセージをメッセージ送受信Ｉ／Ｆ部１１０を介して、データ配信部３００に送信する（ステップＳ３７）。
【００７５】
ステップＳ３２で、クライアント証明書検証部２３０が、受信したメッセージがクライアント証明書を含まないと判別すると（ステップＳ３２；Ｎｏ）、メッセージ管理部２７０は、受信したメッセージのトピックについてのトピック共通鍵をトピック共通鍵記憶部２６２から取得し、トピック共通鍵で受信したメッセージに含まれているデータを復号する（ステップＳ３８）。その後、メッセージ管理部２７０は受信したデータに決められた処理を行う（ステップＳ３９）。
【００７６】
また、プラットフォーム２００がパブリッシャとして動作している場合、メッセージ管理部２７０は、データ配信部３００からメッセージを受信していない場合であっても（ステップＳ３１；Ｎо）、データを出版するタイミングとなると（ステップＳ４０；Ｙｅｓ）、トピック共通鍵記憶部２６２に格納されているトピック共通鍵で、送信するデータを暗号化し（ステップＳ４１）、メッセージ送受信Ｉ／Ｆ部２１０を介して、暗号化したデータを含むメッセージをデータ配信部３００に送信する（ステップＳ４２）。
【００７７】
以上、説明したように、実施の形態に係るデータ処理装置１０においては、同一トピックを発行／購読するクライアント１００とプラットフォーム２００とは、トピック毎に生成されたトピック共通鍵を使用してメッセージの暗号化／復号を行う。実施の形態に係る構成では、パブリッシャとサブスクライバとの組み合わせ毎に鍵を用意する必要はない。例えば、データ処理装置１０に、あるデータ処理を実行するアプリケーションが追加されることにより、トピックを購読するサブスクライバが増えることがある。このような場合であっても、増加したサブスクライバのために鍵を生成する必要はなく、生成済みのトピック共通鍵を追加されたサブスクライバに供給すればよい。
【００７８】
さらに、トピック毎にトピック共通鍵が生成されるため、パブリッシャとサブスクライバとの組み合わせ毎に鍵を用意する場合に比べ、プラットフォーム２００の鍵の生成、鍵の管理等の処理負担を低減することができる。
【００７９】
プラットフォーム２００は、トピック共通鍵をクライアント１００に供給する前に、クライアント１００が提出したクライアント証明書の署名を検証して、クライアント１００が正当なクライアントであるか否かを判別する。プラットフォーム２００は、検証に失敗した場合、そのクライアント１００にトピック共通鍵を供給しない。プラットフォーム２００がこのような構成を備えるため、正当なクライアント１００だけが、トピックを購読するために必要なトピック共通鍵を取得することができる。
【００８０】
実施の形態では、クライアント証明書管理部１３０が保管するクライアント証明書が、クライアント１００の機能を実現するアプリケーションに予め組み込まれているものとする例を説明した。このような構成の、外部のネットワークに接続されていないデータ処理装置１０であっても、プラットフォーム２００はクライアント１００の検証が可能である。ファクトリーオートメーションの分野で使用されるコンピュータは、例えば、セキュリティの観点から、外部のネットワークに接続されていないことがあるからである。この場合、データ処理装置１０は、外部のネットワークに接続して証明書チェーンをたどる必要がないので、外部ネットワークとの接続に伴うセキュリティリスクを避けることができるというメリットがある。
【００８１】
（変形例１）
実施の形態においては、クライアント１００が、クライアント証明書をデータ配信部３００を介してプラットフォーム２００に送信する例を説明したが、これに限られない。図１３に示すように、クライアント１００のクライアント証明書送信部１４０と、プラットフォーム２００のクライアント証明書検証部２３０とが、データ配信部３００を介さずに直接通信してもよい。この場合、クライアント証明書送信部１４０は、クライアント証明書のファイルをクライアント証明書検証部２３０に直接送信する。このように、クライアント証明書送信部１４０とクライアント証明書検証部２３０とは、出版／購読モデルに従った通信によらずに、直接クライアント証明書を送受信してもよい。
【００８２】
図１３に示す構成では、あるクライアント１００が送信したクライアント証明書は、プラットフォーム２００以外には配信されない。例えば、クライアント１００が、クライアント証明書と一緒に、プラットフォーム２００以外が取得することが望ましくないデータを送信することがある。このような場合には、図１３に示すような構成とすることで、クライアント１００が送信したデータをプラットフォーム２００以外に渡さないようにできる。
【００８３】
（変形例２）
実施の形態、変形例１では、プラットフォーム２００は、データ配信部３００を介してトピック共通鍵をクライアント１００に供給するが、これに限られない。例えば、図１４に示すように、プラットフォーム２００のトピック共通鍵管理部２６０と、クライアント１００のトピック共通鍵取得部１６０とが、データ配信部３００を介さずに直接通信してもよい。例えば、トピック共通鍵管理部２６０は、トピック共通鍵を含むファイルをトピック共通鍵取得部１６０に直接送信してもよい。このように、トピック共通鍵管理部２６０とトピック共通鍵取得部１６０とは、出版／購読モデルに従った通信によらずに、直接トピック共通鍵を送受信してもよい。図１４に示す構成とすることで、トピック共通鍵の不正取得、悪用をより効果的に防止することができる。
【００８４】
（変形例３）
実施の形態においては、図９に示すように、プラットフォーム２００のトピック共通鍵管理部２６０が、トピック共通鍵生成部２６１と、トピック共通鍵記憶部２６２とを有する例を説明したが、これに限られない。トピック共通鍵管理部２６０は、トピック共通鍵生成部２６１とトピック共通鍵記憶部２６２とを有していなくてもよい。トピック共通鍵管理部２６０は、トピック共通鍵を自身で生成するのではなく、他のコンピュータが備える記憶手段から取得する。例えば、プラットフォーム２００が起動された後に、トピック共通鍵送信部２６３は、他のコンピュータが保管するトピック共通鍵を、取得したトピック共通鍵をクライアント１００に供給すればよい。この場合、データ処理装置１０はネットワークを介して他のコンピュータと通信可能であるものとする。
【００８５】
（変形例４）
実施の形態では、クライアント証明書管理部１３０が保管するクライアント証明書が、クライアント１００の機能を実現するアプリケーションに予め組み込まれているものとする例を説明したが、これに限られない。
【００８６】
クライアント証明書管理部１３０は、認証局からクライアント証明書を取得してもよい。例えば、クライアント証明書管理部１３０は、クライアント１００の起動直後に認証局に証明書の署名を要求する。この場合、データ処理装置１０は外部ネットワークを介して認証局と通信可能であるものとする。外部ネットワークは、例えば、インターネットのようなオープンなネットワークである。クライアント１００は、クライアント鍵記憶部１２０に格納されているクライアント１００の公開鍵と、公開鍵の所有者であるクライアント１００を識別するクライアント１００の識別情報とを認証局に送信して、証明書の署名を要求する。
【００８７】
認証局は、クライアント１００の識別情報に基づいて、クライアント１００の証明書に署名しても問題ないと判別すると、クライアント１００から受信した公開鍵及び識別情報から署名を生成する。例えば、認証局は、署名の生成のため、クライアント１００の公開鍵及び識別情報からハッシュ値を生成し、ハッシュ値を認証局の秘密鍵で暗号化する。暗号化されたハッシュ値が認証局の署名となる。認証局は、クライアント１００の公開鍵及び識別情報に、署名を付加したクライアント証明書をクライアント１００に供給する。クライアント証明書管理部１３０は、認証局から供給されたクライアント証明書を保管する。
【００８８】
データ処理装置１０は外部ネットワークを介して認証局と通信可能である場合、さらに、プラットフォーム２００のクライアント証明書検証部２３０は、クライアント証明書の検証に失敗した場合には、外部ネットワークを介して、認証局から公開鍵を取得し、取得した認証局の公開鍵でクライアント証明書を検証するようにしてもよい。例えば、クライアント１００が利用する認証局が変更された、クライアント１００が利用する認証局がプラットフォーム２００に予め登録されていないといった場合もあるからである。このような場合に、プラットフォーム２００のクライアント証明書検証部２３０は、証明書チェーンをたどることが望ましい。クライアント証明書検証部２３０は、ルート認証局による検証が成功すると、クライアント証明書の検証に成功したと判別する。証明書チェーンにより段階的な認証を行うことにより、セキュリティを向上させることができる。
【００８９】
実施の形態においては、プラットフォーム２００がパブリッシャとして動作し、クライアント１００がサブスクライバとして動作する例を説明したが、これに限られない。例えば、１つのクライアント１００がパブリッシャとして動作し、プラットフォーム２００と、他のクライアント１００とがサブスクライバとして動作してもよい。また、トピック毎に、パブリッシャが異なっていてもよい。例えば、トピックＴ１のパブリッシャはプラットフォーム２００であり、トピックＴ２のパブリッシャはクライアント１００であってもよい。また、１つのトピックには、２以上のパブリッシャが設定されていてもよい。上記のような場合も、プラットフォーム２００が、トピック共通鍵の生成と配信とを行う。
【００９０】
実施の形態では、クライアント１００は、トピック共通鍵の復号に失敗すると、即ち、受信したトピック共通鍵が他のクライアント１００の公開鍵で暗号化されている場合に、そのトピック共通鍵を破棄していた。このようにして、クライアント１００は、自身宛てのトピック共通鍵だけを取得することができた。あるいは、プラットフォーム２００は、暗号化したトピック共通鍵を含むメッセージに、あて先のクライアント１００の識別情報を含めるようにしてもよい。この場合、クライアントは、メッセージに含まれている識別情報から、自身宛てのメッセージであるか否かを判別することができる。
【００９１】
トピックは階層構造を有していてもよい。例えば、データ処理装置１０が収集するデータが、図１５に示すような階層化構造を有するとする。例えば、デバイス１から収集するデータを１つのトピックとして定義したとする。デバイス１は、工場Ｆ内のライン１上の装置Ａに備えられたものである。この場合、このトピックを、例えば、“工場Ｆ／ライン１／装置Ａ／デバイス１”と表すことができる。サブスクライバは、ブローカにトピックの購読の要求時に最も下の階層のトピックを指定してもよい。例えば、サブスクライバは、“工場Ｆ／ライン１／装置Ａ／デバイス１”を指定してもよい。この場合、ブローカは、サブスクライバに、デバイス１から収集されたデータを配信する。あるいは、サブスクライバは、トピック購読の要求時に上の階層のトピックをしてもよい。例えば、サブスクライバは、“工場Ｆ／ライン１／装置Ａ”を指定してもよい。この場合、ブローカは、サブスクライバに、デバイス１、デバイス２、デバイス３から収集されたデータを配信する。
【００９２】
トピック共通鍵は、必ずしも各トピックに１つずつ用意される必要はない。例えば、プラットフォーム２００は、上の階層のトピックにトピック共通鍵を生成し、下の階層のトピックも同じトピック共通鍵を使用することとしてもよい。例えば、プラットフォーム２００は、“工場Ｆ／ライン１”にトピック共通鍵を生成したとする。この場合、デバイス１のトピックを購読しているサブスクライバ、デバイス２のトピックを購読しているサブスクライバ、デバイス３のトピックを購読しているサブスクライバに、同じトピック共通鍵が供給される。
【００９３】
プラットフォーム２００は、トピック共通鍵を含むメッセージに、あて先のクライアント１００の識別情報を含めることができることを上記したが、例えば、プラットフォーム２００は以下のような方法で、あて先を指定してもよい。プラットフォーム２００は、あて先のクライアントの識別情報で分類したトピックを定義する。プラットフォーム２００は、トピックＴ１のトピックをクライアント１０１、１０２が購読している場合、“トピックＴ１／クライアント１０１”、“トピックＴ１／クライアント１０２”というようにトピックを定義する。プラットフォーム２００は、クライアント１０１にトピック共通鍵を送信する場合、“トピックＴ１／クライアント１０１”を指定してメッセージを送信する。プラットフォーム２００は、クライアント１０２にトピック共通鍵を送信する場合、“トピックＴ１／クライアント１０２”を指定してメッセージを送信する。
【００９４】
実施の形態においては、プラットフォーム２００の購読設定記憶部２５０に、トピックの購読が許可されているクライアント１００についての情報が予め格納されている例を説明したが、これに限られない。プラットフォーム２００は、購読設定記憶部２５０を備えていなくてもよい。この場合、例えば、クライアント１００が、自身が購読するトピックの情報を記憶しておき、クライアント証明書とともに購読するトピックを特定する情報をプラットフォーム２００に送信してもよい。プラットフォーム２００は、クライアント証明書とともに受信したトピックを特定する情報に基づいて、必要なトピック共通鍵をクライアント１００に送信すればよい。
【００９５】
実施の形態においては、データ処理装置１０がクライアント１０１及び１０２と、プラットフォーム２００と、データ配信部３００とを含む例を説明したが、これに限られない。例えば、クライアント１０１、１０２、プラットフォーム２００、データ配信部３００の機能を、ネットワークを介して相互に通信可能な４つのコンピュータが実現してもよい。
【００９６】
また、例えば、外部のシステム事業提供者が提供するサーバ上で動作するアプリケーションが、ブローカであるデータ配信部３００として機能してもよい。あるいは、クラウド上のサービスが、ブローカとして機能してもよい。
【００９７】
実施の形態においては、データ処理装置１０がデータを収集する処理を実行するクライアント１０１、収集されたデータの解析処理を実行するクライアント１０２を備える例を説明したが、これに限られない。
【００９８】
例えば、データ処理装置１０は、さらに、解析結果に基づいたフィードバックをＦＡ機器６００に供給するクライアント１０３を備えていてもよい。この場合、クライアント１０２は、解析結果を示すデータを含むメッセージを発行し、クライアント１０３はそのメッセージを購読する。例えば、クライアント１０３は、受信したメッセージに含まれる解析結果を示すデータに基づいて、ＦＡ機器６００を診断し、診断結果に基づいてＦＡ機器６００を制御する。例えば、クライアント１０３は、ＦＡ機器６００であるプログラマブルロジックコントローラを診断し、診断結果に基づいてプログラマブルロジックコントローラを制御するため、プログラマブルロジックコントローラの特定のメモリ領域に制御に必要な値を書き込んでもよい。
【００９９】
上述したように、データ処理装置１０におけるパブリッシャは、トピック毎に固有のトピック共通鍵によりデータを暗号化し、暗号化したデータを発行する。例えば、外部のサーバ、クラウド上のサービスをブローカとして利用する場合には、データの漏洩のリスクが高まるものの、暗号化したデータを送受信することで、パブリッシャとサブスクライバとは、安全にデータ交換を行うことができる。
【０１００】
上記のプログラムを記録する記録媒体としては、磁気ディスク、光ディスク、光磁気ディスク、フラッシュメモリ、半導体メモリ、磁気テープを含むコンピュータ読取可能な記録媒体を使用することができる。
【０１０１】
本発明は、広義の精神と範囲を逸脱することなく、様々な実施形態及び変形が可能とされるものである。また、上述した実施形態は、本発明を説明するためのものであり、本発明の範囲を限定するものではない。つまり、本発明の範囲は、実施形態ではなく、請求の範囲によって示される。そして、請求の範囲内及びそれと同等の発明の意義の範囲内で施される様々な変形が、本発明の範囲内とみなされる。
【符号の説明】
【０１０２】
Ｂ１  ブローカ、Ｐ１，Ｐ２  パブリッシャ、Ｓ１，Ｓ２  サブスクライバ、１  データ処理システム、Ｔ１，Ｔ２，Ｔ３  トピック、Ｍ１，Ｍ２  メッセージ、１０  データ処理装置、１１  ＣＰＵ、１２  メモリ、１３  通信インタフェース、１４  入力デバイス、１５  出力デバイス、１９  バス、１０１，１０２（１００）  クライアント、１１０，２１０  メッセージ送受信Ｉ／Ｆ部、１２０  クライアント鍵記憶部、１３０  クライアント証明書管理部、１４０  クライアント証明書送信部、１５０，２６２  トピック共通鍵記憶部、１６０  トピック共通鍵取得部、１７０，２７０  メッセージ管理部、２００  プラットフォーム、２２０  認証局公開鍵記憶部、２３０  クライアント証明書検証部、２４０  クライアント公開鍵記憶部、２５０  購読設定記憶部、２６０  トピック共通鍵管理部、２６１  トピック共通鍵生成部、２６３  トピック共通鍵送信部、３００  データ配信部、６０１，６０２（６００）  ＦＡ機器、７０１  ネットワーク
【要約】
プラットフォーム（２００）と少なくとも１つのクライアント（１００）とを含む複数のクライアント部は出版購読型モデルに従って通信する。プラットフォーム（２００）のトピック共通鍵管理部（２６０）は、トピックに対応付けられ、トピックを宛先とするメッセージを暗号化／復号するトピック共通鍵をクライアント（１００）に供給する。メッセージ管理部（２７０）は、トピックに対応付けられたトピック共通鍵で暗号化したメッセージを送信し、受信したメッセージをトピックに対応付けられたトピック共通鍵で復号する。クライアント（１００）のトピック共通鍵記憶部（１５０）は、プラットフォーム（２００）から供給されたトピック共通鍵を、トピックの識別情報と対応付けて記憶する。メッセージ管理部（１７０）は、トピック共通鍵で暗号化したメッセージを送信し、受信したメッセージをトピック共通鍵で復号する。【図１】
0006678842.tif 000002
【図２】
0006678842.tif 000003
【図３】
0006678842.tif 000004
【図４】
0006678842.tif 000005
【図５】
0006678842.tif 000006
【図６】
0006678842.tif 000007
【図７】
0006678842.tif 000008
【図８】
0006678842.tif 000009
【図９】
0006678842.tif 000010
【図１０】
0006678842.tif 000011
【図１１】
0006678842.tif 000012
【図１２】
0006678842.tif 000013
【図１３】
0006678842.tif 000014
【図１４】
0006678842.tif 000015
【図１５】
0006678842.tif 000016