JP2006081082A - メッセージ受信確認方法、通信端末装置及びメッセージ受信確認システム - Google Patents

Abstract

【課題】 マルチホップ環境下の多数のノードに対するデータが、各ノードで受信されたかを確認するための、各ノードでの処理負荷をできるだけ小さくする。
【解決手段】 メッセージ送信装置がメッセージを送信する。メッセージ受信装置は、メッセージの受信時に、メッセージの受信証明情報を生成し、さらに、メッセージの受信証明情報を利用してメッセージの受信確認情報を生成して、メッセージの受信確認情報を受信確認情報検証装置に送信する。受信確認情報検証装置は、受信した受信確認情報を検証する。メッセージ送信装置は、その検証結果に基づいて、メッセージ受信装置に対するメッセージの受信確認を得る。
【選択図】 図１

Description

本発明は、メッセージ受信確認方法、通信端末装置及びメッセージ受信確認システムに関し、例えば、センサネットワークシステムのような、システムを集中制御するサーバと、低コストで構成される膨大な数のセンサノードからなるシステムにおいて、サーバがセンサノードにメッセージをブロードキャストし、その受信確認を行う場合に適用し得るものである。

例えば、ソフトウェアのアップロードデータなど、サーバがノードに対して重要な情報を発信するときは、サーバはノードに正しいデータが届けられたことを確認したい。

マルチホップ通信環境におけるサーバからノードへのブロードキャストおいて受信確認を行うことには、次のような問題点がある。マルチホップ通信環境におけるサーバからノードへのブロードキャストにおいて、受信した全ノードが個々にサーバに対して受信確認メッセージを返すのは、通信オーバーヘッドが大きいし、サーバへの負荷も大きい。マルチホップ通信環境は、送信元の機器と送信先の機器との間に複数のノードが中継する通信形態をとるため、ノードからの受信確認メッセージに信憑性がない（不正な中継ノードが受信確認メッセージを偽造している可能牲がある）。

非特許文献１の５頁には、セキュアなルーティングを実現する方式について記載している。その中で、任意のノードが他の全ノードと１対１の鍵を共有している前提のセキュアルーティング方式として、Ariadne Route Discovery using MACs方式について説明がある。この方式では、ターゲットノードへのルートを生成したいノードがブロードキャストするルートリクエストを受信したノードは、自身を中継したことをルートリクエストのターゲットノードに証明するために、（１）自身のＩＤ情報、（２）ルートリクエストに対するＭＡＣ（Message Authentication Code；但しＭＡＣは、自身とターゲットノードとが１対１で共有する鍵を用いて生成する）、（３）前ホップノードの中継証明情報、を連結してハッシュ関数にかけ、その出力値を自身の中継証明情報として次ホップへのメッセージに付加する。

ターゲットノードは、中継証明情報付きのルートリクエストを受信するにあたり、ルートリクエストを中継したノード情報に偽りがないことを、各ノードと共有する鍵を用いて検証することできる。検証が成功した場合、ターゲットノードはルートリプライとして、中継したノード情報と、そのＭＡＣ（レートリクエスト生成ノードと共有する鍵で生成したもの）をルートリクエスト生成ノードに返信することで、生成ノードはターゲットノードへのセキュアな経路情報を得る。

各中継ノードが出力する中継証明情報は、ハッシュ関数の出力値となるのでデータサイズは大きくなく、また、中継証明情報は各ノードで重畳する形となるので、そのデータサイズはルート上の中継ノード数に依存せず、一定という利点がある。
Yih-Chun Hu, Adrian Perrig, David B. Johnson, "Ariadne: A Secure On-Demand Routing Protocol for Ad Hoc Networks,"MobiCom’02, September 23-26, 2002, Atlanta, Georgia, USA

今想定するセンサネットワークシステムは、システムを集中管理するサーバと、低コストで構成される膨大な数のセンサノードから構成される。センサノードは一般的に電池駆動で資源に制限があるので、センサノードが被る負荷は小さいほうが好ましい。

従来技術をサーバのブロードキャストメッセージの受信確認に適用しようとする場合、サーバのブロードキャストメッセージ（従来技術においてルートリクエスト）の受信確認は、センサノード側（従来技術においてターゲットノード）で検証され、サーバに報告される形態である。この場合、検証のための演算負荷は低コストなセンサノードが被ることになり、また、検証するセンサノードは、検証のために少なくともサーバから自身までの経路上に存在するであろう全センサノードと１対１の鍵を共有しておく必要がある。

また、センサノードが受信確認の検証結果をサーバに報告するという形態は、例えば、センサネットワークの一般的なネットワーク構造であるツリー構造などでは、上流ノードの受信確認の検証に伴う演算が下流ノードにおいて重複してしまう可能性があり、効率が良くない。

以上より、従来技術では、受信確認情報（従来技術において中継証明情報）のデータサイズは大きくなく、また、ホップ数に依存せず一定という利点があるが、センサネットワークにおけるサーバのブロードキャストメッセージの受信確認にそのまま適用することは好ましくなく、センサネットワークシステムにより適したメッセージ受信確認方法やシステムや通信端末装置などが必要である。

第１の本発明は、マルチホップ通信環境下で、メッセージ送信装置が、メッセージ受信装置に対して送信したメッセージの受信確認を得るメッセージ受信確認方法であって、メッセージ送信装置がメッセージを送信する第１の工程と、メッセージ受信装置がメッセージの受信証明情報を生成する第２の工程と、メッセージ受信装置が、メッセージの受信証明情報を利用してメッセージの受信確認情報を生成する第３の工程と、メッセージ受信装置がメッセージの受信確認情報を受信確認情報検証装置に送る第４の工程と、受信確認情報検証装置が受信した受信確認情報を検証する第５の工程と、メッセージ送信装置が、上記第５の工程による検証結果に基づいて、メッセージ受信装置に対するメッセージの受信確認を得る第６の工程とを含むことを特徴とする。

