JPWO2009078217A1

JPWO2009078217A1 - ネットワークシステムおよびデータ送信方法

Info

Publication number: JPWO2009078217A1
Application number: JP2009546178A
Authority: JP
Inventors: 信弥加來
Original assignee: Konica Minolta Inc
Current assignee: Konica Minolta Inc
Priority date: 2007-12-19
Filing date: 2008-10-20
Publication date: 2011-04-28
Also published as: WO2009078217A1

Abstract

管理ノード（ＳＮ）は、乱数ノード（ＲＮ）から受信した乱数（２１４ａ）と、予め格納する秘密情報（２１６ａ）とを用いて一時鍵（２１０ａ）を生成し、この一時鍵（２１０ａ）を用いて、ユーザが入力する上述のようなコマンド（２０６ａ）を暗号化する。各監視カメラ（ＳＣ）では、乱数ノード（ＲＮ）から受信した乱数（３１４ａ）と、予め格納する秘密情報（３１６ａ）とを用いて一時鍵（３１０ａ）を生成し、この一時鍵（３１０ａ）を用いて、受信した暗号化データを復号化する。管理ノード（ＳＮ）および監視カメラ（ＳＣ）の各々は、このリセット指令を受信すると、その時点における一時鍵をリセットする。

Description

この発明は、互いにデータ通信可能な複数の情報処理装置を含むネットワークシステムおよびそのネットワークシステムにおけるデータ送信方法に関し、特にある情報処理装置から１つ以上の他の情報処理装置へのデータ送信を暗号化して行なうことが可能な構成に関する。

複数の情報処理装置が接続されたネットワークにおいて、ある情報処理装置から他の複数の情報処理装置へデータを高速に送信する方法として、マルチキャストと呼ばれる方式が知られている。このマルチキャストとは、複数の宛先に対して同一のデータ（パケット）を送信する方法である。

従来、このようなマルチキャストにおいて暗号化を行なう方法としては、予め定めたれた共通の暗号化鍵を用いる形式が採用されていた。これは、マルチキャストでは１対ｎのデータ通信となるので、暗号化鍵の交換や更新を動的に行なうことが複雑化するからである。しかしながら、このような固定の暗号化鍵を用いる形式では、この暗号化鍵が漏洩または解読されてしまうと、秘匿性を維持することができなくなる。さらに、この暗号化鍵が漏洩または解読されたことを検出することは難しく、送受信するデータが知らない間に漏洩する危険性もあった。

そのため、動的に暗号化鍵を変更可能な暗号化方法に対するニーズがあった。たとえば、特開平１１−１７６７３号公報（特許文献１）には、通信用端末間のデータ通信の暗号化方法として、各通信用端末が擬似乱数生成器によって生成される擬似乱数系列を用いて暗号化または復号化を行なう構成が開示されている（たとえば、図１７）。この構成では、各擬似乱数生成器が予め配布された共有の秘密の鍵を初期値として擬似乱数系列を生成する。また、暗号通信の終了時における内部変数を次回の共通鍵として用いることも開示されている。その他、関連する技術を開示するものとして、特開２００５−３０３７８４号公報（特許文献２）、特表２００３−５０３９４９号公報（特許文献３）、特開２０００−２４２１６８号公報（特許文献４）、および特開２００２−２１７８９３号公報（特許文献５）などが挙げられる。
特開平１１−１７６７３号公報特開２００５−３０３７８４号公報特表２００３−５０３９４９号公報特開２０００−２４２１６８号公報特開２００２−２１７８９３号公報

しかしながら、特開平１１−１７６７３号公報（特許文献１）に開示される構成では、各通信用端末における擬似乱数生成器の間のタイミングがずれてしまうと、暗号化および復号化を正しく行なうことができなくなるという課題があった。そのため、一つの情報処理装置から多数の情報処理装置へのマルチキャストに適用しようとすると、宛先に指定された一部の情報処理装置における擬似乱数系列の生成タイミングがずれることも想定され、この結果、安定したデータ通信を行なうことができないという課題があった。

この発明は、このような課題を解決するためになされたものであり、その目的は、ある情報処理装置から１つ以上の他の情報処理装置へ同一のデータを送信する場合に、秘匿性の高い暗号化方式を用いて安定的にデータ送信を行なうことのできるネットワークシステムおよびそのネットワークシステムにおけるデータ送信方法を提供することである。

この発明のある局面に従うネットワークシステムは、第１情報処理装置と、少なくとも１つの第２情報処理装置とを含む。第１情報処理装置は少なくとも１つの第２情報処理装置へデータ送信可能である。第１情報処理装置は、送信すべきデータを一時鍵を用いて暗号化することで暗号化データを生成するための暗号化部と、前回の暗号化処理で用いられた一時鍵を所定規則に従って更新したうえで、引き続く暗号化処理に使用させる第１更新部とを含む。少なくとも１つの第２情報処理装置の各々は、第１情報処理装置から受信する暗号化データを一時鍵を用い復号化するための復号化部と、前回の復号化処理で用いられた一時鍵を所定規則に従って更新したうえで、引き続く復号化処理に使用させる第２更新部とを含む。第１情報処理装置および少なくとも１つの第２情報処理装置の各々は、リセット指令に応答して、一時鍵を所定値に更新する第３更新部をさらに含む。

好ましくは、第１情報処理装置および少なくとも１つの第２情報処理装置の各々は、第１データ列を含む共通の秘密情報を予め格納しており、リセット指令は、第２データ列を含む。第３更新部は、一時鍵を、第１データ列とリセット指令に含まれる第２データ列とに基づいて生成される値に更新する。

さらに好ましくは、リセット指令に含まれる第２データ列は、乱数として生成される。
好ましくは、第３更新部は、リセット指令に応答して一時鍵を予め定められた初期値に更新する。

好ましくは、ネットワークシステムは、第１情報処理装置および少なくとも１つの第２情報処理装置の各々へリセット指令を送信するための第３情報処理装置をさらに含む。

好ましくは、少なくとも１つの第２情報処理装置の各々は、第１情報処理装置からの暗号化データを受信した場合に、第１情報装置に当該暗号化データの受信確認を通知し、第１更新部は、暗号化データを送信後、当該暗号化データについての受信確認を少なくとも１つの第２の情報処理装置のすべてから受信した場合に、一時鍵を更新する。

好ましくは、少なくとも１つの第２情報処理装置の各々は、第１情報処理装置からの暗号化データを受信した場合に、第１情報装置に当該暗号化データの受信確認を通知し、暗号化部は、暗号化データを送信後、当該暗号化データについての受信確認を少なくとも１つの第２情報処理装置のすべてから受信した場合に、次に送信すべきデータを暗号化する。

好ましくは、第１更新部は、一時鍵および一時鍵の生成に用いるデータの少なくとも一方を、インクリメント、デクリメント、行入れ換え、ビットシフトの少なくとも１つを含む処理によって、一時鍵を更新する。

この発明の別の局面に従えば、第１情報処理装置と少なくとも１つの第２情報処理装置とを含むネットワークシステムにおいて、第１情報処理装置から少なくとも１つの第２情報処理装置へデータを送信する方法を提供する。データ送信方法は、第１情報処理装置が、送信すべきデータを一時鍵を用いて暗号化した暗号化データを少なくとも１つの第２情報処理装置へ送信するステップと、少なくとも１つの第２情報処理装置の各々が、第１情報処理装置から受信した暗号化データを一時鍵を用い復号化するステップと、第１情報処理装置が、暗号化に用いた一時鍵を所定規則に従って更新するステップと、少なくとも１つの第２情報処理装置の各々が、復号化に用いた一時鍵を所定規則に従って更新するステップと、少なくとも１つの第２情報処理装置の各々が、リセット指令に応答して、各々が保持する一時鍵を所定値に更新するステップとを含む。

この発明によれば、ある情報処理装置から１つ以上の他の情報処理装置へ共通のデータを送信する場合に、秘匿性の高い暗号化方式を用いて安定的にデータ送信を行なうことができる。

