(57)【要約】【課題】  暗号鍵を共有することで形成するグループ内での暗号通信において暗号強度維持のために繰り返し、もしくはグループのメンバが変更した際に鍵の更新を行う。この時鍵配布時にノードへの鍵の未着、到着時間のずれが発生すると、データの送信側と受信側での使用鍵に不一致が生じてデータの復号化が失敗する。【解決手段】  通信を行う各ノードにおいて暗号強度維持のための鍵更新後も新旧の複数のバージョンの鍵を保持しておき、通信において、受信データに格納している、暗号化に用いた鍵のバージョン情報を参照して、ノードにおいて保持する鍵の中から該当するバージョンの鍵を選択して受信データの復号化に用いる。これにより、暗号鍵の更新時にデータの送信側、受信側での鍵の不一致をなくし、鍵更新に伴うダウンタイムを低減し、また通信データの漏れを防止する。【選択図】図８
2005159780.tif 000002
【特許請求の範囲】
【請求項１】
制御系と情報系とをネットワークを介して連携させることにより、情報の共有を行う情報制御システムにおいて、
暗号鍵を共有することで形成した、複数のノードからなるグループにおいて、
該グループの各々の前記ノードに対してユニキャストにより、該グループに対応付けた暗号鍵を事前に配布するステップと、
該ノードでは配布された暗号鍵を複数保有しながら該暗号鍵の切り替えを行うステップと、
特定のノードを除いて前記グループ内の各ノードに対して前記グループに対応付けた新しい暗号鍵の配布、切り替えを行うことにより、前記グループのメンバの変更を行うステップを有する
ことを特徴とする、セキュアグループ管理方法。
【請求項２】
請求項１に記載のセキュアグループ管理方法において、
前記グループにおけるマルチキャスト通信の送信データのヘッダ内に含まれている、該データの暗号化に使用した前記グループに対応付けた暗号鍵のバージョン情報を参照することにより、
該データの受信ノードが保有する複数の暗号鍵の中から該バージョンに合致する暗号鍵を抽出し、
該受信データの復号化に使用する
ことを特徴とする、セキュアグループ管理方法。
【請求項３】
請求項１に記載のセキュアグループ管理方法において、
前記セキュアなグループにおけるメンバの各ノードは、自ノード以外の特定ノードには対応せず、グループ内の該特定ノード以外の他のノードに対応する暗号鍵を保持し、
同一の当該鍵を持ち、各メンバのノードを含まないサブグループを、形成し、
マルチキャスト通信においていずれかの前記メンバの特定ノードによる受信を行わせない場合、前記グループのメンバを変更するために新しい暗号鍵の配布、切り替えが完了するまでの間、該特定ノードが属さないサブグループの暗号鍵を用いて暗号化し、マルチキャスト送信する
ことを特徴とする、セキュアグループ管理方法。
【請求項４】
請求項３に記載のセキュアグループ管理方法において、
受信を行わせない複数の特定ノードの各々が所属しないサブグループのそれぞれの暗号鍵で多重に暗号化することにより、前記複数の特定ノードへのマルチキャストデータの受信を行わせない
ことを特徴とする、セキュアグループ管理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、機器制御等を行う制御系と計画管理業務等を行う情報系とを連携させて情報の共有を行う情報制御システムにおけるデータ配信において、セキュリティ強度を維持する技術に関する。
【背景技術】
【０００２】
従来の方法では、鍵提供端末において、情報配信システムにおいて配送するコンテンツを暗号化または復号化する為の共通鍵を作成後、各情報利用端末の暗号鍵で暗号化して暗号化鍵データを生成し、マルチキャストまたはユニキャストにより情報提供端末と各情報利用端末に配送する。情報提供端末及び各情報利用端末では配送された暗号化鍵データを受信後自らの暗号鍵による部分だけを抽出して復号化することで共通鍵を得る。（例えば、特許文献１、２等参照。）
マルチキャストにより鍵が配送される場合、各情報利用端末では、情報提供端末にて新しい共通鍵で暗号化されマルチキャストされたコンテンツを最初に受信した時に復号化用の鍵を受信していた該新しい共通鍵へと切り替える。またユニキャストにより鍵が配送される場合は、鍵提供端末が、鍵を配送した全ての端末から鍵受信完了の応答を受信した後に発する、鍵切り替え指示を受信した端末から新しい共通鍵へと切り替える。
【０００３】
なお新しい共通鍵への切り替え後、古い共通鍵は直ちに破棄される。
【０００４】
【特許文献１】特開２００２−２４７０２２号公報。
【０００５】
【特許文献２】特開２００２−２５２６０７号公報。
【発明の開示】
【発明が解決しようとする課題】
【０００６】
上記従来技術では、暗号鍵をマルチキャストにて各情報利用端末に配布する場合、端末の一時的な停止やネットワークの一時的な切断等の理由により、暗号鍵を必要とする全ての端末に暗号鍵が配布できない場合や、端末によっては暗号鍵の到着に遅延が発生する場合がある。
【０００７】
また新しい鍵を受信した情報利用端末では鍵の切り替え後、古い鍵を破棄する。このため、暗号鍵を受信できなかった情報利用端末では、情報提供端末において新しい鍵で暗号化され、マルチキャスト配信されたデータを受信しても暗号鍵の不一致のため正しく復号化できない。また情報提供端末が新しい暗号鍵を受信できなかった場合、情報提供端末が暗号化して配信したデータを、新しい鍵を受信している情報利用端末が受信しても正しく復号化できない。
【０００８】
さらに上記従来技術ではある固定の端末のみが情報を送信する場合に適用している。グループ内の複数の端末が相互に情報の送信を行うシステムにおいて、通信を行う端末のグループへの参加や、グループからの離脱などが頻繁に変更されると、情報の送信側と受信側の暗号鍵の不一致が発生しやすく、システム内での情報伝達の中断、または正しい情報が伝達されないことによる異常な処理が起こり得る。
【０００９】
またグループから端末が離脱した場合、離脱した端末のデータ受信を拒否するため、グループ内の他の生存する端末に対して新しい鍵を配布し、各端末にて新しい鍵への切り替えが行われる。しかし新しい鍵の配布と切り替えが完了するまでの期間は離脱した端末も継続してデータを受信できてしまう。
【課題を解決するための手段】
【００１０】
本発明は、情報制御システムにおいて広域に分散した複数の拠点または複数のノードの間で頻繁に発生するデータ配信において、通信の処理効率の低下や異常な処理の発生を防止しつつ、配信データのセキュリティ保護を行う技術を提供する。
【００１１】
具体的には、暗号鍵を共有することでマルチキャストまたはユニキャストされる同一のデータを受信するノードのグループを形成する。また暗号強度を保つため該グループでは暗号鍵の配布と切り替えを繰り返し行う。またグループからあるノードが離脱した場合、離脱ノードのデータ受信を拒否するためグループに生存する他のノードに対して新しい鍵の配布と切り替えを行うまでの期間を短くする。
【００１２】
なお暗号鍵の配布は鍵管理サーバより各ノードにユニキャストすることで行い、切り替えのタイミングよりも事前に行うものとする。また特定のノードを除いて新しい鍵の配布、切り替えを行うことによりデータ受信グループのメンバの変更を行う。以上のことを前提とする。
【００１３】
本発明の一態様においては、該暗号鍵を利用するノードでは常に新旧の複数のバージョンの鍵を保有する。上記グループ内のノードからの送信データの通信ヘッダには該データの暗号化に使用した暗号鍵のバージョン情報を含める。受信側のノードではヘッダより抽出した該バージョン情報を参照して、ノードにて保有する複数の暗号鍵の中から該当するバージョンの鍵を選択して該受信データの復号化に用いる。上記方法により暗号鍵の配布、切り替えの期間中でも使用する鍵のバージョンの不一致による受信データの復号化失敗を防ぐことが出来る。
【００１４】
また上記グループでは、各ノードは、自ノード以外のメンバの各ノードに対応する鍵を保持し、鍵毎にサブグループを形成することで、メンバの各ノードがそれぞれ１つだけ加入していないサブグループを形成する。グループから離脱したノード等の特定ノードによるデータ受信を行わせない場合は、鍵管理サーバからグループのメンバの変更のために新しい鍵が配布されるまでの間、当該特定ノードが属さないサブグループの鍵を一時的に用いて暗号化してデータ送信する。複数のノードを受信対象から除く場合はそれぞれが属さないサブグループの鍵で多重に暗号化する。
【００１５】
なお、ノードとは、上記端末、コントローラを総称するものである。
【発明の効果】
【００１６】
本発明によれば、暗号鍵を共有することで形成されたセキュアなグループにおいて、暗号鍵の更新時における、鍵の不一致をなくし、鍵更新に伴うダウンタイムの低減や、通信データの漏れの防止が可能になる。
【発明を実施するための最良の形態】
【００１７】
以下、本発明の実施形態を図面により詳細に説明する。
【００１８】
図１は、本実施形態における機器制御等を行う制御系と計画管理業務等を行う情報系とを連携させた情報制御システムの構成の概要を示す図である。ここでは本社０１０１と支社０１０２、工場０１０３、０１０４等のシステムを、各拠点に設置したゲートウェイ０１１４、０１２１、０１３１、０１４１から広域網０１０５を介して相互に接続した情報制御システムの例を示す。主な構成要素は本社０１０１に設置してある、暗号鍵の生成と配布及びシステム内のノードの管理を行う鍵管理サーバ０１１１と、システム内でマルチキャストによる暗号通信を行う、本社０１０１の業務用サーバ０１１２、端末０１１３、支社０１０２の端末０１２２、０１２３、０１２４、工場０１０３のコントローラ０１３２、０１３３、工場０１０４の端末０１４２、コントローラ０１４３等である。
【００１９】
鍵管理サーバ０１１１のハードウェアは、記憶装置０１５１、処理装置０１５２、通信装置０１５３から成る。記憶装置０１５１には各端末やコントローラに関する情報、各端末やコントローラに対応付けた暗号鍵、各端末やコントローラより受信した端末やコントローラに固有の暗号鍵、各グループに関する情報、各グループに対応付けた暗号鍵、及びこれらの情報や暗号鍵を管理するためのソフトウェア、また暗号鍵を生成、配布するためのソフトウェアが格納され、処理装置０１５２により処理される。通信装置０１５３は通信媒体０３０２と接続して各拠点にある端末０１１３、０１２２、０１２３、０１２４、０１４２、コントローラ０１３２、０１３３に対して鍵を配布したり、鍵要求メッセージを受信したりするための通信に用いる。
【００２０】
端末０１１３のハードウェアは、記憶装置０１６１、処理装置０１６２、通信装置０１６３から成る。記憶装置０１６１には各端末に固有の暗号鍵、鍵管理サーバ０１１１より配布された暗号鍵、データ通信を行うグループや通信相手に関する情報、及びこれらの暗号鍵や情報を管理するためのソフトウェアが格納され、処理装置０１６２により処理される。通信装置０１６３は通信媒体０３０２と接続して、鍵管理サーバ０１１１から配布される暗号鍵の受信や鍵管理サーバ０１１１に対して鍵要求メッセージの送信、グループ内でのマルチキャスト通信の送受信に用いる。他の端末０１２２、０１２３、０１２４、０１４２も同様の構成である。
【００２１】
コントローラ０１４３のハードウェアは、記憶装置０１７１、処理装置０１７２、通信装置０１７３から成る。記憶装置０１７１には各端末に固有の暗号鍵、鍵管理サーバ０１１１より配布された暗号鍵、データ通信を行うグループや通信相手に関する情報、及びこれらの暗号鍵や情報を管理するためのソフトウェアが格納され、処理装置０１７２により処理される。通信装置０１７３は通信媒体０３０２と接続して、鍵管理サーバ０１１１から配布される暗号鍵の受信や鍵管理サーバ０１１１に対して鍵要求メッセージの送信、グループ内でのマルチキャスト通信の送受信に用いる。他のコントローラ０１３２、０１３３も同様の構成である。
【００２２】
図２は、本実施形態の情報制御システムにおけるマルチキャスト通信の概要を示す図である。主な構成要素としては、図１における示した情報制御システムにおける、暗号鍵の生成と配布及びシステム内のノードの管理を行う鍵管理サーバ０１１１とシステム内でマルチキャストによる暗号通信を行う、支社０１０２の端末０１２２、本社０１０１の端末０１１３、工場０１０３のコントローラ０１３２、工場０１０４のコントローラ０１４３を示している。
【００２３】
端末０１２２の持つ暗号鍵０２１２、端末０１１３の持つ暗号鍵０２１３は鍵管理サーバ０１１１から配布されたものであり、グループ０２２１に対応付けられた共通鍵である。また端末０１１３の持つ暗号鍵０２１４、コントローラ０１３２の持つ暗号鍵０２１５、コントローラ０１４３の持つ暗号鍵０２１６は鍵管理サーバ０１１１から配布されたものであり、グループ０２２２に対応付けられた共通鍵である。なおこれら上記の鍵配布０２４１はユニキャスト通信により行われ、配布するグループに対応付けられた暗号鍵の秘匿性を保つため各ノード固有の暗号鍵にて暗号化する。
【００２４】
上記鍵配布０２４１により、グループ０２２１には端末０１２２、端末０１１３が加入しており、グループ０２２２には端末０１１３、コントローラ０１３２、コントローラ０１４３が加入している。データ０２３１はグループ０２２１内でマルチキャストされ、データ０２３２はグループ０２２２内でマルチキャスト通信０２４２される。なお上記データ０２３１、０２３２はそれぞれグループ０２２１、０２２２のそれぞれに対応付けられた暗号鍵で暗号化されているため、同グループ内のノードでのみ受信、復号化が可能である。
【００２５】
なお端末０１２２、端末０１１３、コントローラ０１３２、コントローラ０１４３からは、生存信号が繰り返し発信されており、鍵管理サーバ０１１１はこれらの生存信号を受信して各ノードの生存状態(生または死)を把握している。
【００２６】
図３は、暗号鍵の生成と配布及びグループやノードの管理を行う鍵管理サーバ０１１１の機能構成を示す図である。図１に示した鍵管理サーバ０１１１はシステム内に１つ設置され、信頼性向上のため多重化してもよい。主な構成要素としては、グループ管理テーブル０３２１を用いてグループの管理を行うグループ管理部０３１１、ノード管理テーブル０３２２を用いてノードの管理を行うノード管理部０３１２、暗号鍵の生成を行う暗号鍵生成部０３１３、通信媒体０３０２を介して各ノードに鍵の配布を行う鍵配布部０３１５、送信する暗号鍵の暗号化や受信データの復号化を行う暗号・復号化部０３１４、暗号鍵生成部０３１３により生成された暗号鍵を格納する鍵格納データベース０３２３がある。
【００２７】
グループ管理部０３１１は、グループ管理テーブル０３２１を用いて暗号鍵を共有することで形成したグループの管理を行う。各グループ内での暗号強度を保つために各グループに対応付けた暗号鍵を繰り返し暗号鍵生成部０３１３に生成させて、鍵配布部０３１５により各ノードに対してそれぞれが加入しているグループの暗号鍵をユニキャストにて配布する。
【００２８】
ノード管理部０３１２からノードの新規加入の通知があった場合はグループ管理テーブル０３２１を更新し、該ノードに対して鍵配布部０３１５より加入を許可されたグループの暗号鍵を配布する。またノード管理部０３１２からノードの離脱の通知があった場合はグループ管理テーブル０３２１を更新し、該ノードが加入していたグループの暗号鍵を暗号鍵生成部０３１３に新しく生成させて、該ノードが加入していたグループの、離脱したメンバを除く他のメンバの各ノードに対して該鍵をユニキャストにて配布する。
【００２９】
ノード管理部０３１２は、通信媒体０３０２を介して各ノードからの生存信号を受信してノードの生存状態をノード管理テーブル０３２２に記述する。またノード管理テーブル０３２２の情報を用いてノードの認証等を行う。なお生存信号によりノードの新規加入や離脱等の変化を把握した場合はグループ管理部０３１１に通知する。
【００３０】
図４は、システム内に設置された端末０１１３またはコントローラ０１４３など、暗号鍵を用いてデータの送受信を行うノードの機能構成を示す図である。業務や機器制御等を行うアプリケーション０４０３と通信媒体０３０２を介して暗号化通信や暗号鍵の管理を行うミドルウェア０４０４から成る。ミドルウェア０４０４の主な構成要素としては、鍵管理サーバから配布された暗号鍵を管理し、通信データの暗号化、復号化に用いる暗号化鍵の選択を行う鍵管理部０４１１、鍵管理部０４１１より受け取った暗号鍵を用いて送信データの暗号化、受信データの復号化を行う暗号・復号化部０４１２、通信媒体０３０２を介してグループ内でのマルチキャスト通信や鍵管理サーバから配布される暗号鍵の受信や鍵管理サーバへの鍵要求メッセージの送信等を行うデータ通信部０４１３、鍵管理サーバより配布されたグループ内のマルチキャスト通信用の暗号鍵を格納する鍵格納データベース０４２１がある。
【００３１】
鍵管理部０４１１は、鍵管理サーバから配布された暗号鍵を格納した鍵格納データベース０４２１の管理を行い、鍵管理サーバから暗号鍵を受信する度に鍵格納データベース０４２１の更新を行う。またノード０４０１が加入しているグループに関して該当するバージョンの暗号鍵を保持していない場合は鍵管理サーバに対して鍵要求メッセージを送信する。
【００３２】
暗号・復号化部０４１２は、データ通信部０４１３から受け取った送信データに対してアプリケーション０４０３により指定された送信先のグループの暗号鍵を鍵格納データベース０４２１から取り出して暗号化し、データ通信部０４１３に返す。またデータ通信部０４１３からマルチキャスト通信の受信データを受け取ると、該当する暗号鍵を鍵格納データベース０４２１から取り出して復号化し、データ通信部０４１３に返す。
【００３３】
データ通信部０４１３は、アプリケーション０４０３からデータを受け取ると、データを暗号・復号化部０４１２に渡して暗号化する。上記の暗号化したデータをデータ通信部０４１３は通信媒体０３０２を介して指定されたグループへとマルチキャスト通信を行う。また通信媒体０３０２を介して受信した暗号化されたデータは暗号・復号化処理部０４１２に渡して復号化を行う。上記の復号化したデータをデータ通信部０４１３はアプリケーション０４０３に引き渡す。
【００３４】
なお、上記各ノードの各機能は、それぞれの記憶装置０１５１または０１６１に格納されたプログラムをそれぞれの処理装置０１５２または０１６２が実行することにより、各ノード上に具現化されるものである。各プログラムは、あらかじめ、上記ノード内の記憶装置に格納されていても良いし、必要なときに、ノードが利用可能な、着脱可能な記憶媒体または通信媒体（通信回線または通信回線上の搬送波）を介して、上記記憶装置に導入されてもよい。
【００３５】
図５は、鍵管理サーバ０１１１においてセキュアなグループを管理するためのグループ管理テーブル０３２１を示す図である。主な構成要素としては、暗号鍵を共有することで形成されるセキュアなグループを識別する識別子であるグループ番号０５０１、各グループに加入することが事前に許可されているノードの番号を記載する加入許可ノード番号０５０２、各グループに現在加入して動作中であるノードの番号を記載する現加入メンバノード番号０５０３、各グループに対応付けられた暗号鍵を格納するグループ鍵０５０４、各グループに対応付けられた暗号鍵の現在の最新のバージョン情報を記載するグループ鍵バージョン０５０５がある。
【００３６】
本テーブルは処理に応じてリアルタイムに更新され、本テーブルに格納する情報を用いて、各グループへの鍵の配布や更新の処理、各グループにノードが加入する際の認証処理等が行われる。
【００３７】
図６は、鍵管理サーバ０１１１においてシステム内にあるノードを管理するためのノード管理テーブル０３２２を示す図である。主な構成要素としては、システム内にある各ノードを識別する識別子を記載するノード番号０６０１、各ノードのネットワーク上のアドレスを記載するアドレス０６０２、各ノードの生または死の状態を記載する生存状態０６０３、各ノードに対応付けられた暗号鍵を格納するノード鍵０６０４、各ノードに対応付けられた暗号鍵の現在の最新のバージョン情報を記載するノード鍵バージョン０６０５、各ノードの認証に関する情報を格納する認証情報０６０６がある。
【００３８】
本テーブルは処理に応じてリアルタイムに更新され、本テーブルに格納する情報を用いて、各グループへの鍵の配布や更新の処理等が行われる。
【００３９】
図７は、生存信号を基にした、あるノードが新規に受信グループに加入する場合及び受信グループからあるノードが削除される場合の、鍵管理サーバ０１１１における処理の流れを示すフローチャートである。
０７０１において、鍵管理サーバ０１１１が受信したノードの生存信号が死の状態から生の状態への変化を示している場合、
０７０２において、鍵管理サーバ０１１１により上記生存信号を受信したノードの認証を行う。なお認証には図６で示したノード管理テーブル０３２２に記載されているノードの認証情報０６０６を参照する。認証が失敗した場合は処理を終了する。
認証が成功した場合は０７０３において、ノード管理テーブル０３２２の該ノードの関する“生存状態”の項を“ＤＥＡＤ”から“ＡＬＩＶＥ”に変更する。
０７０４において、該ノードから加入を希望するグループの番号を受け付ける。
０７０５において、０７０４において該ノードから受け付けた加入希望のグループに関して図５で示したグループ管理テーブル０３２１の“加入許可ノード番号”を参照する。該ノードが加入希望グループに加入許可であった場合、
０７０６において、該ノードが加入許可されたグループに関してグループ管理テーブルの“現加入メンバノード番号” の項に該ノードの番号を追加する。
０７０７において、加入が許可されたグループの鍵をノードに送信して処理を終了する。
【００４０】
また０７０１において、鍵管理サーバが受信したノードの生存信号が生の状態から死の状態に変化である場合、
０７１１において、生存信号を受信したノードに関してノード管理テーブルの“生存状態”の項を“ＡＬＩＶＥ”から“ＤＥＡＤ”に変更する。
【００４１】
０７１２において、図５で示したグループ管理テーブルから該ノードが加入しているグループを検索する。
【００４２】
０７１３において、グループ管理テーブルでの、０７１２において検索されたグループに関して“現加入ノード番号”の項から該ノードの番号を削除する。
【００４３】
０７１４において、０７１２において検索されたグループの鍵を新しく生成する。
【００４４】
０７１５において、該ノードが加入していた全てのグループの検索が終えていなければ０７１２、０７１３、０７１４の処理を繰り返す。
【００４５】
全てのグループの検索が終えていれば０７１６において、生成した鍵を該ノード以外の生存する他のノードに配布して処理を終了する。
【００４６】
図８は、各ノードにおける受信データに応じた暗号鍵の切り替え方法の概要を示す図である。主な構成要素は鍵管理サーバ０１１１と同一のグループに加入しているノードＡ０８０１、ノードＢ０８０２、ノードＣ０８０３がある。これらのノードは、図１に示した端末０１１３、０１２２、０１２３、０１２４、０１４２、業務用サーバ０１１２、コントローラ０１３２、０１３３、０１４３に相当する。
【００４７】
なお、各ノードの鍵格納域０８４１に保有する暗号鍵のバージョンの数はシステムに依存する。本実施例では４つのバージョンの鍵を格納できる。図ではVer.1(０８４４)、Ver.2(０８４３)、Ver.3(０８４２)が格納されており、次回鍵が配布されると、空き領域に新しい鍵が格納される。さらにその後、新しい鍵が配布されると、最も古い鍵であるVer.1(０８４４)が削除され、空いた領域に新しい鍵が配布される。
０８１１において鍵管理サーバ０１１１はグループのVer.2の鍵をノードＡ０８０１、ノードＢ０８０２、ノードＣ０８０３にユニキャストにて配布する。
０８２１においてノードＢ０８０２は上記配布されたVer.2の鍵で暗号化してデータ送信を行う。
０８３１においてノードＣ０８０３は上記ノードＢ０８０２が送信したデータを受信すると、ヘッダに格納された暗号鍵のバージョン情報を参照してVer.2の鍵を取り出して復号化する。
【００４８】
０８１２において鍵管理サーバ０１１１からグループのVer.3の鍵をノードＡ０８０１、ノードＣ０８０３に配布され、ノードＢ０８０２にはまだ配布されていない。
０８２２においてノードＡ０８０１は上記配布されたVer.3の鍵を取り出して暗号化してデータ送信を行う。
０８３２においてノードＣ０８０３は上記ノードＡ０８０１が送信したデータを受信すると、ヘッダに格納された暗号鍵のバージョン情報を参照してVer.3の鍵で復号化する。
０８２３においてノードＢ０８０２は上記配布されたVer.3の鍵を受信していないためVer.2の鍵で暗号化してデータ送信を行う。
０８３３においてノードＣ０８０３は上記ノードＢ０８０２が送信したデータを受信すると、ヘッダに格納された暗号鍵のバージョン情報を参照してVer.2の鍵を取り出して復号化する。
【００４９】
図９は、グループ内での暗号通信に用いる通信メッセージの概要及び複数の特定ノードをリアルタイムに除外してマルチキャスト通信を行う場合の通信メッセージの概要を示す図である。
【００５０】
通信メッセージ０９０１にはヘッダ０９０２と、ノードより送信するデータを、グループに対応付けられた暗号鍵を用いて暗号化した暗号化データ０９０３とが含まれる。
【００５１】
ヘッダ０９０２にはマルチキャスト通信の送信先やユニキャスト通信の宛先等の情報を格納している通信ヘッダ０９０４と、送信元のノードにて暗号化データ０９０３を作成するために用いた、グループに対応付けられた暗号鍵のバージョン情報０９０５とが含まれる。暗号鍵のバージョン情報０９０５は、通信メッセージ０９０１を受信したノードにおいて、暗号化データ０９０３を復号化するための暗号鍵を選択する際に参照される。
【００５２】
また３つのノードを除外してマルチキャスト通信を行う場合の通信メッセージの例についても示す。なお除外する３つのノードのそれぞれが含まれないサブグループに対応付けられた暗号鍵をそれぞれ鍵(1)、鍵(2)、鍵(3)としている。
【００５３】
鍵Ａのバージョン情報０９１１と鍵(1)により暗号化された暗号化データ０９１２を合わせて、０９４１において鍵(2)により暗号化した暗号化データ０９２２を作成する。暗号化データ０９２２と、暗号化に用いる鍵(2)のバージョン情報０９２１を合わせて、０９４２において鍵(3)により暗号化し、暗号化データ０９３３を作成する。暗号化データ０９３３に、暗号化に用いる鍵(3)のバージョン情報０９３２と通信ヘッダ０９３１を付加して送信する。通信ヘッダ０９３１と、最後に暗号化した鍵である鍵(3)のバージョン情報０９３２はヘッダ０９５１に格納する。ヘッダ０９５１はヘッダ０９０２と同じである。
【００５４】
図１０は、各ノードにおける受信データに応じて、復号化に用いる暗号鍵のバージョンを切り替える処理を示すフローチャートである。
【００５５】
１００１において、マルチキャスト通信されたデータを受信する。
【００５６】
１００２において、１００１の受信データのヘッダから暗号化に用いている暗号鍵のバージョン情報を抽出する。
【００５７】
１００３において、１００２で抽出したバージョン情報と該当するバージョンの鍵を保持していれば、
１００４において、該当するバージョンの鍵を抽出して鍵の切り替えを行う。
【００５８】
１００５において、１００４において切り替えた鍵を用いて１００１の受信データを復号化する。
【００５９】
１００３において、１００２で抽出したバージョン情報と該当するバージョンの鍵を保持していなければ、
１００６において、１００１の受信データを廃棄する。
【００６０】
１００７において、鍵管理サーバに対して該当するバージョンの鍵の送付を要求して処理を終了する。
【００６１】
図１１は、各ノードにて保持するサブグループに対応付けた暗号鍵の内訳を示す図である。ここではあるグループにノードＡ１１０１、ノードＢ１１０２、ノードＣ１１０３、ノードＤ１１０４、ノードＥ１１０５が加入している場合の例について示す。なおノードＡ１１０１、ノードＢ１１０２、ノードＣ１１０３、ノードＤ１１０４、ノードＥ１１０５は図１に示した情報制御システムにおける端末０１１３、０１２２、０１２３、０１２４、０１４２、業務用サーバ０１１２、コントローラ０１３２、０１３３、０１４３に相当する。
ノードＡ１１０１、ノードＢ１１０２、ノードＣ１１０３、ノードＤ１１０４、ノードＥ１１０５のそれぞれに対応する鍵として鍵(1)１１１１、鍵(2)１１１２、鍵(3)１１１３、鍵(4)１１１４、鍵(5)１１１５を用意する。なお各ノードは、自ノードに対応付けられた鍵は保有せず、グループ内の自ノード以外の全てのノードに対応付けられた鍵を保有する。例えばノードＡ１１０１は、鍵(1)１１１１を保有せず、それ以外の鍵(2)１１１２、鍵(3)１１１３、鍵(4)１１１４、鍵(5)１１１５を保有する。他のノードも同様である。
【００６２】
上記により、鍵(1)１１１１を持つノードＢ１１０２、ノードＣ１１０３、ノードＤ１１０４、ノードＥ１１０５によるサブグループのように、ノードＡ１１０１〜ノードＥ１１０５のそれぞれ１つだけを除いたサブグループが形成される。ある特定のノードを除いてグループ内にマルチキャスト送信を行いたい場合は、該ノードが含まれないサブグループの暗号鍵で暗号化して送信すると良い。
【００６３】
例えばノードＡ１１０１がグループに対してマルチキャスト送信をする場合、ノードＤ１１０４による受信を拒否しようとすると、ノードＡ１１０１はグループの暗号鍵からノードＤ１１０４は加入していないサブグループ１１１４の暗号鍵に切り替えて暗号化しマルチキャスト送信する。この時、ノードＡ１１０１、ノードＢ１１０２、ノード１１０３、ノード１１０５はデータを受信して復号化できるが、ノードＤ１１０４はデータを受信しても対応する暗号鍵を持っていないため、復号化してデータを参照することはできない。
【００６４】
上述の構成によりグループより離脱したノードやハッキングされた可能性のあるノード等のデータ受信を直ちに拒否したり、データ毎に受信を拒否するノードを細かく設定したりすることが可能になる。データの受信側では通信ヘッダに格納された暗号鍵のバージョン情報を参照して保有する鍵の中から該当する鍵を選出して復号化するが、受信を拒否されたノードにおいては該当する鍵が無いために復号化できず、データを参照できない。また、送信側のノードでは保有している鍵の中から、暗号化に使用する鍵をグループの鍵からサブグループの鍵に切り替えるだけでよいので、特定ノードの受信を拒否するためにデータ配信の停止や遅延を起こすことなく、リアルタイムに処理することができる。
【００６５】
なお上述のサブグループの暗号鍵は、グループよりノードが離脱した場合の新しい鍵の配布、切り替えが完了するまでの期間等、一時的に利用するためのものであり、あるグループに新たなノードが認証成立して加入したら鍵管理サーバが生成してグループの各メンバに配布するものである。またあるノードがグループより離脱した場合、該ノードのサブグループ鍵の利用を拒否するため、該ノードが所属していた各サブグループに対して、生存する他のノードへの新しい鍵の配布と切り替えが必要となる。
【００６６】
図１２は、特定ノードが含まれない受信グループへの切り替えをリアルタイムに行う場合の、通信を行うノードにおける送信時の暗号化処理及び受信時の復号化処理の流れを示すフローチャートである。
【００６７】
１２０１において、ノードにおいて実行する通信処理がデータ送信である場合、
１２０２において、受信を拒否するノードが所属しないサブグループの暗号鍵をノードの保有する鍵の中から抽出する。
【００６８】
１２０３において、送信するデータを１５０２において抽出したサブグループ鍵を用いて暗号化する。
【００６９】
１２０４において、送信データのヘッダに１２０３における暗号化に用いたサブグループ鍵に関するバージョン情報を記入する。
【００７０】
１２０５において、受信拒否するノードが他になければ、１２０６において、データを送信して処理を終了する。１２０５において、受信拒否するノードが他にもあれば、１２０２に戻る。
【００７１】
また１２０１において、ノードにおいて実行する通信処理がデータ受信である場合、
１２１１において、マルチキャスト通信によるデータを受信する。
【００７２】
１２１２において、通信ヘッダ内に記述された鍵バージョン情報を参照して対応するサブグループ鍵をノードの保有する鍵の中から抽出する。
【００７３】
１２１３において、該当するサブグループ鍵がなければ、
１２１５において、受信データを破棄して、処理を終了する。
【００７４】
１２１３において、該当するサブグループ鍵があれば、
１２１４において、１２１１で受信したデータを１２１２で抽出したサブグループ鍵を用いて復号化する。
【００７５】
１２１６において、１２１４で復号化したデータがまだ別のサブグループ鍵で暗号化されていれば、１２１２に戻る。
【００７６】
１２１６において、データが他のサブグループ鍵で暗号化されていなければ、処理を終了する。
【００７７】
図１３は、セキュアグループ管理方法を具体的に広域ネットワークを介した遠隔監視システムに適用した場合の概要を示す図である。ここでは本社１３０１にいるオペレータが遠隔地にあり、広域ネットワーク１３０５を介して相互接続されている工場１３０３、１３０４、１３０５等、複数の工場を監視、運用する場合の例を示す。また工場１３０３のように夜間の業務代行を行う場合等も考えられる。なお本社、工場間では専用線ではない一般の広域ネットワークを用いていることから、通信時のデータの漏洩や改竄等を防止するために、通信データの保護が必要となる。
【００７８】
本社１３０１にいるオペレータが使用するノード１３１２、１３１３は工場の設備の操作や生産ラインの管理を行う運用グループ１３２１に所属している。オペレータが使用するノード１３１４、１３１５、１３１６は工場の設備の保守を行う設備保守グループ１３２２に所属している。
【００７９】
運用グループ１３２１では設備の制御コマンドや生産計画、生産実績等の情報が共有され、工場で使用されるノード１３０３、１３０４からは制御データ、生産実績等の情報が該グループに対してマルチキャストにて送信される。また設備保守グループ１３２２で使用されるノードでは設備の稼動計画や保守に関する情報が共有され、工場１３０３、１３０４で使用されるノードからは各設備の稼動状態に関する情報が該グループに対してマルチキャストにて送信される。運用グループ１３２１、設備保守グループ１３２２にはそれぞれ異なる暗号鍵を用いているため、グループ外へ情報が漏洩することがなく、権限のないオペレータ等が不正に工場１３０３、１３０４の設備の操作をしたり、設備データを閲覧したりはできない。なおオペレータ１３１１は監督責任者であり、運用グループ１３２１、設備保守１３２２の両方の情報を閲覧する権限があることから、２つのグループの暗号鍵とも配布されている。
【００８０】
また支社１３０２に出張に来たオペレータ１３１７であっても、使用するノードをネットワークに接続することにより、所属しているグループ内でマルチキャストされている情報を受信することができる。この時通常は工場１３０３、１３０４に関する情報は配信されていない支社１３０２にもオペレータ１３１７がいるためにマルチキャストにより情報が配信される。しかしマルチキャストされるデータはオペレータ１３１７の所属するグループの鍵で暗号化されているため、権限のない支社１３０２にいる他の人々が使用するノードでは工場１３０３、１３０４に関するデータが配信されても閲覧することはできない。このように広域ネットワークを介した遠隔監視システムにおいて、権限に応じて情報の受信者を制限したデータ配信を行うことができる。
【００８１】
図１４は、セキュアグループ管理方法を具体的に公共スペースでの情報配信、情報共有のサービスに適用した場合の概要を示す図である。ここでは公共スペース１４０１に訪れた訪問者１４１１〜１４１５に対する広告やサービス等のコンテンツ配信や訪問者間での情報共有やチャット等のサービスを提供し、また公共スペース１４０１で働くスタッフ１４２１〜１４２４に対しては業務連絡や業務情報の共有等を行う場合の例について示す。なおここでは不特定多数の訪問者、または複数のスタッフに対して効率的に情報を配信するためにマルチキャスト通信が行われる。また情報配信等のサービスは公共スペース１４０１にいる人に対して提供するものであり、訪問者またはスタッフが公共スペース１４０１に滞在している間だけ、または滞在中の一定時間だけ情報配信または情報共有のグループに加入するものとする。
【００８２】
システムの主な構成要素として、公共スペース１４０１内のネットワークに接続されたコンテンツ配信サーバまたは業務管理サーバ１４０２、鍵管理サーバ１４０３、公共スペース１４０１内の無線のアクセスポイント１４０４〜１４０７、スタッフ向けの端末１４３９等がある。また訪問者１４１１〜１４１５及びスタッフは１４２１〜１４２４は情報配信の受信及び情報共有のために無線機能を有する携帯端末１４３１〜１４３８を持っている。
【００８３】
業務に関する情報がスタッフ以外には漏れないように、スタッフ１４２１〜１４２３はスタッフ用のグループ１４４３に加入しており、業務管理サーバ１４０２からの業務情報は該グループに対してマルチキャストされ、またグループ内においてスタッフ同士で業務連絡や業務情報の共有を行う。また訪問者１４１２〜１４１４は受けているサービスによりそれぞれサービス毎に対応付けられたグループ１４４１、１４４２に加入する。サービスコンテンツによっては課金を行うため、料金の払っていない訪問者のデータ受信や、訪問者がサービスの利用を終了した後にも引き続きデータを受信し続けて訪問者に余分に課金すること等を防止するためサービス毎にグループを形成し、訪問者がサービスを受けている間だけ該グループに加入するようにする。
【００８４】
公共スペース１４０１内には不特定の訪問者が訪れ、また訪問者、スタッフとも滞在は流動的である。そこで訪問者１４１１が公共スペース１４０１に訪れた時、訪問者１４１１に対して、グループ１４４１へ加入させサービスを提供するため、訪問者１４１１の持つ携帯端末１４３１にグループ１４４１に対応付けられた暗号鍵を配布する。さらにグループ１４４１に加入していてサービスの提供を受けていた訪問者１４１５が公共スペースから去る場合、またはサービス提供の有効期間が終了した場合は、グループ１４４１に残っている他の訪問者１４１１〜１４１３の携帯端末１４３１〜１４３３に対してグループ１４４１に対応付けられた新しい暗号鍵を配布する。
【００８５】
またスタッフ１４２３がスタッフ１４２４と交代する場合も同様にして、グループ１４４３に引き続き残っているスタッフ１４２１、１４２２及び交代して新しく加入したスタッフ１４２４の携帯端末１４３６、１４３９及び端末１４３８に対してグループ１４４３に対応付けられた新しい暗号鍵を配布する。
【００８６】
上記のように通信を行うノードが不特定であり、また流動的であるようなシステムにおいてもセキュアなグループにおける通信を実現している。
【００８７】
図１５は、セキュアグループ管理方法をセキュリティレベルの異なる異種のネットワークを相互接続したシステムに適用した場合のゲートウェイノードにおける処理の概要を示す図である。
【００８８】
広域網や拠点内のＬＡＮ、他社システム等ではネットワークの特性や状態の違いからお互いにセキュリティのレベルが異なる場合がある。よって異なるのネットワークに属するノード同士が同一の暗号鍵を共有してグループを形成することができない場合がある。そこで広域網に接続しているノード同士のグループ、１つの拠点内のＬＡＮに接続しているノード同士などでのグループ等を形成すると良い。なおそれぞれ異なる暗号鍵を共有するグループであるが、それぞれのネットワークに対して求められるセキュリティのレベルに応じて暗号鍵の種類や更新周期等を設定する。またネットワークによっては暗号鍵を用いないで通信するよう設定することもできる。
【００８９】
上記のセキュリティレベルの異なるグループを超えてデータの共有を行うためには、異なる複数のグループに所属するゲートウェイノードを置き、グループ間でのデータの中継を行う。以下にはゲートウェイノードにおける処理の概要を示す。
【００９０】
１５１１において、グループ(2)のノード１５０３はゲートウェイノード１５０２に対してデータの転送要求を送信する。転送要求には、転送を要求するデータに関する情報(データのＩＤ、データの送信元のアドレス等)、データを転送する宛先(グループ(2)内のノードのアドレスまたはサブグループのＩＤ)、転送の際の通信方式(ユニキャストまたはマルチキャスト)、転送方法(そのまま転送、またはゲートウェイノード１５０２にてグループ(1)の暗号鍵で復号化した後グループ(2)の暗号鍵で暗号化してから転送)等の情報を含める。
【００９１】
１５１２において、ゲートウェイノード１５０２は転送要求を出したグループ(2)のノード１５０３の認証を行う。
【００９２】
１５１３において、ゲートウェイノード１５０２はグループ(2)のノード１５０３に対して認証結果を送信する。認証が成功している場合、
１５１４において、ゲートウェイノード１５０２はグループ(2)に対する転送設定の登録を行う。
【００９３】
１５１５において、グループ(1)のノード１５０１は送信データの暗号化を行う。
【００９４】
１５１６において、グループ(1)のノード１５０１は暗号化したデータのマルチキャスト送信を行う。
【００９５】
１５１７において、ゲートウェイノード１５０２は転送登録されていたデータを受信すると、登録内容に従いデータの処理(復号化と暗号化、または何もしない)を行う。
【００９６】
１５１８において、ゲートウェイノード１５０２は登録されたデータをグループ(2)のノード１５０３に転送する。
【００９７】
１５１９において、グループ(2)のノード１５０３は受信したデータの復号化を行う。
【図面の簡単な説明】
【００９８】
【図１】機器制御等を行う制御系と計画管理業務等を行う情報系とを連携させた情報制御システムの構成の概要を示す図である。
【図２】情報制御システムにおけるマルチキャスト通信の概要を示す図である。
【図３】暗号鍵の生成と配布及びグループやノードの管理を行う鍵管理サーバのモジュール構成を示す図である。
【図４】暗号鍵を用いてデータの送受信を行うノードのモジュール構成を示す図である。
【図５】鍵管理サーバにおいてセキュアなグループを管理するためのグループ管理テーブルを示す図である。
【図６】鍵管理サーバにおいてシステム内にノードを管理するためのノード管理テーブルを示す図である。
【図７】生存信号を基にした、あるノードが新規に受信グループに加入する場合及び受信グループからあるノードが削除される場合の、鍵管理サーバにおける処理の流れを示すフローチャートである。
【図８】各ノードにおける受信データに応じた暗号鍵の切り替え方法の概要を示す図である。
【図９】グループ内での暗号通信に用いる通信メッセージの概要及び複数の特定ノードをリアルタイムに除外してマルチキャスト通信を行う場合の通信メッセージの概要を示す図である。
【図１０】各ノードにおける受信データに応じた復号化に用いる暗号鍵のバージョンの切り替え処理の流れを示すフローチャートである。
【図１１】各ノードにて保持するサブグループに対応付けた暗号鍵の内訳を示す図である。
【図１２】特定ノードが含まれない受信グループへの切り替えをリアルタイムに行う場合の、通信を行うノードにおける送信時の暗号化処理及び受信時の復号化処理の流れを示すフローチャートである。
【図１３】本発明を広域ネットワークを介した遠隔監視システムに適用した場合の概要を示す図である。
【図１４】本発明を公共スペースでの情報配信、情報共有のサービスに適用した場合の概要を示す図である。
【図１５】本発明をセキュリティレベルの異なる異種のネットワークを相互接続したシステムに適用した場合の処理の概要を示す図である。
【符号の説明】
【００９９】
０１１１：鍵管理サーバ、０１１３、０１２２〜０１２４、０１４２：端末、０１３２、０１３３：コントローラ、０３２１：グループ管理テーブル、０３２２：ノード管理テーブル、０５０２：加入許可ノード番号、０５０３：現加入メンバノード番号、０５０４：グループ鍵、０５０５：グループ鍵バージョン、０６０１：ノード番号、０６０２：アドレス、０６０３：生存状態、０６０４：ノード鍵、０６０５：ノード鍵バージョン、０６０６：認証情報、０９０１：通信メッセージ、０９０２：ヘッダ、０９０３：暗号化データ、０９０４：通信ヘッダ、０９０５：暗号鍵のバージョン情報。
【図１】
2005159780.tif 000003
【図２】
2005159780.tif 000004
【図３】
2005159780.tif 000005
【図４】
2005159780.tif 000006
【図５】
2005159780.tif 000007
【図６】
2005159780.tif 000008
【図７】
2005159780.tif 000009
【図８】
2005159780.tif 000010
【図９】
2005159780.tif 000011
【図１０】
2005159780.tif 000012
【図１１】
2005159780.tif 000013
【図１２】
2005159780.tif 000014
【図１３】
2005159780.tif 000015
【図１４】
2005159780.tif 000016
【図１５】
2005159780.tif 000017