第２の本発明は、マルチホップ通信環境下でメッセージ送信装置が送信したメッセージがメッセージ受信装置で受信されたか否かを表す、メッセージ受信装置が送信した受信確認情報を検証する検証用の通信端末装置であって、メッセージ受信装置の情報を管理する受信装置情報管理手段と、受信確認情報を受信する受信手段と、受信した受信確認情報を検証する検証手段とを有することを特徴とする。

第３の本発明は、マルチホップ通信環境下で、メッセージ送信装置が送信したメッセージを受信し、受信したときに受信確認情報を生成するメッセージ受信装置が該当する通信端末装置であって、メッセージを受信する受信手段と、メッセージの受信証明情報を生成する受信証明情報生成手段と、隣接する通信端末装置の情報を管理する隣接装置情報管理手段と、メッセージの受信確認情報を生成する受信確認情報生成手段と、受信確認情報を送信する受信確認情報送信手段とを有することを特徴とする。

第４の本発明のメッセージ受信確認システムは、第２の本発明の検証用の通信端末装置と、第３の本発明のメッセージ受信装置が該当する通信端末装置とを有することを特徴とする。

本発明によれば、マルチホップ通信環境下におけるメッセージの受信確認のための、メッセージ受信装置における処理負荷を少なくし、センサネットワークシステムのような多数のノードを有するネットワークシステムにより適したメッセージ受信確認方法やシステムや通信端末装置を提供することができる。

（Ａ）第１の実施形態
以下、本発明によるメッセージ受信確認方法、通信端末装置及びメッセージ受信確認システムの第１の実施形態を、図面を参照しながら説明する。

第１の実施形態においては、システムを集中管理するサーバは、自身が管理する全ノードの認証鍵（各ノードがサーバと１対１で共有する鍵）と、全てのノードへのルーティングテーブルを保持している。サーバのブロードキャストデータに対して、ノードは、受信したデータに対するＭＡＣを自身とサーバとが１対１で共有する鍵を用いて生成し、生成したＭＡＣと、自身の全ての子ノードから受け取った受信確認情報を連結させたものに対してハッシュ関数にかけたものを自身の受信確認情報として親ノードに送信する。サーバは、自身がブロードキャストしたデータに対する受信確認情報を受けることで、正しいデータが届いたかそうでないか、また、自身の管理するノード情報に変化があるかないかを検出する。

（Ａ−１）第１の実施形態の構成
第１の実施形態のメッセージ受信確認システムが前提とするネットワークは、図１に示すように、サーバ１に対し、多数（図１では５個）のノード２がツリー状に接続された構成を有している。なお、サーバ１、各ノード２が、通信端末装置に該当する。

図２は、第１の実施形態におけるサーバ（ブロードキャストデータの送信者）１の内部構成を示すブロック図である。

サーバ１は、データ生成部１１、ノード情報管理部１２、受信確認情報検証部１３、送信部１４及び受信部１５を有している。

データ生成部１１は、ブロードキャストするデータを生成するものであり、生成したデータを送信部１４と受信確認情報検証部１３へ与えるものである。

ノード情報管理部１２は、管理下のノードの情報を管理するものであり、管理するノード情報を受信確認情報検証部１３へ与えるものである。ここで、ノード情報とは、図１のように、ノードＩＤとノード認証鍵とそのノードへのルート情報より構成されている。ノードＩＤは、ノードを識別するのに用いる情報で、例えば、６４bit-IEEEアドレスなどを適用可能である。ノード認証鍵は、サーバ１と各ノード２が１対１で共有する鍵情報であり、例えば１２８bitsの長さを持つものとする。ノードへのルート情報は、サーバ１と全ノード間のルート情報が分かれば良く、そのデータ形式を限定されない。

受信確認情報検証部１３は、データ生成部１１より与えられたデータと、ノード情報管理部１２より与えられたノード情報と、受信部１５より与えられた受信確認情報より、ブロードキャストしたデータが管理下の全ノードに届いたか、そうでないかを検証するものである。受信確認情報検証部１３は、ＭＡＣ生成アルゴリズムとハッシュ関数を有する。ＭＡＣ生成アルゴリズムは、例えば、ＡＥＳ暗号等のブロック暗号を用いたＣＢＣ−ＭＡＣ（Cipher Block Chaining−ＭＡＣ）であり、ハッシュ関数は、例えば、ＭＤ５（Message Digest ５）やＳＨＡ−１（Secure Hash Algorithm−１）である。これらＭＡＣ生成アルゴリズムとハッシュ関数は、サーバ１とノード２との間で予め決定しておくことを要する。

受信確認情報検証部１３は、ノード情報管理部１２より与えられる管理下ノードへのルート情報に従い、隣接ノードが返信すると想定される受信確認情報を求める。例えば、図１のようなノード情報をサーバ１が保持している場合、受信確認情報検証部１３での演算は、データ生成部１１より与えられたデータと、ノード認証鍵を用いて、図４中の式１のように求める。すなわち、エンドノードに関しては、ブロードキャストデータ文に対するＭＡＣをそのノードの認証鍵を用いて計算したものに対してハッシュ関数を施し、ルータノードに関しては、ブロードキャストデータＸに対するＭＡＣをそのノードの認証鍵を用いて計算したものに、さらに、そのノードが中継している１つ又は複数のノードにおける計算結果を連結したものに対してハッシュ関数を施す、というように各ノードにおける計算結果を重畳して最終的な演算結果を得る。

ここで、ルータノードとは、ツリー構造における親ノードのように、１つ又は複数のノードへの中継ノードとなるノードを指し、エンドノードとは、ツリー構造における子ノードを持たないノードのように、次ホップノードへの中継ノードとならないノードを指す。