この発明の実施の形態１に従うネットワークシステムの概略構成図である。この発明の実施の形態１に従う管理ノードおよび乱数ノードの代表例であるパーソナルコンピュータの概略のハードウェア構成を示す模式図である。この発明の実施の形態１に従う管理ノードにおける制御構造を示す概略図である。この発明の実施の形態１に従う監視カメラにおける制御構造を示す概略図である。この発明の実施の形態１に従う乱数ノードにおける制御構造を示す概略図である。この発明の実施の形態１に従うネットワークシステムにおける各部の処理内容を示す模式図である。乱数ノードからリセット指令がマルチキャストされる処理を示す模式図である。管理ノードから暗号化データがマルチキャストされる処理を示す模式図である。管理ノードにおける処理をより詳細に示す図である。監視カメラの各々における処理をより詳細に示す図である。この発明の実施の形態１における一時鍵の更新処理を説明するための図である。この発明の実施の形態１における一時鍵の更新処理の別形態を説明するための図である。この発明の実施の形態１に従うネットワークシステムにおける処理手順を示すフローチャートである。監視カメラが追加された場合の処理を示す模式図である。監視カメラが暗号化データの受信に失敗した場合を示す模式図である。この発明の実施の形態３に従うネットワークシステムにおける受信確認の通知に係る処理内容を示す模式図である。この発明の実施の形態３に従うネットワークシステムにおける暗号化データの再送処理を示す模式図である。同一の暗号化データが複数回にわたってマルチキャストされた場合における監視カメラにおける処理を示す図である。図１８に示す処理によって生じる結果を示す模式図である。この発明の実施の形態３に従う管理ノードにおける暗号化データ送信の処理手順を示すフローチャートである。この発明の実施の形態３に従う各監視カメラにおける暗号化データ受信の処理手順を示すフローチャートである。この発明の実施の形態３の変形例に従う管理ノードにおける暗号化データ送信の処理手順を示すフローチャートである。

符号の説明

２内部バス、４ディスプレイ部、６ネットワークインターフェイス（Ｉ／Ｆ）部、８入力部、１０ＣＰＵ、１２メモリ部、１４ＣＤ−ＲＯＭドライブ、１４ａＣＤ−ＲＯＭ、１６フレキシブルディスクドライブ、１６ａフレキシブルディスク、１８ハードディスク部（ＨＤＤ）、１０２，２０２，３０２データ送受信部、１０４，２０４，３０４暗号化／復号化部、１０６，２０６，３０６コマンド生成／読取部、１０８，２０８，３０８送信相手リスト保持部、１１０，２１０，３１０一時鍵生成部、１１２，２１２，３１２一時鍵更新部、１１４，２１４，３１４乱数保持部、１１６，２１６，３１６秘密情報保持部、１１８，２１８，３１８リセット部、１２０乱数生成部、２０４ａ暗号化データ、２０６ａコマンド、２１０ａ，３１０ａ一時鍵、２１４ａ，３１４ａ乱数、２１６ａ，３１６ａ秘密情報、２２０，３２０データ作成部、３０４ａコマンド、３２２センサ処理部、３２４センサ部、ＲＮ乱数ノード、ＳＣ，ＳＣ１〜ＳＣ８１監視カメラ、ＳＮ管理ノード。

この発明の実施の形態について、図面を参照しながら詳細に説明する。なお、図中の同一または相当部分については、同一符号を付してその説明は繰返さない。

［実施の形態１］
（ネットワークシステムの全体構成）
図１は、この発明の実施の形態１に従うネットワークシステムの概略構成図である。

図１を参照して、本実施の形態に従うネットワークシステムは、第１情報処理装置に相当する管理ノードＳＮと、第２情報処理装置に相当する監視カメラＳＣ１〜ＳＣ８０と、第３情報処理装置に相当する乱数ノードＲＮとを含む。各ノードおよび各装置は、同じマルチキャストグループに属しており、ネットワークを介して互いにデータ通信可能に構成される。

本実施の形態に従うネットワークシステムでは、多数の監視カメラＳＣ１〜ＳＣ８０（これらを総称して、「監視カメラＳＣ」とも記す。）の各々で撮影された画像を管理ノードＳＮで収集することが可能であるとともに、管理ノードＳＮからコマンドなどを送信することで監視カメラＳＣ１〜ＳＣ８０の遠隔管理が可能である。なお、遠隔管理とは、一例として、監視カメラＳＣ１〜ＳＣ８０のフレームレートの変更や撮影モード変更（たとえば、昼間モードから夜間モードへの切り換え）などである。なお、本実施の形態では、主に、管理ノードＳＮから監視カメラＳＣ１〜ＳＣ８０に対して同じコマンドを一斉送信する場合の処理について説明する。

また、乱数ノードＲＮは、後述するように本実施の形態に従うネットワークシステムにおいて、暗号化通信を行なうための暗号化鍵の生成および更新を行なうための乱数（データ列）を生成し、管理ノードＳＮおよび監視カメラＳＣ１〜ＳＣ８０へ定期的あるいは何らかのイベント発生毎に一斉送信する。

このような監視カメラＳＣ１〜ＳＣ８０と管理ノードＳＮとの間で送受信されるデータは、秘匿性を保つ必要がある。なぜならば、監視カメラＳＣは防犯などの観点から設けられるものであり、悪意をもった部外者によって遠隔管理されてしまうと、その監視機能が果たされなくなるおそれがあるからである。そのため、本実施の形態に従うネットワークシステムでは、少なくとも管理ノードＳＮから監視カメラＳＣ１〜ＳＣ８０に対して、暗号化されたコマンドが送信される。

なお、本実施の形態に従うネットワークシステムは、「センサネットワーク」と称される構成に好適である。このセンサネットワークは、主として無線ネットワークに多数のセンサを接続したものであり、管理ノードからセンサに対してコマンドが送信され、かつ各センサから管理ノードへ集中的にデータが送信される。このようなセンサネットワークに用いられるセンサは、そのスペックが比較的低くても十分であり、小型化・軽量化・低消費電力化・価格などの面において有利である。なお、当然のことながら、ネットワークとして無線ネットワーク以外にも有線ネットワークを採用してもよい。

なお、本実施の形態に従うネットワークシステムでは、監視カメラＳＣ１〜ＳＣ８０と管理ノードＳＮとの間で双方向のデータ通信が可能な構成を想定しているが、いずれか一方が送信専用であり、他方が受信専用であってもよい。

（ハードウェア構成）
図２は、この発明の実施の形態１に従う管理ノードＳＮおよび乱数ノードＲＮの代表例であるパーソナルコンピュータの概略のハードウェア構成を示す模式図である。

図２を参照して、代表的に、本実施の形態に従う管理ノードＳＮは、オペレーティングシステムを含む各種プログラムを実行するＣＰＵ１０と、ＣＰＵ１０でのプログラムの実行に必要なデータを一時的に記憶するメモリ部１２と、ＣＰＵ１０で実行されるプログラムを不揮発的に記憶するハードディスク部（ＨＤＤ）１８とを含む。このようなプログラムは、ＣＤ−ＲＯＭ（Compact Disk-Read Only Memory）ドライブ１４またはフレキシブルディスク（ＦＤ：Flexible Disk）ドライブ１６によって、それぞれＣＤ−ＲＯＭ１４ａまたはフレキシブルディスク１６ａなどから読取られる。

ＣＰＵ１０は、キーボードやマウスなどの入力部８を介してユーザによる操作要求を受け取るとともに、プログラムの実行によって生成される画面出力をディスプレイ部４へ出力する。また、ＣＰＵ１０は、ＬＡＮカードなどのネットワークインターフェイス（Ｉ／Ｆ）部６を介して、監視カメラＳＣや乱数ノードＲＮとの間でデータ通信を行なう。なお、これらの部位は、内部バス２を介して互いに接続される。

本実施の形態に従う乱数ノードＲＮについても、上述の管理ノードＳＮのハードウェア構成と同様であるので、詳細な説明は繰返さない。また、監視カメラＳＣは、代表的に、比較的簡易な機能のハードウェアで実現される。

なお、第１〜第３情報処理装置としては、マルチキャスト通信が可能な通信プロトコルおよびアプリケーションを実装可能な装置であれば、どのような装置であってもよい。具体的には、第１〜第３情報処理装置の実現例としては、複写機能やファクシミリ機能などを搭載したＭＦＰ（Multi Function Peripheral）、携帯電話、ＰＤＡ（Personal Digital Assistance）、ネットワークファクシミリなどを用いることができる。あるいは、専用のハードウェアおよびファームウェアなどからなる装置、単機能なセンサ装置、これらの装置を適宜組み合わせたもののいずれであってもよい。

なお、管理ノードＳＮ、乱数ノードＲＮ、監視カメラＳＣは、論理的にデータ通信可能な状態を形成できれば、必ずしも同一階層のネットワークに物理的に接続されている必要はない。あるいは、ノードという概念を有さない複数の機能の集合体、または複数の機能が分散した構成であってもよい。

