データ送信処理装置及びデータ送信プログラム
【課題】権限の異なる複数の機能が混在したネットワーク機器の安全性を、複雑で無く、保持できるようにしたネットワーク機器を認証する。
【解決手段】本開示の一形態に係るデータ送信処理装置１１は、パケット受信部１１１、処理方法判定部１１２、送出方法定義リスト記憶部１１３、送出元モジュール特定部１１４、データ変換部１１５、送信部１１６を有する。受信したデータを送出したモジュールを特定して、送出方法定義リスト記憶部１１３に記憶される送出方法定義リストを参照して処理方法を決定して、送出方法判定部１１２が通信可能と判断した場合は、データ等を送出する。
【解決手段】本開示の一形態に係るデータ送信処理装置１１は、パケット受信部１１１、処理方法判定部１１２、送出方法定義リスト記憶部１１３、送出元モジュール特定部１１４、データ変換部１１５、送信部１１６を有する。受信したデータを送出したモジュールを特定して、送出方法定義リスト記憶部１１３に記憶される送出方法定義リストを参照して処理方法を決定して、送出方法判定部１１２が通信可能と判断した場合は、データ等を送出する。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明の実施形態は、データを送信する技術に関する。
【背景技術】
【０００２】
従来、通信回線で接続された複数の機器またはプログラム同士が通信を行う際の認証(Authentication)の形態としては、（Ａ）通信機器が認証機能を持つ機器認証方式、（Ｂ）各モジュールが個別に認証機能を持つモジュール認証方式の２つが多く用いられている。
【０００３】
まず、（Ａ）の機器認証方式では単一の機器内に複数のモジュールが実装された場合であっても、認証の対象は１個体として扱う。インタネット・プロトコル(IP)の実装されたネットワーク・コンピュータでは、１つのIPアドレスを持つ機器１台を１個体と考え、機器に対応する秘密鍵により生成された認証子をIPパケットに付加して送信する。機器認証方式に属するものとしては、ネットワークインタフェース固有のID番号(MACアドレス)を用いた認証や、IPsec(Security Architecture for Internet Protocol)に代表される暗号技術に基く認証、さらにはそれを応用したVPN(Virtual Private Network)などが広く普及している。
【０００４】
また、（Ｂ）のモジュール認証方式では、各モジュールが個別に認証用のIDまたは鍵を持ち、それらを用いた認証用アルゴリズムを実装することによってIPアドレス等とは関係無く通信相手との認証を行う。モジュール認証方式では、一般にいかなる認証方法でもプログラム実行できるため方式を限定することなくさまざまな暗号技術等を適用することができる。例えばSSH(Secure SHell)プロトコルなどが使われる。
【０００５】
これら従来の認証方式は、機能が限定された産業用機器の通信や、汎用のPC(パーソナルコンピュータ)などによるインターネット・アプリケーションで利用されている。
【先行技術文献】
【非特許文献】
【０００６】
【非特許文献１】IP Authentication using Keyed MD5 (P. Metzger他 1995/8 IETF RFC1828)
【非特許文献２】IP Authentication Header (S. Kent BBN Technologies 2005/12 IETF RFC4302)
【発明の概要】
【発明が解決しようとする課題】
【０００７】
しかし、通信ネットワークの普及により利用形態が複雑化した機器を認証する場合において、従来のネットワーク機器の認証装置では、権限の異なる複数の機能が混在することにより、アプリケーションのデータ処理のミスなどを原因として送信部より誤送信を行い、本来の認証機能が有効に働かなかったり、あるいは、不正に入り込んだコンピュータ・ウイルスが送信部に不正なデータを送り込んだりすることを防ぐのは難しく、権限の異なる複数の機能が混在する機器の安全性を保つことが難しいという問題があった。
【０００８】
また、これを防ぐために、権限の異なる複数の機能それぞれに独立した認証機能を持たせた場合においては、実装が複雑になり、機器のシステムの安全性を維持することが難しいという問題があった。
【０００９】
そこで、この発明の一観点は、権限の異なる複数の機能が混在したネットワーク機器の安全性を、複雑で無く、保持できるようにしたネットワーク機器の認証方法を提供することを目的とする。
【課題を解決するための手段】
【００１０】
上記目的を達成するために、本発明の一実施形態に係るデータ送信処理装置は、データをデータ受信部で受信し、データを送出したモジュールを送出元モジュール特定部で特定する。送出元モジュール毎に定義された、データ変換方法もしくは通信の可否を含む前記データの処理方法を示す送出方法定義リストを送出方法定義リスト記憶部に記憶しておき、処理方法判定部が送出元モジュール特定部によって特定された送出元モジュールに対応する処理方法を、送出方法定義リストを参照し決定する。処理方法判定部の決定した処理方法に前記データの変換方法が含まれる場合は、データ変換部はデータを変換し、処理方法判定部が通信可能と判断した場合は、送信部はデータまたは変換されたデータを送出する。
【図面の簡単な説明】
【００１１】
【図１】第1の実施形態にかかるシステム構成を示す図。
【図２】第1の実施形態にかかるシステムの動作概要を示す図。
【図３】第1の実施形態にかかる送出方法定義リストの例を示す図。
【図４】第1の実施形態にかかる受信データおよび送信データの例を示す図。
【図５】第2の実施形態にかかるシステム構成を示す図。
【図６】第3の実施形態にかかるシステム構成を示す図。
【図７】第4の実施形態にかかる送出方法定義リストの例を示す図。
【図８】第4の実施形態にかかる受信データおよび送信データの例を示す図。
【図９】第5の実施形態にかかるシステム構成の一部を示す図。
【図１０】第6の実施形態にかかるプロセステーブル例を示す図。
【図１１】第6の実施形態にかかる送出方法定義リストの例を示す図。
【図１２】実施形態の発明が適用される場面例を示す図である。
【発明を実施するための形態】
【００１２】
（第１の実施形態）
以下に図面を参照して、この発明にかかる第１の実施形態を詳細に説明する。
【００１３】
図１は、本実施形態のデータ送信システムとそのシステムと連携する機器の構成を示す図であり、インタネット等の公衆ネットワークを介して接続された電力監視機器群の配置例とその機能ブロックを示している。
【００１４】
本実施形態のデータ送信システムは、スマートメーター１、コントロール部データ受信サーバ２、電力量受信サーバ３を有する。本実施形態のデータ送信システムは、ディスプレイ４とHEMS５(Home Energy Management System：ホームサーバ)と接続されており、HEMS５は家電機器６と接続している。
【００１５】
スマートメーター１は、一般家庭やビル、工場などの電力消費ポイント（需要家）に設けられた電力計（メータ）であり、ネットワークに接続する機能を有している。
【００１６】
スマートメーター１は、電力測定部１２、コントロール部１３、パケット受信部１１１、処理方法判定部１１２、送出方法定義リスト記憶部１１３、送出元モジュール特定部１１４、データ変換部１１５、送信部１１６を有する。また、パケット受信部１１１、処理方法判定部１１２、送出元モジュール特定部１１４、送出方法定義リスト記憶部１１３、データ変換部１１５、送信部１１６を有する部分を送信処理部１１（送信処理装置）とする。なお、スマートメーター１は、電力網の制御に関わるさまざまな機能モジュールを持つことができるが、本実施形態では説明を簡略化しており、他の機能モジュールを有していても良い。
【００１７】
ここで、モジュールとは、ある１つの処理（処理単位）をいう。典型的にはコンピュータの１実行主体（プロセス）のことであるが、場合によってはプログラムの格納された１ファイル（exeファイル）や、実装された１機能（共有ライブラリやdllファイルなど）と考えても良い。また、ソフトウエアで実装されたプログラムでも良いし、ある機能を実装したハードウエアであっても良い。
【００１８】
電力測定部１２は、専ら使用電力量などの重要データを扱う。電力測定部１２は、電力線に接続されており、電力線に接続され機器の電力量の測定をする。例えば、図１では家電機器６が電力線にされており、電力測定部１２は家電機器６の電力量を測定するが、これに限られず、電力線に接続されている機器であれば、電力量を測定できる。また、電力測定部１２は測定した電力量を含むデータ（パケット）を後述するコントロール部１３、パケット受信部１１１に送信する。
【００１９】
コントロール部１３は、家庭内の家電機器６コントロールや消費電力の表示など雑多なデータを扱う。コントロール部１３は、電力測定部１２からのデータを受信する。コントロール部１３は、家庭内に設置されたディスプレイ４への表示機能のコントロールや、家電機器６と連携したHEMS５とのデータ送受信を行ってHEMS５のコントロールを行っても良い。これらのデータのやり取りについては従来技術と何等変わるところが無いので、詳細な説明および図示は省略する。また、コントロール部１３では、コントロール部１３で扱うデータ（パケット）を後述するパケット受信部１１１に送信する。
【００２０】
HEMS５は、コントロール部１３と接続されているほかに、家電機器６と接続されている。HEMS５はHEMS５が保持する情報を利用して、家電機器６を制御したり、家電機器６から情報を入手しても良い。
【００２１】
電力測定部１２とコントロール部は基本的には独立のものであるが、システムによっては電力測定部１２で計測したデータの一部をコントロール部１３に渡して処理することも考えられる。
【００２２】
パケット受信部１１１は、受信したデータ（パケット）を後述する処理方法判定部１１２に送信する。
【００２３】
処理方法判定部１１２は、パケット受信部１１１からデータ（パケット）を受信すると、後述する送出元モジュール特定部１１４にデータ（パケット）を送信し、受信したデータ（パケット）の送出元モジュールの識別情報を入手する。ここで、送出元モジュールの識別情報とは、データ（パケット）を送出した元のモジュールを識別する情報であり、本実施形態の例では、電力測定部１２またはコントロール部１３のモジュールを示す名称などであるが、データ（パケット）を送出した元のモジュールを識別する情報であれば、これに限定されるものではない。
【００２４】
処理方法判定部１１２は、データ（パケット）の送出元モジュールの識別情報と、送出方法定義リストに記載された処理方法に関する情報とを、送出元モジュールの識別情報をキーとして照らし合わせた上で、パケットの処理方法を確定する（送出元モジュールに対応する処理方法を、送出方法定義リストを参照し決定する）。そして、処理方法判定部１１２は、通信が許可されているものについてはデータ（パケット）を送出し、必要な場合は後述するデータ変換部１１５に処理方法（処理方法情報）や鍵も送出する。
【００２５】
送出方法定義リスト記憶部１１３は、送出方法定義リストを記憶する。送出方法定義リストは、送出元モジュールの識別情報と通信の可否との対応付けた情報または送出元モジュールの識別情報とデータ変換方法とを対応付けた情報を有する（送出元モジュール毎に定義された、データ変換方法もしくは通信の可否を含む前記データの処理方法を示す情報を有する）。例えば、あるパケットの送出を許可し、またあるパケットは送出を禁止する情報である。また、送出を許可するパケットについては認証子を付加して送出したり、暗号化してから送出したりすることもあり、これらのデータ変換方法のルールを記述する。また、認証子の作成や暗号化にあたって必要な「鍵」も保持する。ここで、鍵とは一般的な暗号技術で使われる鍵一般のことを広く指し、秘密鍵であるか公開鍵であるかといったことは特に限定しない。図３は、送出方法定義リストの例を示す図である。図３の例では、Prog1、Prog2、Prog3、Miscについて送出方法が定義されている。以下に詳細を説明する。
【００２６】
Prog1は、電力測定部１２のプログラム・モジュールの名称である。
【００２７】
通信は許可となっており、電力測定部１２のプログラム・モジュールからのデータは通信を許可する。また、認証子はhmac−sha1となっており、転送時には hmac−sha1 アルゴリズムにより生成された認証子をパケットに付加する。
【００２８】
hmac−sha1は、ハッシュ関数 sha1 に鍵を適用する方式 hmac を組み合わせた、良く知られた認証子生成方法であるので、その手順説明は省略する。また、hmac−sha1適用にあたっては、鍵である4f434e23f355 を用いる。実際には安全性の観点からより長い鍵を用いるのが普通であるが、説明文を簡略化するため短い鍵を表記している（以下同様）。
【００２９】
また、暗号化はしないになっており、パケットの暗号化は行わない。ここで、鍵は、電力量受信サーバ３も同一の鍵を保持しているため、電力量受信サーバ３は鍵とhmac−sha1アルゴリズムを用いて演算した認証子がパケットに付加されている認証子の値と同一であることを以て、このパケットが、当該スマートメーター１の当該モジュール（電力測定部１２）から送信されたパケットであるということを認証することができる。
【００３０】
なお、この例ではProg1はパケットを暗号化しないものとして説明した。本実施例は、電力測定部１２の測定したデータは盗聴されても構わないという立場だからである。言うまでもなく、必要に応じパケットを暗号化したり、誤ったサーバに送出されないようパケット・フィルタリングするような措置を施す方式も考えられるが、一般的な技術を利用するため本実施形態では特にそれを説明しない。
【００３１】
一方、Prog2はコントロール部１３のプログラム・モジュールの名称である。通信は許可となっており、コントロール部１３からのデータは通信を許可する。また、認証子はhmac−md5となっており、転送時にはhmac−md5アルゴリズムにより生成された認証子をパケットに付加する。その際、鍵 である3a53f324fa47 を用いる。hmac−md5も良く知られた認証子生成方法であるのでその手順説明は省略する。さらに、暗号化アルゴリズムであるAESと、鍵 である3f233322434e を用いてパケットを暗号化する。暗号化の鍵の扱いについては本特許の核となる要件ではないため、実施形態概要を示した図１には図示を省略している。なお、暗号化の処理と、認証子の付加処理の順番については、特にどちらかでなければならないという制約は無く、システムに応じて暗号化を先に行っても良く、その場合には送出方法定義リストに記載する順番を逆にすれば良い。
【００３２】
また、Prog3は一般ライブラリのプログラム・モジュールの１名称である。通信は拒否となっており、一般ライブラリからのパケットは通信を拒否することを示している。
【００３３】
また、Misc は今までのリストに無かったプログラム・モジュールを示している。通信は拒否となっており、プログラム・モジュールの名称記載の無いものについては全て通信を拒否することを示している。
【００３４】
このように図３の例では、各行毎に処理と処理方法を示す情報が記載されているが、他の方法で表現されても処理方法（処理内容）が特定できれば本例に限られない。
【００３５】
送出元モジュール特定部１１４は、処理方法判定部１１２からデータ（パケット）を受信すると、パケットの識別情報とパケットの送出元モジュールの識別情報とが対応付けられたパケット送出元モジュール情報に基づいてパケットの送出元モジュールを特定する。そして、送信元モジュールの識別情報を処理方法判定部１１２に送出する。パケットの識別情報とはパケットを識別するための情報であり、単一の情報や複数の情報の組み合わせであっても良い。
【００３６】
パケットの送出元モジュールを知る方法の例を示す。例えばパケット受信部１１１の受信するデータがIPv4のTCPパケットである場合、そのパケットはRFC791で規定されたIPv4(Internet Protocol version 4)およびRFC793で規定されたTCP(Transmission Control Protocol)の構造になっているので、そのデータを参照することにより、Destination Address(送信先IPアドレス)、Source Port(ソースポート番号)、Destination Port(宛先ポート番号)などの情報が判る。
【００３７】
データ変換部１１５は、処理方法判定部１１２からデータ（パケット）と処理方法（処理方法情報）を受信すると、データ（パケット）に処理方法に従った変換処理を行う（処理方法判定部１１２の決定した処理方法に前記データの変換方法が含まれる場合は、前記データを変換する）。変換処理としては、暗号化や認証子の付加などを行う。そして、変換処理されたデータ（パケット）を送信部に送出する。例えば、図３の例では、データ（パケット）の送出元モジュールがProg１であった場合は、認証子をhmac−sha1で鍵4f434e23f355に基づいて生成する。そのため、図４のようにデータ（パケット）に認証子が追加された形に変換される。こういった認証子の追加には例えばIPの拡張データフィールドを用いることができ、IPsecなどの従来技術においても用いられている。
【００３８】
送信部１１６は、データ変換部から変換処理されたデータ（パケット）を受信し、スマートメーター１の外部に送信する。本実施形態ではコントロール部データ受信サーバ２または電力量受信サーバ３に送信する。その際、電力測定部１２からのデータ（パケット）は電力量受信サーバ３へ送り、コントロール部１３からのデータ（パケット）はコントロール部データ受信サーバ２へ送るという切り替えが発生する。これは一般のIP(Internet Protocol)技術においてパケット内に書かれているDestination Address(送信先IPアドレス)を元に切り替えることが従来より行われており、本実施形態においても実施できる。
【００３９】
実際のシステムでは、セキュリティを高めるためプログラム・モジュール毎に送信可能なサーバを限定したり、送信先によってデータ変換方法を変えるなどのバリエーションが考えられるが、一般にファイア・ウォールと呼ばれているパケット・フィルタリング技術の単純な組み合わせで容易に実現可能であるため、それらバリエーションについては例示を省略する。
【００４０】
コントロール部データ受信サーバ２は、送信部よりデータ（パケット）を受信する。電力会社によって管理されていても良いし、電力制御とは全く関係のないインタネット・サービス提供者によって管理される場合もある。
【００４１】
電力量受信サーバ３は、送信部よりデータ（パケット）を受信する。電力量受信サーバ３は、電力会社の管理する変電所内に置かれたり、またはそのデータの中継点に設置されたＭＤＭＳ(Meter Data Management System)に置かれ、各スマートメーター１の動作を監視している。
【００４２】
本実施形態の動作の概要を図２を利用して説明する。パケット受信部１１１がデータ（パケット）を受信し、受信したデータ（パケット）を処理方法判定部１１２に送信する（Ｓ１０１）。
【００４３】
処理方法判定部１１２は送出元モジュールの特定を送出元モジュール特定部１１４に依頼する（Ｓ１０２）。
【００４４】
送出元モジュール特定部１１４はデータ（パケット）を送出中のモジュールを特定して、送出元モジュールの識別情報を処理方法判定部１１２に送信する（Ｓ１０３）。
【００４５】
処理方法判定部１１２は送出元モジュールの識別情報と送出方法定義リスト記憶部１１３に記憶されている送出方法定義リストを用いてデータ（パケット）の処理方法を決定し、データ（パケット）が送信可能であればデータ変換部にデータ（パケット）を送信する（Ｓ１０４）。
【００４６】
データ変換部１１５はデータ（パケット）の変換が必要な場合は変換をし、変換の必要が無い場合はそのままのデータ（パケット）を送信部１１６に送信する（Ｓ１０５）。
【００４７】
データ送信部はデータ（パケット）をスマートメーター外に送信する（Ｓ１０６）。
【００４８】
本実施形態により権限の異なる複数の機能が混在したネットワーク機器の安全性を、複雑で無く、保持できるようにしたネットワーク機器の認証方法を提供することができる。
【００４９】
（第２の実施形態）
本実施形態の一実施例を図５を用いて以下に説明する。
【００５０】
上述の実施形態と同様の機能については、説明は省略し、図１とは異なるＯＳカーネル１４、ＯＳカーネル・メモリ１５、送出元モジュール特定部、電力測定部１２−２、コントロール部を中心に説明する。
【００５１】
ＯＳカーネル１４とは、プロセス管理を行う一般的なオペレーティング・システム(ＯＳ)と考えて良いが、実装法によっては単にライブラリ関数を切り替えるためのコンピュータ・プログラムの場合もある。
【００５２】
ＯＳカーネル１４は、動作している各モジュールを管理する。さらに、各モジュールがＯＳカーネルにパケット受信部に送信を要求したパケットの情報もカーネル・メモリ内に保持している。そのため、カーネル・メモリ内の情報を参照することで、そのパケットを送出要求しているモジュールが何であるかを知ることができる。
【００５３】
本実施形態では、ＯＳカーネル１４は、電力測定部１２−２やコントロール部から情報を入手する。具体的には、電力測定部１２−２やコントロール部で動作している各モジュールを管理し、各モジュールが送信したデータ（パケット）の情報もカーネル・メモリ内に保持している。また、電力測定部１２−２やコントロール部１３−２に何らかの情報を送信しても良い。
【００５４】
電力測定部１２−２は、電力測定部１２−２内で動作している各モジュールはデータ（パケット）をパケット受信部１１１に送信することをＯＳカーネル１４に要求する。ＯＳカーネル１４は要求されたデータ（パケット）をパケット受信部１１１に送信する。また、ＯＳカーネル１４はカーネル・メモリ１５に要求した電力測定部１２−２のモジュールの識別情報と送信したデータ（パケット）との対応付けて記憶する。コントロール部１３−２は、コントロール部内で動作している各モジュールはデータ（パケット）をパケット受信部１１１に送信することをＯＳカーネル１４に要求する。また、ＯＳカーネル１４はカーネル・メモリ１５に要求したコントロール部１３−２のモジュールの識別情報と送信したデータ（パケット）との対応付けて記憶する。
【００５５】
ＯＳカーネル・メモリ１５は、各モジュールが送信したパケットの情報を一定期間記憶している。具体的には、電力測定部１２−２やコントロール部１３−２で動作している各モジュールがＯＳカーネル１４に送信要求して送信中のデータ（パケット）の情報を記憶する。これは、一般的なＯＳのメカニズムとして、TCPのセッション管理などの目的で、パケットを送信した後にも、通信が完了するまでパケットの情報を保持する必要があるからである。少なくともパケットがスマートメータから外部に送信される迄の間、このパケットの情報は保持される。なお、ＯＳカーネル・メモリ１５に記憶したパケットの情報をいかなるタイミングで消去するかという点に関しては一般的なＯＳのメカニズムを利用するものとし、詳細説明は省略する。
【００５６】
送出元モジュール特定部１１４−２は、処理方法判定部１１２からデータ（パケット）を受信すると、ＯＳカーネル・メモリ１５の情報を参照して、送出元モジュールの識別情報を特定する。そして、送出元モジュールの識別情報を処理方法判定部へ送信する。例えば、netstatコマンド、psコマンド、proc file system、等の名称で広く使われている。さらには、それをユーザに解釈されやすく整形したコマンド類(Windows(登録商標)用のTCPViewなど)も使われている。また、送出元モジュール特定部１１４−２は、処理方法判定部１１２からデータ（パケット）を受信すると、データ（パケット）の識別情報などをＯＳカーネル１４に送出し、ＯＳカーネル１４が受信したデータ（パケット）の識別情報に対応する送出元モジュールの識別情報を抽出し、送出元モジュール特定部１１４−２に送出しても良い。
【００５７】
（第３の実施形態）
上述の実施形態では、スマートメーター１は１つのＯＳカーネル１４−３により管理された複数の機能モジュール（プログラム・ライブラリ）を用いて構成されているものとしているが、ＯＳカーネル１４−３等の実装形態については、言うまでもなく、その部分の設計はいかなるものであっても良い。
【００５８】
本実施形態では、図６に例示するように、スマートメーター１が仮想マシン技術によって構成されていた例を説明する。仮想マシン技術とは、１つの計算機の上で複数のＯＳを同時に動作させ、ＯＳをあたかもプログラムの１つであるかの如く扱う技術である。仮想マシン技術を実装したソフトウエアの例として VMware、Virtual PC、Xen などが広く使われている。
【００５９】
仮想マシン技術を用いての構成例では、スマートメーター１は仮想マシンホストによって管理される。仮想マシンホストは、ホストＯＳと呼ばれることもある。ここで動作するＯＳは、ゲストＯＳと呼ばれるものであり、図６の例では仮想マシンゲストＯＳ（１）１６と仮想マシンゲストＯＳ（２）１７が動作している。各ゲストＯＳは同一種類のＯＳであっても、異なる種類のＯＳであっても良い。例えば1つはWindows（登録商標） ＯＳであり、他方は Linux ＯＳであって良い。
【００６０】
このような構成では、各仮想マシンゲストＯＳは、各仮想マシンゲストＯＳ毎に定められた特定のモジュールはデータ（パケット）をパケット受信部１１１に送信することを仮想マシンゲストＯＳに要求する。そして、各仮想マシンゲストＯＳは、受け付けた要求とデータ（パケット）をＯＳカーネル１４−３に送信する。
【００６１】
例えば、仮想マシンゲストＯＳ（１）１６は電力測定部１２−３からのデータ（パケット）とパケット受信部１１１への送信要求を入手し、入手したデータ（パケット）とパケット受信部１１１への送信要求をＯＳカーネル１４−３に送信する。仮想マシンゲストＯＳ（２）１６はコントロール部１３−３からのデータ（パケット）とパケット受信部１１１への送信要求を入手し、入手したデータ（パケット）とパケット受信部１１１への送信要求をＯＳカーネル１４−３に送信する。また、電力測定部１２−３は仮想マシンゲストＯＳ（１）１６に情報を送信してもよく、コントロール部１３−３は仮想マシンゲストＯＳ（２）１７に情報を送信してもよい。
【００６２】
ＯＳカーネル１４−３は、仮想マシンゲストＯＳ（１）または仮想マシンゲストＯＳ（２）からデータ（パケット）とパケット受信部１１１への送信要求を受信する。そして、受信したデータ（パケット）をパケット受信部１１１に送信する。また、ＯＳカーネル１４−３は、仮想マシンゲストＯＳの識別情報と仮想マシンゲストＯＳから受信したデータ（パケット）とを対応付けた情報をＯＳカーネル・メモリ１５−３に記憶させる。また、必要に応じて仮想マシンゲストＯＳの識別情報と仮想マシンゲストＯＳから受信したデータ（パケット）とを対応付けた情報を読み出す。また、送出元モジュール特定部からの要求に応じて、読み出した情報を送出元モジュール特定部１１４−３に送出したり、または、データ（パケット）を受信した仮想マシンゲストＯＳを特定して送出元モジュール特定部に送出する。
【００６３】
また、上記例ではＯＳカーネルがパケット受信部１１１にデータ（パケット）を送信しているが、各仮想マシンゲストＯＳがパケット受信部１１１にデータ（パケット）を送信しても良い。
【００６４】
このような構成のスマートメーター１においては、各仮想マシンゲストＯＳ毎に定義された送出方法を送出方法定義リストに記述し、送出元モジュール特定部１１４−３が特定したゲストＯＳ情報を利用して、処理方法判定部１１２が送信データの処理方法を判定することで、各ゲストＯＳに割り当てられた機能に応じたデータ送信を行うことができるので、例えば要求される安全性の大きく異なるゲストＯＳが混在するスマートメーター１においても、個別に複雑な認証メカニズムを実装することなく適切なアクセス制限を実現することができる。特に、実装上の理由で、コンピュータ・ウイルスに感染しやすい危険なＯＳをゲストＯＳに用いたとしても、そのウイルスによる動作不具合は当該ゲストＯＳおよび、当該ゲストＯＳの通信する先のサーバに限定され、他のゲストＯＳおよび、他のゲストＯＳの通信する先のサーバに悪影響が及ぶことを防止することができる。
【００６５】
（第４の実施形態）
本実施形態では、データ変換部１１５は、送出元モジュール特定部１１４または１１４−２または１１４−３によって特定された、モジュールの種別情報をデータに付加する実施例について説明する。データ変換部、送出方法定義リスト以外については、上述の実施形態や実施例と共通するため、説明は省略する。また、データ変換部が異なり、全体の構成は図１、４、５と同様であるため、図示も省略する。
【００６６】
本実施形態の送出方法定義リスト記憶部に記憶される送出方法定義リストには、送出元モジュールを識別する送出元モジュール識別情報（以下送出元モジュールＩＤという）を付加することの指示が追加されている。例えば、図７は本実施形態の送出方法定義リストの例を示すものであり、本図を利用して説明する。図４ではProg1にhmac-sha1認証子を付加することが指示されているが、これに加え、Prog1というモジュールの送出元モジュールＩＤを付加した上で、さらにhmac-sha1認証子を計算することの指示が追加されている。Prog2についても同様である。
【００６７】
データ変換部は、送出方法定義リストで送出元モジュールを識別する送出元モジュール識別情報を付加することの指示が追加されているため、図８のように元のデータに送出元モジュールIDを付加した上で、さらにhmac-sha1認証子を計算して付与する。
【００６８】
認証子が付加されているため、仮にデータが暗号化されていない場合であっても、ネットワーク上で送出元モジュールIDが改ざんされるおそれは無い。
【００６９】
こうすることにより、スマートメーター１より送出されるデータが、スマートメーター１内のどのプログラム・モジュールによって作られたものであるかという情報を、そのデータを受信するサーバに安全に伝達することができる。したがって、パケットの送出方法について送出方法定義リストのみの情報で固定的に定めるのではなく、そのデータを受信するサーバが、送出元モジュールIDも参考にして、サーバ側のポリシーに従い、柔軟に通信の可否を定めることができ、より柔軟なアクセス制御が実現できる。
【００７０】
従来技術においてこれを実現するには、たった１台のスマートメーター１の認証のために認証の対象となるモジュールの数に相当する数多くの認証メカニズムを実装する必要があり煩雑であったが、本発明の方法によれば単にProg1という送出元モジュールIDを比較するだけで、個別の認証を行ったのと同等の効果が得られるため、単純な実装が可能である。
【００７１】
（第５の実施形態）
本実施形態では、送出元モジュール特定部の別の実現方法として、特定したモジュールの持つソフトウエアのデジタル署名（または認証子、チェックサム）を検証することができる例について図９を用いて説明する。本実施形態では、図９のように特定が必要な送出元モジュールが送出したデータ（パケット）に予め該モジュールデータのデジタル署名を加えておきそれを署名検証用鍵で検証する。
【００７２】
図９では送出元モジュール特定部、処理方法判定部、署名検証用鍵記憶部以外は上記実施形態と同様であるため、省略し、どの実施形態に組み合わせることができる。
【００７３】
処理方法判定部１１２−４ではパケット受信部１１１−４（図示せず）が受信し、パケット受信部１１１−４が処理方法判定部１１２−４に送信したデジタル署名が付加されたデータ（パケット）を受信する。そして、受信したデータ（パケット）を署名検証用鍵で検証して、正当な署名であるかを確認する。
【００７４】
正当な署名の付いているモジュールは正当と判断しても良いし、より正確にはプログラム名称等も含めたデジタル署名を付加しておき、その名称をチェックして正しければ送出元モジュールが正しいと判断するといった実装も可能である。
【００７５】
また、この方法を用いることで、送出元モジュールの特定にあたって必ずしもＯＳが管理する情報（カーネル・メモリ１５または１５−３）を参照する必要が無くなる。ＯＳの性質によっては、ＯＳが管理する情報を参照するには困難が伴う場合があるため、本方式の方が優れている場合もある。
【００７６】
なお、デジタル署名と呼ばれる技術は、通常公開鍵暗号方式を用いた署名を指すことが多いが、ここでは電子的な署名であれば何でも良く、例えば認証子を付加したり、単なるチェックサムを念のため付加しておくといったケースも考えられ、特に署名の方式を限定しない。
【００７７】
ＯＳが特定できる送出元モジュールが例えばそのプログラムのパス名であった場合、パス名はそのままに悪意のプログラム等にプログラムの中身が変更（差し替え）されていても判別できないが、本実施形態を用いることで誤った動作を未然に防ぐことができる。
【００７８】
（第６の実施形態）
本実施形態では、送信元モジュール特定部は、特定したモジュールの持つソフトウエアが起動されるに至った経緯情報を特定する例について説明する。システム構成は上記実施形態と同様であるため、図は省略し、図１、４、５の送出元モジュール特定部１１４、１１４−２、１１４−３、１１４―４や、処理方法判定部１１２の変形例として説明し、他の構成要素については同様である。
【００７９】
このような機能が必要となる背景について以下に記載する。一般に、ＯＳにより管理されているプログラムは、１プログラムで１機能を実現するといった単独のものであることはまれであり、多くの場合、親プロセスから子プロセスが起動され、さらにその子プロセスが起動される、という流れによって機能が実現されている。従って、単に１プログラムの名称のみでアクセス制御を行うのみでは十分な安全性が確保できないケースも考えられる。
【００８０】
例えば、通常 Ａ→Ｂ→Ｃ→Ｄ という順番で起動されるプログラム D が正当なものであった場合、送信元モジュール特定部が送信元モジュールのみを特定するのであれば、E →D’ という順番で起動されたプログラム D’ も正当なものとして扱われてしまう。
【００８１】
しかしこのように想定外の順番でプログラムが起動される場合、不安全な事態が発生している可能性が極めて高い。例えばプログラムEは電子メールをネットワークから受信するサーバであるとすると、サーバに不正侵入され実行権限を乗っ取られたために、プログラム E の権限（管理者権限など）でプログラム D が不正実行されていると考えられる。
【００８２】
そのため、特定したモジュールの持つソフトウエアが起動されるに至った経緯情報を特定している。
【００８３】
経緯情報を特定するために、ＯＳカーネル１４または１４―３は、プログラム（プログラムモジュール）とそのプログラムが実行するプロセスの識別情報（プロセスＩＤ）とそのプロセスの親プロセスの識別情報（親プロセスＩＤ）を対応付けて把握する。この対応付けられた情報は、プロセステーブルという。プロセステーブルの例を図１０に示す。
【００８４】
例えば、図１０の例では、Ａ（sshd）→Ｂ（bash）→Ｃ（Data_Measure）→Ｄ（Data_send）という順番で起動されるプログラムがある場合を示す。ＯＳカーネル１４または１４―３は最初にプログラム（init）を起動する。するとＯＳカーネル１４または１４―３ではプログラム（init）と、親プロセスはないため親プロセスＩＤは「−１」、プロセスＩＤは「１」として対応付けて把握する。
【００８５】
次ぎに、プログラムＡ（sshd）が起動する。するとＯＳカーネル１４または１４―３ではプログラムＡ（プログラム識別情報はsshd）の親プロセスＩＤは「１」であり、自己のプロセスＩＤは「６６４」であるので、このプログラム識別情報sshdと親プロセスＩＤ「１」とプロセスＩＤ「６６４」も対応付けて把握する。
【００８６】
次にプログラムＢ（bash）が起動する。するとＯＳカーネル１４または１４―３ではプログラムＢ（プログラム識別情報はbash）の親プロセスＩＤは「６６４」であり、自己のプロセスＩＤは「３０６３８」であるので、このプログラム識別情報bashと親プロセスＩＤ「６６４」とプロセスＩＤ「３０６３８」も対応付けて把握する。
【００８７】
次にプログラムＣ（Data_Measure）が起動する。するとＯＳカーネル１４または１４―３ではプログラムＣ（プログラム識別情報はData_Measure）の親プロセスＩＤは「３０６３８」であり、自己のプロセスＩＤは「３０６３９」であるので、このプログラム識別情報bashと親プロセスＩＤ「３０６３８」とプロセスＩＤ「３０６３９」も対応付けて把握する。
【００８８】
さらに、プログラムＤ（Data_send）が起動する。するとＯＳカーネル１４または１４―３ではプログラムＤ（プログラム識別情報はData_send）の親プロセスＩＤは「３０６３９」であり、自己のプロセスＩＤは「３２５０７」であるので、このプログラム識別情報bashと親プロセスＩＤ「３０６３９」とプロセスＩＤ「３２５０７」も対応付けて把握する。このようにＯＳカーネル１４または１４―３が管理するプロセステーブルによって、親プロセスのIDを参照し、順に親プロセスをたどることが可能である。
【００８９】
送信元モジュール特定部１１４または１１４−２または１１４−３または１１４―４は、上記実施形態や実施例のように送出元モジュールを特定するとＯＳカーネル１４または１４―３が管理するプロセステーブルをＯＳカーネル１４または１４―３に要求して入手する。そして、入手したプロセステーブルを利用して、特定されたモジュールの親プロセスＩＤを参照してどのプログラムがどのプログラムから起動されているかの情報であるプログラム起動関係情報を抽出する。そして、プログラム起動関係情報を処理方法判定部に送信する。
【００９０】
処理方法判定部１１２は、送信元モジュール特定部から受信したプログラム起動関係情報のうち最後に起動されているプログラムを特定し、特定したプログラムに関する送出方法定義リスト記憶部から処理方法定義リストを入手する。入手した処理方法定義リストとプログラム起動関係情報に基づいて、起動が正当なプログラムからなされたものであるか否かを判断する。不正なプログラムから起動されたと判断された場合は、処理方法判定部は、データ（パケット）の送出を中止する。
【００９１】
図１１は本実施形態の送出方法定義リストの例を示す。送出方法判定部１１２は送出方法定義リストを送出方法定義リスト記憶部１１３から読み出して、Ａ→Ｂ→Ｃ→Ｄの順で起動されていれば、通信は可能である旨とデータ（パケット）と、図１１で示される鍵でhmac-sha1アルゴリズムで認証子を生成し、暗号化はしないで送信する旨をデータ変換部１１５に送出する。
【００９２】
本実施形態の発明によれば、権限の異なる複数の機能が混在したネットワーク機器において、各機能それぞれに独立した認証機能を持たせることなく、異なる権限を区別して実行する認証機能を実現することができる。
【００９３】
モジュール毎に認証メカニズムを実装する必要が無いため、実装が単純になり、プログラミングのミス（バグ）が出にくく、使用メモリ量も最小限で済む。また、鍵管理を機器全体に対し一本化することができるためその手順を単純化することができる。
【００９４】
また、鍵管理が一本化されているにもかかわらず、機器の中に正しく実装されていないモジュールが含まれていたとしても、その影響は不具合のあるモジュールの機能に限定することができ、システム全体の安全性が低下することが無い。さらには、秘密鍵をモジュール毎に管理する必要が無いため、他のモジュールから関係の無い秘密鍵が見えてしまい、鍵が漏洩したり誤ったデータ送信を行うといったリスクが無い。
【００９５】
また、将来暗号解読技術が進んだ際においても、認証モジュールが一本化されているため、複数の認証モジュールを完全に置き換えるための膨大な確認作業を必要とせず、容易に認証機能の入れ替えを行い安全性を向上させることができるので、システム保守性の面でも有利になる。
【００９６】
上記実施形態の発明によれば、例えば以下のような場面での適用が考えられる。
【００９７】
図１２は上記実施形態の発明が適用される場面例を示す図である。例えば、「スマートグリッド」と呼ばれる電力監視網（次世代電力網）においては、需要家（一般家庭等）に設置された監視端末（スマートメーター１−５）が、電力需給予測を変電所に送信するなどの重要で安全性の要求されるデータ通信を行う。それと同時に、監視端末（スマートメーター）は、ディスプレイ２−５への電力使用状況の表示や、エアコンなどの家電機器のコントロールなど、複雑でプログラムミスの起こりやすい各種アプリケーションを動かしたり、またはプログラムミスの起こりやすい外部のアプリケーションから受信したデータを元に動作することもあり、機器全体としての安全性を損なうことが危惧される。
【００９８】
この種の複雑な機能を持つスマートメーター１−５を従来の（Ａ）機器認証方式で実装した場合、スマートメーター１−５では電力線に接続された電力測定部の測定したデータを、遠隔地にあるコンセントレータ３−５等を経由してスマートグリッドの変電所、MDMS４−５(Metering Data Management System)等へ送信する。その際、送信部９−５にて認証処理（認証子の付加や暗号化など）を行うことによりセキュアな通信を行う。スマートメーター１−５からの通信データは必ず送信部９−５を通り、送信部９−５にて認証処理が確実に行われる。
【００９９】
しかし、スマートメーター１−５内のコントロール部８−５は、ディスプレイ２−５への表示機能や、家電機器５−５と連携したHEMS６−５(Home Energy Management System：ホームサーバ)とのデータ送受信などを行う巨大なアプリケーションである。そのため、誤ったデータ処理や、HEMS６−５から受信した誤データなどが原因となり、送信部９−５が誤送信を行うミスが起こりやすい。その場合、通常、送信部９−５は誤送信か否かの判断はできないため、そのままスマートグリッドの通信網へ誤ったデータを送信し、それが元で地域の送配電システムを混乱させ、最悪、停電等の問題を引き起こす可能性がある。同様に、スマートメーター１−５に何等かの理由で不正に入り込んだコンピュータ・ウイルスが送信部９−５に不正なデータを送り込んだり、外部の攻撃者がネットワークを経由して送信部９−５に不正なデータを送り込んだりすることにより、送配電システムが混乱する恐れがある。
【０１００】
また、スマートメーター１−５を従来の（Ｂ）モジュール認証方式で実装した場合、電力測定部７−５は独自に認証機能を持ち、秘密鍵を用いて認証子を付加するなどして、スマートグリッド網を通してMDMS４−５へ通信を行う。MDMS４−５は電力測定部７−５と同じ秘密鍵にて認証子を検証する。一方、コントロール部８−５は別途認証機能を持ち、家電制御等の複雑なデータをASP(Application Service Provider)へ送信する。MDMS４−５とASPはそれぞれ役割が異なり、認証機能も秘密鍵も個別に持っているため、例えばコントロール部８−５が誤って生成した不正なデータをMDMS４−５に送信してしまい、送配電網を混乱させるといった事故は起こらない。
【０１０１】
しかしながら、アクセス主体毎に認証の方法を分離することで安全性を高めるメリットがあるものの、同時にさまざまなデメリットもある。
【０１０２】
まず、モジュール毎に認証メカニズムを実装しなくてはならないため、実装が複雑になり、プログラミングのミス（バグ）が出やすくなったり、使用メモリ量が多くなったり、鍵管理の手順が複雑になったりする。また、正しく実装されていないモジュールがひとつでもあるとシステム全体の安全性が低下することにもなる。さらには、モジュール毎の秘密鍵は機器の中では特に守られていないため、他のモジュールから関係の無い秘密鍵が見えてしまい、鍵が漏洩したり誤ったデータ送信を行うリスクが無くならない。また、将来暗号解読技術が進んだ際に、認証モジュールを置き換えなければならないが、沢山の認証モジュールが複雑に組み込まれていると、完全に置き換えるためには膨大な確認作業が発生する。つまり、このような実装方法は、非常に手間がかかると同時に安全性の維持が難しく、望ましいものではない。
【０１０３】
上述のように、通信ネットワークの普及により利用形態が複雑化した機器を認証する場合において、従来のネットワーク機器の認証装置では、権限の異なる複数の機能が混在することにより、アプリケーションのデータ処理のミスなどを原因として送信部９−５より誤送信を行い、本来の認証機能が有効に働かなかったり、あるいは、不正に入り込んだコンピュータ・ウイルスが送信部９−５に不正なデータを送り込んだりすることを防ぐのは難しかった。
【０１０４】
また、これを防ぐために、権限の異なる複数の機能それぞれに独立した認証機能を持たせた場合においては、実装が複雑になり、プログラミングのミス（バグ）が出やすくなったり、鍵管理の手順が複雑になったりすることにより、システムの安全性を維持することが難しいという問題があった。
【０１０５】
この実施形態の発明は、権限の異なる複数の機能が混在したネットワーク機器を、非常に簡単な手順により、安全に実装することができるようにした、ネットワーク機器の認証方法を提供することができる。
【０１０６】
上記各実施形態では、認証子の生成、および暗号化に必要な鍵が送出方法定義リスト記憶部に記憶されているとしているが、送出方法定義リストの構成はこれに限定するものではない。例えば、データ変換部が鍵情報を持ち、送出方法定義リストには（鍵情報そのものではなく）どの鍵を使うべきかのインデックス番号のみを記載する、といった別の形態も考えられる。
【０１０７】
なお、上記各実施形態に記載した手法は、コンピュータに実行させることのできるプログラムとして、磁気ディスク（フロッピー（登録商標）ディスク、ハードディスクなど）、光ディスク（ＣＤ−ＲＯＭ、ＤＶＤなど）、光磁気ディスク（ＭＯ）、半導体メモリなどの記憶媒体に格納して頒布することもできる。
【０１０８】
また、この記憶媒体としては、プログラムを記憶でき、かつコンピュータが読み取り可能な記憶媒体であれば、その記憶形式は何れの形態であっても良い。
【０１０９】
また、記憶媒体からコンピュータにインストールされたプログラムの指示に基づきコンピュータ上で稼働しているＯＳ（オペレーティングシステム）や、データベース管理ソフト、ネットワークソフト等のＭＷ（ミドルウェア）等が本実施形態を実現するための各処理の一部を実行しても良い。
【０１１０】
さらに、本発明における記憶媒体は、コンピュータと独立した媒体に限らず、ＬＡＮやインターネット等により伝送されたプログラムをダウンロードして記憶または一時記憶した記憶媒体も含まれる。
【０１１１】
また、記憶媒体は１つに限らず、複数の媒体から本実施形態における処理が実行される場合も本発明における記憶媒体に含まれ、媒体構成は何れの構成であっても良い。
【０１１２】
尚、本発明におけるコンピュータは、記憶媒体に記憶されたプログラムに基づき、本実施形態における各処理を実行するものであって、パソコン等の１つからなる装置、複数の装置がネットワーク接続されたシステム等の何れの構成であっても良い。
【０１１３】
また、本発明におけるコンピュータとは、パソコンに限らず、情報処理機器に含まれる演算処理装置、マイコン等も含み、プログラムによって本発明の機能を実現することが可能な機器、装置を総称している。
【０１１４】
本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。
【符号の説明】
【０１１５】
１・・・スマートメーター
２・・・コントロール部データ受信サーバ
３・・・電力量受信サーバ
４・・・ディスプレイ
５・・・ＨＥＭＳ
６・・・家電機器
１１・・・データ送出処理部
１２・・・電力測定部
１３・・・コントロール部
１１１・・・パケット受信部
１１２・・・処理方法判定部
１１３・・・送出方法定義リスト記憶部
１１４・・・送出元モジュール特定部
１１５・・・データ変換部
１１６・・・送信部
【技術分野】
【０００１】
この発明の実施形態は、データを送信する技術に関する。
【背景技術】
【０００２】
従来、通信回線で接続された複数の機器またはプログラム同士が通信を行う際の認証(Authentication)の形態としては、（Ａ）通信機器が認証機能を持つ機器認証方式、（Ｂ）各モジュールが個別に認証機能を持つモジュール認証方式の２つが多く用いられている。
【０００３】
まず、（Ａ）の機器認証方式では単一の機器内に複数のモジュールが実装された場合であっても、認証の対象は１個体として扱う。インタネット・プロトコル(IP)の実装されたネットワーク・コンピュータでは、１つのIPアドレスを持つ機器１台を１個体と考え、機器に対応する秘密鍵により生成された認証子をIPパケットに付加して送信する。機器認証方式に属するものとしては、ネットワークインタフェース固有のID番号(MACアドレス)を用いた認証や、IPsec(Security Architecture for Internet Protocol)に代表される暗号技術に基く認証、さらにはそれを応用したVPN(Virtual Private Network)などが広く普及している。
【０００４】
また、（Ｂ）のモジュール認証方式では、各モジュールが個別に認証用のIDまたは鍵を持ち、それらを用いた認証用アルゴリズムを実装することによってIPアドレス等とは関係無く通信相手との認証を行う。モジュール認証方式では、一般にいかなる認証方法でもプログラム実行できるため方式を限定することなくさまざまな暗号技術等を適用することができる。例えばSSH(Secure SHell)プロトコルなどが使われる。
【０００５】
これら従来の認証方式は、機能が限定された産業用機器の通信や、汎用のPC(パーソナルコンピュータ)などによるインターネット・アプリケーションで利用されている。
【先行技術文献】
【非特許文献】
【０００６】
【非特許文献１】IP Authentication using Keyed MD5 (P. Metzger他 1995/8 IETF RFC1828)
【非特許文献２】IP Authentication Header (S. Kent BBN Technologies 2005/12 IETF RFC4302)
【発明の概要】
【発明が解決しようとする課題】
【０００７】
しかし、通信ネットワークの普及により利用形態が複雑化した機器を認証する場合において、従来のネットワーク機器の認証装置では、権限の異なる複数の機能が混在することにより、アプリケーションのデータ処理のミスなどを原因として送信部より誤送信を行い、本来の認証機能が有効に働かなかったり、あるいは、不正に入り込んだコンピュータ・ウイルスが送信部に不正なデータを送り込んだりすることを防ぐのは難しく、権限の異なる複数の機能が混在する機器の安全性を保つことが難しいという問題があった。
【０００８】
また、これを防ぐために、権限の異なる複数の機能それぞれに独立した認証機能を持たせた場合においては、実装が複雑になり、機器のシステムの安全性を維持することが難しいという問題があった。
【０００９】
そこで、この発明の一観点は、権限の異なる複数の機能が混在したネットワーク機器の安全性を、複雑で無く、保持できるようにしたネットワーク機器の認証方法を提供することを目的とする。
【課題を解決するための手段】
【００１０】
上記目的を達成するために、本発明の一実施形態に係るデータ送信処理装置は、データをデータ受信部で受信し、データを送出したモジュールを送出元モジュール特定部で特定する。送出元モジュール毎に定義された、データ変換方法もしくは通信の可否を含む前記データの処理方法を示す送出方法定義リストを送出方法定義リスト記憶部に記憶しておき、処理方法判定部が送出元モジュール特定部によって特定された送出元モジュールに対応する処理方法を、送出方法定義リストを参照し決定する。処理方法判定部の決定した処理方法に前記データの変換方法が含まれる場合は、データ変換部はデータを変換し、処理方法判定部が通信可能と判断した場合は、送信部はデータまたは変換されたデータを送出する。
【図面の簡単な説明】
【００１１】
【図１】第1の実施形態にかかるシステム構成を示す図。
【図２】第1の実施形態にかかるシステムの動作概要を示す図。
【図３】第1の実施形態にかかる送出方法定義リストの例を示す図。
【図４】第1の実施形態にかかる受信データおよび送信データの例を示す図。
【図５】第2の実施形態にかかるシステム構成を示す図。
【図６】第3の実施形態にかかるシステム構成を示す図。
【図７】第4の実施形態にかかる送出方法定義リストの例を示す図。
【図８】第4の実施形態にかかる受信データおよび送信データの例を示す図。
【図９】第5の実施形態にかかるシステム構成の一部を示す図。
【図１０】第6の実施形態にかかるプロセステーブル例を示す図。
【図１１】第6の実施形態にかかる送出方法定義リストの例を示す図。
【図１２】実施形態の発明が適用される場面例を示す図である。
【発明を実施するための形態】
【００１２】
（第１の実施形態）
以下に図面を参照して、この発明にかかる第１の実施形態を詳細に説明する。
【００１３】
図１は、本実施形態のデータ送信システムとそのシステムと連携する機器の構成を示す図であり、インタネット等の公衆ネットワークを介して接続された電力監視機器群の配置例とその機能ブロックを示している。
【００１４】
本実施形態のデータ送信システムは、スマートメーター１、コントロール部データ受信サーバ２、電力量受信サーバ３を有する。本実施形態のデータ送信システムは、ディスプレイ４とHEMS５(Home Energy Management System：ホームサーバ)と接続されており、HEMS５は家電機器６と接続している。
【００１５】
スマートメーター１は、一般家庭やビル、工場などの電力消費ポイント（需要家）に設けられた電力計（メータ）であり、ネットワークに接続する機能を有している。
【００１６】
スマートメーター１は、電力測定部１２、コントロール部１３、パケット受信部１１１、処理方法判定部１１２、送出方法定義リスト記憶部１１３、送出元モジュール特定部１１４、データ変換部１１５、送信部１１６を有する。また、パケット受信部１１１、処理方法判定部１１２、送出元モジュール特定部１１４、送出方法定義リスト記憶部１１３、データ変換部１１５、送信部１１６を有する部分を送信処理部１１（送信処理装置）とする。なお、スマートメーター１は、電力網の制御に関わるさまざまな機能モジュールを持つことができるが、本実施形態では説明を簡略化しており、他の機能モジュールを有していても良い。
【００１７】
ここで、モジュールとは、ある１つの処理（処理単位）をいう。典型的にはコンピュータの１実行主体（プロセス）のことであるが、場合によってはプログラムの格納された１ファイル（exeファイル）や、実装された１機能（共有ライブラリやdllファイルなど）と考えても良い。また、ソフトウエアで実装されたプログラムでも良いし、ある機能を実装したハードウエアであっても良い。
【００１８】
電力測定部１２は、専ら使用電力量などの重要データを扱う。電力測定部１２は、電力線に接続されており、電力線に接続され機器の電力量の測定をする。例えば、図１では家電機器６が電力線にされており、電力測定部１２は家電機器６の電力量を測定するが、これに限られず、電力線に接続されている機器であれば、電力量を測定できる。また、電力測定部１２は測定した電力量を含むデータ（パケット）を後述するコントロール部１３、パケット受信部１１１に送信する。
【００１９】
コントロール部１３は、家庭内の家電機器６コントロールや消費電力の表示など雑多なデータを扱う。コントロール部１３は、電力測定部１２からのデータを受信する。コントロール部１３は、家庭内に設置されたディスプレイ４への表示機能のコントロールや、家電機器６と連携したHEMS５とのデータ送受信を行ってHEMS５のコントロールを行っても良い。これらのデータのやり取りについては従来技術と何等変わるところが無いので、詳細な説明および図示は省略する。また、コントロール部１３では、コントロール部１３で扱うデータ（パケット）を後述するパケット受信部１１１に送信する。
【００２０】
HEMS５は、コントロール部１３と接続されているほかに、家電機器６と接続されている。HEMS５はHEMS５が保持する情報を利用して、家電機器６を制御したり、家電機器６から情報を入手しても良い。
【００２１】
電力測定部１２とコントロール部は基本的には独立のものであるが、システムによっては電力測定部１２で計測したデータの一部をコントロール部１３に渡して処理することも考えられる。
【００２２】
パケット受信部１１１は、受信したデータ（パケット）を後述する処理方法判定部１１２に送信する。
【００２３】
処理方法判定部１１２は、パケット受信部１１１からデータ（パケット）を受信すると、後述する送出元モジュール特定部１１４にデータ（パケット）を送信し、受信したデータ（パケット）の送出元モジュールの識別情報を入手する。ここで、送出元モジュールの識別情報とは、データ（パケット）を送出した元のモジュールを識別する情報であり、本実施形態の例では、電力測定部１２またはコントロール部１３のモジュールを示す名称などであるが、データ（パケット）を送出した元のモジュールを識別する情報であれば、これに限定されるものではない。
【００２４】
処理方法判定部１１２は、データ（パケット）の送出元モジュールの識別情報と、送出方法定義リストに記載された処理方法に関する情報とを、送出元モジュールの識別情報をキーとして照らし合わせた上で、パケットの処理方法を確定する（送出元モジュールに対応する処理方法を、送出方法定義リストを参照し決定する）。そして、処理方法判定部１１２は、通信が許可されているものについてはデータ（パケット）を送出し、必要な場合は後述するデータ変換部１１５に処理方法（処理方法情報）や鍵も送出する。
【００２５】
送出方法定義リスト記憶部１１３は、送出方法定義リストを記憶する。送出方法定義リストは、送出元モジュールの識別情報と通信の可否との対応付けた情報または送出元モジュールの識別情報とデータ変換方法とを対応付けた情報を有する（送出元モジュール毎に定義された、データ変換方法もしくは通信の可否を含む前記データの処理方法を示す情報を有する）。例えば、あるパケットの送出を許可し、またあるパケットは送出を禁止する情報である。また、送出を許可するパケットについては認証子を付加して送出したり、暗号化してから送出したりすることもあり、これらのデータ変換方法のルールを記述する。また、認証子の作成や暗号化にあたって必要な「鍵」も保持する。ここで、鍵とは一般的な暗号技術で使われる鍵一般のことを広く指し、秘密鍵であるか公開鍵であるかといったことは特に限定しない。図３は、送出方法定義リストの例を示す図である。図３の例では、Prog1、Prog2、Prog3、Miscについて送出方法が定義されている。以下に詳細を説明する。
【００２６】
Prog1は、電力測定部１２のプログラム・モジュールの名称である。
【００２７】
通信は許可となっており、電力測定部１２のプログラム・モジュールからのデータは通信を許可する。また、認証子はhmac−sha1となっており、転送時には hmac−sha1 アルゴリズムにより生成された認証子をパケットに付加する。
【００２８】
hmac−sha1は、ハッシュ関数 sha1 に鍵を適用する方式 hmac を組み合わせた、良く知られた認証子生成方法であるので、その手順説明は省略する。また、hmac−sha1適用にあたっては、鍵である4f434e23f355 を用いる。実際には安全性の観点からより長い鍵を用いるのが普通であるが、説明文を簡略化するため短い鍵を表記している（以下同様）。
【００２９】
また、暗号化はしないになっており、パケットの暗号化は行わない。ここで、鍵は、電力量受信サーバ３も同一の鍵を保持しているため、電力量受信サーバ３は鍵とhmac−sha1アルゴリズムを用いて演算した認証子がパケットに付加されている認証子の値と同一であることを以て、このパケットが、当該スマートメーター１の当該モジュール（電力測定部１２）から送信されたパケットであるということを認証することができる。
【００３０】
なお、この例ではProg1はパケットを暗号化しないものとして説明した。本実施例は、電力測定部１２の測定したデータは盗聴されても構わないという立場だからである。言うまでもなく、必要に応じパケットを暗号化したり、誤ったサーバに送出されないようパケット・フィルタリングするような措置を施す方式も考えられるが、一般的な技術を利用するため本実施形態では特にそれを説明しない。
【００３１】
一方、Prog2はコントロール部１３のプログラム・モジュールの名称である。通信は許可となっており、コントロール部１３からのデータは通信を許可する。また、認証子はhmac−md5となっており、転送時にはhmac−md5アルゴリズムにより生成された認証子をパケットに付加する。その際、鍵 である3a53f324fa47 を用いる。hmac−md5も良く知られた認証子生成方法であるのでその手順説明は省略する。さらに、暗号化アルゴリズムであるAESと、鍵 である3f233322434e を用いてパケットを暗号化する。暗号化の鍵の扱いについては本特許の核となる要件ではないため、実施形態概要を示した図１には図示を省略している。なお、暗号化の処理と、認証子の付加処理の順番については、特にどちらかでなければならないという制約は無く、システムに応じて暗号化を先に行っても良く、その場合には送出方法定義リストに記載する順番を逆にすれば良い。
【００３２】
また、Prog3は一般ライブラリのプログラム・モジュールの１名称である。通信は拒否となっており、一般ライブラリからのパケットは通信を拒否することを示している。
【００３３】
また、Misc は今までのリストに無かったプログラム・モジュールを示している。通信は拒否となっており、プログラム・モジュールの名称記載の無いものについては全て通信を拒否することを示している。
【００３４】
このように図３の例では、各行毎に処理と処理方法を示す情報が記載されているが、他の方法で表現されても処理方法（処理内容）が特定できれば本例に限られない。
【００３５】
送出元モジュール特定部１１４は、処理方法判定部１１２からデータ（パケット）を受信すると、パケットの識別情報とパケットの送出元モジュールの識別情報とが対応付けられたパケット送出元モジュール情報に基づいてパケットの送出元モジュールを特定する。そして、送信元モジュールの識別情報を処理方法判定部１１２に送出する。パケットの識別情報とはパケットを識別するための情報であり、単一の情報や複数の情報の組み合わせであっても良い。
【００３６】
パケットの送出元モジュールを知る方法の例を示す。例えばパケット受信部１１１の受信するデータがIPv4のTCPパケットである場合、そのパケットはRFC791で規定されたIPv4(Internet Protocol version 4)およびRFC793で規定されたTCP(Transmission Control Protocol)の構造になっているので、そのデータを参照することにより、Destination Address(送信先IPアドレス)、Source Port(ソースポート番号)、Destination Port(宛先ポート番号)などの情報が判る。
【００３７】
データ変換部１１５は、処理方法判定部１１２からデータ（パケット）と処理方法（処理方法情報）を受信すると、データ（パケット）に処理方法に従った変換処理を行う（処理方法判定部１１２の決定した処理方法に前記データの変換方法が含まれる場合は、前記データを変換する）。変換処理としては、暗号化や認証子の付加などを行う。そして、変換処理されたデータ（パケット）を送信部に送出する。例えば、図３の例では、データ（パケット）の送出元モジュールがProg１であった場合は、認証子をhmac−sha1で鍵4f434e23f355に基づいて生成する。そのため、図４のようにデータ（パケット）に認証子が追加された形に変換される。こういった認証子の追加には例えばIPの拡張データフィールドを用いることができ、IPsecなどの従来技術においても用いられている。
【００３８】
送信部１１６は、データ変換部から変換処理されたデータ（パケット）を受信し、スマートメーター１の外部に送信する。本実施形態ではコントロール部データ受信サーバ２または電力量受信サーバ３に送信する。その際、電力測定部１２からのデータ（パケット）は電力量受信サーバ３へ送り、コントロール部１３からのデータ（パケット）はコントロール部データ受信サーバ２へ送るという切り替えが発生する。これは一般のIP(Internet Protocol)技術においてパケット内に書かれているDestination Address(送信先IPアドレス)を元に切り替えることが従来より行われており、本実施形態においても実施できる。
【００３９】
実際のシステムでは、セキュリティを高めるためプログラム・モジュール毎に送信可能なサーバを限定したり、送信先によってデータ変換方法を変えるなどのバリエーションが考えられるが、一般にファイア・ウォールと呼ばれているパケット・フィルタリング技術の単純な組み合わせで容易に実現可能であるため、それらバリエーションについては例示を省略する。
【００４０】
コントロール部データ受信サーバ２は、送信部よりデータ（パケット）を受信する。電力会社によって管理されていても良いし、電力制御とは全く関係のないインタネット・サービス提供者によって管理される場合もある。
【００４１】
電力量受信サーバ３は、送信部よりデータ（パケット）を受信する。電力量受信サーバ３は、電力会社の管理する変電所内に置かれたり、またはそのデータの中継点に設置されたＭＤＭＳ(Meter Data Management System)に置かれ、各スマートメーター１の動作を監視している。
【００４２】
本実施形態の動作の概要を図２を利用して説明する。パケット受信部１１１がデータ（パケット）を受信し、受信したデータ（パケット）を処理方法判定部１１２に送信する（Ｓ１０１）。
【００４３】
処理方法判定部１１２は送出元モジュールの特定を送出元モジュール特定部１１４に依頼する（Ｓ１０２）。
【００４４】
送出元モジュール特定部１１４はデータ（パケット）を送出中のモジュールを特定して、送出元モジュールの識別情報を処理方法判定部１１２に送信する（Ｓ１０３）。
【００４５】
処理方法判定部１１２は送出元モジュールの識別情報と送出方法定義リスト記憶部１１３に記憶されている送出方法定義リストを用いてデータ（パケット）の処理方法を決定し、データ（パケット）が送信可能であればデータ変換部にデータ（パケット）を送信する（Ｓ１０４）。
【００４６】
データ変換部１１５はデータ（パケット）の変換が必要な場合は変換をし、変換の必要が無い場合はそのままのデータ（パケット）を送信部１１６に送信する（Ｓ１０５）。
【００４７】
データ送信部はデータ（パケット）をスマートメーター外に送信する（Ｓ１０６）。
【００４８】
本実施形態により権限の異なる複数の機能が混在したネットワーク機器の安全性を、複雑で無く、保持できるようにしたネットワーク機器の認証方法を提供することができる。
【００４９】
（第２の実施形態）
本実施形態の一実施例を図５を用いて以下に説明する。
【００５０】
上述の実施形態と同様の機能については、説明は省略し、図１とは異なるＯＳカーネル１４、ＯＳカーネル・メモリ１５、送出元モジュール特定部、電力測定部１２−２、コントロール部を中心に説明する。
【００５１】
ＯＳカーネル１４とは、プロセス管理を行う一般的なオペレーティング・システム(ＯＳ)と考えて良いが、実装法によっては単にライブラリ関数を切り替えるためのコンピュータ・プログラムの場合もある。
【００５２】
ＯＳカーネル１４は、動作している各モジュールを管理する。さらに、各モジュールがＯＳカーネルにパケット受信部に送信を要求したパケットの情報もカーネル・メモリ内に保持している。そのため、カーネル・メモリ内の情報を参照することで、そのパケットを送出要求しているモジュールが何であるかを知ることができる。
【００５３】
本実施形態では、ＯＳカーネル１４は、電力測定部１２−２やコントロール部から情報を入手する。具体的には、電力測定部１２−２やコントロール部で動作している各モジュールを管理し、各モジュールが送信したデータ（パケット）の情報もカーネル・メモリ内に保持している。また、電力測定部１２−２やコントロール部１３−２に何らかの情報を送信しても良い。
【００５４】
電力測定部１２−２は、電力測定部１２−２内で動作している各モジュールはデータ（パケット）をパケット受信部１１１に送信することをＯＳカーネル１４に要求する。ＯＳカーネル１４は要求されたデータ（パケット）をパケット受信部１１１に送信する。また、ＯＳカーネル１４はカーネル・メモリ１５に要求した電力測定部１２−２のモジュールの識別情報と送信したデータ（パケット）との対応付けて記憶する。コントロール部１３−２は、コントロール部内で動作している各モジュールはデータ（パケット）をパケット受信部１１１に送信することをＯＳカーネル１４に要求する。また、ＯＳカーネル１４はカーネル・メモリ１５に要求したコントロール部１３−２のモジュールの識別情報と送信したデータ（パケット）との対応付けて記憶する。
【００５５】
ＯＳカーネル・メモリ１５は、各モジュールが送信したパケットの情報を一定期間記憶している。具体的には、電力測定部１２−２やコントロール部１３−２で動作している各モジュールがＯＳカーネル１４に送信要求して送信中のデータ（パケット）の情報を記憶する。これは、一般的なＯＳのメカニズムとして、TCPのセッション管理などの目的で、パケットを送信した後にも、通信が完了するまでパケットの情報を保持する必要があるからである。少なくともパケットがスマートメータから外部に送信される迄の間、このパケットの情報は保持される。なお、ＯＳカーネル・メモリ１５に記憶したパケットの情報をいかなるタイミングで消去するかという点に関しては一般的なＯＳのメカニズムを利用するものとし、詳細説明は省略する。
【００５６】
送出元モジュール特定部１１４−２は、処理方法判定部１１２からデータ（パケット）を受信すると、ＯＳカーネル・メモリ１５の情報を参照して、送出元モジュールの識別情報を特定する。そして、送出元モジュールの識別情報を処理方法判定部へ送信する。例えば、netstatコマンド、psコマンド、proc file system、等の名称で広く使われている。さらには、それをユーザに解釈されやすく整形したコマンド類(Windows(登録商標)用のTCPViewなど)も使われている。また、送出元モジュール特定部１１４−２は、処理方法判定部１１２からデータ（パケット）を受信すると、データ（パケット）の識別情報などをＯＳカーネル１４に送出し、ＯＳカーネル１４が受信したデータ（パケット）の識別情報に対応する送出元モジュールの識別情報を抽出し、送出元モジュール特定部１１４−２に送出しても良い。
【００５７】
（第３の実施形態）
上述の実施形態では、スマートメーター１は１つのＯＳカーネル１４−３により管理された複数の機能モジュール（プログラム・ライブラリ）を用いて構成されているものとしているが、ＯＳカーネル１４−３等の実装形態については、言うまでもなく、その部分の設計はいかなるものであっても良い。
【００５８】
本実施形態では、図６に例示するように、スマートメーター１が仮想マシン技術によって構成されていた例を説明する。仮想マシン技術とは、１つの計算機の上で複数のＯＳを同時に動作させ、ＯＳをあたかもプログラムの１つであるかの如く扱う技術である。仮想マシン技術を実装したソフトウエアの例として VMware、Virtual PC、Xen などが広く使われている。
【００５９】
仮想マシン技術を用いての構成例では、スマートメーター１は仮想マシンホストによって管理される。仮想マシンホストは、ホストＯＳと呼ばれることもある。ここで動作するＯＳは、ゲストＯＳと呼ばれるものであり、図６の例では仮想マシンゲストＯＳ（１）１６と仮想マシンゲストＯＳ（２）１７が動作している。各ゲストＯＳは同一種類のＯＳであっても、異なる種類のＯＳであっても良い。例えば1つはWindows（登録商標） ＯＳであり、他方は Linux ＯＳであって良い。
【００６０】
このような構成では、各仮想マシンゲストＯＳは、各仮想マシンゲストＯＳ毎に定められた特定のモジュールはデータ（パケット）をパケット受信部１１１に送信することを仮想マシンゲストＯＳに要求する。そして、各仮想マシンゲストＯＳは、受け付けた要求とデータ（パケット）をＯＳカーネル１４−３に送信する。
【００６１】
例えば、仮想マシンゲストＯＳ（１）１６は電力測定部１２−３からのデータ（パケット）とパケット受信部１１１への送信要求を入手し、入手したデータ（パケット）とパケット受信部１１１への送信要求をＯＳカーネル１４−３に送信する。仮想マシンゲストＯＳ（２）１６はコントロール部１３−３からのデータ（パケット）とパケット受信部１１１への送信要求を入手し、入手したデータ（パケット）とパケット受信部１１１への送信要求をＯＳカーネル１４−３に送信する。また、電力測定部１２−３は仮想マシンゲストＯＳ（１）１６に情報を送信してもよく、コントロール部１３−３は仮想マシンゲストＯＳ（２）１７に情報を送信してもよい。
【００６２】
ＯＳカーネル１４−３は、仮想マシンゲストＯＳ（１）または仮想マシンゲストＯＳ（２）からデータ（パケット）とパケット受信部１１１への送信要求を受信する。そして、受信したデータ（パケット）をパケット受信部１１１に送信する。また、ＯＳカーネル１４−３は、仮想マシンゲストＯＳの識別情報と仮想マシンゲストＯＳから受信したデータ（パケット）とを対応付けた情報をＯＳカーネル・メモリ１５−３に記憶させる。また、必要に応じて仮想マシンゲストＯＳの識別情報と仮想マシンゲストＯＳから受信したデータ（パケット）とを対応付けた情報を読み出す。また、送出元モジュール特定部からの要求に応じて、読み出した情報を送出元モジュール特定部１１４−３に送出したり、または、データ（パケット）を受信した仮想マシンゲストＯＳを特定して送出元モジュール特定部に送出する。
【００６３】
また、上記例ではＯＳカーネルがパケット受信部１１１にデータ（パケット）を送信しているが、各仮想マシンゲストＯＳがパケット受信部１１１にデータ（パケット）を送信しても良い。
【００６４】
このような構成のスマートメーター１においては、各仮想マシンゲストＯＳ毎に定義された送出方法を送出方法定義リストに記述し、送出元モジュール特定部１１４−３が特定したゲストＯＳ情報を利用して、処理方法判定部１１２が送信データの処理方法を判定することで、各ゲストＯＳに割り当てられた機能に応じたデータ送信を行うことができるので、例えば要求される安全性の大きく異なるゲストＯＳが混在するスマートメーター１においても、個別に複雑な認証メカニズムを実装することなく適切なアクセス制限を実現することができる。特に、実装上の理由で、コンピュータ・ウイルスに感染しやすい危険なＯＳをゲストＯＳに用いたとしても、そのウイルスによる動作不具合は当該ゲストＯＳおよび、当該ゲストＯＳの通信する先のサーバに限定され、他のゲストＯＳおよび、他のゲストＯＳの通信する先のサーバに悪影響が及ぶことを防止することができる。
【００６５】
（第４の実施形態）
本実施形態では、データ変換部１１５は、送出元モジュール特定部１１４または１１４−２または１１４−３によって特定された、モジュールの種別情報をデータに付加する実施例について説明する。データ変換部、送出方法定義リスト以外については、上述の実施形態や実施例と共通するため、説明は省略する。また、データ変換部が異なり、全体の構成は図１、４、５と同様であるため、図示も省略する。
【００６６】
本実施形態の送出方法定義リスト記憶部に記憶される送出方法定義リストには、送出元モジュールを識別する送出元モジュール識別情報（以下送出元モジュールＩＤという）を付加することの指示が追加されている。例えば、図７は本実施形態の送出方法定義リストの例を示すものであり、本図を利用して説明する。図４ではProg1にhmac-sha1認証子を付加することが指示されているが、これに加え、Prog1というモジュールの送出元モジュールＩＤを付加した上で、さらにhmac-sha1認証子を計算することの指示が追加されている。Prog2についても同様である。
【００６７】
データ変換部は、送出方法定義リストで送出元モジュールを識別する送出元モジュール識別情報を付加することの指示が追加されているため、図８のように元のデータに送出元モジュールIDを付加した上で、さらにhmac-sha1認証子を計算して付与する。
【００６８】
認証子が付加されているため、仮にデータが暗号化されていない場合であっても、ネットワーク上で送出元モジュールIDが改ざんされるおそれは無い。
【００６９】
こうすることにより、スマートメーター１より送出されるデータが、スマートメーター１内のどのプログラム・モジュールによって作られたものであるかという情報を、そのデータを受信するサーバに安全に伝達することができる。したがって、パケットの送出方法について送出方法定義リストのみの情報で固定的に定めるのではなく、そのデータを受信するサーバが、送出元モジュールIDも参考にして、サーバ側のポリシーに従い、柔軟に通信の可否を定めることができ、より柔軟なアクセス制御が実現できる。
【００７０】
従来技術においてこれを実現するには、たった１台のスマートメーター１の認証のために認証の対象となるモジュールの数に相当する数多くの認証メカニズムを実装する必要があり煩雑であったが、本発明の方法によれば単にProg1という送出元モジュールIDを比較するだけで、個別の認証を行ったのと同等の効果が得られるため、単純な実装が可能である。
【００７１】
（第５の実施形態）
本実施形態では、送出元モジュール特定部の別の実現方法として、特定したモジュールの持つソフトウエアのデジタル署名（または認証子、チェックサム）を検証することができる例について図９を用いて説明する。本実施形態では、図９のように特定が必要な送出元モジュールが送出したデータ（パケット）に予め該モジュールデータのデジタル署名を加えておきそれを署名検証用鍵で検証する。
【００７２】
図９では送出元モジュール特定部、処理方法判定部、署名検証用鍵記憶部以外は上記実施形態と同様であるため、省略し、どの実施形態に組み合わせることができる。
【００７３】
処理方法判定部１１２−４ではパケット受信部１１１−４（図示せず）が受信し、パケット受信部１１１−４が処理方法判定部１１２−４に送信したデジタル署名が付加されたデータ（パケット）を受信する。そして、受信したデータ（パケット）を署名検証用鍵で検証して、正当な署名であるかを確認する。
【００７４】
正当な署名の付いているモジュールは正当と判断しても良いし、より正確にはプログラム名称等も含めたデジタル署名を付加しておき、その名称をチェックして正しければ送出元モジュールが正しいと判断するといった実装も可能である。
【００７５】
また、この方法を用いることで、送出元モジュールの特定にあたって必ずしもＯＳが管理する情報（カーネル・メモリ１５または１５−３）を参照する必要が無くなる。ＯＳの性質によっては、ＯＳが管理する情報を参照するには困難が伴う場合があるため、本方式の方が優れている場合もある。
【００７６】
なお、デジタル署名と呼ばれる技術は、通常公開鍵暗号方式を用いた署名を指すことが多いが、ここでは電子的な署名であれば何でも良く、例えば認証子を付加したり、単なるチェックサムを念のため付加しておくといったケースも考えられ、特に署名の方式を限定しない。
【００７７】
ＯＳが特定できる送出元モジュールが例えばそのプログラムのパス名であった場合、パス名はそのままに悪意のプログラム等にプログラムの中身が変更（差し替え）されていても判別できないが、本実施形態を用いることで誤った動作を未然に防ぐことができる。
【００７８】
（第６の実施形態）
本実施形態では、送信元モジュール特定部は、特定したモジュールの持つソフトウエアが起動されるに至った経緯情報を特定する例について説明する。システム構成は上記実施形態と同様であるため、図は省略し、図１、４、５の送出元モジュール特定部１１４、１１４−２、１１４−３、１１４―４や、処理方法判定部１１２の変形例として説明し、他の構成要素については同様である。
【００７９】
このような機能が必要となる背景について以下に記載する。一般に、ＯＳにより管理されているプログラムは、１プログラムで１機能を実現するといった単独のものであることはまれであり、多くの場合、親プロセスから子プロセスが起動され、さらにその子プロセスが起動される、という流れによって機能が実現されている。従って、単に１プログラムの名称のみでアクセス制御を行うのみでは十分な安全性が確保できないケースも考えられる。
【００８０】
例えば、通常 Ａ→Ｂ→Ｃ→Ｄ という順番で起動されるプログラム D が正当なものであった場合、送信元モジュール特定部が送信元モジュールのみを特定するのであれば、E →D’ という順番で起動されたプログラム D’ も正当なものとして扱われてしまう。
【００８１】
しかしこのように想定外の順番でプログラムが起動される場合、不安全な事態が発生している可能性が極めて高い。例えばプログラムEは電子メールをネットワークから受信するサーバであるとすると、サーバに不正侵入され実行権限を乗っ取られたために、プログラム E の権限（管理者権限など）でプログラム D が不正実行されていると考えられる。
【００８２】
そのため、特定したモジュールの持つソフトウエアが起動されるに至った経緯情報を特定している。
【００８３】
経緯情報を特定するために、ＯＳカーネル１４または１４―３は、プログラム（プログラムモジュール）とそのプログラムが実行するプロセスの識別情報（プロセスＩＤ）とそのプロセスの親プロセスの識別情報（親プロセスＩＤ）を対応付けて把握する。この対応付けられた情報は、プロセステーブルという。プロセステーブルの例を図１０に示す。
【００８４】
例えば、図１０の例では、Ａ（sshd）→Ｂ（bash）→Ｃ（Data_Measure）→Ｄ（Data_send）という順番で起動されるプログラムがある場合を示す。ＯＳカーネル１４または１４―３は最初にプログラム（init）を起動する。するとＯＳカーネル１４または１４―３ではプログラム（init）と、親プロセスはないため親プロセスＩＤは「−１」、プロセスＩＤは「１」として対応付けて把握する。
【００８５】
次ぎに、プログラムＡ（sshd）が起動する。するとＯＳカーネル１４または１４―３ではプログラムＡ（プログラム識別情報はsshd）の親プロセスＩＤは「１」であり、自己のプロセスＩＤは「６６４」であるので、このプログラム識別情報sshdと親プロセスＩＤ「１」とプロセスＩＤ「６６４」も対応付けて把握する。
【００８６】
次にプログラムＢ（bash）が起動する。するとＯＳカーネル１４または１４―３ではプログラムＢ（プログラム識別情報はbash）の親プロセスＩＤは「６６４」であり、自己のプロセスＩＤは「３０６３８」であるので、このプログラム識別情報bashと親プロセスＩＤ「６６４」とプロセスＩＤ「３０６３８」も対応付けて把握する。
【００８７】
次にプログラムＣ（Data_Measure）が起動する。するとＯＳカーネル１４または１４―３ではプログラムＣ（プログラム識別情報はData_Measure）の親プロセスＩＤは「３０６３８」であり、自己のプロセスＩＤは「３０６３９」であるので、このプログラム識別情報bashと親プロセスＩＤ「３０６３８」とプロセスＩＤ「３０６３９」も対応付けて把握する。
【００８８】
さらに、プログラムＤ（Data_send）が起動する。するとＯＳカーネル１４または１４―３ではプログラムＤ（プログラム識別情報はData_send）の親プロセスＩＤは「３０６３９」であり、自己のプロセスＩＤは「３２５０７」であるので、このプログラム識別情報bashと親プロセスＩＤ「３０６３９」とプロセスＩＤ「３２５０７」も対応付けて把握する。このようにＯＳカーネル１４または１４―３が管理するプロセステーブルによって、親プロセスのIDを参照し、順に親プロセスをたどることが可能である。
【００８９】
送信元モジュール特定部１１４または１１４−２または１１４−３または１１４―４は、上記実施形態や実施例のように送出元モジュールを特定するとＯＳカーネル１４または１４―３が管理するプロセステーブルをＯＳカーネル１４または１４―３に要求して入手する。そして、入手したプロセステーブルを利用して、特定されたモジュールの親プロセスＩＤを参照してどのプログラムがどのプログラムから起動されているかの情報であるプログラム起動関係情報を抽出する。そして、プログラム起動関係情報を処理方法判定部に送信する。
【００９０】
処理方法判定部１１２は、送信元モジュール特定部から受信したプログラム起動関係情報のうち最後に起動されているプログラムを特定し、特定したプログラムに関する送出方法定義リスト記憶部から処理方法定義リストを入手する。入手した処理方法定義リストとプログラム起動関係情報に基づいて、起動が正当なプログラムからなされたものであるか否かを判断する。不正なプログラムから起動されたと判断された場合は、処理方法判定部は、データ（パケット）の送出を中止する。
【００９１】
図１１は本実施形態の送出方法定義リストの例を示す。送出方法判定部１１２は送出方法定義リストを送出方法定義リスト記憶部１１３から読み出して、Ａ→Ｂ→Ｃ→Ｄの順で起動されていれば、通信は可能である旨とデータ（パケット）と、図１１で示される鍵でhmac-sha1アルゴリズムで認証子を生成し、暗号化はしないで送信する旨をデータ変換部１１５に送出する。
【００９２】
本実施形態の発明によれば、権限の異なる複数の機能が混在したネットワーク機器において、各機能それぞれに独立した認証機能を持たせることなく、異なる権限を区別して実行する認証機能を実現することができる。
【００９３】
モジュール毎に認証メカニズムを実装する必要が無いため、実装が単純になり、プログラミングのミス（バグ）が出にくく、使用メモリ量も最小限で済む。また、鍵管理を機器全体に対し一本化することができるためその手順を単純化することができる。
【００９４】
また、鍵管理が一本化されているにもかかわらず、機器の中に正しく実装されていないモジュールが含まれていたとしても、その影響は不具合のあるモジュールの機能に限定することができ、システム全体の安全性が低下することが無い。さらには、秘密鍵をモジュール毎に管理する必要が無いため、他のモジュールから関係の無い秘密鍵が見えてしまい、鍵が漏洩したり誤ったデータ送信を行うといったリスクが無い。
【００９５】
また、将来暗号解読技術が進んだ際においても、認証モジュールが一本化されているため、複数の認証モジュールを完全に置き換えるための膨大な確認作業を必要とせず、容易に認証機能の入れ替えを行い安全性を向上させることができるので、システム保守性の面でも有利になる。
【００９６】
上記実施形態の発明によれば、例えば以下のような場面での適用が考えられる。
【００９７】
図１２は上記実施形態の発明が適用される場面例を示す図である。例えば、「スマートグリッド」と呼ばれる電力監視網（次世代電力網）においては、需要家（一般家庭等）に設置された監視端末（スマートメーター１−５）が、電力需給予測を変電所に送信するなどの重要で安全性の要求されるデータ通信を行う。それと同時に、監視端末（スマートメーター）は、ディスプレイ２−５への電力使用状況の表示や、エアコンなどの家電機器のコントロールなど、複雑でプログラムミスの起こりやすい各種アプリケーションを動かしたり、またはプログラムミスの起こりやすい外部のアプリケーションから受信したデータを元に動作することもあり、機器全体としての安全性を損なうことが危惧される。
【００９８】
この種の複雑な機能を持つスマートメーター１−５を従来の（Ａ）機器認証方式で実装した場合、スマートメーター１−５では電力線に接続された電力測定部の測定したデータを、遠隔地にあるコンセントレータ３−５等を経由してスマートグリッドの変電所、MDMS４−５(Metering Data Management System)等へ送信する。その際、送信部９−５にて認証処理（認証子の付加や暗号化など）を行うことによりセキュアな通信を行う。スマートメーター１−５からの通信データは必ず送信部９−５を通り、送信部９−５にて認証処理が確実に行われる。
【００９９】
しかし、スマートメーター１−５内のコントロール部８−５は、ディスプレイ２−５への表示機能や、家電機器５−５と連携したHEMS６−５(Home Energy Management System：ホームサーバ)とのデータ送受信などを行う巨大なアプリケーションである。そのため、誤ったデータ処理や、HEMS６−５から受信した誤データなどが原因となり、送信部９−５が誤送信を行うミスが起こりやすい。その場合、通常、送信部９−５は誤送信か否かの判断はできないため、そのままスマートグリッドの通信網へ誤ったデータを送信し、それが元で地域の送配電システムを混乱させ、最悪、停電等の問題を引き起こす可能性がある。同様に、スマートメーター１−５に何等かの理由で不正に入り込んだコンピュータ・ウイルスが送信部９−５に不正なデータを送り込んだり、外部の攻撃者がネットワークを経由して送信部９−５に不正なデータを送り込んだりすることにより、送配電システムが混乱する恐れがある。
【０１００】
また、スマートメーター１−５を従来の（Ｂ）モジュール認証方式で実装した場合、電力測定部７−５は独自に認証機能を持ち、秘密鍵を用いて認証子を付加するなどして、スマートグリッド網を通してMDMS４−５へ通信を行う。MDMS４−５は電力測定部７−５と同じ秘密鍵にて認証子を検証する。一方、コントロール部８−５は別途認証機能を持ち、家電制御等の複雑なデータをASP(Application Service Provider)へ送信する。MDMS４−５とASPはそれぞれ役割が異なり、認証機能も秘密鍵も個別に持っているため、例えばコントロール部８−５が誤って生成した不正なデータをMDMS４−５に送信してしまい、送配電網を混乱させるといった事故は起こらない。
【０１０１】
しかしながら、アクセス主体毎に認証の方法を分離することで安全性を高めるメリットがあるものの、同時にさまざまなデメリットもある。
【０１０２】
まず、モジュール毎に認証メカニズムを実装しなくてはならないため、実装が複雑になり、プログラミングのミス（バグ）が出やすくなったり、使用メモリ量が多くなったり、鍵管理の手順が複雑になったりする。また、正しく実装されていないモジュールがひとつでもあるとシステム全体の安全性が低下することにもなる。さらには、モジュール毎の秘密鍵は機器の中では特に守られていないため、他のモジュールから関係の無い秘密鍵が見えてしまい、鍵が漏洩したり誤ったデータ送信を行うリスクが無くならない。また、将来暗号解読技術が進んだ際に、認証モジュールを置き換えなければならないが、沢山の認証モジュールが複雑に組み込まれていると、完全に置き換えるためには膨大な確認作業が発生する。つまり、このような実装方法は、非常に手間がかかると同時に安全性の維持が難しく、望ましいものではない。
【０１０３】
上述のように、通信ネットワークの普及により利用形態が複雑化した機器を認証する場合において、従来のネットワーク機器の認証装置では、権限の異なる複数の機能が混在することにより、アプリケーションのデータ処理のミスなどを原因として送信部９−５より誤送信を行い、本来の認証機能が有効に働かなかったり、あるいは、不正に入り込んだコンピュータ・ウイルスが送信部９−５に不正なデータを送り込んだりすることを防ぐのは難しかった。
【０１０４】
また、これを防ぐために、権限の異なる複数の機能それぞれに独立した認証機能を持たせた場合においては、実装が複雑になり、プログラミングのミス（バグ）が出やすくなったり、鍵管理の手順が複雑になったりすることにより、システムの安全性を維持することが難しいという問題があった。
【０１０５】
この実施形態の発明は、権限の異なる複数の機能が混在したネットワーク機器を、非常に簡単な手順により、安全に実装することができるようにした、ネットワーク機器の認証方法を提供することができる。
【０１０６】
上記各実施形態では、認証子の生成、および暗号化に必要な鍵が送出方法定義リスト記憶部に記憶されているとしているが、送出方法定義リストの構成はこれに限定するものではない。例えば、データ変換部が鍵情報を持ち、送出方法定義リストには（鍵情報そのものではなく）どの鍵を使うべきかのインデックス番号のみを記載する、といった別の形態も考えられる。
【０１０７】
なお、上記各実施形態に記載した手法は、コンピュータに実行させることのできるプログラムとして、磁気ディスク（フロッピー（登録商標）ディスク、ハードディスクなど）、光ディスク（ＣＤ−ＲＯＭ、ＤＶＤなど）、光磁気ディスク（ＭＯ）、半導体メモリなどの記憶媒体に格納して頒布することもできる。
【０１０８】
また、この記憶媒体としては、プログラムを記憶でき、かつコンピュータが読み取り可能な記憶媒体であれば、その記憶形式は何れの形態であっても良い。
【０１０９】
また、記憶媒体からコンピュータにインストールされたプログラムの指示に基づきコンピュータ上で稼働しているＯＳ（オペレーティングシステム）や、データベース管理ソフト、ネットワークソフト等のＭＷ（ミドルウェア）等が本実施形態を実現するための各処理の一部を実行しても良い。
【０１１０】
さらに、本発明における記憶媒体は、コンピュータと独立した媒体に限らず、ＬＡＮやインターネット等により伝送されたプログラムをダウンロードして記憶または一時記憶した記憶媒体も含まれる。
【０１１１】
また、記憶媒体は１つに限らず、複数の媒体から本実施形態における処理が実行される場合も本発明における記憶媒体に含まれ、媒体構成は何れの構成であっても良い。
【０１１２】
尚、本発明におけるコンピュータは、記憶媒体に記憶されたプログラムに基づき、本実施形態における各処理を実行するものであって、パソコン等の１つからなる装置、複数の装置がネットワーク接続されたシステム等の何れの構成であっても良い。
【０１１３】
また、本発明におけるコンピュータとは、パソコンに限らず、情報処理機器に含まれる演算処理装置、マイコン等も含み、プログラムによって本発明の機能を実現することが可能な機器、装置を総称している。
【０１１４】
本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。
【符号の説明】
【０１１５】
１・・・スマートメーター
２・・・コントロール部データ受信サーバ
３・・・電力量受信サーバ
４・・・ディスプレイ
５・・・ＨＥＭＳ
６・・・家電機器
１１・・・データ送出処理部
１２・・・電力測定部
１３・・・コントロール部
１１１・・・パケット受信部
１１２・・・処理方法判定部
１１３・・・送出方法定義リスト記憶部
１１４・・・送出元モジュール特定部
１１５・・・データ変換部
１１６・・・送信部
【特許請求の範囲】
【請求項１】
データを受信するデータ受信部と、
前記データを送出したモジュールを特定する送出元モジュール特定部と、
送出元モジュール毎に定義された、データ変換方法もしくは通信の可否を含む前記データの処理方法を示す送出方法定義リストを記憶する送出方法定義リスト記憶部と、
送出元モジュール特定部によって特定された送出元モジュールに対応する処理方法を、送出方法定義リストを参照し決定する、処理方法判定部と、
処理方法判定部の決定した処理方法に前記データの変換方法が含まれる場合は、前記データを変換するデータ変換部と、
処理方法判定部が通信可能と判断した場合は、前記データまたは変換されたデータを送出する送信部と
を有する、データ送信処理装置。
【請求項２】
前記データ変換部は、送出元モジュール特定部によって特定されたモジュールの識別情報をデータに付加することを特徴とする、請求項１記載のデータ送信処理装置。
【請求項３】
前記データ受信部は、さらに前記データを送出したモジュールのデジタル署名または認証子またはチェックサムを受信し、
前記送出元モジュール特定部は、特定したモジュールのデジタル署名または認証子またはチェックサムを検証して正しいモジュールであるか否かを確認することを特徴とする、請求項２記載のデータ送信処理装置。
【請求項４】
前記送信元モジュール特定部は、特定したモジュールが起動されるに至った経緯情報を検出することを特徴とする、請求項３記載のデータ送信処理装置。
【請求項５】
コンピュータに
データを受信するデータ受信部、
前記データを送出したモジュールを特定する送出元モジュール特定部、
送出元モジュール毎に定義された、データ変換方法もしくは通信の可否を含む前記データの処理方法を示す送出方法定義リストを記憶する送出方法定義リスト記憶部、
送出元モジュール特定部によって特定された送出元モジュールに対応する処理方法を、送出方法定義リストを参照し決定する、処理方法判定部、
処理方法判定部の決定した処理方法に前記データの変換方法が含まれる場合は、前記データを変換するデータ変換部、
処理方法判定部が通信可能と判断した場合は、前記データまたは変換されたデータを送出する送信部
を実現させるためのデータ送信処理プログラム。
【請求項１】
データを受信するデータ受信部と、
前記データを送出したモジュールを特定する送出元モジュール特定部と、
送出元モジュール毎に定義された、データ変換方法もしくは通信の可否を含む前記データの処理方法を示す送出方法定義リストを記憶する送出方法定義リスト記憶部と、
送出元モジュール特定部によって特定された送出元モジュールに対応する処理方法を、送出方法定義リストを参照し決定する、処理方法判定部と、
処理方法判定部の決定した処理方法に前記データの変換方法が含まれる場合は、前記データを変換するデータ変換部と、
処理方法判定部が通信可能と判断した場合は、前記データまたは変換されたデータを送出する送信部と
を有する、データ送信処理装置。
【請求項２】
前記データ変換部は、送出元モジュール特定部によって特定されたモジュールの識別情報をデータに付加することを特徴とする、請求項１記載のデータ送信処理装置。
【請求項３】
前記データ受信部は、さらに前記データを送出したモジュールのデジタル署名または認証子またはチェックサムを受信し、
前記送出元モジュール特定部は、特定したモジュールのデジタル署名または認証子またはチェックサムを検証して正しいモジュールであるか否かを確認することを特徴とする、請求項２記載のデータ送信処理装置。
【請求項４】
前記送信元モジュール特定部は、特定したモジュールが起動されるに至った経緯情報を検出することを特徴とする、請求項３記載のデータ送信処理装置。
【請求項５】
コンピュータに
データを受信するデータ受信部、
前記データを送出したモジュールを特定する送出元モジュール特定部、
送出元モジュール毎に定義された、データ変換方法もしくは通信の可否を含む前記データの処理方法を示す送出方法定義リストを記憶する送出方法定義リスト記憶部、
送出元モジュール特定部によって特定された送出元モジュールに対応する処理方法を、送出方法定義リストを参照し決定する、処理方法判定部、
処理方法判定部の決定した処理方法に前記データの変換方法が含まれる場合は、前記データを変換するデータ変換部、
処理方法判定部が通信可能と判断した場合は、前記データまたは変換されたデータを送出する送信部
を実現させるためのデータ送信処理プログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【公開番号】特開２０１２−４８５７６（Ｐ２０１２−４８５７６Ａ）
【公開日】平成２４年３月８日（２０１２．３．８）
【国際特許分類】
【出願番号】特願２０１０−１９１３３９（Ｐ２０１０−１９１３３９）
【出願日】平成２２年８月２７日（２０１０．８．２７）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．Ｌｉｎｕｘ
【出願人】（０００００３０７８）株式会社東芝 (54,554)
【Ｆターム（参考）】
【公開日】平成２４年３月８日（２０１２．３．８）
【国際特許分類】
【出願日】平成２２年８月２７日（２０１０．８．２７）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．Ｌｉｎｕｘ
【出願人】（０００００３０７８）株式会社東芝 (54,554)
【Ｆターム（参考）】
[ Back to top ]