受信確認情報検証部１３での演算結果と、受信部１５より与えられた受信確認情報が一致するか否かで、サーバ１がブロードキャストした正しいデータが管理下のノードに届いたかそうでないかが分かる。

送信部１４は、データ生成部１１より与えられるデータを、管理下のノードへブロードキャストするものである。

受信部１５は、隣接する管理下ノードから受信した受信確認情報を、受信確認情報検証部１３へ与えるものである。ここで、「隣接する」とは、１ホップでデータの送受信が可能な範囲を表している。

図３は、第１の実施形態における各ノード（ブロードキャストデータの受信者）２の詳細構成を示すブロック図である。なお、図３は、各ノードがブロードキャストデータを受信したことをサーバ側に伝える構成面から構成要素を記載しており、ブロードキャストデータを、子ノード側に中継送信する構成については省略している。

各ノード２は、受信データ保持部２１、自ノード認証鍵管理部２２、ＭＡＣ生成部２３、子ノード情報管理部２４、受信確認情報生成部２５、受信部２６及び送信部２７を有する。

受信データ保持部２１は、受信部２６より与えられるサーバ１のブロードキャストデータを保持するものであり、保持するデータをＭＡＣ生成部２３へ与えるものである。

自ノード認証鍵管理部２２は、サーバ１と当該ノードとが１対１で共有する鍵を管理するものであり、管理する鍵をＭＡＣ生成部２３へ与えるものである。ここで、管理する鍵は、サーバ１に当該ノードを認証せしめる認証鍵として用いる。

ＭＡＣ生成部２３は、受信データ保持部２１から与えられるサーバ１のブロードキャストデータと、自ノード認証鍵管理部２２から与えられる当該ノードの認証鍵より、データに対するＭＡＣを生成するものであり、生成したＭＡＣを受信確認情報生成部２５へ与えるものである。ＭＡＣ生成部２３は、ＭＡＣ生成アルゴリズムを有する。ここでのＭＡＣ生成アルゴリズムは、サーバとの間で事前に決定されたものである。

子ノード情報管理部２４は、当該ノードがルータノードであるかエンドノードであるか、そして、ルータノードの場合には、当該ノードが中継となっているノードの情報を管理するものであり、管理する情報を受信確認情報生成部２５へ与える。子ノード情報管理部２４でノード情報を管理していないことは、当該ノードがエンドノードであることを意味し、子ノード情報管理部２４で、ノード情報を管理していることは、当該ノードがルータノードであることを意味する。子ノード情報管理部２４が管理する情報は、ノードＩＤと、そのノードがルータノードであるかエンドノードであるかという情報である。

受信確認情報生成部２５は、子ノード情報管理部２４より与えられる情報と、ＭＡＣ生成部２３より与えられるＭＡＣと、受信部２６より与えられる子ノードの生成した受信確認情報より、当該ノードの受信確認情報を生成するものであり、生成した受信確認情報を送信部２７へ与える。受信確認情報生成部２５は、ハッシュ関数を有する。受信確認情報生成部２５が保持するハッシュ関数は、サーバ１との間で事前に決定されたものである。受信確認情報生成部２５は、子ノード情報管理部２４より当該ノードがエンドノードであることを受けてＭＡＣ生成部２３より与えられるＭＡＣに対してハッシュ関数を施し、それを当該ノードの受信確認情報として送信部２７へ与える。また、受信確認情報生成部２５は、子ノード情報管理部２４より当該ノードがルータノードであることと、１つ又は複数の子ノードのＩＤを受けて、ＭＡＣ生成部２３より与えられるＭＡＣと、受信部２６より与えられる全ての子ノードの受信確認情報を連結したものに対して、ハッシュ関数を施し、それを当該ノードの受信確認情報として送信部２７へ与える。ここで、複数の子ノードより受信確認情報を与えられた場合の受信確認情報の連結の順番は、特に指定しない。例えば、ノードＩＤの大小に従って連結する順番を決定しても良い。但し、サーバ１との間で事前に決定された仕様に従う必要がある。

受信部２６は、サーバ１からのブロードキャストデータを受信データ保持部２１へ、また、子ノードからの受信確認情報を受信確認情報生成部２５へ与えるものである。

送信部２７は、受信確認情報生成部２５より与えられる当該ノードの受信確認情報を自身の親ノード（親がサーバの場合はサーバ）に送信するものである。

（Ａ−２）第１の実施形態の動作
次に、第１の実施形態のメッセージ受信確認システムの動作（メッセージ受信確認方法）を説明する。

第１の実施形態のメッセージ受信確認システムの動作は、大きくは、３段階の動作（Ｓ１０１〜Ｓ１０３）でなっている。

第１段階Ｓ１０１（図５参照）
サーバ１は、データ生成部１１においてブロードキャストデータＸを生成し、送信部１４を通して管理下のノード２にブロードキャストする。

第２段階Ｓ１０２（図６参照）
サーバ１は、受信確認情報検証部１３において、データ生成部１１より与えられるブロードキャストデータＸと、ノード情報管理部１２より与えられるノードＩＤ、ノード認証鍵、ルート情報から、隣接ノードから返信されると予測される受信確認情報を演算により求めておく。

一方、各ノード２は、受信部２６が受信したサーバ１からのブロードキャストデータＸを受信データ保持部２１に保持し、さらに、ＭＡＣ生成部２３において、受信データ保持部２１より与えられるサーバ１からのブロードキャストデータＸと、自ノード認証鍵管理部２２により与えられる当該ノードの認証鍵を入力して、受信データのＭＡＣを生成し、受信確認情報生成部２５へ与える。

また、各ノード２は、受信確認情報生成部２５において、子ノード情報管理部２４から与えられる情報により、自身がエンドノードかルータノードかを判断する。

各ノード２は、自身がエンドノードである場合には（図１のネットワーク構成であれば、ＩＤが「０３」〜「０５」のノード）、ＭＡＣ生成部２３より与えられるＭＡＣに対してハッシュ関数を施したハッシュ値を、自身の受信確認情報として、送信部２７から親ノードに送信する。