（暗号化鍵の更新処理）
本実施の形態に従うネットワークシステムでは、管理ノードＳＮおよび各監視カメラＳＣがそれぞれ共通の一時鍵を用いて暗号化処理を行なう。すなわち、管理ノードＳＮがコマンドなどのデータを一時鍵を用いて暗号化した暗号化データを監視カメラＳＣへ送信し、各監視カメラＳＣが管理ノードＳＮと同じ一時鍵を用いて受信した暗号化データを復号する。特に、管理ノードＳＮおよび各監視カメラＳＣは、暗号化／復号化処理を実行するたびに一時鍵を共通の規則（ルール）に従って更新する。すなわち、管理ノードＳＮおよび監視カメラＳＣの各々は、両者における値を同一に保つように、一時鍵を自律的に順次更新する。これにより、１回の送信および受信の実行毎に暗号化に用いられる一時鍵が更新されることになるので秘匿性を高めることができる。

さらに、本実施の形態に従うネットワークシステムでは、乱数ノードＲＮが定期的あるいはイベント発生時にリセット指令を一斉送信し、管理ノードＳＮおよび監視カメラＳＣの各々は、このリセット指令を受信すると、その時点における一時鍵をリセットする。そのため、何らかの通信エラーなどの発生によって、管理ノードＳＮおよび各監視カメラＳＣが共通に保持する一時鍵が一致しないものとなっていたとしても、そのリセット指令が送信された時点で、管理ノードＳＮおよび各監視カメラＳＣにおける一時鍵を再度一致させることができる。このような構成によって、管理ノードＳＮと各監視カメラＳＣとの間のデータ通信を安定して行なうことができる。

なお、本実施の形態では、管理ノードＳＮおよび各監視カメラＳＣが所定のデータ列からなる秘密情報を予め保持しており、この秘密情報と後述する乱数とに基づいて、一時鍵が生成される。

以下、より詳細な構成について例示する。
（管理ノードの機能構成）
図３は、この発明の実施の形態１に従う管理ノードＳＮにおける制御構造を示す概略図である。図３に示す制御構造は、代表的に、ＣＰＵ１０（図２）が、ハードディスク部１８（図２）に予め格納されたプログラムをメモリ部１２（図２）に展開して実行することで実現される。

図３を参照して、管理ノードＳＮは、データ送受信部２０２と、暗号化／復号化部２０４と、コマンド生成／読取部２０６と、送信相手リスト保持部２０８と、一時鍵生成部２１０と、一時鍵更新部２１２と、乱数保持部２１４と、秘密情報保持部２１６と、リセット部２１８と、データ作成部２２０とをその機能として含む。

秘密情報保持部２１６は、暗号化に用いられる一時鍵を生成するための秘密情報を保持している。この秘密情報は、所定のビット数からなるデータ列であり、後述する一時鍵と同じビット数のデータ列が採用されることが好ましい。

乱数保持部２１４は、秘密情報とともに一時鍵の生成に用いられる乱数を保持する。この乱数保持部２１４に保持される乱数は、暗号化／復号化部２０４における復号化処理の実行に伴って更新され、あるいは乱数ノードＲＮからのリセット指令などに応じて、その値がリセットされる。なお、乱数保持部２１４に保持される乱数の保持時間（ライフ）や保持量（数）などについては適宜設計することができる。本実施例では、乱数保持部２１４には、十分な量の乱数が蓄えられており、必要に応じて任意に呼び出すことができ、その値の更新も瞬時に実行可能であるものとする。

一時鍵生成部２１０は、秘密情報保持部２１６に保持されている秘密情報と、乱数保持部２１４に保持されている乱数とを用いて、所定の演算処理によって一時鍵を生成する。本実施の形態では、一時鍵を生成するための演算処理の代表例として、排他的論理和（ＸＯＲ：Exclusive OR）を用いる場合について例示する。この一時鍵生成部２１０が生成した一時鍵は暗号化／復号化部２０４へ随時出力される。

一時鍵更新部２１２は、暗号化／復号化部２０４で一回の暗号化処理（復号化処理）が実行されると、当該暗号化処理で用いられた一時鍵を所定規則に従って更新し、引き続く暗号化処理においては更新後の一時鍵を使用させる。より具体的には、一時鍵更新部２１２は、乱数保持部２１４に保持されている乱数を読み出し、この読み出した乱数を所定規則に従って更新（たとえば、インクリメント）する。これにより、引き続く暗号化処理に用いられる一時鍵は、この更新後の乱数に基づいて生成されるので、前回の暗号化処理で用いられた一時鍵とは異なったものとなる。なお、一時鍵そのものを随時更新してもよいが、このように一時鍵を生成するための元データの一部のみを更新することで、秘密情報またはその生成ロジックが秘密に保たれている限り、随時更新される一時鍵を予測することがより困難になり、安全性の観点からはより好ましい。

暗号化／復号化部２０４は、コマンド生成／読取部２０６から出力される送信すべきデータを、一時鍵生成部２１０で生成された一時鍵を用いて暗号化することで暗号化データを生成する。また、暗号化／復号化部２０４は、データ送受信部２０２で受信された暗号化データを、一時鍵生成部２１０で生成された一時鍵を用いてコマンドなどのデータに復号化する。なお、暗号化ロジックとしては、共通鍵暗号方式であればいずれの方式であっても採用することができる。このような共通鍵暗号方式の代表例としては、ＡＥＳ（Advanced Encryption Standard）、ＤＥＳ（Data Encryption Standard）、ＩＤＥＡ（International Data Encryption Algorithm）、ＦＥＡＬ（Fast data Encipherment ALgorithm）、ＲＣ５（Ron’s Code 5）、ＣＡＳＴなどが知られている。

データ送受信部２０２は、ネットワーク上を流れるデータパケットのうち自ノード宛のデータパケットを選択的に受信して、暗号化／復号化部２０４またはリセット部２１８へ出力する。また、データ送受信部２０２は、送信相手リスト保持部２０８に保持されている送信相手リストを参照して、暗号化／復号化部２０４で暗号化される暗号化データを所定の宛先に送信する。

送信相手リスト保持部２０８は、管理ノードＳＮ、監視カメラＳＣ、乱数ノードＲＮを特定するための情報が記載された送信相手リストを保持する。本実施の形態に従うネットワークシステムでは、マルチキャストによってデータ送信されるので、送信相手リストには、マルチキャストアドレスが格納されていれば十分である。なお、この送信相手リストに、監視カメラＳＣや乱数ノードＲＮの各々を特定するためのネットワークアドレス（代表的に、ＩＰアドレス）が格納されていてもよい。さらに、図示しないネットワークに所属する他のノード（情報処理装置）のネットワークアドレスが格納されていてもよい。

コマンド生成／読取部２０６は、監視カメラＳＣとの間でコマンドをやり取りする。具体的には、コマンド生成／読取部２０６は、図示しないユーザ操作などに応じて、監視カメラＳＣに対する任意のコマンド（命令）を生成し、暗号化／復号化部２０４へ出力する。また、コマンド生成／読取部２０６は、暗号化／復号化部２０４で復号されたコマンドなどを解釈し、対応する処理を実行させる。

データ作成部２２０は、コマンド生成／読取部２０６や暗号化／復号化部２０４での処理に必要なデータを生成する。

リセット部２１８は、データ送受信部２０２を介して後述するリセット指令を受けると、そのリセット指令の内容に従って乱数保持部２１４に格納される乱数をリセットする。本実施の形態では、代表的にリセット指令は所定のビット数からなる乱数（データ列）を含み、リセット部２１８は、この乱数を乱数保持部２１４に格納される値に更新する。このように乱数保持部２１４に格納される乱数の値がリセットされることで、この乱数を用いて生成される一時鍵についてもリセットされることになる。

なお、このような形態に代えて、リセット部２１８がリセット指令に応答して、乱数保持部２１４に格納される値を予め定められた初期値に更新するようにしてもよい。

（監視カメラの機能構成）
図４は、この発明の実施の形態１に従う監視カメラＳＣにおける制御構造を示す概略図である。図４に示す制御構造は、代表的に、ハードウェアおよびそのハードウェア用に設計されたファームウェアなどによって実現される。

図４を参照して、監視カメラＳＣの各々は、データ送受信部３０２と、暗号化／復号化部３０４と、コマンド生成／読取部３０６と、送信相手リスト保持部３０８と、一時鍵生成部３１０と、一時鍵更新部３１２と、乱数保持部３１４と、秘密情報保持部３１６と、リセット部３１８と、データ作成部３２０と、センサ処理部３２２と、センサ部３２４とをその機能として含む。

センサ部３２４は、ＣＣＤ（Charge Coupled Device）などの撮像素子を含むカメラであり、撮影した画像データをセンサ処理部３２２へ順次出力する。

センサ処理部３２２は、センサ部３２４からの画像データに所定の画像処理を施してデータ作成部３２０へ出力する。具体的には、センサ処理部３２２は、管理ノードＳＮからのコマンドに応じて、センサ部３２４からの画像データの取り込み周期を変更したり、センサ部３２４の撮像感度などを変更したりする。

