説明

データ送信装置および認証方法

【課題】性質の異なる複数のネットワーク機器が混在したネットワーク通信回線を介したデータ認証を、当該ネットワーク機器の性質を予め考慮することなく適切な認証方式を用いて行う。
【解決手段】データ送信装置は、認証子生成部と、通信部とを備える。前記認証子生成部は、第1の暗号鍵4001aを用いて第1の認証子を生成し、第2の暗号鍵4002aを用いて第1乃至第n断片情報を含む第2の認証子を生成する。前記通信部は、前記第1の認証子と前記第1断片情報とを含む第1のパケット501を送信先機器に送信し、前記第1のパケットの送信後、認証の成功を示す応答601を一定期間内に前記送信先機器から受信しなかった場合、前記第iの断片情報を含む第i(iは2以上でn以下の整数)のパケット502、503を、前記送信先機器に順次送信する。

【発明の詳細な説明】
【技術分野】
【0001】
この発明の実施形態は、データ送信装置および認証方法に関する。
【背景技術】
【0002】
通信機器のデータ認証にあたり、IPオプションフィールドなどの認証子格納フィールドに認証子を挿入する方法が一般的である。認証子を生成するには、例えば認証を行う相手機器との間で事前に共有された秘密鍵と、事前に取り決めた一方向関数とを用いたHMACを用いることができる。
【0003】
しかし、スマートグリッドの運用のような、ネットワークの管理をエンドユーザやプロバイダ(他社)に任されている場合においては、ルータ等のネットワーク機器がどのような性質を持つかを管理/運用することができないため、認証子格納フィールドの値は、インタネット上のルータの性質等により捨てられ、認証が行えない場合があった。
【0004】
このようなケースに対応する技術としては、TCPヘッダ内など捨てられる危険の無い、(認証子のサイズに比べ)小さな領域に認証子を書き込み、認証を要求する複数のパケットを送信することが試みられている。例えば、TCPヘッダの送信先ポート番号(Destination Port Number)に認証子の情報の一部を書き込み、認証を通った後に実際の通信ポートを開く方法が知られている。
【先行技術文献】
【非特許文献】
【0005】
【非特許文献1】HMAC: Keyed-Hashing for Message Authentication (H. Krawczyk 他 1997/2 RFC2104)
【非特許文献2】特開2003-91503号公報
【発明の概要】
【発明が解決しようとする課題】
【0006】
複数のパケットの送信により認証する方法は、通信機器の性質がさまざまであってもネットワーク通過性が高まり、通信可能性が保証されるというメリットがある。その一方で、パケット数の増加により通信の性能低下につながる場合があるという問題や、それらパケットを受信するサーバ側では認証処理が1パケットの受信では完了しないため、その通信セッション管理が複雑になり処理負荷が大きくなるという問題がある。多くの場合は複数のパケットを送信する方法でなくとも認証が行えるにもかかわらず、ネットワーク通過性を高めるためには、全ての通信に対して処理の重い複数のパケットを送信する方法を採る必要があり、効率が悪かった。
【0007】
一方、これを防ぐために常に最適な認証方法を選択するためには、各通信路毎にどの認証子であればネットワークを通過できるかということを知る必要がある。しかしながら、スマートグリッド等の運用では、ネットワーク上の各機器は、エンドユーザやプロバイダの管理下にあるものが多く、その機種/機能選定や設定について電力会社等のスマートグリッド管理側が事前に知ることはできない。このため、ネットワークの性質毎に適切な認証方法を選択し切り替える、という管理は運用上困難であり、これらの管理の手間をかけずに異なるネットワーク環境で共通して使えるデータ認証方法が必要となる。
【0008】
本発明は、上記課題を解決するべくなされたものであり、性質の異なる複数のネットワーク機器が混在し得るネットワーク通信回線を介したデータ認証を、当該ネットワーク機器の性質を予め考慮することなく、適切な認証方式により行うとするものである。
【課題を解決するための手段】
【0009】
本発明の一態様としてのデータ送信装置は、認証子生成部と、通信部とを備える。
【0010】
前記認証子生成部は、第1の暗号鍵を用いて第1の認証子を生成し、第2の暗号鍵を用いて第1乃至第n断片情報を含む第2の認証子を生成する。
【0011】
前記通信部は、前記第1の認証子と前記第1断片情報とを含む第1のパケットを送信先機器に送信し、前記第1のパケットの送信後、認証の成功を示す応答を一定期間内に前記送信先機器から受信しなかった場合、前記第iの断片情報を含む第i(iは2以上でn以下の整数)のパケットを、前記送信先機器に順次送信する。
【図面の簡単な説明】
【0012】
【図1】第1の実施形態にかかるシステム全体構成例を示す図。
【図2】第1の実施形態にかかるシステムの動作概要を説明するための図。
【図3】第1の実施形態にかかるスマートメーターの概略構成図。
【図4】第1の認証子のみを用いた認証方式の例を示す図。
【図5】第2の認証子のみを用いた認証方式の例を示す図。
【図6】第1の実施形態に係るパケット送信の動作概要を示す図。
【図7】第1の実施形態におけるスマートメーターの動作の流れを示すフローチャート。
【図8】第1のIPパケットの例を示す図。
【図9】MDMSがスマートメーターから受信し得るパケットの構成パターンを示す図。
【図10】第2の実施形態のパケット送信の動作概要を示す図。
【図11】第2の実施形態におけるスマートメーターの動作の流れを示すフローチャート。
【図12】第3の実施形態の通信履歴データベースに格納された情報の例を示す図。
【図13】第3の実施形態にかかるスマートメーターの概略構成図。
【図14】第3の実施形態におけるスマートメーターの動作の流れを示すフローチャート。
【発明を実施するための形態】
【0013】
以下に図面を参照して、この発明にかかる実施形態を詳細に説明する。
【0014】
(第1の実施形態)
図1は、次世代電力通信網(スマートグリッド)の一構成例を示す図であり、本実施形態に係るデータ認証方法を用いたクライアント側機器と、スマートグリッドのシステムで連携する機器の配置例を示している。それぞれの機器は、インタネット等の公衆ネットワークを介して接続される。
【0015】
スマートグリッドでは、電力使用量を集計するスマートメーター3010aと、家電機器を管理するホームサーバであるHEMS(Home Energy Management System)3020が各家庭に設置される。また、商業ビルを対象として、ビル内の電気機器を管理するサーバであるBEMS(Building Energy Management System)3030がビル毎に設置される。商業ビルには、スマートメーター3010aと同様のスマートメーター3010bが設置される。以下では、スマートメーター3010aおよびスマートメーター3010bを単にスマートメーターという。
【0016】
スマートメーターは、コンセントレータ(中継器)3040によって数台ごとにまとめられ、通信網を介してメーターデータ管理システムであるMDMS(Meter Data Management System)3050と通信する。MDMS3050は、各家庭のスマートメーターから一定の間隔で電力使用量を受信して記憶する。エネルギー管理システムであるEMS(Energy Management System)3060は、MDMS3050に集まった複数の家庭の電力使用量、或いは、電力系統に設置されたセンサからの情報に基づいて、スマートメーターやHEMS3020、BEMS3030などに対して電力使用を抑制するよう要求するなどの電力制御を行う。また、EMS3060は、遠隔端末ユニットであるRTU(Remote Terminal Unit)3071に接続された太陽光発電や風力発電などの分散電源3080、同じくRTU3072に接続された蓄電装置3090、および、RTU3073に接続された発電側との間の送電量を制御する送配電制御装置3100を制御し、電力系統網全体の電圧および周波数を安定化するための制御を行う。
【0017】
図1に示したように、スマートグリッドでは、多種多様な機器がネットワークを介して接続されており、その多くは電力系統網の制御に関わるため、テロリスト等による不正なデータ送信を防ぐ必要があり、全てデータの認証を行うことが重要となる。本実施形態は、スマートグリッドを構成する任意の機器間のデータ認証に用いることのできるものであり、特定の機器に限定したものでない。例えば、データ送信を行うのが家庭のスマートメーター3010aであり、そのデータを受信するのがMDMS3050である場合、データ送出クライアントであるスマートメーター3010aに本実施形態のクライアント側データ認証方式を適用することができる。この部分を抜き出し、本実施形態をより理解しやすく簡略化したものが図2である。
【0018】
図2は、スマートメーター3010aが、ネットワーク回線(インタネット等)を使い、コンセントレータ3040を経由してMDMS3050へデータパケットを送信するにあたり、本実施形態の方式を用いる例を示している。データ送信クライアントであるスマートメーター3010aは事前に第1の鍵4001aおよび第2の鍵4002aを格納している。一方、データ受信サーバであるMDMS3050は事前に第1の鍵4001bおよび第2の鍵4002bを格納している。鍵4001aと鍵4001bは暗号技術的に対になったものである。例えば、共通鍵を用いた認証を行う際には鍵4001aと鍵4001bは同一の値を持つ。あるいは公開鍵を用いた認証を行う際には、鍵4001aと鍵4001bとは公開鍵暗号方式における公開鍵と秘密鍵の関係にある。これらの鍵の性質についてはあくまで例を示したものであり、鍵4001aと鍵4001bとが暗号理論的に対になっていれば、それらがどのようなものであっても良い。同様に、鍵4002aと鍵4002bは暗号技術的に対になったものである。これらの鍵の用い方については後述する。
【0019】
スマートメーター3010aがパケットをMDMS3050へ送信する際には、第1の鍵4001aおよび第2の鍵4002aを用いて、本実施形態に特有な方式で生成された認証子を、送信するパケットに付加した後に送信を行う。一方、パケットを受信したMDMS3050は、第1の鍵4001bおよび第2の鍵4002bを用いて、パケットに付加されている認証子を検証し、正当な認証子が付いていればそれを受信し、そうでなければ不正な機器からのパケット(攻撃パケット)とみなし受信しない。
【0020】
なお、本実施形態では、経由するコンセントレータ3040はパケットを転送するだけの機能しか持たないものとし、認証子の検証などは全く行わないものであるとしたが、もちろん、コンセントレータ3040に対して本実施形態の方式を用いることも、同様に行うことができる。または別の従来の技術による認証を行うことが可能であることは言うまでもない。
【0021】
また、本実施形態の説明において、より一般的な説明とするために第1の鍵と第2の鍵は異なるものとして説明するが、第1の鍵と第2の鍵が同じものであってもかまわない。
【0022】
図2のスマートメーター3010aによるデータ送信部分をより詳細に示したのが図3である。パケット生成部301は送信するデータパケットを生成する部分である。インタネット上で通信を行う場合、通常はIP(Internet Protocol)通信を用いるため、パケット生成部301はIPパケットを生成するものとする。これは一般的な通信機器が持つ機能であり、説明は省略する。認証子生成部302は、送信するIPパケットがMDMS3050に対するものであると判断したら、それに対応する鍵である第1の鍵4001aおよび第2の鍵4002aを用いて以下認証子を作成する。IPパケットにはそのヘッダ部分に送信先のIP addressが記載されているから、そのフィールドを参照すれば送信先機器を区別することが可能である。
【0023】
ここでは送信先がMDMS3050に対するものであった場合のみを説明するため、それに使用する鍵についても鍵4001aと鍵4002aの1組だけであるが、データを送信する先が複数ある場合には、送信先毎に異なる鍵を用いることもでき、その場合は、送信先機器と、各機器向けの認証子を作成するための鍵の対応を記載したテーブルを参照し、第1の鍵と第2の鍵を取り出せば良い。この応用については手段が明白なため詳細な説明は省略する。
【0024】
まず認証子生成部302は第1の鍵4001aを用いて、送信するパケットに対応する認証子を生成する。認証子を生成するアルゴリズムについては従来から知られているさまざまな方式を用いることができ、特に方式を限定しない。例えば、非特許文献1に示したhmac方式を用い、パケットのデータと鍵を入力として認証子を生成すれば良い。なお、hmac方式では入力であるデータと鍵が同一であれば、常に同一の認証子が生成されるため、安全性を高めるために入力としてタイマー304の値(現在時刻)を用いることで、同一のデータであっても異なる認証子が生成されるようにして、安全性を高めることもできる。またはタイマー304の値のかわりに、パケット送信毎に加算される通し番号を入力として用いることもできる。
【0025】
このような手順によって、認証子生成部302はパケットと鍵4001aを用いて第1の認証子を生成し、同様にして、当該パケットと鍵4002aを用いて第2の認証子を生成する。
【0026】
ここまでの説明においては、第1の認証子と第2の認証子は同等の性質を持っており差異は無いが、それぞれの送信の方法が異なるので、それについて説明する。
【0027】
まず、第1の認証子の送信方法について説明する。第1の認証子は、認証子生成部302により、送信すべきデータと同一のIPパケットに認証子格納フィールドのデータとして単純に付加して送信される。付加する方法については既存のIP(インタネット・プロトコル)仕様に準拠することが望ましいので、例えばIPヘッダのオプション部のデータとして格納する。他の格納場所としては、TCPヘッダのオプション部、TCP/SYNなどのデータを持たないTCPヘッダのデータ部などが考えられる。また、近年の拡張されたIPsecプロトコルにおけるAH(Authentication Header)もこの認証子格納フィールドに相当する。
【0028】
第1の認証子のみを用いたデータ認証方法では、図4に概念を示したように、スマートメーターは鍵4001aを用いて生成された第1の認証子をIPパケットに付加してネットワーク回線(インタネット等)を通じてMDMSに送信し、MDMSは受信した第1の認証子を鍵4001bを用いて検証する。このような認証方法では、通信経路において第1の認証子が通過できずに消滅し、MDMSにおいて検証ができない場合があるという問題が発生する。
【0029】
この理由は、スマートメーターは一般家庭に配置された機器であるため、その家庭においていかなるネットワーク機器を用いているかが保証されないからである。例えば、インタネット・ブラウジングだけを目的とした安価な家庭向けルータ装置では、IP(インタネット・プロトコル)等が必ずしも完全に実装されておらず、第1の認証子の含まれたフィールドの情報を伝達しないといった、予測不能な事態が発生する。
【0030】
スマートグリッドの運用にあたって、全ての一般家庭の機器を予め調べることは不可能であるから、第1の認証子のみを用いたデータ認証方法では、スマートメーターとMDMSとの間の通信が保証されるか否か実際に動かして運用してみないと判らないことになり、社会インフラであるスマートグリッドの性質としては望ましいものでない。
【0031】
次に、第2の認証子の送信方法について説明する。第2の認証子は認証子格納フィールドを追加することなくIPパケットに埋め込む。すなわち、IPパケットの冗長部に認証子断片挿入フィールド、を持ち、そこに埋め込む。例えばTCPのSYNパケットの場合であれば、sequence number フィールド、window sizeフィールド、acknowledgement number フィールドは互換性のために存在するものの意味の無いデータであるため、そこに第2の認証子を埋め込むことができる。ただし、一般にIPパケットの冗長部すなわち認証子断片挿入フィールドのサイズを大きく取ることはできないので、第2の認証子を埋め込むにはサイズが小さく、第2の認証子を複数の断片に分割し、それぞれを別のIPパケットの認証子断片挿入フィールドに埋め込む。
【0032】
また、意味の無いフィールドは通常情報を埋め込まないためデータ転送中に削除されることが懸念されるので、削除されにくいフィールドとして destination port number フィールドを用いることもできる。本来はサーバ側のポート番号を指定するためのデータであるが、MDMSに実装された専用のサーバにアクセスすることを前提とすれば、それを認証用データの埋め込みに利用することができる(非特許文献2)。
【0033】
第2の認証子のみを用いたデータ認証方法では、図5に概念を示したように、スマートメーターは鍵4002aを用いて生成された第2の認証子を複数のIPパケットの認証子断片挿入フィールドに挿入してネットワーク回線(インタネット等)を通じてMDMSに送信し、MDMSは受信した第2の認証子を、鍵4002bを用いて検証するものであるが、ただ1回の認証を行うだけの目的で複数のIPパケットを送信しなければならず、スマートメーターの処理が重くなる。一般にスマートメーターは安価なハードウェアを用いた機器であるため、このデメリットは受け入れ難い。さらには、サーバ側であるMDMSはそれら複数のIPパケットを他の通信と区別しセッション管理するという処理の重い動作が必要になる。このように、第2の認証子のみを用いたデータ認証方法では、ネットワーク透過性が向上するのと引き替えに、実装上の別の問題が多く発生する。
【0034】
本実施形態は、第1の認証子による認証すなわち1つのパケットに認証子を付ける方法と、第2の認証子による認証すなわち複数のパケットで認証を行う方法を適宜組み合わせ、両方の特徴を生かした認証子の付け方を提案する。この方法では、1つのパケットのみで認証が行える場合においては軽い処理で済ませることができると同時に、それでは不足の場合にのみ複数のパケットで認証を行うことで、処理速度と接続可能性の両方を高めることが可能となる。つまり、負荷の増大を最小限に抑えつつも、ネットワーク通過性を高めることが可能となる。
【0035】
図6は本実施形態において各種の認証子が送信される手順概略を示した図である。 図7は、図3に示したスマートメーターの動作の流れを示すフローチャートである。
【0036】
認証子生成部302では、第1の鍵4001aを使って第1の認証子を作成し、第2の鍵4002aを使って、複数(ここでは3つ)の断片からなる第2の認証子を作成する(ステップS501)。
【0037】
スマートメーターからMDMSへデータを送信するにあたり、スマートメーターの認証子生成部302では、第1のIPパケット501には第1の鍵4001aを使って作成された第1の認証子を付加するとともに、第2の鍵4002aを使って作成された第2の認証子を3分割したものの最初の断片を認証子断片挿入フィールドに挿入する(ステップS502)。
【0038】
第1の認証子および最初の断片が挿入された第1のパケットを、通信部303を通じインタネット等のネットワークを経由して、送信先機器であるMDMSへ送信する(ステップS503)。認証子の生成の手順例については既に図3を用いて詳細を説明したので繰り返さない。
【0039】
本例では第2の認証子を3分割したものとして説明しているが、複数(n個)に分割するのであれば分割の数は問わない。分割する数を増やす程より多くの情報を認証子として送信することができるが、あまり増やし過ぎると通信負荷が増大するので好ましくない。分割数は第2の認証子が格納できる必要最小限にすべきである。
【0040】
図6より第1のIPパケットがスマートメーターから送信された状態のみを抜き出したのが図8である。望ましくは図8に示した第1のIPパケットをMDMSがそのまま受信できれば良いが、既に述べた通り通信経路の性質により必ずしもそのまま通過できるわけではなく、一部の情報が欠落する場合もある。MDMSに到達した時点での第1のIPパケットのデータについて、第1の認証子、および第2の認証子の最初の断片の有無によって分類すれば図9(A)から図9(D)の4通りに分類できる。
【0041】
まず、図9(A)のように第1の認証子と第2の認証子の最初の断片が両方ともMDMSに届いた場合には第1の認証子のみをもって認証が成功する。つまり鍵4001bを用いて第1の認証子を確認すればIPパケットが鍵4001aを持つスマートメーターから送信されたことを証明することができる。また、図9(B)のように第1の認証子が届き、第2の認証子の最初の断片が届かなかった場合には、同様に第1の認証子のみをもって認証が成功する。これらは最も簡単なケースであり、MDMSは認証に成功したことを確認できる返答601をスマートメーターに送信する。返答601の形式はいかなるものでも良く本実施形態は特にそのデータ構造等を限定しないが、例えばTCP/IP通信の場合、TCPの3-wayハンドシェークのサーバ側応答(SYN/ACKパケット)に相当すると考えれば良い。
【0042】
図9(C)および図9(D)は、第1の認証子が届かなかったケースを図示している。届かないとは第1の認証子が埋め込まれていた追加フィールド自体が通信途上で欠落する場合と、追加フィールドは残っているもののその中にあった第1の認証子データが消滅している場合とが考えられるが、どちらも意味は同じであり図9では前者の場合を図示している。
【0043】
図9(C)では、第1の認証子は届かなかったものの第2の認証子の最初の断片は届いている。この場合、第2の認証子の残りの断片も届けば鍵4002bを用いて第2の認証子を確認することができるが、まだ届いていないため確認はできない。したがってMDMSは認証に成功したことを確認できる返答601をスマートメーターに送信することはしない。
【0044】
図9(D)のように第1の認証子も第2の認証子の最初の断片もいずれも届かなかった場合、やはりMDMSは認証に成功したことを確認できる返答601をスマートメーターに送信することはしない。ただし、図9(C)の場合とは異なり、いずれにせよ今後認証子が届く期待はできないので、この時点で認証エラーと考え、認証エラーを示す返答をスマートメーターに送信しても良い。図9(D)のようなケースはネットワーク機器が極めて保守的な運用をしている場合にしか起こらないものであり、実際のシステム設計においては考慮しなくて良いと考えられる。
【0045】
一方、スマートメーターは認証に成功したことを確認できる返答601を受信するか否かによって、MDMSにおける認証が成功したと判断できる。しかし、一般に、返答がいつまでに戻って来るかを予め知ることはできないので、最悪の場合永遠に待たないと判断できないことにならず実用的でない。そこで、一定時間以上は待つこと無くタイムアウトするのが好ましい実装だと考えられる。
【0046】
スマートメーターの認証子生成部302は第1のIPパケット501を送信した後一定時間内に、認証に成功したことを確認できる返答601を通信部303で受信できたかを検査する(ステップS504)。受信できなかった場合には、MDMSが第1の認証子による認証ができなかった、すなわち図9(C)のケースであった可能性が高いと判断し、第2のIPパケット502、第3のIPパケット503を順次送信する(ステップS505)。受信できた場合は、認証に成功したとして(ステップS507)、以降の通信を継続する。
【0047】
第2のIPパケット502には、第2の鍵4002aを使って作成された第2の認証子を3分割したもののうち2番目の断片が認証子断片挿入フィールドに挿入され、通信部303を通じインタネット等のネットワークを経由してMDMSへ送信される(ステップS505)。第2の認証子は、既に送信した第1のIPパケット501の情報を用いて計算された認証子であるから、第2のIPパケットの情報を認証するものではない。第2のIPパケットは、第1のIPパケットをMDMSが認証するのに必要な認証子断片をMDMSに伝える目的で送信する。したがって、第2のIPパケットは特に認証を必要としないデータパケットであっても良いし、認証子断片を送信するだけの目的のダミー・データであっても構わない。
【0048】
第3のIPパケット503には、第2の鍵4002aを使って作成された第2の認証子を3分割したもののうち3番目の断片が、認証子断片挿入フィールドに挿入され、通信部303を通じ、インタネット等のネットワークを経由してMDMSへ送信される(ステップS505)。
【0049】
MDMSは第2のIPパケットおよび第3のIPパケットを受信することで、第2の認証子を3分割したもののうち、2番目および3番目の断片を得ることができる。前に述べた通り、MDMSは既に第2の認証子を3分割したもののうち最初の断片を得ているので、これで第2の認証子の断片全てを結合して第2の認証子とし、第2の認証子を用いて第1のIPパケットのデータが正当なスマートメーター、すなわち秘密鍵4001aおよび4002aを持つスマートメーター、から送信されたものであるということを、認証することができる。
【0050】
スマートメーターの認証子生成部302は、第3のIPパケットを送信した後一定時間内に、認証に成功したことを確認できる返答601を通信部303で受信できたかを検査する(ステップS506)。受信できた場合は、認証成功と判断し(S507)、以降の通信を継続する。受信できなかった場合は、認証失敗と判断する(ステップS508)。この場合、認証失敗として即座に終了しても良いが、一般に IP通信ではネットワークの混雑等の理由でパケットの一部が転送途上で消滅し、それが原因で認証に失敗することがあるので、再試行すれば成功する可能性もある。したがって、即座に終了するのではなく、ステップS501の最初から、またはステップS505から、再度、認証の手続きを実行しても良い。
【0051】
以上詳細に述べた手順にて、スマートメーターとMDMSとの間のネットワークが第1の認証子を通過させるものである場合には、第1の認証子を用いた高速な認証を行うことができると同時に、万一第1の認証子が通過せず第1の認証子による認証が不可能な場合であっても、スマートメーターから複数回に分けて送信された第2の認証子を用いることで確実な認証を行うことが可能であり、処理速度と接続可能性の両方を高めることを実現する。つまり、負荷の増大を最小限に抑えつつも、ネットワーク通過性を高めたデータ認証を実現する。
【0052】
以上、詳述したように、本実施形態によれば、インタネットなどの通信回線において、それを構成する特性の異なる複数の通信機器が混在したり、異なるプロバイダ業者が管理することでさまざまなポリシーのパケット・フィルタリングが行われたりするなどのスマートグリッド網において、機器間でデータ認証を行う際に、それぞれの機器が接続された通信回線の特性毎に最適な認証方法を予め設定することなく、性能の高い認証方式またはより接続性の高い認証方式が自動的に選択されるため、低い運用コストで高い性能(処理速度と接続可能性)が得られる。
【0053】
(第2の実施形態)
上述の第1の実施形態では、スマートメーターが第1のIPパケット501を送信した後一定時間内に、認証に成功したことを確認できる返答601を受信できなかった場合には、第2のIPパケット502、第3のIPパケット503を順次送信した。
【0054】
本実施形態において、スマートメーターが第1のIPパケット501を送信した後一定時間内に、認証に成功したことを確認できる返答601を受信できなかった場合には、第2のIPパケット502を送信するところまでは、上述の第1の実施形態と同一である。
【0055】
図10は本実施形態において各種の認証子が送信される手順概略を示した図である。 図11は、本実施形態に係わるスマートメーターの動作の流れを示すフローチャートである。
【0056】
本実施形態では、スマートメーターが第2のIPパケット502を送信し(ステップS505a)、その後一定時間内に、認証に成功したことを確認できる返答601を受信できたかを判断する(ステップS506a)。受信できなかった場合には、第3のIPパケット503を送信し(ステップS505b)、その後一定期間内に応答を受信した場合は、認証成功と判断し(ステップS507)、受信できなかった場合は認証失敗と判断する(ステップS508)。ただし、図10に示すように、当該一定時間内に返答601を受信できた場合、すなわちMDMSが既に送付した断片情報を用いて認証に成功した場合には、第3のIPパケット503の送信を行うことなく、認証が成功したと判断する(ステップS507)。つまり、第2の認証子を3分割したもののうち、最初と2番目の断片のみを送信し3番目の断片の送信は省略する。
【0057】
MDMSが全ての断片を受信しないと第2の認証子をMDMSが得ることはできないから、本来であればスマートメーターが第3のIPパケット503を送出した後でなければ認証ができないのであるが、本実施形態では第2のIPパケット502をMDMSが受信した時点で認証に成功したものとして、返答601をMDMSが送信している。
【0058】
このようなことができる理由は、一般に使われているHMAC等のアルゴリズムでは、偏りの無い認証子を生成するため、生成結果の全ての情報(全てのビット情報)を必ずしもチェックせずとも、一部の情報(一部のビット情報)をチェックしただけでも、認証を行う効果が得られるからである。
【0059】
当然、チェックする情報が少なければ少ないほど、安全性は低下するため、全ての情報をチェックするのが望ましいが、ネットワークの混雑時や、MDMSのサーバ処理の高負荷時などでは、多くのパケットを処理する余裕が無く、無理に全てのパケットを処理して認証処理がスムーズにできなくなるよりは、チェックする情報を減らして処理を先に進めた方が安全性が高まるケースがある。本実施形態では、このようなケースにも対応できる手順として、既に述べた通り第2のIPパケット502を送出後一定時間内に、認証に成功したことを確認できる返答601を受信した場合には、第3のIPパケット503の送信を行わないというメカニズムを加えた。
【0060】
ここでは第2の認証子を3つの断片に分割するとして説明したが、分割数は3つ以上のいくつでも良く、複数の断片を順次送出している途中で返答601を受信した時点で、以後の断片の送出を省略することができる。すなわち、分割数nのとき、第2のパケットの送信後、第x(xは2より大でn以下の整数)のパケットの送信前に、認証の成功が受信されたときは、第x乃至第nのパケットの送信を省略できる。その結果MDMSにもはや使われない無駄なパケットをネットワークに流すことを防ぐことができる。この性質は殊にネットワーク混雑時やMDMSサーバ高負荷時の挙動として望ましいものである。
【0061】
以上、本実施形態によれば、複数のIPパケットを送信して認証を行う場合において、ネットワーク混雑時やサーバ高負荷時などにおいて送信すべき認証用IPパケットの数を動的に減らすことにより、より一層高い通信性能を示すこともできる。
【0062】
(第3の実施形態)
本実施形態では、認証に成功したことを確認できる返答601は、第1の認証子により認証が成功したか、第2の認証子により認証が成功したか、いずれであるかが確認できる情報フラグを持ち、スマートメーターは、受信した返答601を確認することにより、いずれの認証子が通ったのかを知る。なお、以下の説明で、第1の認証子に基づく認証方式を第1認証方式、第2の認証子に基づく認証方式を第2認証方式と称する。
【0063】
上述の実施形態の説明では、手順を追って説明したため、第1の認証子により認証が成功した場合にはスマートメーターが返答601を第2のIPパケット送出前に受信し、第2の認証子により認証が成功した場合にはスマートメーターが早くとも第2のIPパケット送出後に受信する、と区別できるかのように読める。しかしながら、実際にはネットワークをパケットが流れるのは時間がゼロではないため、順番があとさきになる場合がある。特にMDMSの処理が高負荷だったり、途中経路のネットワークが混雑したりした場合には、全ての認証処理(第1の認証子の認証と第2の認証子の認証の両方)が終わった後に、返答601をスマートメーターが受信することもありえる。
【0064】
したがって、返答601に前記した確認のための情報フラグを持つことにより、認証の状況を知ることができる。
【0065】
この情報、すなわち第1の認証子により認証が成功したか、第2の認証子により認証が成功したか、の情報を、図13に示すように認証子生成部302によりアクセス可能な通信履歴データベース305に保存しておき、その情報を利用することにより、以下に説明する効率的な通信を行うことが可能となる。
【0066】
スマートメーターの通信相手(送信先機器)は、MDMSなどの電力網監視関連の機器であるため、いくつかの決まった相手と繰り返し通信することになる。また、同じ相手との通信経路は滅多に変更されることが無いから、前回の通信で通過できた認証子のフィールドは、次回の通信においても通過できる可能性が極めて高い。
【0067】
確認のための情報フラグの履歴を通信履歴データベースに記録する。通信履歴データベースに情報フラグが記録された例を図12に示す。第2認証子の「NG」は、第1〜第3のパケットを送信したにも拘わらず認証成功が返ってこない場合の他、第1認証子の認証が高速に行われたため、第2または第3のパケットを送信しなかった場合も含み得る。
【0068】
図14のフローチャートに示すように、本実施形態のスマートメーターでは、第1の認証子により認証が成功したか、第2の認証子により認証が成功したかを、送信先機器毎に毎回記録し(ステップS601)、その記録に基づき、次回の通信に用いる認証方式を切り替える(ステップS602)ことができる。例えば、第1の認証子が通過できるか否かは、一番最後に通信した時に第1の認証子が通過できたか否かで判断すれば概ね正しい。また、過去の履歴を見て高い確率で通過している場合には、やはり次回も通過できる確率が高いと考えることができる。
【0069】
第1認証方式を選択したときは、第1の認証子を含み、断片を含まない第1のパケットを送信する(ステップS603)。一方、第2認証方式を選択したときは、第1〜第3の断片を含む第1〜第3のパケット(第1の認証子はいずれも含まない)を順次送信する(ステップS604)。
【0070】
図12の例では、MDMS-1への送信の過去3回の履歴が残っているが、3回とも第1の認証子が通過していることを示しているから、次回のMDMS-1への送信時にも、第1の認証子が通過する可能性が極めて高く、第1認証方式を選択し、パケット送信を行う(ステップS603)。この場合、第2の認証子の計算を省略することができるので、処理を軽くすることができる。さらには、第1のIPパケット送出後に、第2のIPパケットを送出するか否かを判断するために返答601を待つ必要も無くなるため、その部分の処理も削減することができる。
【0071】
一方、第1の認証子が通過できないことが確実であれば、上述のように第2認証方式を選択し、第1〜第3の断片を含む第1〜第3のパケットを、順次送信する(ステップS604)。この場合、第1の認証子の計算を省略することができるので、処理を軽くすることができる。第1の認証子をIPパケットに付加する必要が無くなるので送信データのサイズも小さくすることができる。図12の例では、MDMS-2への通信では第1の認証子が使える可能性は低く、第2の認証子のみを使うのが良いということが判る。
【0072】
なお、ここで述べた履歴に基づく予測が外れる場合も小さな確率ながらある。例えばインタネット・プロバイダがネットワーク構成を変えたり、ルータ機器を換えたり、パケット・フィルタリングのルールを変えたりすることが考えられる。そのような場合、認証に失敗することも考えられるが、問題は無い。なぜなら、TCP/IPはじめ多くの通信プロトコルでは通信失敗時のパケット再送機能を持つため、失敗したことが記録されるために、再送時には改めて通信できる方法で認証子の付加を行うことができるからである。つまり、ステップS603で送信したパケットでの認証が失敗したときは、第2認証方式で再度送信を行い、またステップS604で認証が失敗したときは、第1認証方式で再度、送信を行えばよい。
【0073】
以上のような手順にて、確認のための情報フラグの履歴を利用することで、2回目以降の通信をより効率化することができる。
【0074】
以上、本実施形態によれば、いかなる認証方式により接続できたかの履歴を通信履歴データベースに記録し利用することにより、以後の通信をより一層高速な方式を選択して行うこともできるようになる。
【0075】
これまで述べてきた第1〜第3実施形態により、スマートグリッドにおけるネットワーク機器のデータ認証を効率的に行うと同時に、運用コストを下げることが実現可能となる。
【符号の説明】
【0076】
301・・・パケット生成部
302・・・認証子生成部
303・・・通信部
304・・・タイマー
305・・・通信履歴データベース
501・・・第1のIPパケット
502・・・第2のIPパケット
503・・・第3のIPパケット
601・・・認証に成功したことを確認できる返答
4001a・・・第1の暗号鍵
4002a・・・第2の暗号鍵