これに対して、各ノード２は、自身がルータノードの場合には（図１のネットワーク構成であれば、ＩＤが「０１」、「０２」のノード）、受信部２６を介して全ての子ノードの受信確認情報が与えられるので、ＭＡＣ生成部２３より与えられるＭＡＣと、全ての子ノードの受信確認情報とを連結させたものに対してハッシュ関数を施したハッシュ値を、自身の受信確認情報として送信部２７から親ノードに送信する。

例えば、図６のＩＤが「０４」のエンドノードにおいては、ＭＡＣ生成部２３が、サーバ１からのブロードキャストデータＸ（図６では誤って届いている可能性もあるので、Ｘ’で表している）と、当該ノードの認証鍵Ｋ０４’を入力して、受信データのＭＡＣを生成し、受信確認情報生成部２５が、そのＭＡＣに対してハッシュ関数Ｈ（・）を施したハッシュ値を、自身の受信確認情報として、送信部２７から親ノード（「０２」のノード）に送信する。

また例えば、図６のＩＤが「０２」のルータノードにおいては、受信確認情報生成部２５は、ＭＡＣ生成部２３より与えられるＭＡＣと、全ての子ノード（「０４」及び「０５」）の受信確認情報ｈ’０４、ｈ’０５とを連結させたものに対してハッシュ関数Ｈ（・）を施したハッシュ値を、自身の受信確認情報として送信部２７から親ノードに送信する。

第３段階Ｓ１０３（図７参照）
サーバ１は、受信確認情報検証部１３において、第２段階の演算により求めた受信確認情報と、受信部１５を介して与えられた隣接ノードからの受信確認情報が一致するかどうかを検証する。

（Ａ−３）第１の実施形態の効果
第１の実施形態のメッセージ受信確認装置、システム及び方法によれば、以下の効果を奏することができる。

サーバが発信するブロードキャストデータ（メッセージ）に対して、各ノードが受信確認情報を返信し、それをサーバが検証するという形態をとるので、検証のための演算負荷を計算資源が小さいノードが被る必要はなく、計算資源のあるサーバにまかせることができる。また、検証をサーバが行うので、各ノードは、サーバから自身までの経路上に存在する全てのノードと１対１の鍵を共有しておく必要はなく、システムを集中管理するサーバと１対１の鍵を共有しておくだけで済む。

各ルータノードが返信する受信確認情報は、そのルータノードの子ノードの受信確認情報を重畳する。そのため、子ノードが複数の場合には、各子ノードが個々にサーバに受信確認情報を返信する場合に比べて、ルータノードが受信確認情報を中継するための通信回数を減少させることができる。また、各ノードが重複して受信確認情報を生成することがなく効率が良い。

サーバは、自身の発信したブロードキャストデータが自身の管理するノードに正しく届けられたか、そうでないかが分かる。例えば、ソフトウェアのアップロードデータなどの重要なデータの発信に際し、サーバは、正しいデータが管理下のノードに届けられたか否かを把握することができる。

サーバは、自身の管理するノード情報に変化があるか否かがわかる。例えば、サーバとノード間のルートが、サーバの把握しているルート情報と同じか、そうでないかを検出することができる。

受信確認情報は、複数のノードで重畳してサーバに返信されるため、攻撃者（システムにとって第３者）による偽造が困難である。攻撃者が受信確認情報を偽造するためには、受信確認情報を重畳する全ノードの認証鍵を暴露する必要がある。

受信確認情報は複数のノードで重畳するため、不正な中継ノードが受信確認情報を偽造するためには、そのノードから下流の全ノードの認証鍵を暴露する必要がある。従って、下流に存在するノードの数が多いノード（例えば、サーバの近くに位置するルータノード）ほど、受信確認情報を偽造するのは困難である。

（Ｂ）第２の実施形態
次に、本発明によるメッセージ受信確認装置、システム及び方法の第２の実施形態を、図面を参照しながら説明する。

上述した第１の実施形態は、サーバのブロードキャストデータに対して、ノードが必ず受信確認情報を返すことを前提としたものであった。しかし、例えば、ノードの故障や、ノードが本来のあるべき場所に存在しないなどの理由で、受信確認情報を応答しない場合が想定される。

この第２の実施形態は、ルータノードが受信確認情報に、受信確認情報を得られなかった子ノードのＩＤを付加することで、サーバが、データが不達の可能性があるノードを検知することができるようにしたものである。

（Ｂ−１）第２の実施形態の構成
図８は、第２の実施形態のサーバ（ブロードキャストデータの送信者）１Ｂの構成を示すブロック図であり、第１の実施形態に係る図２との同一、対応部分には同一符号を付して示している。

第２の実施形態のサーバ１Ｂは、データ生成部１１、ノード情報管理部１２、受信確認情報検証部１３、不達ノードＩＤ管理部１６、送信部１４及び受信部１５を有する。第１の実施形態に比較すると、不達ノードＩＤ管理部１６が追加されており、また、受信確認情報検証部１３及び受信部１５の機能も多少異なっている。以下では、第１の実施形態と異なる構成要素について説明する。

第２の実施形態の受信確認情報検証部１３は、以下の点が、第１の実施形態の受信確認情報検証部と異なっている。