データ作成部３２０は、管理ノードＳＮとセンサ処理部３２２との間におけるコマンドやデータのやり取りを司る。具体的には、データ作成部３２０は、センサ処理部３２２から出力されるデータを暗号化／復号化部３０４へ出力し、コマンド生成／読取部３０６が管理ノードＳＮから受信したコマンドに応じて発生する内部指令をセンサ処理部３２２へ出力する。

データ送受信部３０２、暗号化／復号化部３０４、コマンド生成／読取部３０６、送信相手リスト保持部３０８、一時鍵生成部３１０、一時鍵更新部３１２、乱数保持部３１４、秘密情報保持部３１６、およびリセット部３１８については、それぞれ図３に示すデータ送受信部２０２、暗号化／復号化部２０４、コマンド生成／読取部２０６、送信相手リスト保持部２０８、一時鍵生成部２１０、一時鍵更新部２１２、乱数保持部２１４、秘密情報保持部２１６、およびリセット部２１８と同様の機能であるので、詳細な説明は繰返さない。

（乱数ノードの機能構成）
図５は、この発明の実施の形態１に従う乱数ノードＲＮにおける制御構造を示す概略図である。図５に示す制御構造は、図５に示す制御構造は、代表的に、ＣＰＵ１０（図２）がハードディスク部１８（図２）に予め格納されたプログラムをメモリ部１２（図２）に展開して実行することで実現される。

図５を参照して、乱数ノードＲＮは、データ送受信部１０２と、暗号化／復号化部１０４と、コマンド生成／読取部１０６と、送信相手リスト保持部１０８と、一時鍵生成部１１０と、一時鍵更新部１１２と、乱数保持部１１４と、秘密情報保持部１１６と、リセット部１１８と、乱数生成部１２０とをその機能として含む。

乱数生成部１２０は、暗号学的に安全な乱数を生成する。一例として、乱数生成部１２０は、乱数ノードＲＮのハードディスク部（ＨＤＤ）１８のシークタイム、マイク（図示しない）入力のホワイトノイズ、温度センサ（図示しない）の熱雑音などに基づいて、予測不可であり、かつ再現性のない乱数を発生する。あるいは、乱数生成部１２０として、専用のハードウェアを用いてもよいし、暗号学的に安全な擬似乱数を用いてもよい。

そして、乱数生成部１２０は、所定のタイミング（たとえば、１時間毎）に生成した乱数を含むリセット指令を管理ノードＳＮおよび各監視カメラＳＣに対してマルチキャストする。後述するように、このリセット指令によって、管理ノードＳＮおよび各監視カメラＳＣの一時鍵がリセットされる。

データ送受信部１０２、暗号化／復号化部１０４、コマンド生成／読取部１０６、送信相手リスト保持部１０８、一時鍵生成部１１０、一時鍵更新部１１２、乱数保持部１１４、秘密情報保持部１１６、およびリセット部１１８については、それぞれ図３に示すデータ送受信部２０２、暗号化／復号化部２０４、コマンド生成／読取部２０６、送信相手リスト保持部２０８、一時鍵生成部２１０、一時鍵更新部２１２、乱数保持部２１４、秘密情報保持部２１６、およびリセット部２１８と同様の機能であるので、詳細な説明は繰返さない。

（全体処理）
次に、図６〜図１３を参照して、本実施の形態に従うネットワークシステムにおけるデータ送信に係る処理について説明する。一例として、管理ノードＳＮから各監視カメラＳＣに対して、所定のコマンドを送信する場合について説明する。一例として、各監視カメラＳＣに対して、以下に示す内容のフレームレートおよび送信方法（監視画像送信頻度）の変更を指示するコマンドを考える。

この場合には、管理ノードＳＮのコマンド生成／読取部２０６は、たとえば、以下のようなコマンドを生成する。

Security camera command
SCC\nChange frame_rate 5fp\nChange transmission_method not_used_buffer\n\n
図６は、この発明の実施の形態１に従うネットワークシステムにおける各部の処理内容を示す模式図である。図７は、乱数ノードＲＮからリセット指令がマルチキャストされる処理を示す模式図である。図８は、管理ノードＳＮから暗号化データがマルチキャストされる処理を示す模式図である。図９は、管理ノードＳＮにおける処理をより詳細に示す図である。図１０は、監視カメラＳＣの各々における処理をより詳細に示す図である。

図６および図７を参照して、まずコマンド送信前の初期状態として、乱数ノードＲＮから管理ノードＳＮおよび各監視カメラＳＣに対して、乱数を含むリセット指令がマルチキャストされているとする。管理ノードＳＮおよび各監視カメラＳＣは、このマルチキャストされるリセット指令を受信すると、それぞれ乱数保持部２１４および３１４に当該乱数を格納する。

図６、図８および図９を参照して、管理ノードＳＮは、乱数ノードＲＮから受信した乱数２１４ａと、予め格納する秘密情報２１６ａとを用いて一時鍵２１０ａを生成し、この一時鍵２１０ａを用いて、ユーザが入力する上述のようなコマンド２０６ａを暗号化する。この暗号化によって生成された暗号化データ２０４ａが各監視カメラＳＣへマルチキャストされる。

一方、図６、図８および図１０を参照して、各監視カメラＳＣでは、管理ノードＳＮから暗号化データ２０４ａを受信すると、乱数ノードＲＮから受信した乱数３１４ａと、予め格納する秘密情報３１６ａとを用いて一時鍵３１０ａを生成し、この一時鍵３１０ａを用いて、受信した暗号化データを復号化して、コマンド３０４ａを生成する。コマンド生成／読取部３０６は、復号されたコマンド３０４ａを受け取ると、このコマンド３０４ａに従ってセンサ処理部３２２に指令を与え、センサ部３２４を所定の状態に制御する。すなわち、センサ処理部３２２は、上述のように、センサ部３２４のフレームレートおよび送信方法を変更する。

ここで、管理ノードＳＮが暗号化処理に使用する一時鍵２１０ａおよび監視カメラＳＣが復号化処理に用いる一時鍵３１０ａは、共通のルールに従って生成される。本実施の形態では、一例として、それぞれ乱数２１４ａ，３１４ａと秘密情報２１６ａ，３１６ａとの排他的論理和（ＸＯＲ）を用いて一時鍵２１０ａ，３１０ａが生成される。

より具体的には、図６に示すように、乱数２１４ａ，３１４ａの値がいずれも２進１０ビットのデータ列「１０１００００１００」であり、秘密情報２１６ａ，３１６ａの値がいずれも２進１０ビットのデータ列「００１００１００１０」である場合には、両者の排他的論理和は以下のようになる。

（１０１００００１００）．ＸＯＲ．（００１００１００１０）
＝１００００１０１１０
したがって、この排他的論理和の値が一時鍵２１０ａ，３１０ａの値として採用される。

なお、一時鍵の生成方法としては、排他的論理和を用いる方法以外にも、乱数２１４ａ，３１４ａを鍵としてそれぞれ秘密情報２１６ａ，３１６ａを暗号化した結果を一時鍵にする方法や、秘密情報２１６ａ，３１６ａを鍵としてそれぞれ乱数２１４ａ，３１４ａを暗号化した結果を一時鍵にする方法などを用いてもよい。

また、上述の説明では、簡単化のために、２進１０ビットのデータ列を用いる場合について例示したが、十分な秘匿性を確保するためには、１２８ビット〜５１２ビット程度以上が好ましい。

次に、管理ノードＳＮおよび各監視カメラＳＣは、一時鍵を用いて一回の暗号化／復号化を行なうと、次の暗号化／復号化に用いるために一時鍵を更新する。

図９に示すように、管理ノードＳＮでは、一時鍵更新部２１２が、乱数保持部２１４から読み出した乱数２１４ａの値を所定の規則に従って更新し、その更新後の値を乱数保持部２１４へ再度書き込む。同様に、図１０に示すように、各監視カメラＳＣでは、一時鍵更新部３１２が、乱数保持部３１４から読み出した乱数３１４ａの値を所定の規則に従って更新し、その更新後の値を乱数保持部３１４へ再度書き込む。

ここで、一時鍵更新部２１２および３１２が一時鍵を更新する規則は両者の間で共通となっている。一時鍵更新部２１２および３１２が一時鍵を更新する際に適用される規則の代表例として、本実施例では乱数をインクリメントする構成について例示する。

図１１は、この発明の実施の形態１における一時鍵の更新処理を説明するための図である。

図１１を参照して、一時鍵更新部２１２および３１２は、それぞれ乱数保持部２１４および３１４から乱数を読み出し、この乱数に「１」を加算する。そして、一時鍵更新部２１２および３１２は、この加算後の乱数をそれぞれ乱数保持部２１４および３１４に再度書き込む。上述したように、本実施の形態では、一時鍵が乱数と秘密情報とに基づいて生成されるので、乱数を順次インクリメントすることで、一時鍵を順次更新することができる。