【特許請求の範囲】
【請求項1】
第1の暗号鍵を用いて第1の認証子を生成し、第2の暗号鍵を用いて第1乃至第n断片情報を含む第2の認証子を生成する認証子生成部と、
前記第1の認証子と前記第1断片情報とを含む第1のパケットを送信先機器に送信し、前記第1のパケットの送信後、認証の成功を示す応答を一定期間内に前記送信先機器から受信しなかった場合、前記第i断片情報を含む第iのパケット(iは2以上でn以下の整数)を、前記送信先機器に順次送信する、通信部と、
を備えたデータ送信装置。
【請求項2】
前記通信部は、前記認証の成功を示す応答が、前記第2のパケットの送信後、前記第x(xは2より大でn以下の整数)のパケットの送信前に受信されたときは、前記第x乃至第nのパケットの送信を省略する
ことを特徴とする請求項1に記載のデータ送信装置。
【請求項3】
通信履歴データベースをさらに備え、
前記通信部は、前記送信先機器から前記第1の認証子および前記第2の認証子のどちらにより認証が成功したかの情報を含む応答を受信し、
前記通信履歴データベースは、前記送信先機器に対して、前記情報の履歴を格納し、
前記認証子生成部は、前記通信履歴データベースに基づき、前記第1の認証子と第2の認証子のどちらによる認証を要求するかを選択し、
前記通信部は、
前記認証子生成部により前記第1の認証子による認証が選択されたとき、前記第1の認証子を含み、前記第1乃至第nの断片情報のいずれも含まない第1のパケットを、前記送信先機器に送信し、
前記認証子生成部により前記第2の認証子による認証が選択されたとき、前記第1の認証子を含まず、前記第i断片情報を含む第iのパケット(iは2以上でn以下の整数)を、順次送信する
ことを特徴とする請求項1に記載のデータ送信装置。
【請求項4】
前記認証子生成部は、前記第1および第2の認証子による認証のうち、最も直近に成功した認証を選択する
ことを特徴とする請求項3に記載のデータ送信装置。
【請求項5】
前記認証子生成部は、前記第1および第2の認証子による認証のうち、成功回数の多い方の認証を選択する
ことを特徴とする請求項3に記載のデータ送信装置。
【請求項6】
第1の暗号鍵を用いて第1の認証子を生成し、第2の暗号鍵を用いて第1乃至第n断片情報を含む第2の認証子を生成するステップと、
前記第1の認証子と前記第1断片情報とを含む第1のパケットを送信先機器に送信するステップと、
前記第1のパケットの送信後、認証の成功を示す応答を一定期間内に前記送信先機器から受信しなかった場合、前記第i断片情報を含む第iのパケット(iは2以上でn以下の整数)を、前記送信先機器に順次送信するステップと、
を備えた認証方法。

【図1】
image rotate

【図2】
image rotate

【図3】
image rotate

【図4】
image rotate

【図5】
image rotate

【図6】
image rotate

【図7】
image rotate

【図8】
image rotate

【図9】
image rotate

【図10】
image rotate

【図11】
image rotate

【図12】
image rotate

【図13】
image rotate

【図14】
image rotate


【公開番号】特開2012−186721(P2012−186721A)
【公開日】平成24年9月27日(2012.9.27)
【国際特許分類】
【出願番号】特願2011−49412(P2011−49412)
【出願日】平成23年3月7日(2011.3.7)
【出願人】(000003078)株式会社東芝 (54,554)
【Fターム(参考)】