第２の実施形態の受信確認情報検証部１３には、受信部１５より０以上の不達ノードＩＤが付加された受信確認情報を与えられる。不達ノードＩＤ付き受信確認情報は、例えば、受信確認情報の後にノードＩＤが連結された形式をとっており、受信確認情報検証部１３では、予めシステムで設定されているピット長に従い、受信確認情報と、０以上の不達ノードＩＤとを抽出する。例えば、不達ノードのＩＤが存在する場合は、図１０のように、その不達ノードを含め、その不達ノードより下流のノードは届かなかったと認識し、図１０中の式２のように、ブロードキャストデータが到達したノードに係る情報だけを用いた演算を実行する。受信確認情報検証部１３での演算結果と、受信部１５より与えられた受信確認情報とが、一致するか否かにより、サーバ１Ｂがブロードキャストした正しいデータが、サーバ１Ｂが管理するノードの中で、不達ノードとそれより下流のノード以外に届いたか否かを把握できる。受信確認情報検証部１３は、検証結果が一致すると、不達ノードのＩＤを不達ノードＩＤ管理部１６へ与える。

不達ノードＩＤ管理部１６は、受信確認情報検証部１３より与えられる不達ノードＩＤを保持するものである。ここで、ＩＤを保持することは、ＩＤを保持する不達ノードと、それよりも下流のノードにはブロードキャストデータが正しく届いたか否かが分からないことを表している。

受信部１６は、隣接する管理下ノードから受信した０以上の不達ノードＩＤ付き受信確認情報を、受信確認情報検証部１３へ与えるものである。

図９は、第２の実施形態の各ノード（ブロードキャストデータの受信者）２Ｂの構成を示すブロック図であり、第１の実施形態に係る図３との同一、対応部分には同一符号を付して示している。

第２の実施形態のノード２Ｂは、受信データ保持部２１、自ノード認証鍵管理部２２、ＭＡＣ生成部２３、子ノード情報管理部２４、受信確認情報生成部２５、不達ノードＩＤ管理部２８、ノードＩＤ付加部２９、受信部２６及び送信部２７を有している。

以下では、第１の実施形態では存在しなかった不達ノードＩＤ管理部２８及びノードＩＤ付加部２９と、第１の実施形態における対応要素と機能が多少異なっている受信確認情報生成部２５、受信部２６及び送信部２７について説明する。

第２の実施形態の受信確認情報生成部２５については、第１の実施形態の受信確認情報検証部と異なるところについて説明する。第２の実施形態の受信確認情報生成部２５は、受信部２６より与えられる子ノードの受信確認情報に不達ノードＩＤが付加されている場合には、全ての不達ノードＩＤを取り除いたものを子ノードからの受信確認情報とする。不達ノードＩＤが付加された受信確認情報は、例えば、受信確認情報の後にノードＩＤがビット連結された形式をとっており、受信確認情報生成部２５は、予めシステムで設定されているビット長に従い、受信確認情報と、０以上の不達ノードＩＤとを抽出する。

また、受信確認情報生成部２５は、ある子ノードへブロードキャストデータを中継送信した時点から所定時間を経過しても、受信部２６からその子ノードの受信確認情報を与えられないと、ＭＡＣ生成部２３より与えられたＭＡＣと、受信部２６より既に与えられている０以上の受信確認情報を連結したものに対して、ハッシュ関数を施し、それを当該ノードの受信確認情報として、ノードＩＤ付加部２９へ与える。ここで、上述の所定時間は、例えば、システムに共通の値としても良く、子ノードがルータノードかエンドノードか等により各々値を変えて設定しても良い。

さらに、受信確認情報生成部２５は、受信部２６より与えられた受信確認情報に付加されている０以上の不達ノードＩＤと、受信部２６より受信確認情報を与えられなかった０以上の全ての子ノードのＩＤを、不達ノードＩＤ管理部２８へ与える。

不達ノードＩＤ管理部２８は、受信確認情報生成部２５より与えられる不達ノードＩＤを管理するものである。また、不達ノードＩＤ管理部２８は、受信確認情報生成部２５より不達ノードのＩＤを与えられることで、必要に応じて、その不達ノードのＩＤをノードＩＤ付加部２９へ与える。

ノードＩＤ付加部２９は、不達ノードＩＤ管理部２８より０以上の不達ノードのＩＤを与えられることで、受信確認情報生成部２５より与えられる当該ノードの受信確認情報に、不達ノードＩＤを付加して不達ノードＩＤ付き受信確認情報を生成するものであり、生成した不達ノードＩＤ付き受信確認情報を送信部２７へ与える。不達ノードＩＤ付受信確認情報の形式は、予めシステムで設定されている。

受信部２６は、サーバ１Ｂからのブロードキャストデータを受信データ保持部２１へ、また、子ノードからの０以上の不達ノードＩＤ付き受信確認情報を受信確認情報生成部２５へ与えるものである。

送信部２７は、ノードＩＤ付加部２９より与えられる０以上の不達ノードＩＤ付き受信確認情報を、自身の親ノード（親がサーバの場合はサーバ）に送信するものである。

（Ｂ−２）第２の実施形態の動作
次に、第２の実施形態のメッセージ受信確認システムの動作（メッセージ受信確認方法）を説明する。

第２の実施形態のメッセージ受信確認システムの動作も、大きくは、３段階の動作（Ｓ２０１〜Ｓ２０３）でなっている。

第１段階Ｓ２０１（図１１参照）
サーバ１Ｂは、データ生成部１１においてブロードキャストデータＸを生成し、送信部１４を通して管理下のノード２Ｂにブロードキャストする。

第２段階Ｓ２０２（図１２参照）
各ノード２Ｂは、受信部２６によって受信した、サーバ１Ｂからのブロードキャストデータを受信データ保持部２１に保持し、さらに、ＭＡＣ生成部２３において、受信データ保持部２１より与えられるサーバ１Ｂからのブロードキャストデータと、自ノード認証鍵管理部２２より与えられる当該ノードの認証鍵を入力して、受信データのＭＡＣを生成し、受信確認情報生成部２５へ与える。

各ノード２Ｂは、受信部２６より、子ノードからの不達ノードＩＤ付き受信確認情報が与えられることで、０以上の不達ノードＩＤを取り除いた受信確認情報を受信確認情報生成部へ与える。