上述のような手順に従って、管理ノードＳＮから各監視カメラＳＣに対して暗号化データが送信される毎に、一時鍵が順次更新されていく。その結果、従来のような固定された共通の暗号化鍵を用いる形式に比較して、秘匿性を高めたデータ通信を行なうことができる。

図１２は、この発明の実施の形態１における一時鍵の更新処理の別形態を説明するための図である。図１２（Ａ）は、デクリメントにより乱数を更新する場合を示し、図１２（Ｂ）は、行入れ換えにより乱数を更新する場合を示し、図１２（Ｃ）は、ビットシフトにより乱数を更新する場合を示す。

図１２（Ａ）を参照して、デクリメントにより乱数を更新する場合には、乱数保持部に格納されている乱数が読み出され、この乱数から「１」が減算される。そして、この減算後の乱数が乱数保持部２１４，３１４に再度書き込まれる。

図１２（Ｂ）を参照して、行入れ換えにより乱数を更新する場合には、乱数を構成するビット列（この場合には、１０ビット）が各５ビットの上位ビットと下位ビットに分離され、この上位ビットと下位ビットとがその順序を入れ換えられる。そして、この入れ換え後の乱数が乱数保持部２１４，３１４に再度書き込まれる。

図１２（Ｃ）を参照して、ビットシフトにより乱数を更新する場合には、乱数を構成するビット列（この場合には、１０ビット）のうち最上位ビットを除く各ビットが上位側にシフトされるとともに、この最上位ビットが最下位ビットとして挿入される。そして、このビットシフト後の乱数が乱数保持部２１４，３１４に再度書き込まれる。

上述したような乱数の更新方法以外にも、（１）前回の乱数を種として新たに乱数を発生させ、この乱数を用いる構成、（２）一方向関数（不可逆関数）に前回の乱数を入力して得られる出力を新たな乱数とする構成などを用いることもできる。さらに、上述したような規則のうち複数の規則を、乱数ノードＲＮなどからの指令に応じて適宜切り換えるようにしてもよい。たとえば、「乱数をインクリメントする」構成と「乱数をデクリメントする」構成とを適宜切り換えるようにしてもよい。

再度、図６および図７を参照して、管理ノードＳＮは、このようなデータ通信とは独立して、乱数を含むリセット指令を適宜のタイミングでマルチキャストする。このマルチキャストされた乱数を含むリセット指令を受けて、管理ノードＳＮおよび各監視カメラＳＣは、その保持する乱数を当該受信した値に更新するので、管理ノードＳＮおよび各監視カメラＳＣが暗号化に使用する一時鍵が一斉に更新されることになる。このように、一時鍵を一斉に更新することで、万が一、管理ノードＳＮおよび各監視カメラＳＣの間で一時鍵の不一致が発生しても、それを修正することができる。

なお、乱数ノードＲＮが乱数を含むリセット指令をマルチキャストするタイミングとしては、様々なものが考えられるが、代表的には、（１）所定の周期毎（たとえば、１時間毎）、（２）予め定められた日時、（３）管理者によるリセットの指示が与えられたタイミング、（４）ランダムなタイミング、などが挙げられる。

なお、リセット指令として乱数を送信する形態に代えて、乱数を予め定められた初期値に戻すように指示する指令を与えてもよい。この場合には、管理ノードＳＮおよび各監視カメラＳＣの一時鍵更新部２１２および３１２に予め乱数の初期値をそれぞれ格納しておき、リセット指令に応じてこの初期値をそれぞれ乱数保持部２１４および３１４へ書き込むことで実現できる。

あるいは、上述のように乱数を順次インクリメントする場合には、インクリメントの回数をカウントしておくことで、リセット指令を受けた場合に、そのカウント値を当該時点における乱数から引き算することで、乱数をリセットして初期値に戻すことができる。

（処理手順）
上述した本実施の形態に従うネットワークシステムにおけるデータ通信の処理についてまとめると、図１３に示すようなフローチャートになる。

図１３は、この発明の実施の形態１に従うネットワークシステムにおける処理手順を示すフローチャートである。

図１３を参照して、管理ノードＳＮは、まず、リセット指令を受信したか否かを判断する（ステップＳ１００）。リセット指令を受信していれば（ステップＳ１００においてＹＥＳ）、管理ノードＳＮは、自身の保持する乱数を当該受信したリセット指令に含まれる乱数に更新することで、乱数をリセットする（ステップＳ１０２）。

一方、リセット指令を受信していなければ（ステップＳ１００においてＮＯ）、管理ノードＳＮは、コマンド指令を受付けたか否かを判断する（ステップＳ１０４）。すなわち、管理ノードＳＮは、ユーザからコマンドの送信を指示されたか否かを判断する。ここで、コマンド指令を受付けていなければ（ステップＳ１０４においてＮＯ）、ステップＳ１００以下の処理が繰返される。

コマンド指令を受付けていれば（ステップＳ１０４においてＹＥＳ）、管理ノードＳＮは、保持している乱数を読み出す（ステップＳ１０６）とともに、保持している秘密情報を読み出す（ステップＳ１０８）。そして、管理ノードＳＮは、読み出した乱数および秘密情報に基づいて一時鍵を生成し（ステップＳ１１０）、コマンド指令に対応するコマンド（データ）をこの一時鍵を使用して暗号化する（ステップＳ１１２）。さらに、管理ノードＳＮは、送信相手リスト読み出して（ステップＳ１１４）、マルチキャストすべき送信先（監視カメラＳＣ）を特定し、暗号化によって生成された暗号化データをマルチキャストする（ステップＳ１１６）。暗号化データのマルチキャスト後、管理ノードＳＮは、保持する乱数をインクリメントして更新する（ステップＳ１１８）。そして、一連の処理は終了する。

一方、監視カメラＳＣは、まず、リセット指令を受信したか否かを判断する（ステップＳ２００）。リセット指令を受信していれば（ステップＳ２００においてＹＥＳ）、監視カメラＳＣは、自身の保持する乱数を当該受信したリセット指令に含まれる乱数に更新することで、乱数をリセットする（ステップＳ２０２）。

一方、リセット指令を受信していなければ（ステップＳ２００においてＮＯ）、監視カメラＳＣは、管理ノードＳＮから暗号化データを受信したか否かを判断する（ステップＳ２０４）。ここで、暗号化データを受信してなければ（ステップＳ２０４においてＮＯ）、ステップＳ２００以下の処理が繰返される。

暗号化データを受信していれば（ステップＳ２０４においてＹＥＳ）、監視カメラＳＣは、保持している乱数を読み出す（ステップＳ２０６）とともに、保持している秘密情報を読み出す（ステップＳ２０８）。そして、監視カメラＳＣは、読み出した乱数および秘密情報に基づいて一時鍵を生成し（ステップＳ２１０）、暗号化データをこの一時鍵を使用して復号化し（ステップＳ２１２）、この復号化によって生成されたデータ（コマンド）に基づいてコマンドに応じた処理を実行する（ステップＳ２１４）。さらに、監視カメラＳＣは、保持する乱数をインクリメントして更新する（ステップＳ２１６）。そして、一連の処理は終了する。

（本実施の形態における効果）
この発明の実施の形態１によれば、管理ノードＳＮおよび各監視カメラＳＣがそれぞれ独立に一時鍵を更新しながらデータ通信を行なうので、固定の暗号化鍵を用いる構成に比較して、より秘匿性の高い状態でデータ通信を行なうことができる。同時に、比較的低頻度でリセット指令をマルチキャストするだけでよいので、頻繁に鍵交換などを行なう構成に比較して、ネットワークに流れる通信量を低減できる。

また、この発明の実施の形態１によれば、リセット指令によってネットワークに所属する各装置が使用する一時鍵を一斉にリセットできるので、万が一、一部の装置が使用する一時鍵が他の装置が使用する一時鍵と異なるものとなったとしても、再度同期をとることができる。そのため、安定的にデータ通信を継続できる。

［実施の形態２］
上述の実施の形態１では、乱数ノードＲＮが乱数を含むリセット指令を管理ノードＳＮおよび各監視カメラＳＣへマルチキャストすることで、ネットワークシステムに所属する各装置が保持する一時鍵を一斉に更新する構成について例示した。このような構成において、たとえば新たに監視カメラＳＣが追加された場合などには、この追加された監視カメラＳＣを含めて各装置が保持する一時鍵を一斉に更新することが好ましい。以下、本実施の形態では、このような場合の処理について説明する。

