以下、本発明の実施形態について、図面を参照して説明する。
図1は、本発明の実施形態による通信システム1の構成例を示すブロック図である。通信システム1は、例えば、クラウド10と、認証局20と、更新管理サーバ30と、MQTTブローカ40と、複数のデバイス50(デバイス50-1、50-2、…、50-N)とを備える。Nは任意の自然数である。クラウド10は、「サーバ装置」の一例である。デバイス50は、「クライアント装置」の一例である。
クラウド10と、認証局20と、更新管理サーバ30と、MQTTブローカ40と、デバイス50とは、通信ネットワークNWを介して互いに通信可能に接続される。デバイス50は、図示しない中継装置を介して、クラウド10と通信するようにしてもよい。
クラウド10は、データを集約するサーバ等のコンピュータ装置である。クラウド10は、デバイス50によりセンシングされたデータを受信(集約)する。デバイス50によりセンシングされるデータは、任意のデータであってよいが、例えば、監視カメラ等による撮像データ、或いは、温度センサ等により測定された温度データなどである。
クラウド10は、認証局20によって発行された電子証明書(サーバ証明書)を記憶する。クラウド10は、デバイス50と通信する場合、まずデバイス50との相互認証を行う。そして、クラウド10は、デバイス50が正当な装置であることが確認された場合に、デバイス50とのデータのやりとりを行う。相互認証は、例えば、後述する電子証明書を用いて行われる。この場合、通信先の装置から送られてきた電子証明書を相互に検証し、電子証明書が改ざん等されていない場合に通信先の装置が正当であると判定する。
デバイス50は、例えば、通信機能付きのセンサ端末である。デバイス50は、センシングしたデータを、MQTTブローカ40を介してクラウド10に送信する。MQTTブローカ40については後で詳しく説明する。デバイス50は、認証局20によって発行された電子証明書(クライアント証明書)を記憶する。デバイス50は、クラウド10と通信する場合、まずクラウド10との相互認証を行い、クラウド10が正当な装置であることが確認された場合に、通信を行う。
認証局20は、電子証明書を発行するサーバ等のコンピュータ装置である。認証局20は、電子証明書は、データの送受信に関わる装置が正当な装置であることを認証する電子的な情報である。電子証明書は、例えば、CSR(Certificate Signing Request)と呼ばれる電子文書(証明書署名要求データ)に基づいて認証局20により発行される電子署名付きの電子データである。電子証明書は、例えば、ITU-T(International Telecommunication Union-Telecommunication sector、国際通信連合)の公開鍵基盤(PKI(Public Key Infrastructure))の規格であるx.509に基づいて、生成される(例えば、https://tools.ietf.org/html/rfc5280を参照)。
認証局20は、外部装置からの要求に応じて電子証明書を発行する。ここでの外部装置は、主にクラウド10、デバイス50である。システムによって更新管理サーバ30やMQTTブローカ40が外部装置として機能してもよい。この場合、認証局20は、更新管理サーバ30やMQTTブローカ40からの要求に応じて電子証明書を発行する。認証局20は、外部装置から通知されたCSRに応じた電子証明書を生成し、生成した電子証明書を外部装置に送付することにより、電子証明書を発行する。
更新管理サーバ30は、電子証明書の期限管理を行うサーバ等のコンピュータ装置である。例えば、更新管理サーバ30は、電子証明書の有効期限を管理し、現時点から所定の期間(例えば、1か月)以内に有効期限を迎える電子証明書を記憶しているデバイス50に、電子証明書の更新を促す通知を行う。
更新管理サーバ30は、例えば、認証局20による電子証明書の発行を仲介し、発行された電子証明書のデータを記憶する。具体的に、更新管理サーバ30は、デバイス50からの証明書発行要求を受信し、受信した要求に基づいて、認証局20に当該デバイス50に電子証明書を発行するように依頼する。更新管理サーバ30は、認証局20から発行された電子証明書をデバイス50に送信する。
更新管理サーバ30は、認証局20に電子証明書の発行を依頼する際、発行される電子証明書を管理するための情報を、CSRに含めるようにする。電子証明書を管理するための情報は、少なくとも発行される電子証明書を識別できる情報が含まれていればよく、例えば、要求元のデバイス50(証明書発行要求をしたデバイス50)の識別情報である。要求元のデバイス50の識別情報としては、例えば、要求元のデバイス50に対して個々に割り当てられるUUID(Universally Unique Identifier)における128ビットの識別子が考えられる。
以下の説明では、電子証明書を管理するための情報としてデバイス50ごとに割り当てられるUUIDが用いられる場合を例に説明する。しかしながらこれに限定されることはない。電子証明書を管理するための情報は、電子証明書を識別できる情報が含まれていればよく、例えば、証明書が発行された日時、デバイス50のシリアル番号、及びこれらを組み合わせたものであってもよい。
更新管理サーバ30は、要求元のデバイス50から電子証明書の発行要求を受信すると、UUIDを含むCSRを生成する。更新管理サーバ30は、生成したCSRを認証局20に送信して電子証明書の発行を要求する。これによって、CSRを元とした電子証明書が認証局20により発行される。更新管理サーバ30は、第2電子文書を元とした電子証明書を認証局20から受信する。
更新管理サーバ30は、第2電子文書を元とした電子証明書を、UUIDと共に要求元のデバイス50に送信する。更新管理サーバ30は、電子証明書に関する情報を、UUIDに対応づけたものを、後述する証明書管理情報320として記憶する。電子証明書に関する情報は、特に電子証明書の期限に関するもの、例えば、電子証明書の発行日時、有効期限、更新時期などを示す情報である。ここで、電子証明書自体にUUIDが含まれている。このため、更新管理サーバ30はUUIDを意識することなく電子証明書をデバイス50に通知し、デバイス50が通知された電子証明書からUUIDを取り出すようにしてもよい。
更新管理サーバ30は、任意のタイミングで証明書管理情報320を参照し、更新を促す通知(以下、更新通知という)をするデバイス50を抽出する。更新管理サーバ30は、例えば、現時点から所定の期間内(例えば、1か月)以内に有効期限を迎える電子証明書を記憶しているデバイス50を、更新通知を行う対象の装置として抽出する。更新管理サーバ30は、UUIDを含む更新通知を生成し、生成した更新通知をMQTTブローカ40に通知する。
MQTTブローカ40は、装置間の通信を仲介するサーバ等のコンピュータ装置である。ここでの装置間の通信は、特に多数の装置同士の通信、例えばクラウド10と複数のデバイス50との通信、及び更新管理サーバ30と複数のデバイス50との通信を想定している。しかしながらこれに限定されない。MQTTブローカ40は、1対1の通信、例えば、更新管理サーバ30とクラウド10との通信を仲介してもよい。この場合にも、クラウド10と複数のデバイス50との通信の場合と同様の手法を適用することができる。
MQTTブローカ40は、MQTT(Message Queueing Telemetry Transport)プトロコル、特にパブリッシュ/サブスクライブ接続プロトコルにしたがった非同期通信を行う。MQTTブローカ40は、接続先の装置からトピックを指定したサブスクライブ(メッセージの受信登録)を受け付ける。トピックは、メッセージの内容を示す情報であって、例えば、「sensor_data」、「config_change」等で示される。「sensor_data」トピックは、センサによって測定されたデータ値がメッセージの内容であることを示す。「config_change」トピックは、センサのパラメータ変更がメッセージの内容であることを示す。
例えば、接続先の装置がクラウド10である場合、MQTTブローカ40は、クラウド10から「sensor_data」トピックを指定したサブスクライブを受け付ける。つまり、クラウド10は、「sensor_data」トピックをMQTTブローカ40にサブスクライブする。或いは、接続先の装置がデバイス50である場合、MQTTブローカ40は、デバイス50から「config_change」トピックを指定したサブスクライブを受け付ける。つまり、デバイス50は、「config_change」トピックをMQTTブローカ40にサブスクライブする。MQTTブローカ40は、トピックごとに、サブスクライブしてきた装置を記憶する。
MQTTブローカ40は、デバイス50からセンサによって測定されたデータ値を受信すると、そのデータ値を「sensor_data」トピックをサブスクライブした装置、つまりクラウド10にパブリッシュ(配信)する。これにより、デバイス50からの測定データが非同期にクラウド10に送信される。また、MQTTブローカ40は、クラウド10や図示しないメンテナンス装置からセンサパラメータの設定値や変更値を受信すると、その設定値や変更値を「config_change」トピックをサブスクライブした装置、つまりデバイス50にパブリッシュする。
ここで、比較例としてデバイス50からクラウド10に直に測定データを送信する場合を考える。この場合、デバイス50は、デバイス50とクラウド10との通信同期を確立させた上で、測定データを送信し、更に送信した測定データが正しく受信されたこと(例えば、Ack)を待つなどの処理が必要となる。このため、測定データを送信する場合における処理負担が大きくなる傾向にある。さらに、1つのクラウド10に対して複数のデバイス50が接続する構成であれば、クラウド10の処理負担も増大する傾向にあった。
これに対し、本実施形態では、デバイス50は、クラウド10が測定データを受信したか否かに関わらず、MQTTブローカ40に測定データを送信しておけば、測定データがクラウド10に配信される。すなわち、MQTTブローカ40を仲介させることによって、クラウド10とデバイス50との双方の処理負担を軽減させている。
本実施形態では、このパブリッシュ/サブスクライブ接続プロトコルにしたがった非同期通信を、電子証明書の期限管理にも適用する。具体的に、MQTTブローカ40は、更新管理サーバ30からデバイス50に送信される更新通知を仲介する。
MQTTブローカ40は、デバイス50から「UUID-a/…/need_update」トピックを指定したサブスクライブを受け付ける。ここで「UUID-a」は、特定のデバイス50(例えば、デバイス50-1)のUUIDである。つまり、デバイス50-1は、「UUID-a/…/need_update」トピックをMQTTブローカ40にサブスクライブする。これにより、デバイス50-1にUUID-aに対応する電子証明書の更新通知に係るメッセージがパブリッシュ(配信)されるようになる。
同様に、MQTTブローカ40は、デバイス50-2から「UUID-b/…/need_update」トピックを指定したサブスクライブを受け付ける。ここで「UUID-b」は、デバイス50-2のUUIDである。これにより、デバイス50-2にUUID-bに対応する電子証明書の更新通知に係るメッセージがパブリッシュ(配信)されるようになる。このように、複数のデバイス50のそれぞれが、自身が記憶する電子証明書に対応するUUIDを含む更新通知に係るトピックをサブスクライブし、自身が記憶する電子証明書の更新通知がパブリッシュ(配信)されるようにする。これにより、更新管理サーバ30とデバイス50の双方の負担を増加させることなく、デバイス50のそれぞれの電子証明書の有効期限を適切に管理することが可能である。
通信ネットワークNWは、例えば、インターネット、WAN(Wide Area Network)、LAN(Local Area Network)、プロバイダ装置、無線基地局、専用回線などのうちの一部または全部を含む通信網である。
図2は、本発明の実施形態による更新管理サーバ30の構成例を示すブロック図である。更新管理サーバ30は、例えば、通信部31と、記憶部32と、制御部33とを備える。通信部31は、通信ネットワークNWを介して、認証局20及びMQTTブローカ40等と通信を行う。
記憶部32は、記憶媒体、例えば、HDD(Hard Disk Drive)、フラッシュメモリ、EEPROM(Electrically Erasable Programmable Read Only Memory)、RAM(Random Access read/write Memory)、ROM(Read Only Memory)、またはこれらの記憶媒体の任意の組み合わせによって構成される。
記憶部32は、例えば、証明書管理情報320と、更新通知情報321とを記憶する。証明書管理情報320は、認証局20により発行された電子証明書の期限を管理するための情報であり、例えば、電子証明書の発行日や有効期限を示す情報である。更新通知情報321は、更新通知に関する情報であり、例えば、更新通知を行った日時などを示す情報である。
制御部33は、例えば、更新管理サーバ30がハードウェアとして備えるCPU(Central Processing Unit)に、記憶部32に記憶されたプログラムを実行させることによって実現される。制御部33は、例えば、認証部330と、証明書管理部331と、更新通知部332と、装置制御部333とを備える。
認証部330は、認証に係る処理を行う。認証に係る処理は、通信先の装置を認証する処理であって、例えば、相互認証、或いは片側認証を行う処理である。認証部330は、例えば、デバイス50から証明書の発行要求を受ける前に、デバイス50と相互認証を行う。認証部330は、デバイス50を認証した認証結果を証明書管理部331に出力する。
証明書管理部331は、デバイス50に対して発行される電子証明書を管理する。証明書管理部331は、デバイス50からの要求に応じて、認証局20に電子証明書の発行を依頼する。例えば、証明書管理部331は、認証後のデバイス50から公開鍵を取得する。また、証明書管理部331は、UUIDを生成する。証明書管理部331は、公開鍵とUUIDとを含むCSRを生成する。証明書管理部331は、生成したCSRを認証局20に送付して認証局20に電子証明書の発行を依頼する。証明書管理部331は、認証局20により発行された電子証明書を、認証局20から受信する。証明書管理部331は、受信した電子証明書を、UUIDと共にデバイス50に送付する。証明書管理部331は、デバイス50に送付した電子証明書に関する情報を生成し、生成した情報を、証明書管理情報320として記憶部32に記憶させる。
更新通知部332は、更新通知を行う。更新通知部332は、任意のタイミングで証明書管理情報320を参照し、更新通知を行うデバイス50を抽出する。更新通知部332は抽出したデバイス50に対応づけられたUUIDを含む更新通知を生成し、生成した更新通知を、通信部31を介してMQTTブローカ40に送信する。更新通知部332は、送信した更新通知に関する情報を生成し、生成した情報を、更新通知情報321として記憶部32に記憶させる。
装置制御部333は、更新管理サーバ30を統括的に制御する。装置制御部333は、例えば、認証時において、デバイス50から受信したデータを認証部330に出力する。装置制御部333は、認証局20により発行された電子証明書を証明書管理部331に出力する。
図3は、本発明の実施形態によるMQTTブローカ40の構成例を示すブロック図である。MQTTブローカ40は、例えば、通信部41と、記憶部42と、制御部43とを備える。通信部41は、通信ネットワークNWを介して、クラウド10、更新管理サーバ30、MQTTブローカ40、及びデバイス50と通信する。
記憶部42は、記憶媒体、例えば、HDD、フラッシュメモリ、EEPROM、RAM、ROM、またはこれらの記憶媒体の任意の組み合わせによって構成される。記憶部42は、例えば、トピック情報420を記憶する。トピック情報420は、仲介するメッセージのトピックに対応づけられたサブスクライバを示す情報である。サブスクライバは、サブスクライブ(メッセージの受信を登録)した装置である。例えば、センサによる測定値を示すメッセージのトピックであれば、トピック情報420は、「sensor_data」などを示す情報に、そのメッセージの受信を登録したクラウド10が対応づけられた情報である。
制御部43は、例えば、MQTTブローカ40がハードウェアとして備えるCPUに、記憶部42に記憶されたプログラムを実行させることによって実現される。制御部43は、例えば、メッセージ処理部430と、装置制御部431とを備える。
メッセージ処理部430は、パブリッシュ/サブスクライブ接続プロトコルにしたがった非同期通信を行う。メッセージ処理部430は、サブスクライブされたトピックを、サブスクライバに対応づけた情報を、トピック情報420として記憶する。メッセージ処理部430は、パブリッシャからのメッセージを受信する。パブリッシャは、メッセージをパブリッシュする装置である。例えば、「sensor_data」トピックに係るメッセージのパブリッシャはデバイス50である。メッセージ処理部430は、パブリッシャから受信したメッセージのトピックを抽出し、抽出したトピックに基づいてトピック情報420を参照する。メッセージ処理部430は、抽出したトピックに対応づけられたサブスクライバに、当該メッセージをパブリッシュ(配信)する。
装置制御部431は、MQTTブローカ40を統括的に制御する。装置制御部431は、例えば、通信部41によって受信されたメッセージをメッセージ処理部430に出力する。装置制御部431は、メッセージ処理部430によりパブリッシュ(配信)されるメッセージを、通信部41を介して配信先の装置に送信する。
図4は、本発明の実施形態によるデバイス50の構成例を示すブロック図である。デバイス50は、例えば、通信部51と、記憶部52と、制御部53とを備える。通信部51は、通信ネットワークNWを介して、クラウド10、更新管理サーバ30、MQTTブローカ40等と通信を行う。
記憶部52は、記憶媒体、例えば、HDD、フラッシュメモリ、EEPROM、RAM、ROM、またはこれらの記憶媒体の任意の組み合わせによって構成される。記憶部52は、例えば、鍵情報520と、証明書情報521と、センサ情報522とを記憶する。鍵情報520は、相互認証、或いは暗号化通信などに用いられる暗号鍵に関する情報である。証明書情報521は、認証局20によって発行された電子証明書に関する情報である。センサ情報522は、センサにより測定された測定データを示す情報である。
制御部53は、例えば、デバイス50がハードウェアとして備えるCPUに、記憶部52に記憶されたプログラムを実行させることによって実現される。制御部53は、例えば、証明書要求部530と、認証部531と、受信登録部532と、センサ情報取得部533と、装置制御部534とを備える。
証明書要求部530は、電子証明書の発行を要求する。証明書要求部530は、例えば、デバイス50の公開鍵の情報を更新管理サーバ30に送信して電子証明書の発行を要求する。また、証明書要求部530は、認証局20によって発行された電子証明書を更新管理サーバ30から取得し、取得した電子証明書を示す情報を、証明書情報521として、記憶部52に記憶させる。また、証明書要求部530は、更新管理サーバ30から電子証明書と共に送信されたUUIDを取得し、取得したUUIDを受信登録部532に出力する。
認証部531は、認証に係る処理を行う。認証部531が行う処理は、認証部330と同様であるためその説明を省略する。認証部531は、例えば、証明書要求部530による要求が行われた際に、更新管理サーバ30と相互認証を行う。
受信登録部532は、更新通知に係るメッセージの受信を登録する。受信登録部532は、証明書要求部530からUUIDを取得し、取得したUUIDを含む更新通知のトピックをMQTTブローカ40にサブスクライブする。
センサ情報取得部533は、センサによって測定された測定データを取得し、取得した測定データを、センサ情報522として記憶部52に記憶させる。装置制御部534は、デバイス50を統括的に制御する。装置制御部534は、例えば、センサによって測定された測定データをセンサ情報取得部533に出力する。装置制御部534は、MQTTブローカ40により更新通知がパブリッシュ(配信)された場合、当該更新通知を証明書要求部530に出力する。この場合、証明書要求部530は、電子証明書の有効期限を更新させる要求(以下、更新要求ともいう)を、更新管理サーバ30を介して認証局20に依頼する。
図5は、本発明の実施形態による証明書管理情報320の構成例を示す図である。証明書管理情報320は、例えば、証明書ID、UUID、発行要求受信日、発行日、有効期限などの項目を備える。証明書IDは、電子証明書を一意に識別する識別情報である。UUIDは、証明書IDにより特定される電子証明書の期限を管理するための情報であって、例えば、証明書を要求したデバイス50ごとにユニークに割り当てられた情報である。発行要求受信日は、デバイス50から証明書を要求する通知が受信された日である。発行日は、認証局20によって証明書が発行された日である。有効期限は、証明書の有効期限である。
図6は、本発明の実施形態による更新通知情報321の構成例を示す図である。更新通知情報321は、例えば、証明書ID、UUID、更新通知日、更新要求受信日などの項目を備える。証明書ID、UUIDは、証明書管理情報320における証明書ID、UUIDと同様である。更新通知日は、更新通知を行った日を示す情報である。更新要求受信日は、デバイス50から更新要求がなされた日を示す情報である。
図7は、本発明の実施形態によるトピック情報420の構成例を示す図である。トピック情報420は、例えば、トピックID、トピックなどの項目を備える。トピックIDは、トピックを一意に識別する識別情報である。トピックは、トピックIDで特定されるトピックの内容を示す情報である。この例では、トピックID(1)はデバイス50-1が記憶する電子証明書の更新通知に係るメッセージであることが示されている。トピックID(2)はデバイス50-2が記憶する電子証明書の更新通知に係るメッセージであることが示されている。トピックID(3)はデバイス50-3が記憶する電子証明書の更新通知に係るメッセージであることが示されている。
図8は、本発明の実施形態による通信システム1が行う処理の流れを示すシーケンス図である。
ステップS10において、あらかじめ(例えば、装置の製造時、工場出荷時など)、認証用の共通鍵Aをデバイス50と更新管理サーバ30とに記憶させておく。認証用の共通鍵Aは、例えば、TDES(Triple DES(Data Encryption Standard))や、AES(Advanced Encryption Standard)等の暗号方式にしたがって生成される共通鍵である。或いは、認証用の共通鍵Aは、RSA(Rivest-Shamir-Adleman cryptosystem)や、楕円曲線暗号の鍵ペアでもよい。
ステップS11において、デバイス50は、秘密鍵と公開鍵の鍵ペアを生成する。鍵ペアは、例えば、RSAや楕円曲線暗号の暗号方式にしたがって生成される鍵ペアである。
ステップS12において、デバイス50は、電子証明書の発行要求を更新管理サーバ30に送信する。デバイス50は、発行要求に、CSRに含める情報、どのようなデータの発行を要求するか、複数の認証局が存在する場合にどの認証局に証明書を発行してもらうか等の情報(例えば、データ名称、認証局名称、URI(Uniform Resource Identifier)等)を含めていてもよい。
ステップS13において、デバイス50と更新管理サーバ30との相互認証が行われる。相互認証は、例えば、ステップS10において双方の装置に記憶された共通鍵Aによる暗号を用いたチャレンジ&レスポンス方式にて行われる。チャレンジ側(例えば、デバイス50)は、レスポンス側(例えば、更新管理サーバ30)にチャレンジ(ホスト乱数)を送信する。レスポンス側は、ホスト乱数を暗号化する。暗号化は、チャレンジ側とレスポンス側とで予め共有している認証用の共通鍵を用いて行われる。レスポンス側は、暗号化したホスト乱数をチャレンジ側に通知する。チャレンジ側は、暗号化されたホスト乱数を復号する。復号は、チャレンジ側とレスポンス側とで予め共有している認証用の共通鍵を用いて行われる。チャレンジ側は、復号したホスト乱数と、送信したホスト乱数とが一致した場合に、レスポンス側が通信先として正当な装置であると認証する。相互に認証を行う場合、チャレンジ側とレスポンス側とを入れ替えて同様のやりとりを行うことにより認証が行われる。以下では、相互認証において互いの通信先の装置が正当な装置であると判定された場合の処理を説明する。
ステップS14において、デバイス50は、ステップS11において生成した公開鍵を更新管理サーバ30に送信する。ステップS15において、更新管理サーバ30は、UUIDを生成し、生成したUUIDを含めたCSRを生成する。例えば、更新管理サーバ30は、CSRのコモンネームにUUIDを含める。また、更新管理サーバ30は、ステップS14においてデバイス50から取得した公開鍵がCSRに含まれるようにする。ステップS16において、更新管理サーバ30は、CSRを認証局20に送信し、電子証明書の発行を要求する。
ステップS17において、認証局20は、通知されたCSRをインプットとして電子署名をした電子証明書を発行する。ステップS18において、認証局20は、発行した電子証明書を更新管理サーバ30に送信する。ステップS19において、更新管理サーバ30は、認証局20から受信した電子証明書を、UUIDとともにデバイス50に送信する。ステップS20において、デバイス50は、電子証明書、及びUUIDを更新管理サーバ30から受信し、受信したUUID、及び電子証明書を装置内に記憶させる。
ステップS21において、デバイス50は、UUIDに対応する電子証明書の更新通知のトピックを指定して、MQTTブローカ40にサブスクライブする。この場合のトピックは、例えば、「/sensor/security/certificate/{UUID}/need_update」である。これにより、MQTTブローカ40から当該トピックを含む更新通知がデバイス50にパブリッシュ(配信)されるようになる。
ステップS22において、クラウド10とデバイス50とのやり取り、例えば、相互認証が行われる。例えば、クラウド10は、デバイス50から送信された電子証明書を検証し、デバイス50から送信された電子証明書に改ざん等が認められない場合には、デバイス50が正当な装置であると判定する。この場合、デバイス50は、ステップS19において受信した電子証明書をクラウド10に送信する。デバイス50は、クラウド10から送信された電子証明書(サーバ証明書)を検証し、クラウド10から送信された電子証明書に改ざん等が認められない場合には、クラウド10が正当な装置であると判定する。さらに、ステップS22において、クラウド10とデバイス50との間で、相互認証後に共有された共通鍵を用いた暗号化通信が行われる。
なお、上述した図8のフローチャートでは、ステップS14においてデバイス50が公開鍵を更新管理サーバ30に送信する場合を例示して説明した。ここでデバイス50は、CSRを生成し、生成したCSRを公開鍵に代えて、更新管理サーバ30に送信してもよい。この場合、デバイス50は、UUIDを生成し、生成したUUIDをCSRに含めてもよい。あるいは、デバイス50の製造時等において、UUIDをデバイス50の記憶部52に記憶させておき、そのUUIDをCSRに含めるようにしてもよい。
図9は、本発明の実施形態による通信システム1が行う処理を説明する図である。この例では、複数のデバイス50(デバイス50-1~50-N)のそれぞれが、トピックを指定したサブスクライブを行う流れが模式的に示されている。例えば、デバイス50-1は、UUID-aの更新通知を指定したトピックをMQTTブローカ40にサブスクライブする。これにより、MQTTブローカ40は、UUID-aの更新通知を指定したトピックにデバイス50-1を登録する。この例では、UUID-aの更新通知を指定したトピックは、「…/{UUID-a}/…/need_update/…」で示されている。
図10は、本発明の実施形態による通信システム1が行う処理の流れを示すシーケンス図である。図10には、図9で示した処理の後において更新通知がなされるまでの処理の流れが示されている。
ステップS30において、更新管理サーバ30は、任意のタイミングにて証明書管理情報320を参照しデバイス50に発行された電子証明書の有効期限を確認し、更新通知をすべきデバイス50の有無を判定する。以下では、更新通知をすべきデバイス50があった場合の処理について説明する。
ステップS31において、更新管理サーバ30は、更新通知をMQTTブローカ40に送信する。ここでの更新通知にはUUIDが含まれており、特定のUUIDにおける更新通知であることがトピックとして指定されている。なお、更新通知の内容は、デバイス50が認識可能な情報であれば任意の情報(例えば、「true」という文字列)であってよい。
ステップS32において、MQTTブローカ40は、更新管理サーバ30から通知された更新通知のトピックをサブスクライブしているデバイス50に、更新通知をパブリッシュする。
ステップS32において、デバイス50は、パブリッシュされた更新通知から電子証明書に更新が必要であると判定し、更新するための処理を開始する。例えば、デバイス50は、秘密鍵と公開鍵の鍵ペアを生成する。鍵ペアを生成する方法は、上述したステップS11と同様である。ステップS32では、ステップS11とは異なる新たな鍵ペアを生成するようにしてもよいし、ステップS11と同じ鍵ペアを再利用するようにしてもよい。
ステップS33において、デバイス50は、更新要求を更新管理サーバ30に通知する。この場合、デバイス50は、更新要求にデバイス50に割り当てられたUUIDが含まれるようにする。ステップS34~S42に示す処理は、上述したステップS16~S21に示す処理と同等である。このため、これらの説明を省略する。
図11は、本発明の実施形態による通信システム1が行う処理を説明する図である。図11には、更新管理サーバ30により通知された更新通知が、特定のデバイス50に配信される流れが模式的に示されている。この例では、更新管理サーバ30が、トピックが「…/{UUID-b}/…/need_update/…」である更新通知を、MQTTブローカ40にパブリッシュしたことが示されている。そして、MQTTブローカ40は、そのトピックを登録したデバイス50-2に当該更新通知をパブリッシュしたことが示されている。
図12は、本発明の実施形態による通信システム1が行う処理を説明する図である。図12には、更新通知を受けて、デバイス50が証明書を更新する流れが模式的に示されている。この例では、デバイス50-2が、更新管理サーバ30にCSR(ここでは、証明書更新リクエスト)を送信する。この場合、デバイス50と更新管理サーバ30とは相互認証を行い、互いに装置が正当であることを認証した後に電子証明書を更新する処理を開始する。
以上説明したように、実施形態の通信システム1は、デバイス50と、更新管理サーバ30と、MQTTブローカ40とを備える。デバイス50は、通信システム1において複数設けられている。それぞれのデバイス50は、それぞれの電子証明書を記憶する。更新管理サーバ30は、複数のデバイス50のそれぞれが記憶する電子証明書における期限管理を行う。MQTTブローカ40は、複数のデバイス50のそれぞれと更新管理サーバ30との通信を仲介する。複数のデバイス50のそれぞれは、自身が記憶する電子証明書の更新通知の受信をMQTTブローカ40に依頼する。更新管理サーバ30は、電子証明書における更新通知をMQTTブローカ40に送信する。MQTTブローカ40は、更新管理サーバ30から受信した通知と、複数のデバイス50のそれぞれから依頼された内容とに基づいて、当該通知において期限管理の対象となる電子証明書を記憶するデバイス50に、当該通知を配信する。これにより、MQTTブローカ40が更新管理サーバ30から通知された更新通知を、対象のデバイス50に配信することができる。したがって、1つの更新管理サーバ30が多数のデバイス50と直接に更新通知を通信する場合と比較して、双方の処理を増大させることなく、デバイス50のそれぞれが、自身が記憶する電子証明書の更新通知を受信することができる。すなわち、多数のデバイス50を備える場合であっても、それぞれの電子証明書の有効期限を適切に管理することが可能である。
通信システム1は、「期限管理システム」の一例である。
デバイス50は、「クライアント装置」の一例である。
MQTTブローカ40は、「通信処理サーバ」の一例である。
電子証明書は、有効期限が設定されており、「有期情報」の一例である。なお、上述した実施形態では電子証明書の有効期限を管理して更新通知を行う場合を例示して説明したが、これに限定されない。「有期情報」は、少なくとも有効期限を管理すべき情報であればよく、例えば、パスワードや暗号鍵など証明書以外の情報であってもよい。この場合、その「有期情報」の有効期限など、期限に関する情報が証明書管理情報320に記憶される。
更新通知は、「期限管理に関する通知」の一例である。
実施形態の通信システム1における更新通知を配信する仕組みがパブリッシュ/サブスクライブ接続プロトコルに基づいて行われていてもよい。つまり、複数のデバイス50のそれぞれは、パブリッシュ/サブスクライブ接続プロトコルに基づいて、自身が記憶する電子証明書の更新に関するトピックをMQTTブローカ40にサブスクライブする。更新管理サーバ30は、パブリッシュ/サブスクライブ接続プロトコルに基づいて、電子証明書における更新通知をMQTTブローカ40にパブリッシュする。MQTTブローカ40は、複数のデバイス50のそれぞれからサブスクライブされたトピックを記憶し、更新管理サーバ30によってパブリッシュされた通知に含まれるトピックをサブスクライブしたデバイス50に、当該通知をパブリッシュする。これにより、パブリッシュ/サブスクライブ接続プロトコルを利用した非同期通信により、デバイス50のそれぞれが、自身が記憶する電子証明書の更新通知を受信することができ、上述した効果と同様の効果を奏する。また、センサによる測定データを集約するシステムにおいては、パブリッシュ/サブスクライブ接続プロトコルを利用したデータ集約が行われることが多い。このため、パブリッシュ/サブスクライブ接続プロトコルを利用したデータ集約を行うシステムにおいては、パブリッシュ/サブスクライブ接続プロトコルを利用した既存の通信装置(MQTTブローカ40)を用いて、つまり専用の装置を追加することなく電子証明書の更新を適切に管理することが可能である。
実施形態の通信システム1では、デバイス50は、電子証明書に対応づけられたUUID含むトピックを、MQTTブローカ40にサブスクライブする。これにより、実施形態の通信システム1では、複数のデバイス50のうち、更新が必要な電子証明書を記憶するデバイス50に特化して更新通知を通知することができる。
実施形態の通信システム1では、デバイス50は、認証局20によって発行されたクライアント証明書を期限管理対象の電子証明書として記憶する。これにより、実施形態の通信システム1では、クライアント証明書に有効期限を設定して安全性を維持させることができ、尚且つ、システムの負荷を増大させることなく有効期限を適切に管理することができる。
実施形態の通信システム1では、デバイス50は、更新管理サーバ30を介して、認証局20にクライアント証明書の発行を要求する要求通知を行う。更新管理サーバ30は、要求通知に基づいて、デバイス50のUUIDを含むクライアント証明書の発行を認証局20に要求する。これにより、実施形態の通信システム1では、UUIDを含む電子証明書を発行することができ、UUIDを用いて期限管理を行うことが可能となる。
実施形態の通信システム1では、更新管理サーバ30は、認証局20よって発行されたクライアント証明書を、UUIDと共に、デバイス50に送信する。これにより、実施形態の通信システム1では、UUID(電子証明書の期限管理を行うための情報)をデバイス50が取得することが可能となる。
実施形態の通信システム1では、デバイス50は、更新管理サーバ30から受信したクライアント証明書に含まれるUUID、又は更新管理サーバ30から受信したクライアント証明書と共に受信したUUIDを含むトピックを、MQTTブローカ40にサブスクライブする。これにより、実施形態の通信システム1では、UUID(電子証明書の期限管理を行うための情報)をトピックとしたサブスクライブを行うことが可能となる。
なお、上述の各実施の形態で説明した機能は、ハードウェアを用いて構成するにとどまらず、ソフトウェアを用いて各機能を記載したプログラムをコンピュータに読み込ませて実現することもできる。また、各機能は、適宜ソフトウェア、ハードウェアのいずれかを選択して構成するものであってもよい。
上述した実施形態における通信システム1、更新管理サーバ30、MQTTブローカ40、デバイス50の全部または一部をコンピュータで実現するようにしてもよい。その場合、この機能を実現するためのプログラムをコンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピュータシステムに読み込ませ、実行することによって実現してもよい。なお、ここでいう「コンピュータシステム」とは、OSや周辺機器等のハードウェアを含むものとする。また、「コンピュータ読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ROM、CD-ROM等の可搬媒体、コンピュータシステムに内蔵されるハードディスク等の記憶装置のことをいう。さらに「コンピュータ読み取り可能な記録媒体」とは、インターネット等のネットワークや電話回線等の通信回線を介してプログラムを送信する場合の通信線のように、短時間の間、動的にプログラムを保持するもの、その場合のサーバやクライアントとなるコンピュータシステム内部の揮発性メモリのように、一定時間プログラムを保持しているものも含んでもよい。また上記プログラムは、前述した機能の一部を実現するためのものであってもよく、さらに前述した機能をコンピュータシステムにすでに記録されているプログラムとの組み合わせで実現できるものであってもよく、FPGA等のプログラマブルロジックデバイスを用いて実現されるものであってもよい。
以上、この発明の実施形態について図面を参照して詳述してきたが、具体的な構成はこの実施形態に限られるものではなく、この発明の要旨を逸脱しない範囲の設計等も含まれる。