各ノード２Ｂは、受信確認情報生成部２５において、子ノード情報管理部２４から与えられる情報より自身がエンドノードかルータノードかを判断する。そして、エンドノードである場合には、ＭＡＣ生成部２３より与えられるＭＡＣに対してハッシュ関数を施したハッシュ値を、自身の受信確認情報として、ノードＩＤ付加部２９へ与える。一方、自身がルータノードの場合には、受信部２６より全ての子ノードの受信確認情報が与えられることで、ＭＡＣ生成部２３より与えられるＭＡＣと、全ての子ノードの受信確認情報とを連結させたものに対して、ハッシュ関数を施したハッシュ値を、自身の受信確認情報として、ノードＩＤ付加部２９へ与える。但し、ある子ノードへブロードキャストデータを中継送信した時点から、所定時間経過しても、その子ノードからの受信確認情報が与えられないと、ＭＡＣ生成部２３より与えられるＭＡＣと既に与えられている０以上の受信確認情報とを連結させたものに対してハッシュ関数を施したハッシュ値を、自身の受信確認情報として、ノードＩＤ付加部２９へ与える。また、子ノードからの受信確認情報に不達ノードＩＤが付加されている場合には、若しくは、受信確認情報が与えられなかった子ノードが存在する場合は、それらノードＩＤを不達ノードＩＤ管理部２８へ与える。

各ノード２Ｂは、ノードＩＤ付加部２９において、不達ノードＩＤ管理部２８から０以上の不達ノードのＩＤが与えられることにより、受信確認情報生成部２５より与えられた当該ノードの受信確認情報に、不達ノードＩＤを付加して、不達ノードＩＤ付き受信確認情報を生成し、送信部２７から親ノードに送信する。

図１２において、例えば、ＩＤが「０２」のノードでは、「０４」の子ノードからの受信確認情報が所定時間経過しても届かないので、受信確認情報生成部２５は、ＭＡＣ生成部２３より与えられるＭＡＣと、既に与えられている他の全ての子ノード（ここでは「０５」のノードだけ）からの受信確認情報とを連結させたものに対してハッシュ関数を施したハッシュ値を、自身の受信確認情報として、ノードＩＤ付加部２９へ与え、ノードＩＤ付加部２９は、この受信確認情報（ハッシュ値）に、不達ノードＩＤ「０４」を連結させて、受信応答情報として送信部２７より親ノード（「０１」のノード）に送信させる。

また例えば、ＩＤが「０１」のノードでは、「０２」の子ノードからの受信確認情報は不達ノードＩＤ「０４」が付加されているので、不達ノードＩＤ「０４」と受信確認情報とを分離し、他方の「０３」の子ノードからの受信確認情報は所定時間経過しても届かないので、受信確認情報生成部２５は、所定時間の経過時に、ＭＡＣ生成部２３より与えられるＭＡＣと、既に与えられている他の全ての子ノード（ここでは「０２」のノードだけ）からの受信確認情報とを連結させたものに対してハッシュ関数を施したハッシュ値を、自身の受信確認情報として、ノードＩＤ付加部２９へ与え、ノードＩＤ付加部２９は、この受信確認情報（ハッシュ値）に、不達ノードＩＤ「０３」及び「０４」を連結させて、受信応答情報として送信部２７より親ノード（「０１」のノード）に送信させる。

第３段階Ｓ２０３（図１３参照）
サーバ１Ｂは、受信確認情報検証部１３において、受信部１５より与えられる０以上の不達ノードＩＤが付加された受信確認情報から、受信確認情報と全ての不達ノードＩＤを抽出する。

サーバ１Ｂは、受信確認情報検証部１３において、データ生成部１１より与えられるブロードキャストデータと、ノード情報管理部１２より与えられるノードＩＤ、ノード認証鍵、ルート情報と、抽出した不達ノードのＩＤより、隣接ノードから返信されるであろう受信確認情報を演算により求める。そして、演算により求めた受信確認情報と、受信部１５より与えられた隣接ノードからの受信確認情報が一致するかどうかを検証する。そして、一致という検証結果を得ることで、不達ノードＩＤ管理部１６において、不達ノードのＩＤを管理する。

（Ｂ−３）第２の実施形態の効果
第２の実施形態によっても、第１の実施形態と同様な効果を奏することができると共に、さらに、以下のような効果を奏することができる。

第２の実施形態によれば、サーバが、データが不達の可能性があるノードを検知することができる。

また、サーバは、自身のブロードキャストしたデータが、受信確認情報に付加されていたＩＤを持つノードとその下流のノード以外のノードに、正しく届けらたれか、そうでないかを認識することができる。

さらに、サーバは、受信確認情報に付加されていたＩＤを持つノードからの受信確認情報が、なんらかの理由で得られないか否かを認識することができる。例えば、故障や、不正に位置を変更されることによって、受信確認情報を応答しないノードの存在をサーバが検知することができる。

（Ｃ）他の実施形態
上記各実施形態の説明においても、種々変形実施形態に言及したが、さらに以下に例示するような変形実施形態を挙げることができる。

上記各実施形態では、説明の簡単化のため、サーバに隣接するノードが１つの場合で説明したが、この構成に限定されるものではない。サーバに複数のノードが隣接している場合でも、サーバは、それぞれの隣接ノードより受信した受信確認情報を検証するようにすれば良い。

また、上記各実施形態では、説明の簡単化のため、サーバとノード間には直接のリンクがある例で説明したが、この構成に限定するものではない。センサネットワークの形態としては、図１４のようにサーバとノード間にゲートウェイとなるノードが存在するのが一般的である。図１４中のゲートウェイノードを、上記各実施形態でのサーバのように、データを送信し受信確認情報を検証しても良いし、図１４中のサーバがゲートウェイノードを経由してノードにデータを送信し、ゲートウェイノードを経由して受信した受信確認情報を検証しても良い。