図１４は、監視カメラＳＣ８１が追加された場合の処理を示す模式図である。
図１４を参照して、監視カメラＳＣ８１が追加された後、ユーザが当該追加された監視カメラＳＣに対して操作を行なうことで、リセット要求が管理ノードＳＮ、乱数ノード、各監視カメラＳＣへマルチキャストされる。管理ノードＳＮ、乱数ノードＲＮ、各監視カメラＳＣは、このリセット要求を受信すると、保持している乱数を破棄する。また、乱数ノードＲＮは、このリセット要求に応答して、新たな乱数を含むリセット指令を管理ノードＳＮおよび各監視カメラＳＣ（監視カメラＳＣ８１を含む）へマルチキャストする（図７参照）。管理ノードＳＮおよび各監視カメラＳＣは、このマルチキャストされた乱数を新たに乱数保持部へ格納し、暗号化／復号化処理を継続する。

なお、管理ノードＳＮおよび各監視カメラＳＣは、リセット要求を受信した後から乱数を含む新たなリセット指令を受信するまでの間、暗号化／復号化処理を中断することが望ましい。あるいは、リセット要求が受信されると、管理ノードＳＮおよび各監視カメラＳＣで保持される乱数を初期値に戻すようにしてもよい。また、リセット要求が受信された場合において、管理ノードＳＮ、乱数ノードＲＮ、各監視カメラＳＣが互いにＳＳＬ（Secure Socket Layer）通信を行なって、秘密情報を更新してもよい。

上述の例では、追加された監視カメラＳＣ８１に対してユーザ操作が行われることで、リセット要求がマルチキャストされる構成について例示したが、その他の条件に従ってリセット要求をマルチキャストするようにしてもよい。たとえば、（１）各監視カメラがネットワークに新たに接続されたことを検出してリセット要求を送信、（２）乱数ノードＲＮから乱数を含むリセット指令を受信してから所定期間経過後、（３）予め定められた日時、（４）前回のリセット要求の送信から所定期間経過後、（５）管理者によるリセットの指示が与えられたタイミング、などが挙げられる。

なお、その他の構成および処理などについては、上述の実施の形態１と同様であるので、詳細な説明は繰返さない。

（本実施の形態における効果）
この発明の実施の形態２によれば、上述の実施の形態１における効果に加えて、ネットワークに所属する装置の増減または変更があった場合であっても、暗号化された状態でのデータ通信を継続することができる。

［実施の形態３］
上述の実施の形態１では、管理ノードＳＮから各監視カメラＳＣへ暗号化データがマルチキャストされる構成について説明したが、一部の監視カメラＳＣがパケットの破損などによって暗号化データを完全には受信できなことも想定される。本実施の形態では、図１５〜図２１を参照して、一部の監視カメラＳＣが暗号化データの受信を失敗した場合であっても通信を継続できる構成について説明する。

図１５は、監視カメラＳＣ７９およびＳＣ８０が暗号化データの受信に失敗した場合を示す模式図である。

図１５を参照して、一例として、管理ノードＳＮから各監視カメラＳＣに対して暗号化データがマルチキャストされた場合に、監視カメラＳＣ７９およびＳＣ８０がその暗号化データの受信に失敗した場合を考える。この場合において、監視カメラＳＣ７９およびＳＣ８０を除く各監視カメラＳＣおよび管理ノードＳＮでは、当該暗号化データの送信処理および受信処理が完了しているので、一時鍵を生成するための乱数が更新されている。すなわち、監視カメラＳＣ７９およびＳＣ８０が保持する乱数（一時鍵）は、管理ノードＳＮおよび他の監視カメラＳＣの保持する値とは異なったものとなっている。そのため、管理ノードＳＮがその後に新たな暗号化データを各監視カメラＳＣにマルチキャストした場合において、監視カメラＳＣ７９およびＳＣ８０は当該新たな暗号化データを復号化することができず、それ以降の暗号化データについても同様に復号化できない。

そこで、各監視カメラＳＣが暗号化データを受信したことを管理ノードＳＮに通知することが好ましい。

図１６は、この発明の実施の形態３に従うネットワークシステムにおける受信確認の通知に係る処理内容を示す模式図である。なお、図１６では、図１５に示す状態における処理を示している。図１７は、この発明の実施の形態３に従うネットワークシステムにおける暗号化データの再送処理を示す模式図である。

図１６を参照して、監視カメラＳＣ１〜ＳＣ８０のうち、暗号化データの受信に失敗した監視カメラＳＣ７９およびＳＣ８０を除く各監視カメラＳＣ１〜ＳＣ７８は、暗号化データを受信すると、この受信を通知するための受信確認を管理ノードＳＮへ送信する。なお、この受信確認の通知は、各監視カメラＳＣのデータ送受信部３０２（図４）が実行する。

管理ノードＳＮは、暗号化データのマルチキャストの宛先である監視カメラＳＣ１〜ＳＣ８０のすべてから受信確認が通知された場合に、暗号化データの送信の処理を完了する。もし、いずれかの監視カメラＳＣ（図１６の場合には、監視カメラＳＣ７９，ＳＣ８０）から所定期間内に受信確認を通知されなかった場合には、図１７に示すように、暗号化データを再度マルチキャストする。

なお、管理ノードＳＮでは、マルチキャストの宛先である監視カメラＳＣのすべてから受信確認が通知されるまで、一旦送信した暗号化データを保持しておいてもよいし、監視カメラＳＣのすべてからは受信確認が通知されなかったと判断された場合に、再度同一の一時鍵を用いて暗号化データを生成してもよい。処理速度の観点からは、前者の方法が好ましい。

図１８および図１９を参照して、同一の暗号化データが複数回にわたってマルチキャストされた場合の処理について説明する。

図１８は、同一の暗号化データが複数回にわたってマルチキャストされた場合における監視カメラＳＣにおける処理を示す図である。図１８（Ａ）は、最初の暗号化データの受信に成功した監視カメラＳＣ１における処理を示し、図１８（Ｂ）は、最初の暗号化データの受信に失敗した監視カメラＳＣ８０における処理を示す。図１９は、図１８に示す処理によって生じる結果を示す模式図である。

図１８（Ａ）および図１９を参照して、最初の暗号化データの受信に成功した監視カメラＳＣ１では、最初の暗号化データの受信によって、その保持する乱数がすでに更新（インクリメント）されている。すなわち、最初の暗号化データの受信時における一時鍵と異なる一時鍵に更新されている。そのため、最初の暗号化データと同じ暗号化データが再送されると、暗号化に用いられた一時鍵（この場合には、「１００００１０１１０」）とは異なる一時鍵（この場合には、「１００００１０１１１」）を用いて復号化を行なおうとするので、復号化に失敗する。その結果、最初の暗号化データ（コマンド）に応じた処理が繰返し実行されることを回避することができる。また、復号化に失敗するので、現在保持している乱数がさらに更新されることもない。

一方、図１８（Ｂ）および図１９を参照して、最初の暗号化データの受信に失敗した監視カメラＳＣ８０では、その保持する乱数に対する更新（インクリメント）はなされていない。すなわち、最初の暗号化データの受信時における一時鍵と同じ一時鍵を維持している。そのため、最初の暗号化データと同じ暗号化データが再送されると、暗号化に用いられた一時鍵（この場合には、「１００００１０１１０」）とは同じ一時鍵を用いて復号化を行なうので、正しい復号を行なうことができる。その結果、暗号化データ（コマンド）に応じた処理が正しく実行されるとともに、この復号化の成功によって、乱数が更新（インクリメント）されるので、他の監視カメラＳＣが保持する乱数（一時鍵）と同じ値を維持することができる。

上述したように、一部の監視カメラＳＣが暗号化データの受信に失敗し、管理ノードＳＮが同一の暗号化データを再送する場合であっても、各監視カメラＳＣでは、同一の暗号化データに応じた処理が１回だけ実行されることになる。

このような構成に伴って、いわゆる悪意をもった部外者による再生攻撃に対する防御方法としても有効である。「再生攻撃」とは、ネットワークに流れるコマンド（暗号化データ）を盗聴し、同じコマンドを再度ネットワークに流すような攻撃である。たとえば、「監視カメラの向きを上向きに５°だけ変更せよ」とのコマンドを暗号化した暗号化データが盗聴された場合を考える。この盗聴された暗号化データからコマンドを解読することは困難であるし、たとえコマンドを解読できたとしても、本発明に係るネットワークシステムのように一時鍵が随時更新される構成では、解読したコマンドを暗号化することも事実上、不可能である。