データ発信者と受信確認情報検証者が互いに信頼できる関係であり、それらの間にセキュアなルートが構築されていれば、データ発信者と受信確認情報検証者は同じ端末でなくても良い。例えば、図１４中のゲートウェイノードがデータを送信し、受信した受信確認情報をサーバで検証してもらい結果の報告を受けるようにしても良い。

上記各実施形態では、データをブロードキャストする場合を説明したが、マルチキャストする場合にも本発明を適用でき、この場合、第２の実施形態の不達ノード情報が、送信先ノードでないものだけを含んでいることを妥当と捉えるようにすることもできる。

第１の実施形態のメッセージ受信確認システムに係るネットワークの構成例を示すと共に、サーバが管理するノード情報の説明図である。 第１の実施形態のサーバの詳細構成を示すブロック図である。 第１の実施形態のノードの詳細構成を示すブロック図である。 第１の実施形態のサーバ内の受信確認情報検証部が実行する演算式の説明図である。 第１の実施形態のメッセージ受信確認システムの第１段階の動作の説明図である。 第１の実施形態のメッセージ受信確認システムの第２段階の動作の説明図である。 第１の実施形態のメッセージ受信確認システムの第３段階の動作の説明図である。 第２の実施形態のサーバの詳細構成を示すブロック図である。 第２の実施形態のノードの詳細構成を示すブロック図である。 第２の実施形態のサーバ内の受信確認情報検証部が実行する演算式の説明図である。 第２の実施形態のメッセージ受信確認システムの第１段階の動作の説明図である。 第２の実施形態のメッセージ受信確認システムの第２段階の動作の説明図である。 第２の実施形態のメッセージ受信確認システムの第３段階の動作の説明図である。 本発明のメッセージ受信確認システムを適用可能なネットワークの他の構成例を示す説明図である。

符号の説明

１、１Ｂ…サーバ、２、２Ｂ…ノード、１１…データ生成部、１２…ノード情報管理部、１３…受信確認情報検証部、１４…送信部、１５…受信部、１６…不達ノードＩＤ管理部、２１…受信データ保持部、２２…自ノード認証鍵管理部、２３…ＭＡＣ生成部、２４…子ノード情報管理部、２５…受信確認情報生成部、２６…受信部、２７…送信部、２８…不達ノードＩＤ管理部、２９…ノードＩＤ付加部。

Claims (30)

1. マルチホップ通信環境下で、メッセージ送信装置が、メッセージ受信装置に対して送信したメッセージの受信確認を得るメッセージ受信確認方法であって、
   メッセージ送信装置がメッセージを送信する第１の工程と、
   メッセージ受信装置がメッセージの受信証明情報を生成する第２の工程と、
   メッセージ受信装置が、メッセージの受信証明情報を利用してメッセージの受信確認情報を生成する第３の工程と、
   メッセージ受信装置がメッセージの受信確認情報を受信確認情報検証装置に送る第４の工程と、
   受信確認情報検証装置が受信した受信確認情報を検証する第５の工程と、
   メッセージ送信装置が、上記第５の工程による検証結果に基づいて、メッセージ受信装置に対するメッセージの受信確認を得る第６の工程と
   を含むことを特徴とするメッセージ受信確認方法。
2. 上記第２の工程は、メッセージ受信装置と受信確認情報検証装置とが共有する鍵を用いてメッセージの受信証明情報を生成することを特徴とする請求項１に記載のメッセージ受信確認方法。
3. 上記第２の工程は、メッセージ受信装置と受信確認情報検証装置とが共有する鍵を用いて、メッセージの受信証明情報として、メッセージに対するＭＡＣを生成することを特徴とする請求項２に記載のメッセージ受信確認方法。
4. 上記第３の工程は、０以上の他のメッセージ受信装置の受信確認情報と、自身の受信証明情報とから、受信確認情報を生成することを特徴とする請求項１〜３のいずれかに記載のメッセージ受信確認方法。
5. 上記第３の工程は、０以上の他のメッセージ受信装置の受信確認情報と自身の受信証明情報とを入力として、そのハッシュ値を生成して受信確認情報とすることを特徴とする請求項４に記載のメッセージ受信確認方法。
6. 上記第４の工程は、０以上の他のメッセージ受信装置の受信確認情報を受信した後に、自身の受信確認情報を受信確認情報検証装置に送ることを特徴とする請求項１〜５のいずれかに記載のメッセージ受信確認方法。
7. メッセージ受信装置が受信した受信確認情報を利用する上記他のメッセージ受信装置は、ツリー構造上で自身の子ノードであることを特徴とする請求項４〜６のいずれかに記載のメッセージ受信確認方法。
8. 上記第４の工程は、第４の工程を実行するメッセージ受信装置自身の受信確認情報に、０以上のノード識別情報を付加して、受信確認情報を受信確認情報検証装置に送ることを特徴とする請求項１〜７のいずれかに記載のメッセージ受信確認方法。
9. 自身の受信確認情報に付加するノード識別情報は、マルチホップ通信環境を提供するツリー構造上における自身の子ノードの中で受信確認情報を得なかった子ノードの識別情報であり、上記第３の工程は、自身の受信確認情報は、その子ノードが生成する受信確認情報を利用せずに生成していることを特徴とする請求項８に記載のメッセージ受信確認方法。
10. 上記第５の工程は、受信確認情報検証装置が受信確認情報を受信する前に、受信されると想定される受信確認情報を予め演算により求めておき、受信した受信確認情報と比較を行うことで、受信確認情報を検証することを特徴とする請求項１〜９のいずれかに記載のメッセージ受信確認方法。
11. 上記第５の工程は、受信した受信確認情報に付加されている０以上のノード識別情報より、それらノードを除外して受信されると想定される受信確認情報を演算により求め、受信した受信確認情報と比較を行うことで、受信確認情報を検証することを特徴とする請求項１０に記載のメッセージ受信確認方法。
12. 上記第５の工程を実行する受信確認情報検証装置は、受信確認を検証する全てのメッセージ受信装置と鍵を共有し、かつ、それらメッセージ受信装置の生成する受信確認情報がどのような経路で受信確認情報検証装置へ送られるかを把握しており、上記第５の工程は、それらメッセージ受信装置が受信確認情報を生成するのと同じ手順で、受信されると想定される受信確認情報を求めることを特徴とする請求項１１に記載のメッセージ受信確認方法。
13. 上記第６の工程を実行するメッセージ送信装置は、受信確認情報検証装置より、情報の改竄やなりすましのできない方式で、メッセージの受信確認を得ることを特徴とする請求項１〜１２のいずれかに記載のメッセージ受信確認方法。
14. 上記第６の工程は、メッセージの受信確認を得ると共に、メッセージの受信が確認できなかった０以上のメッセージ受信装置を検出することを特徴とする請求項１〜１３のいずれかに記載のメッセージ受信確認方法。
15. 上記受信確認情報検証装置とメッセージ送信装置とが同一であることを特徴とする請求項１〜１４のいずれかに記載のメッセージ受信確認方法。
16. マルチホップ通信環境下でメッセージ送信装置が送信したメッセージがメッセージ受信装置で受信されたか否かを表す、メッセージ受信装置が送信した受信確認情報を検証する検証用の通信端末装置であって、
    メッセージ受信装置の情報を管理する受信装置情報管理手段と、
    受信確認情報を受信する受信手段と、
    受信した受信確認情報を検証する検証手段と
    を有することを特徴とする通信端末装置。