しかしながら、この盗聴した暗号化データを多数回に亘って再送することで、ネットワークの管理者が意図しない処理が行なわれてしまうおそれがある。すなわち、上述のような暗号化データを１７回再送されてしまうと、「監視カメラの向きを上向きに５°だけ変更せよ」とのコマンドに応じた動作が、本来の暗号化データを含めて合計１８回実行されることになる。その結果、監視カメラの向きは、５°×１８回＝９０°の変更を生じる。すなわち、再生攻撃を受けると、「監視カメラの向きを上向きに５°だけ変更せよ」とのコマンドが、実質的に「監視カメラの向きを上向きに９０°だけ変更せよ」と同等のコマンドが与えられたことに相当してしまう。

しかしながら、上述したように、本実施の形態に従うネットワークシステムにおいては、各監視カメラＳＣが同一の暗号化データに応じた処理を１回だけ実行するので、このような再生攻撃に対しても防御することができる。

なお、最初の暗号化データの受信に失敗した、すなわち受信確認を受信できなかった監視カメラＳＣに対して、最初の暗号化データとは異なるコマンドを含む暗号化データを送信してもよい。この場合にも、最初の暗号化データと、再送される暗号化データとは、同じ一時鍵を用いて暗号化される。

これは、マルチキャストされた暗号化データを受信できなかった監視カメラＳＣについては、当該監視カメラＳＣ自体あるいは当該監視カメラＳＣまでのネットワーク経路に障害がある場合が想定される。そのため、最初の暗号化データに含まれていたコマンドに、このような障害をチェックするためのコマンドを加えたデータを暗号化することで、再送すべき暗号化データを生成してもよい。上述したように、最初の暗号化データとは異なるコマンドを含む暗号化データを再送した場合であっても、これらの暗号化データを同一の一時鍵を用いて生成している以上、最初の暗号化データの受信に失敗した監視カメラＳＣだけがこの再送される暗号化データを復号化するので、最初の暗号化データの受信に成功した監視カメラＳＣに対して何らの影響も与えない。

（処理手順）
上述した本実施の形態に従う管理ノードＳＮにおけるデータ通信の処理についてまとめると、図２０および図２１に示すようなフローチャートになる。

図２０は、この発明の実施の形態３に従う管理ノードＳＮにおける暗号化データ送信の処理手順を示すフローチャートである。図２１は、この発明の実施の形態３に従う各監視カメラＳＣにおける暗号化データ受信の処理手順を示すフローチャートである。

図２０を参照して、管理ノードＳＮは、まず、リセット指令を受信したか否かを判断する（ステップＳ３００）。リセット指令を受信していれば（ステップＳ３００においてＹＥＳ）、管理ノードＳＮは、自身の保持する乱数を当該受信したリセット指令に含まれる乱数に更新することで、乱数をリセットする（ステップＳ３０２）。

一方、リセット指令を受信していなければ（ステップＳ３００においてＮＯ）、管理ノードＳＮは、コマンド指令を受付けたか否かを判断する（ステップＳ３０４）。すなわち、管理ノードＳＮは、ユーザからコマンドの送信を指示されたか否かを判断する。ここで、コマンド指令を受付けていなければ（ステップＳ３０４においてＮＯ）、ステップＳ３００以下の処理が繰返される。

コマンド指令を受付けていれば（ステップＳ３０４においてＹＥＳ）、管理ノードＳＮは、保持している乱数を読み出す（ステップＳ３０６）とともに、保持している秘密情報を読み出す（ステップＳ３０８）。そして、管理ノードＳＮは、読み出した乱数および秘密情報に基づいて一時鍵を生成し（ステップＳ３１０）、コマンド指令に対応するコマンド（データ）をこの一時鍵を使用して暗号化する（ステップＳ３１２）。さらに、管理ノードＳＮは、送信相手リスト読み出して（ステップＳ３１４）、マルチキャストすべき送信先（監視カメラＳＣ）を特定し、暗号化によって生成された暗号化データをマルチキャストする（ステップＳ３１６）。

暗号化データの送信先である監視カメラＳＣのすべてから受信確認を受信したか否かを判断する（ステップＳ３１８）。監視カメラＳＣのすべてからは受信確認を受信できなかった場合（ステップＳ３１８においてＮＯの場合）には、管理ノードＳＮは、所定期間だけ待機（ステップＳ３２０）した後、暗号化データを再度マルチキャストする（ステップＳ３１６）。以下、ステップＳ３１８の処理が繰返される。

一方、監視カメラＳＣのすべてから受信確認を受信できた場合（ステップＳ３１８においてＹＥＳの場合）には、管理ノードＳＮは、保持する乱数をインクリメントして更新する（ステップＳ３２２）。そして、一連の処理は終了する。

なお、ステップＳ３１８を所定回数（たとえば、３回）だけ実行しても、監視カメラＳＣのすべてからは受信確認を受信できなかった場合には、宛先の監視カメラＳＣの故障なども考えられるので、ステップＳ３１８の処理を無視して、ステップＳ３２０以降の処理を実行するようにしてもよい。このような処理を行なったとしても、応答の無かった監視カメラＳＣの機能が正常に戻り、乱数ノードＲＮから乱数を含むリセット指令がマルチキャストされることで、当該監視カメラの機能は正常化する。

図２１を参照して、監視カメラＳＣは、まず、リセット指令を受信したか否かを判断する（ステップＳ４００）。リセット指令を受信していれば（ステップＳ４００においてＹＥＳ）、監視カメラＳＣは、自身の保持する乱数を当該受信したリセット指令に含まれる乱数に更新することで、乱数をリセットする（ステップＳ４０２）。

一方、リセット指令を受信していなければ（ステップＳ４００においてＮＯ）、監視カメラＳＣは、管理ノードＳＮから暗号化データを受信したか否かを判断する（ステップＳ４０４）。ここで、暗号化データを受信してなければ（ステップＳ４０４においてＮＯ）、ステップＳ４００以下の処理が繰返される。

暗号化データを受信していれば（ステップＳ４０４においてＹＥＳ）、監視カメラＳＣは、保持している乱数を読み出す（ステップＳ４０６）とともに、保持している秘密情報を読み出す（ステップＳ４０８）。そして、監視カメラＳＣは、読み出した乱数および秘密情報に基づいて一時鍵を生成し（ステップＳ４１０）、暗号化データをこの一時鍵を使用して復号化する（ステップＳ４１２）。さらに、監視カメラＳＣは、復号化が成功したか否かを判断する（ステップＳ４１４）。

復号化が成功した場合（ステップＳ４１４においてＹＥＳの場合）には、監視カメラＳＣは、この復号化によって生成されたデータ（コマンド）に基づいてコマンドに応じた処理を実行する（ステップＳ４１６）。さらに、監視カメラＳＣは、保持する乱数をインクリメントして更新する（ステップＳ４１８）。そして、一連の処理は終了する。

一方、復号化が失敗した場合（ステップＳ４１４においてＮＯの場合）には、以後の処理は行なわない。

（本実施の形態における効果）
この発明の実施の形態３によれば、上述の実施の形態１における効果に加えて、必要な監視カメラＳＣ以外には影響を与えることなく、暗号化データをマルチキャストで再送できる。すなわち、上述したように、一旦暗号化データの受信が成功した監視カメラＳＣでは、乱数（すなわち、一時鍵）が更新されるので、同じ一時鍵を使用して生成された暗号化データを複数回受信しても、最初の１回だけが有効となる。そのため、各監視カメラＳＣに対して、確実に暗号化データを送信することができる。

また、この発明の実施の形態３によれば、上述したような再生攻撃に対しても有効な防御方法を提供できる。

［実施の形態３の変形例］
上述の実施の形態３では、管理ノードＳＮは、すべての監視カメラＳＣから受信確認を受信しない限り、自身の保持する乱数を更新しない構成について例示した（図２０）が、一旦暗号化データを作成した時点で、この乱数を更新するようにしてもよい。

図２２は、この発明の実施の形態３の変形例に従う管理ノードＳＮにおける暗号化データ送信の処理手順を示すフローチャートである。

図２２を参照して、管理ノードＳＮは、まず、リセット指令を受信したか否かを判断する（ステップＳ５００）。リセット指令を受信していれば（ステップＳ５００においてＹＥＳ）、管理ノードＳＮは、自身の保持する乱数を当該受信したリセット指令に含まれる乱数に更新することで、乱数をリセットする（ステップＳ５０２）。

一方、リセット指令を受信していなければ（ステップＳ５００においてＮＯ）、管理ノードＳＮは、コマンド指令を受付けたか否かを判断する（ステップＳ５０４）。すなわち、管理ノードＳＮは、ユーザからコマンドの送信を指示されたか否かを判断する。ここで、コマンド指令を受付けていなければ（ステップＳ５０４においてＮＯ）、ステップＳ５００以下の処理が繰返される。

コマンド指令を受付けていれば（ステップＳ５０４においてＹＥＳ）、管理ノードＳＮは、保持している乱数を読み出す（ステップＳ５０６）とともに、保持している秘密情報を読み出す（ステップＳ５０８）。そして、管理ノードＳＮは、読み出した乱数および秘密情報に基づいて一時鍵を生成し（ステップＳ５１０）、コマンド指令に対応するコマンド（データ）をこの一時鍵を使用して暗号化する（ステップＳ５１２）。さらに、管理ノードＳＮは、送信相手リスト読み出して（ステップＳ５１４）、マルチキャストすべき送信先（監視カメラＳＣ）を特定し、暗号化によって生成された暗号化データをマルチキャストする（ステップＳ５１６）。また、管理ノードＳＮは、保持する乱数をインクリメントして更新する（ステップＳ５１８）。

続いて、管理ノードＳＮは、暗号化データの送信先である監視カメラＳＣのすべてから受信確認を受信したか否かを判断する（ステップＳ５２０）。監視カメラＳＣのすべてからは受信確認を受信できなかった場合（ステップＳ５２０においてＮＯの場合）には、暗号化データを再度マルチキャストし（ステップＳ５２２）、所定期間だけ待機（ステップＳ５２４）する。その後、再度、ステップＳ５２０の処理が実行される。

一方、監視カメラＳＣのすべてから受信確認を受信できた場合（ステップＳ５２０においてＹＥＳの場合）には、処理は終了する。

なお、その他の構成および処理などについては、上述の実施の形態３と同様であるので、詳細な説明は繰返さない。

この発明の実施の形態３の変形例によれば、上述の実施の形態１における効果に加えて、すべての監視カメラＳＣから受信確認を受信するまで次の暗号化データ送信が待機されるので、より確実に監視カメラＳＣの各々に暗号化データを送信することができる。

［その他の実施の形態］
上述の実施の形態では、管理ノードＳＮがデータ送信側であり、各監視カメラＳＣがデータ受信側である時点の動作について例示したが、各監視カメラＳＣが管理ノードＳＮへ画像データを送信する処理を並行して実行することも可能である。

また、上述の実施の形態では、ネットワーク上に管理ノードＳＮとは別に乱数ノードＲＮを設ける構成について例示したが、この乱数ノードＲＮの機能を管理ノードＳＮ内またはいずれかの監視カメラＳＣに実装してもよい。あるいは、乱数を含むリセット指令を管理ノードＳＮおよび各監視カメラＳＣにマルチキャストできれば、必ずしも同一のネットワークに接続されている必要もない。

また、乱数ノードＲＮは、リセット指令として、乱数に代えて、もしくは乱数とともに、管理ノードＳＮおよび各監視カメラＳＣが保持する乱数を更新するための規則を一斉に変更するためのコマンドや乱数を予め定められた初期値にリセットするためのコマンドを含んでいてもよい。

本発明に係るプログラムは、コンピュータのオペレーティングシステム（ＯＳ）の一部として提供されるプログラムモジュールのうち、必要なモジュールを所定の配列で所定のタイミングで呼び出して処理を実行させるものであってもよい。その場合、プログラム自体には上記モジュールが含まれずＯＳと協働して処理が実行される。このようなモジュールを含まないプログラムも、本発明に係るプログラムに含まれ得る。

また、本発明に係るプログラムは他のプログラムの一部に組込まれて提供されるものであってもよい。その場合にも、プログラム自体には上記他のプログラムに含まれるモジュールが含まれず、他のプログラムと協働して処理が実行される。このような他のプログラムに組込まれたプログラムも、本発明に係るプログラムに含まれ得る。

提供されるプログラム製品は、ハードディスクなどのプログラム格納部にインストールされて実行される。なお、プログラム製品は、プログラム自体と、プログラムが記憶された記憶媒体とを含む。

さらに、本発明に係るプログラムによって実現される機能の一部または全部を専用のハードウェアによって構成してもよい。

今回開示された実施の形態はすべての点で例示であって制限的なものではないと考えられるべきである。本発明の範囲は、上記した説明ではなく、請求の範囲によって示され、請求の範囲と均等の意味および範囲内でのすべての変更が含まれることが意図される。

Claims

ネットワークシステムであって、
第１情報処理装置（ＳＮ）と、
少なくとも１つの第２情報処理装置（ＳＣ）とを備え、前記第１情報処理装置は前記少なくとも１つの第２情報処理装置へデータ送信可能であり、
前記第１情報処理装置は、
送信すべきデータを一時鍵を用いて暗号化することで暗号化データを生成するための暗号化部（２０４）と、
前回の暗号化処理で用いられた一時鍵を所定規則に従って更新したうえで、引き続く暗号化処理に使用させる第１更新部（２１２）とを含み、
前記少なくとも１つの第２情報処理装置の各々は、
前記第１情報処理装置から受信する暗号化データを一時鍵を用い復号化するための復号化部（３０４）と、
前回の復号化処理で用いられた一時鍵を前記所定規則に従って更新したうえで、引き続く復号化処理に使用させる第２更新部（３１２）とを含み、
前記第１情報処理装置および前記少なくとも１つの第２情報処理装置の各々は、リセット指令に応答して、前記一時鍵を所定値に更新する第３更新部（２１０，３１０）をさらに含む、ネットワークシステム。
前記第１情報処理装置および前記少なくとも１つの第２情報処理装置の各々は、第１データ列を含む共通の秘密情報を予め格納しており、
前記リセット指令は、第２データ列を含み、
前記第３更新部は、前記一時鍵を、前記第１データ列と前記リセット指令に含まれる前記第２データ列とに基づいて生成される値に更新する、請求の範囲第１項に記載のネットワークシステム。
前記リセット指令に含まれる前記第２データ列は、乱数として生成される、請求の範囲第２項に記載のネットワークシステム。
前記第３更新部は、前記リセット指令に応答して前記一時鍵を予め定められた初期値に更新する、請求の範囲第１項に記載のネットワークシステム。
前記第１情報処理装置および前記少なくとも１つの第２情報処理装置の各々へ前記リセット指令を送信するための第３情報処理装置（ＲＮ）をさらに備える、請求の範囲第１項に記載のネットワークシステム。
前記少なくとも１つの第２情報処理装置の各々は、前記第１情報処理装置からの前記暗号化データを受信した場合に、前記第１情報装置に当該暗号化データの受信確認を通知し、
前記第１更新部は、前記暗号化データを送信後、当該暗号化データについての前記受信確認を前記少なくとも１つの第２の情報処理装置のすべてから受信した場合に、前記一時鍵を更新する、請求の範囲第１項に記載のネットワークシステム。
前記少なくとも１つの第２情報処理装置の各々は、前記第１情報処理装置からの前記暗号化データを受信した場合に、前記第１情報装置に当該暗号化データの受信確認を通知し、
前記暗号化部は、前記暗号化データを送信後、当該暗号化データについての前記受信確認を前記少なくとも１つの第２情報処理装置のすべてから受信した場合に、次に送信すべきデータを暗号化する、請求の範囲第１項に記載のネットワークシステム。
前記第１更新部は、前記一時鍵および前記一時鍵の生成に用いるデータの少なくとも一方を、インクリメント、デクリメント、行入れ換え、ビットシフトの少なくとも１つを含む処理によって、前記一時鍵を更新する、請求の範囲第１項に記載のネットワークシステム。
第１情報処理装置（ＳＮ）と少なくとも１つの第２情報処理装置（ＳＣ）とを含むネットワークシステムにおいて、前記第１情報処理装置から前記少なくとも１つの第２情報処理装置へデータを送信する方法であって、
前記第１情報処理装置が、送信すべきデータを一時鍵を用いて暗号化した暗号化データを前記少なくとも１つの第２情報処理装置へ送信するステップ（Ｓ１１２，Ｓ１１４，Ｓ１１６）と、
前記少なくとも１つの第２情報処理装置の各々が、前記第１情報処理装置から受信した暗号化データを一時鍵を用い復号化するステップ（Ｓ２１２，Ｓ２１４）と、
前記第１情報処理装置が、暗号化に用いた一時鍵を所定規則に従って更新するステップ（Ｓ１１８，Ｓ１０６，Ｓ１０８，Ｓ１１０）と、
前記少なくとも１つの第２情報処理装置の各々が、復号化に用いた一時鍵を所定規則に従って更新するステップ（Ｓ２１６，Ｓ２０６，Ｓ２０８，Ｓ２１０）と、
前記少なくとも１つの第２情報処理装置の各々が、リセット指令に応答して、各々が保持する前記一時鍵を所定値に更新するステップ（Ｓ１００，Ｓ１０２，Ｓ１０６，Ｓ１０８，Ｓ１１０；Ｓ２００，Ｓ２０２，Ｓ２０６，Ｓ２０８，Ｓ２１０）とを備える、データ送信方法。