17. 上記受信装置情報管理手段は、各メッセージ受信装置を識別する情報と、それら各メッセージ受信装置を認証するために、当該検証用の通信端末装置自身と各メッセージ受信装置が１対１で共有する認証鍵と、各メッセージ受信装置から当該検証用の通信端末装置自身への経路情報とを保持することを特徴とする請求項１６に記載の通信端末装置。
18. 上記検証手段は、送信されたメッセージと、各メッセージ受信装置の認証鍵と、経路情報とから、受信確認を検証する全てのメッセージ受信装置の認証鍵と、それら各メッセージ受信装置が生成する受信確認情報がどのような経路で自身へ送られるかとを把握し、それら各メッセージ受信装置が受信確認情報を生成するのと同じ手順で、受信すると想定される受信確認情報を演算により求め、受信した受信確認情報と一致するか否かを判断することを特徴とする請求項１７に記載の通信端末装置。
19. メッセージの受信が確認できなかったメッセージ受信装置の識別情報を管理する不達受信装置情報管理手段を有することを特徴とする請求項１６〜１８のいずれかに記載の通信端末装置。
20. マルチホップ通信環境下で、メッセージ送信装置が送信したメッセージを受信し、受信したときに受信確認情報を生成するメッセージ受信装置が該当する通信端末装置であって、
    メッセージを受信する受信手段と、
    メッセージの受信証明情報を生成する受信証明情報生成手段と、
    隣接する通信端末装置の情報を管理する隣接装置情報管理手段と、
    メッセージの受信確認情報を生成する受信確認情報生成手段と、
    受信確認情報を送信する受信確認情報送信手段と
    を有することを特徴とする通信端末装置。
21. 上記受信証明情報生成手段は、受信したメッセージと、自身が受信確認情報検証側の通信端末装置と共有する鍵を用いて、メッセージの受信証明情報を生成することを特徴とする請求項２０に記載の通信端末装置。
22. 上記受信証明情報生成手段は、自身と受信確認情報検証装置が共有する鍵を用いて、メッセージに対するＭＡＣを、メッセージの受信証明情報として生成することを特徴とする請求項２１に記載の通信端末装置。
23. 上記隣接装置情報管理手段は、マルチホップ通信環境を提供するツリー構造において、自身がエンドノードであるかルータノードであるかを把握することを可能とし、自身の子ノードとなるメッセージ受信装置の識別情報と、そのノードがルータノードかエンドノードかを管理することを特徴とする請求項２０〜２２のいずれかに記載の通信端末装置。
24. 上記受信確認情報生成手段は、０以上の他のメッセージ受信装置の受信確認情報と、自身の受信証明情報とから、メッセージの受信確認情報を生成することを特徴とする請求項２０〜２３のいずれかに記載の通信端末装置。
25. 上記受信確認情報生成手段は、０以上の他のメッセージ受信装置の受信確認情報と、自身の受信証明情報とを入力として、そのハッシュ値を、メッセージの受信確認情報として生成することを特徴とする請求項２４に記載の通信端末装置。
26. 上記受信確認情報生成手段が、メッセージの受信確認情報の生成に用いる、０以上の他のメッセージ受信装置の受信確認情報は、マルチホップ通信環境を提供するツリー構造において、自身の子ノードであるメッセージ受信装置が生成したものであることを特徴とする請求項２４又は２５に記載の通信端末装置。
27. 他のメッセージ受信装置に係るノード識別情報を付加するノード識別情報付加手段を有することを特徴とする請求項２０〜２６のいずれかに記載の通信端末装置。
28. 上記ノード識別情報付加手段は、自身の受信確認情報に、０以上のノード識別情報を付加して送ることを特徴とする請求項２７に記載の通信端末装置。
29. 上記ノード識別情報付加手段が自身の受信確認情報に付加する０以上のノード識別情報は、マルチホップ通信環境を提供するツリー構造において、自身の子ノードであるメッセージ受信装置の中で、自身が、受信確認情報を得ることができなかった子ノードの識別情報であることを特徴とする請求項２８に記載の通信端末装置。
30. 請求項１６〜１９のいずれかの検証用の通信端末装置と、請求項２０〜２９のいずれかに記載のメッセージ受信装置が該当する通信端末装置とを有することを特徴とするメッセージ受信確認システム。
    
    

Images