無線ネットワークにおいて機密データを安全にブロードキャストするための方法
本発明は、トラストセンターと呼ばれる中央装置と複数のセンサノードを有する無線センサネットワークにおいて機密データを安全にブロードキャストするための方法に関し、トラストセンターは暗号学的ハッシュチェインで初期化され、各ノードはノード鍵とトラストセンターハッシュチェインのアンカーで初期化され、方法は以下のステップを有する：トラストセンターが第１の安全なメッセージをノードへブロードキャストするステップ、各ノードが第１のメッセージの受信後に第１の確認応答メッセージを作り、それをトラストセンターへ送り返すステップ、トラストセンターが、全ノードが各自の第１の確認応答メッセージを送信したかどうかをチェックするステップ、及び全メッセージが受信されている場合、トラストセンターが機密データを第３のメッセージにおいて安全にブロードキャストするステップ、ノードが、第１のメッセージに含まれるエレメントに基づいて、機密データが実際にトラストセンターから来ているかどうかをチェックするステップ。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、無線ネットワーク、より具体的には無線センサネットワークにおけるデータの安全なブロードキャストを保証するための方法に関する。
【０００２】
本発明は、例えば同種のネットワークにおいて無線ソフトウェア更新を保証することに関する。
【背景技術】
【０００３】
無線センサネットワーク（ＷＳＮ）、例えばＺｉｇＢｅｅ（登録商標）ネットワークは、無線リンクを通して通信する多数の資源制約型センサ及びアクチュエータを有する。これらの装置は、例えばパワー、メモリ、若しくは伝送速度に関して制約される。ＷＳＮは患者モニタリング、ホームオートメーション、スマートエネルギー、若しくは照明システムなどの多くの用途で使用される。これら全ての用途において、ネットワークのトラストセンターから異なるノードへ安全にデータを送信する機会を得ることは極めて有用である。実際、こうした機会は、例えば追加アプリケーションを含む、問題を解く、又はより効率的なプロトコルを導入するために、異なるノード上で実行しているソフトウェアを更新することを可能にする。同種のネットワークにおいて、展開されたネットワークに対する影響を最小限にしながら、新たなソフトウェアが時々インストールされることができることは高度に有利である。
【０００４】
しかしながら、ネットワーク上の安全なデータブロードキャストのための既存の方法は、以下を課す無線センサネットワークの特定の要件を満たすことができない：
‐帯域幅の量の低減、エネルギー及びＣＰＵに関するセンサノードの資源制約的特性、ネットワークの分散特性、及び関連する操作要件など、同種のネットワークの特定の物理的要件を管理し、
‐同時に、ソフトウェア更新について話すときの重要な特徴である、高レベルの安全性を維持する。実際、攻撃者がノードに偽物のソフトウェアをどうにか入れようとする場合は、ネットワーク全体を制御し得ることになり、重要な情報を読み出し、又は予測不可能な結果を伴うサービス妨害攻撃を実行する。
【０００５】
既存の方法は、例えば、所要セキュリティレベルを得ることを可能にする公開鍵暗号方式の使用を含む。実際、かかる方法において、無線センサネットワークの基地局はブロードキャストする前にその公開鍵で新たなソフトウェア更新に署名する。そしてネットワーク内のノードは署名の真正性をチェックすることによってソフトウェアの起源を検証することができる。しかしながら、これらの方法はセンサネットワークにとって計算コストが高過ぎる。加えて、これらは根底にあるセキュリティプリミティブ及びプロトコルのための追加メモリを要する。さらに、ソフトウェア更新のための安全なプロトコルは予測されるシステムオペレーションに適合しなければならない。それはセンサノードと無線接続が高いストレージ要件又は送信オーバーヘッドに悩まされてはならないことを意味する。
【発明の概要】
【発明が解決しようとする課題】
【０００６】
本発明の目的は、上述の欠点を克服する、無線ネットワークでデータを安全にブロードキャストするための方法を提案することである。
【０００７】
より正確には、本発明の目的はネットワークの物理的及びセキュリティ要件を順守しながらデータをブロードキャストするための方法を提案することである。
【０００８】
本発明の別の目的は、安全にソフトウェアネットワーク無線を実行するための方法を提供することである。
【０００９】
本発明のさらに別の目的は、ソフトウェア更新が実際に開始するまで低いストレージ要件を保証するソフトウェア更新プロトコルを提供することである。
【００１０】
本発明のさらに別の目的は、ソフトウェアの更新時にノードのメモリ全体を書き換えるのを避けるためにメモリを管理するための方法を提供することである。
【００１１】
本発明のさらに別の目的は、通信を保証し、ソフトウェア更新を送信し、ソフトウェアの安全なアクティベーションを実行するための完全なプロトコルを提案することである。
【００１２】
本発明のさらに別の目的は、期待されるプロコル操作を妨げる非協調ノード、例えば危殆化（ｃｏｍｐｒｏｍｉｓｅｄ）ノードを見つけ出すための方法を提供することである。
【課題を解決するための手段】
【００１３】
このために、本発明はトラストセンターと呼ばれる中央装置と複数のセンサノードを有する無線センサネットワークにおいて機密データを安全にブロードキャストするための方法を提案し、トラストセンターは暗号学的ハッシュチェインで初期化され、各ノードはノード鍵とトラストセンターハッシュチェインのアンカーで初期化され、方法は以下のステップを有する：
‐トラストセンターが第１の安全なメッセージをノードへブロードキャストするステップ、
‐各ノードが第１のメッセージの受信後に第１の確認応答メッセージを作り、それをトラストセンターへ送り返すステップ、
‐トラストセンターが、全ノードが各自の第１の確認応答メッセージを送信したかどうかをチェックするステップ、及び全メッセージが受信されている場合、
‐トラストセンターが機密データを安全にブロードキャストするステップ、
‐ノードが、第１のメッセージに含まれるエレメントに基づいて、機密データが実際にトラストセンターから来ているかどうかをチェックするステップ。
【００１４】
提案されるプロトコル、若しくは方法は、トラストセンターによって所有されるハッシュチェインを含む。このハッシュチェインは完全に非同期形式で将来のソフトウェア更新を公開するために使用される。第１のステップにおいて、トラストセンターは更新を公開し、全ノードは、受信したｐｒｅ‐ＭＡＣが正しいことを、それが未知値のハッシュチェインと一緒に公開されると、確認することができる。第２のステップにおいて、トラストセンターは全ノードが正しいｐｒｅ‐ＭＡＣを得たことを、ノードがＡＣＫで応答すると、確認する。全ノードが第１のメッセージを得たことをトラストセンターが検証すると、トラストセンターは更新されるべきソフトウェアを公開する。ノードは既にｐｒｅ‐ＭＡＣを得ているのでソフトウェアを検証することができる。
【００１５】
こうしたアプローチは、メッシュ及びツリールーティングプロトコルなどの多数のルーティングプロトコルに有効である。メッシュルーティングプロトコルにおいて、トラストセンターは複数のルータから複数の結合されたｐｒｅ‐ＡＣＫを取得し得る。ツリーベースルーティングプロトコルにおいて、トラストセンターは木のレベル１におけるノードから結合されたｐｒｅ‐ＡＣＫのみを取得する。ほとんどの実施形態において、レベル１におけるルータはレベル１＋１におけるノード若しくはルータから来る確認メッセージを集約する。
【００１６】
さらに、ネットワークがネットワーク鍵によって保護される場合、ソフトウェア更新のための全通信はネットワーク鍵を用いて保護されるはずである。これは外部攻撃者が偽造情報を導入することを防ぐ。
【００１７】
本発明の一実施形態において、ネットワークは複数のノードに接続されるルータ装置をさらに有し、ノードが第１の確認応答メッセージをトラストセンターへ送信するステップは、
‐各ノードが第１の確認応答メッセージをルータ装置へ送信するステップと、
‐ルータ装置がメッセージを結合して完全な第１の確認応答メッセージを作るステップと、
‐ルータ装置が完全な第１の確認応答メッセージをトラストセンターへ送信するステップとを有する。
【００１８】
結合されたＡＣＫの使用は通信オーバーヘッドを減らす。トラストセンターが誤ったメッセージを取得する場合、プロトコルは非協調ノードを発見する能力を含む。このため、トラストセンターは誤ったノードを見つけるためにネットワークを分割する。例えば図１に描かれるネットワークを仮定し、結合されたｐｒｅ‐ＡＣＫが有効でないと仮定すると、トラストセンターは誤った動作を導入しているネットワークの部分を見つけ出すことができるように、ルータ１及びルータ２にそれらの結合されたｐｒｅ‐ＡＣＫをトラストセンターへ直接送信するように要求し得る。このアプローチは二分探索を適用することによってさらに拡張されることができる。
【００１９】
本発明の好適な実施形態において、送信されるべきデータが大きい場合、通信オーバーヘッドを最小化するためにマークル木が使用される。マークル木は以下のように構築される。
‐機密データが複数のサブセットに分割される。
‐各サブセットのハッシュ関数が計算される。
‐各サブセットのハッシュ関数はハッシュ木の葉とみなされ、ハッシュ木のノードとルートを導き出す。
【００２０】
かかる場合において、方法は次の通りである。
‐第１のメッセージをノードへブロードキャストするステップは、ハッシュ木のルートをブロードキャストするステップを有する。
‐機密データをブロードキャストするステップはハッシュ木のノードとルートを送信するステップを有する。
【００２１】
機密データをブロードキャストするステップは、ノードが機密データを完成させるメッセージを受信することを確認するだけでよいので、長期間にわたって実行されることができることがここで留意され得る。
【００２２】
別の実施形態において、機密データをブロードキャストするステップは、以前に送信された機密データと比較して変更による影響を受けているハッシュ木のノードのみをブロードキャストするステップを有する。
【００２３】
別の実施形態において、第１のメッセージは、
‐次のエレメントと呼ばれる、最後に送信されたエレメントの直後に位置するトラストセンターハッシュチェインのエレメントと、
‐最後に送信されたハッシュチェインのエレメントと連結された、ブロードキャストされるべき機密データのハッシュ関数とを有する。
【００２４】
別の実施形態において、送信されるべき機密データはソフトウェア若しくはソフトウェア更新のコードイメージに対応する。
【００２５】
別の実施形態において、方法は、ソフトウェアを均一にアクティベートするためのメッセージをノードへブロードキャストする、トラストセンターに対する最終ステップを有する。
【００２６】
本発明のさらに別の実施形態において、ノードのメモリはメモリページに分割され、方法は、機密データをメモリページの長さよりも短い複数のデータサブセットに分割する初期ステップを有する。
【００２７】
本発明のこれらの及び他の態様は以下に記載の実施形態から明らかとなり、それらを参照して解明される。
【００２８】
本発明は添付の図面を参照して一例としてより詳細に記載される。
【図面の簡単な説明】
【００２９】
【図１】本発明にかかる方法を実行するネットワークをあらわす。
【図２】マークル木を示す。
【図３】安全な増分ソフトウェア更新を示す。
【発明を実施するための形態】
【００３０】
本発明は図１に示される無線センサネットワークにおいてソフトウェアを安全にブロードキャストするための方法に関する。
【００３１】
このネットワークは基地局１、すなわちトラストセンター、及び資源制約型ノード（ノード１、ノード２、ノード３…ノード６）を有する。
【００３２】
トラストセンターはシステムセキュリティを管理し、センサノードに対する新たなソフトウェアイメージを受信し検証する能力を持つ。トラストセンターと資源制約型ノードとの間の通信は、ルーティングプロトコル、例えばメッシュ若しくはツリーベースプロトコルを用いることによって実行される。かかる場合、ネットワークはトラストセンターとノードとの間で通信を中継するためのルータ（ルータ１、ルータ２及びルータ３）も有する。
【００３３】
本発明にかかるネットワークにおいて実行される通信プロトコルは、以下のようにネットワークの異なる装置の初期化を必要とする：
‐トラストセンターは
であるようなハッシュチェイン
を有する。値
はそれぞれこのハッシュチェインのシードとアンカーである。
‐ノード鍵が各ノードに割り当てられ、各鍵Ｋｊはトラストセンターとノードｊの間で共有される鍵である。
‐各ノードもまたトラストセンターハッシュチェインのアンカーで初期化される。この機密もまたシステムオペレーション中にトラストセンターからノードの各々へ安全に送信されることができる。
【００３４】
ノードのメモリの初期化がさらに詳述される。
【００３５】
機密データＭの送信が完全なソフトウェア更新に対応する場合、プロトコルは次の３フェーズを有する：
‐第１フェーズにおいて、トラストセンターは、ネットワークの全ノードが新たなソフトウェア更新のための有効な署名を受信したことを確認する。この署名はメッセージの起源を認証するためにノードによって使用される。
‐第２フェーズにおいて、新たなソフトウェアがネットワーク内の全ノードへ向かって安全にブロードキャストされる。
‐第３フェーズにおいて、同期され認証された方法でソフトウェアがアクティベートされる。
【００３６】
一実施形態において、フェーズの各々はハッシュチェインエレメントを用いて署名される。
【００３７】
第１フェーズは、トラストセンターがソフトウェア署名のための有効な署名を送信し、全ノードがそれを正しく受信したかどうかをチェックすることにある。
【００３８】
従って、第１ステップにおいて、トラストセンターはトラストセンターハッシュチェインの次のエレメント
と、同じハッシュチェインの次のエレメント
と連結される新たなコードイメージＭのハッシュを含むメッセージをブロードキャストする。この最後のエレメントは受信したｐｒｅ‐ＭＡＣ（すなわちハッシュ）がよいものであり、誰もそれを変更していないことを確認するためにノードによって使用される。
【００３９】
本発明の意味の範囲内では、"次のエレメント"はチェインのシード（若しくはルート）へ向かうときにハッシュチェイン内の現在のエレメントの直後に位置するエレメントを指定する。
【００４０】
そして、第２ステップにおいて、ノードは、メッセージ１の受信後、ｐｒｅ‐ａｃｋ Ｐｒｅ‐ＡＣＫｊ＝ｈａｓｈ（Ｋｊ｜｜Ｍｅｓｓａｇｅ１）を作る。ノードは受信メッセージが有効な
と一緒に送信された場合のみｐｒｅ‐ａｃｋを作る。ｐｒｅ‐ａｃｋはメッセージ１をＫｊで暗号化することによって作られることもできる。
【００４１】
特定の実施形態において、ノードはｐｒｅ‐ａｃｋメッセージをトラストセンターへ直接送信せずにルータへ送信し、そしてこれは複数の端末装置からの複数のｐｒｅ‐ａｃｋを結合し、他のルータへ若しくはトラストセンターへ直接送信されるべき結合されたｐｒｅ‐ａｃｋを作る。
【００４２】
この場合、ノードはルータへメッセージ２．１を送信する：
ｐｒｅ‐ＡＣＫｊ＝ｈａｓｈ（Ｋｊ｜Ｍｅｓｓａｇｅ１）
【００４３】
ルータは以下の通り異なるメッセージを結合する：
ｈａｓｈ（Ｐｒｅ‐ＡＣＫｊ１｜Ｐｒｅ‐ＡＣＫｊ２｜…｜Ｐｒｅ‐ＡＣＫｊＭ），ｊ１，ｊ２，…，ｊＭ
【００４４】
ｐｒｅ‐ａｃｋが暗号化関数を用いて作られる場合、結合されたｐｒｅ‐ａｃｋもまたルータの鍵でｐｒｅ‐ａｃｋを暗号化することによって作られることができる。さらなるアプローチは同型暗号プリミティブの使用に言及する。
【００４５】
第３ステップにおいて、トラストセンターは全ノードがｐｒｅ‐ＭＡＣの受信を確認したかどうかをチェックする。このチェックは前述の通り第１フェーズを完了する。
【００４６】
プロトコルの第２フェーズはソフトウェア自体のブロードキャストに対応する。トラストセンターは全ノードによる正しい受信をチェックしたので、トラストセンターはトラストセンターハッシュチェインの次のエレメントと一緒にメッセージを公開する。
【００４７】
従ってメッセージ３は次の通りである：
ノードは
を所有するので、受信メッセージがトラストセンターによって作られたかどうかをチェックすることができる。従って、ノードはメッセージを安全に扱うことができ、例えばメッセージが実際に１本のソフトウェアのコードイメージをあらわす場合、ノードはそのソフトウェアをインストールすることができる。
【００４８】
いくらかのタイムアウト後にノードから何の確認も受信されていない場合、プロトコルは例外モードに入り、確認をしたノードで続行する。誤った値が見つかる場合、システムは続けて、さらに記載される方法を実行することによって動作のおかしいノードを見つけ出すことができる。
【００４９】
メッセージ３の受信後、ノードは確認応答メッセージＡＣＫｊ＝ｈａｓｈ（Ｍｅｓｓａｇｅ３｜Ｋｊ）を作り、それをトラストセンターへ直接若しくはルータを介して送り返す。ルータが使用される場合、ルータは複数のＷＳＮノード（若しくは端末装置）から複数のＡＣＫを結合し、結合されたＡＣＫを作る。ルータはそれを他のルータへ若しくはトラストセンターへ直接送信する。
ｈａｓｈ（ＡＣＫｊ１｜ＡＣＫｊ２…｜ＡＣＫｊＭ），ｊ１，ｊ２，…，ｊＭ
【００５０】
いくつかの実施形態において、メッセージ３は非常に大きくなり得る。従ってその場合ノードは代わりに、メッセージ１がメッセージ３のフィンガープリントであるため、ＡＣＫｊ＝ｈａｓｈ（Ｍｅｓｓａｇｅ１｜Ｋｊ）を送信し得る。ノードはまたＡＣＫｊ＝ｈａｓｈ（Ｍｅｓｓａｇｅ３ｆｉｒｓｔ ｂｙｔｅｓ｜Ｋｊ）も送信し得、Ｍｅｓｓａｇｅ３ｆｉｒｓｔ ｂｙｔｅｓはメッセージ３の第１バイトをあらわす。
【００５１】
そして、機密データが各ノードへ正しく送信され、確認応答メッセージが送り返された後、プロトコルのフェーズ２が完了する。
【００５２】
方法の第３フェーズは、送信データのタイプに依存するため、完全に任意である。ソフトウェア更新の場合、トラストセンターは新たなソフトウェアを均一にアクティベートするためにネットワーク内の全ノードへ安全なブロードキャストメッセージを送信し得る。
【００５３】
このメッセージが、異なるソフトウェアバージョンでネットワーク内のノードを取得しようとすることによってサービス妨害攻撃を実行しようとする攻撃者ではなく、トラストセンターによって送信されることを確認するために、トラストセンターはこの値と一緒にハッシュチェインの次の値
を公開する。このようにして、ノードがアクティベーションメッセージを得る場合、ノードは最初に付属のハッシュ値が正しいことを検証する。２つのノードが互いに通信し合う場合、さらにそれらのソフトウェアバージョンを検証することができる。それらが異なる場合、最新のソフトウェアバージョンを持つノードがソフトウェアアクティベーションメッセージを第二者へ転送し得る。第２のノードは上述の通りメッセージの妥当性を検証することができる。
【００５４】
本明細書に記載の完全なプロトコルは、ネットワーク内のトラストセンターが、メッセージがネットワーク内の全ノードによって安全に受信されることを確認することを可能にする。しかしながらソフトウェア更新の場合、前述の通り、このメッセージは非常に大きくなり得るので、通信オーバーヘッドにつながり得る。この問題を解決するために、本発明の特定の実施形態において、図２に示す通り、マークル木若しくはハッシュ木を使用することが決まっている。この木は以下のように構築される：
ソフトウェア若しくはソフトウェア更新のコードイメージが異なるページ（ページ１，ページ２…ページＰ）に分割され、異なるメモリ空間に保存される。
トラストセンターはメモリページの各々のハッシュ関数の計算を実行する；これらの値はマークル木の葉をあらわす。
そしてトラストセンターはマークル木のルートＭを計算する。
【００５５】
そしてマークル木を用いるソフトウェア更新のための方法は、以下の修正を伴って前述のものと同様である：
メッセージ１において、Ｍはメッセージ全体ではなく、マークル木のルートのみである。
メッセージ３において、木のルートはマークル木の全ノードと一緒に公開される。従って、木の中の全ノードが公開される場合、トラストセンターは新たなソフトウェアをブロードキャストすることができる。ノードは公開されたソフトウェア更新から作られるマークル木がマークル木のルートに一致することを検証した後にＡＣＫで応答する（メッセージ３において公開され、ｐｒｅ‐ＭＡＣを用いて検証される）。
【００５６】
こうしたアプローチは、システムが、マークル木のルートの安全な公開を可能にする上記セクションで記載されたメッセージで容易に拡張されることができるので、ＺｉｇＢｅｅ（登録商標）センサネットワークなどの無線センサネットワークにとって高度に有利である。ソフトウェア更新のメッセージの残りは既存プリミティブを用いることによって公開されることができる。
【００５７】
ＷＳＮなどの無線ネットワークにおいて、ソフトウェアは増分更新で定期的に更新される。こうした更新はネットワーク内の情報ブロードキャストの量の削減を可能にする。しかしながら、このアプローチはノード側でのソフトウェアの認証及び検証に関しては主要な欠点を提示する。実際、ソフトウェア更新は一般にコード若しくはコードのイメージの１つ若しくは複数の部分のわずかな変更にある。こうした変更は、わずかであっても、ノードのメモリページの全てに対する変更につながる。従って、受信データを検証するために、各ページごとに更新ハッシュ関数を計算し、そして更新されたルートを得るために木全体を再計算する必要がある。この重い計算は１ページずつベースで構築される既存認証スキームの性能の低下につながる。さらに、このアプローチはメモリ全体を書き換えることを必要とし、これは推奨されない。
【００５８】
この問題を克服するために、本発明の一実施形態において、ノードのメモリはＢ‐バイト長ページに分割されるが、情報はＢ'＜Ｂバイトにのみ保存される。
【００５９】
ここで、第１及び第２のページにおいて数バイトが変更されるソフトウェア更新が必要とされると仮定する。システムがＢ'バイトのバッファを含まなかった場合、変化は伝搬し得るのでメモリ全体が更新される必要がある。Ｂ'のバッファを持つことは、図３に見られる通り変更が局所領域に制限されるため、これを克服する。
【００６０】
同様に、プログラムコードがＭＡＣ、セキュリティなどに関連する複数のアプリケーションとソフトウェアを有する場合は、メモリを複数のアプリケーションセクションへ分割し得る。これらのアプリケーションの各々を保存するために使用されるページは上記の通り構成され得るが（Ｂ'バイトのバッファを持つＢバイトのページ)、さらに単独アプリケーションを更新するときのメモリ変化を最小限にするためにアプリケーション間に２〜３の空ページも含む。
【００６１】
本発明の文脈において、こうしたメモリ管理は、数ページのみが変更されるので、従ってマークル木のノードの一部しか再送される必要がないという主要な利点において高度に有利である。システムオペレーションは以下の通りである。まず、トラストセンターが第１フェーズにおける前記ステップに従い、メッセージのハッシュ（すなわちメモリ全体）を安全に公開する。そして、トラストセンターは増分メモリ更新を可能にする部分更新を公開する。第３に、ノードは公開されたメッセージに従ってそのメモリを再構築する。これは再プログラミング前に外部メモリにおいてなされるべきである。一旦これがなされると、ノードは得られるコードがマークル木構造を用いて同じ公開されたマークル木ルートとなるかどうかをチェックする。
【００６２】
方法の説明において、時々、いくつかのノードが第１のｐｒｅ‐Ｍａｃメッセージに応答してｐｒｅ‐ａｃｋメッセージを送り返さないということが起こり得ることが言及されている。これらのノードは従って非協調的とみなされるが、これらは危殆化の可能性もある。こうした場合、他のネットワークエレメントのさらなる危殆化を避けるために、危殆化エレメントを検出するための特徴を提供することが有用である。
【００６３】
危殆化ノードを検出することは、特に図１に示すようにノードとトラストセンターとの間の通信がルータを介して中継される場合、あまり容易でない。実際、たった１つのノードが誤ったＡＣＫ若しくはｐｒｅ‐ＡＣＫを作る場合、ルータは誤った結合されたＡＣＫ若しくはｐｒｅ‐ＡＣＫを作ることになる。トラストセンターはＡＣＫ及びｐｒｅ‐ＡＣＫを検証しようとし得るが、結合された値の生成に使用されるいかなる誤った値も最終結果を変更するので、これは失敗する。
【００６４】
この問題を克服するために、本発明の一実施形態において、非協調ノードを見つけ出すために、トラストセンターは結合されたＡＣＫ若しくはｐｒｅ‐ＡＣＫに寄与するノードを複数のセグメントに分割する。このために、基地局（若しくはトラストセンター）は関係するルータへ要求を送信する。ルータは各セグメントにおいてノードからＡＣＫ若しくはｐｒｅ‐ＡＣＫを収集する。そのようにして、トラストセンターはどのセグメントが正しく動作しどれが正しく動作しないかを見つけ出すことができる。トラストセンターはさらに危殆化した若しくは動作のおかしいノードを正確に決定するために二分探索を実行することができる。
【００６５】
従って、本発明において開示された異なる特徴の組み合わせは、ＷＳＮのセンサノードの物理的制約を考慮しながら、安全に無線でソフトウェアを更新するための方法を提供することを可能にする。
【００６６】
本発明は特に、医療センサネットワーク、照明システム、スマートエネルギー、ビルオートメーション、若しくは分散システムとセンサネットワークを含む任意の他の用途を専用とする。
【００６７】
本願の明細書及び請求項において、ある要素に先行する"ａ"若しくは"ａｎ"という語はかかる要素の複数の存在を除外しない。さらに、"有する"という語は列挙されたもの以外の要素若しくはステップの存在を除外しない。
【００６８】
請求項における括弧内の参照符号の包含は理解を助ける意図であり限定する意図ではない。
【００６９】
本開示の読解から、他の変更が当業者に明らかとなる。こうした変更は、無線センサネットワーク制御の分野において既知であり、本明細書に既に記載の特徴の代わりに若しくは加えて使用され得る他の特徴を含み得る。
【技術分野】
【０００１】
本発明は、無線ネットワーク、より具体的には無線センサネットワークにおけるデータの安全なブロードキャストを保証するための方法に関する。
【０００２】
本発明は、例えば同種のネットワークにおいて無線ソフトウェア更新を保証することに関する。
【背景技術】
【０００３】
無線センサネットワーク（ＷＳＮ）、例えばＺｉｇＢｅｅ（登録商標）ネットワークは、無線リンクを通して通信する多数の資源制約型センサ及びアクチュエータを有する。これらの装置は、例えばパワー、メモリ、若しくは伝送速度に関して制約される。ＷＳＮは患者モニタリング、ホームオートメーション、スマートエネルギー、若しくは照明システムなどの多くの用途で使用される。これら全ての用途において、ネットワークのトラストセンターから異なるノードへ安全にデータを送信する機会を得ることは極めて有用である。実際、こうした機会は、例えば追加アプリケーションを含む、問題を解く、又はより効率的なプロトコルを導入するために、異なるノード上で実行しているソフトウェアを更新することを可能にする。同種のネットワークにおいて、展開されたネットワークに対する影響を最小限にしながら、新たなソフトウェアが時々インストールされることができることは高度に有利である。
【０００４】
しかしながら、ネットワーク上の安全なデータブロードキャストのための既存の方法は、以下を課す無線センサネットワークの特定の要件を満たすことができない：
‐帯域幅の量の低減、エネルギー及びＣＰＵに関するセンサノードの資源制約的特性、ネットワークの分散特性、及び関連する操作要件など、同種のネットワークの特定の物理的要件を管理し、
‐同時に、ソフトウェア更新について話すときの重要な特徴である、高レベルの安全性を維持する。実際、攻撃者がノードに偽物のソフトウェアをどうにか入れようとする場合は、ネットワーク全体を制御し得ることになり、重要な情報を読み出し、又は予測不可能な結果を伴うサービス妨害攻撃を実行する。
【０００５】
既存の方法は、例えば、所要セキュリティレベルを得ることを可能にする公開鍵暗号方式の使用を含む。実際、かかる方法において、無線センサネットワークの基地局はブロードキャストする前にその公開鍵で新たなソフトウェア更新に署名する。そしてネットワーク内のノードは署名の真正性をチェックすることによってソフトウェアの起源を検証することができる。しかしながら、これらの方法はセンサネットワークにとって計算コストが高過ぎる。加えて、これらは根底にあるセキュリティプリミティブ及びプロトコルのための追加メモリを要する。さらに、ソフトウェア更新のための安全なプロトコルは予測されるシステムオペレーションに適合しなければならない。それはセンサノードと無線接続が高いストレージ要件又は送信オーバーヘッドに悩まされてはならないことを意味する。
【発明の概要】
【発明が解決しようとする課題】
【０００６】
本発明の目的は、上述の欠点を克服する、無線ネットワークでデータを安全にブロードキャストするための方法を提案することである。
【０００７】
より正確には、本発明の目的はネットワークの物理的及びセキュリティ要件を順守しながらデータをブロードキャストするための方法を提案することである。
【０００８】
本発明の別の目的は、安全にソフトウェアネットワーク無線を実行するための方法を提供することである。
【０００９】
本発明のさらに別の目的は、ソフトウェア更新が実際に開始するまで低いストレージ要件を保証するソフトウェア更新プロトコルを提供することである。
【００１０】
本発明のさらに別の目的は、ソフトウェアの更新時にノードのメモリ全体を書き換えるのを避けるためにメモリを管理するための方法を提供することである。
【００１１】
本発明のさらに別の目的は、通信を保証し、ソフトウェア更新を送信し、ソフトウェアの安全なアクティベーションを実行するための完全なプロトコルを提案することである。
【００１２】
本発明のさらに別の目的は、期待されるプロコル操作を妨げる非協調ノード、例えば危殆化（ｃｏｍｐｒｏｍｉｓｅｄ）ノードを見つけ出すための方法を提供することである。
【課題を解決するための手段】
【００１３】
このために、本発明はトラストセンターと呼ばれる中央装置と複数のセンサノードを有する無線センサネットワークにおいて機密データを安全にブロードキャストするための方法を提案し、トラストセンターは暗号学的ハッシュチェインで初期化され、各ノードはノード鍵とトラストセンターハッシュチェインのアンカーで初期化され、方法は以下のステップを有する：
‐トラストセンターが第１の安全なメッセージをノードへブロードキャストするステップ、
‐各ノードが第１のメッセージの受信後に第１の確認応答メッセージを作り、それをトラストセンターへ送り返すステップ、
‐トラストセンターが、全ノードが各自の第１の確認応答メッセージを送信したかどうかをチェックするステップ、及び全メッセージが受信されている場合、
‐トラストセンターが機密データを安全にブロードキャストするステップ、
‐ノードが、第１のメッセージに含まれるエレメントに基づいて、機密データが実際にトラストセンターから来ているかどうかをチェックするステップ。
【００１４】
提案されるプロトコル、若しくは方法は、トラストセンターによって所有されるハッシュチェインを含む。このハッシュチェインは完全に非同期形式で将来のソフトウェア更新を公開するために使用される。第１のステップにおいて、トラストセンターは更新を公開し、全ノードは、受信したｐｒｅ‐ＭＡＣが正しいことを、それが未知値のハッシュチェインと一緒に公開されると、確認することができる。第２のステップにおいて、トラストセンターは全ノードが正しいｐｒｅ‐ＭＡＣを得たことを、ノードがＡＣＫで応答すると、確認する。全ノードが第１のメッセージを得たことをトラストセンターが検証すると、トラストセンターは更新されるべきソフトウェアを公開する。ノードは既にｐｒｅ‐ＭＡＣを得ているのでソフトウェアを検証することができる。
【００１５】
こうしたアプローチは、メッシュ及びツリールーティングプロトコルなどの多数のルーティングプロトコルに有効である。メッシュルーティングプロトコルにおいて、トラストセンターは複数のルータから複数の結合されたｐｒｅ‐ＡＣＫを取得し得る。ツリーベースルーティングプロトコルにおいて、トラストセンターは木のレベル１におけるノードから結合されたｐｒｅ‐ＡＣＫのみを取得する。ほとんどの実施形態において、レベル１におけるルータはレベル１＋１におけるノード若しくはルータから来る確認メッセージを集約する。
【００１６】
さらに、ネットワークがネットワーク鍵によって保護される場合、ソフトウェア更新のための全通信はネットワーク鍵を用いて保護されるはずである。これは外部攻撃者が偽造情報を導入することを防ぐ。
【００１７】
本発明の一実施形態において、ネットワークは複数のノードに接続されるルータ装置をさらに有し、ノードが第１の確認応答メッセージをトラストセンターへ送信するステップは、
‐各ノードが第１の確認応答メッセージをルータ装置へ送信するステップと、
‐ルータ装置がメッセージを結合して完全な第１の確認応答メッセージを作るステップと、
‐ルータ装置が完全な第１の確認応答メッセージをトラストセンターへ送信するステップとを有する。
【００１８】
結合されたＡＣＫの使用は通信オーバーヘッドを減らす。トラストセンターが誤ったメッセージを取得する場合、プロトコルは非協調ノードを発見する能力を含む。このため、トラストセンターは誤ったノードを見つけるためにネットワークを分割する。例えば図１に描かれるネットワークを仮定し、結合されたｐｒｅ‐ＡＣＫが有効でないと仮定すると、トラストセンターは誤った動作を導入しているネットワークの部分を見つけ出すことができるように、ルータ１及びルータ２にそれらの結合されたｐｒｅ‐ＡＣＫをトラストセンターへ直接送信するように要求し得る。このアプローチは二分探索を適用することによってさらに拡張されることができる。
【００１９】
本発明の好適な実施形態において、送信されるべきデータが大きい場合、通信オーバーヘッドを最小化するためにマークル木が使用される。マークル木は以下のように構築される。
‐機密データが複数のサブセットに分割される。
‐各サブセットのハッシュ関数が計算される。
‐各サブセットのハッシュ関数はハッシュ木の葉とみなされ、ハッシュ木のノードとルートを導き出す。
【００２０】
かかる場合において、方法は次の通りである。
‐第１のメッセージをノードへブロードキャストするステップは、ハッシュ木のルートをブロードキャストするステップを有する。
‐機密データをブロードキャストするステップはハッシュ木のノードとルートを送信するステップを有する。
【００２１】
機密データをブロードキャストするステップは、ノードが機密データを完成させるメッセージを受信することを確認するだけでよいので、長期間にわたって実行されることができることがここで留意され得る。
【００２２】
別の実施形態において、機密データをブロードキャストするステップは、以前に送信された機密データと比較して変更による影響を受けているハッシュ木のノードのみをブロードキャストするステップを有する。
【００２３】
別の実施形態において、第１のメッセージは、
‐次のエレメントと呼ばれる、最後に送信されたエレメントの直後に位置するトラストセンターハッシュチェインのエレメントと、
‐最後に送信されたハッシュチェインのエレメントと連結された、ブロードキャストされるべき機密データのハッシュ関数とを有する。
【００２４】
別の実施形態において、送信されるべき機密データはソフトウェア若しくはソフトウェア更新のコードイメージに対応する。
【００２５】
別の実施形態において、方法は、ソフトウェアを均一にアクティベートするためのメッセージをノードへブロードキャストする、トラストセンターに対する最終ステップを有する。
【００２６】
本発明のさらに別の実施形態において、ノードのメモリはメモリページに分割され、方法は、機密データをメモリページの長さよりも短い複数のデータサブセットに分割する初期ステップを有する。
【００２７】
本発明のこれらの及び他の態様は以下に記載の実施形態から明らかとなり、それらを参照して解明される。
【００２８】
本発明は添付の図面を参照して一例としてより詳細に記載される。
【図面の簡単な説明】
【００２９】
【図１】本発明にかかる方法を実行するネットワークをあらわす。
【図２】マークル木を示す。
【図３】安全な増分ソフトウェア更新を示す。
【発明を実施するための形態】
【００３０】
本発明は図１に示される無線センサネットワークにおいてソフトウェアを安全にブロードキャストするための方法に関する。
【００３１】
このネットワークは基地局１、すなわちトラストセンター、及び資源制約型ノード（ノード１、ノード２、ノード３…ノード６）を有する。
【００３２】
トラストセンターはシステムセキュリティを管理し、センサノードに対する新たなソフトウェアイメージを受信し検証する能力を持つ。トラストセンターと資源制約型ノードとの間の通信は、ルーティングプロトコル、例えばメッシュ若しくはツリーベースプロトコルを用いることによって実行される。かかる場合、ネットワークはトラストセンターとノードとの間で通信を中継するためのルータ（ルータ１、ルータ２及びルータ３）も有する。
【００３３】
本発明にかかるネットワークにおいて実行される通信プロトコルは、以下のようにネットワークの異なる装置の初期化を必要とする：
‐トラストセンターは
であるようなハッシュチェイン
を有する。値
はそれぞれこのハッシュチェインのシードとアンカーである。
‐ノード鍵が各ノードに割り当てられ、各鍵Ｋｊはトラストセンターとノードｊの間で共有される鍵である。
‐各ノードもまたトラストセンターハッシュチェインのアンカーで初期化される。この機密もまたシステムオペレーション中にトラストセンターからノードの各々へ安全に送信されることができる。
【００３４】
ノードのメモリの初期化がさらに詳述される。
【００３５】
機密データＭの送信が完全なソフトウェア更新に対応する場合、プロトコルは次の３フェーズを有する：
‐第１フェーズにおいて、トラストセンターは、ネットワークの全ノードが新たなソフトウェア更新のための有効な署名を受信したことを確認する。この署名はメッセージの起源を認証するためにノードによって使用される。
‐第２フェーズにおいて、新たなソフトウェアがネットワーク内の全ノードへ向かって安全にブロードキャストされる。
‐第３フェーズにおいて、同期され認証された方法でソフトウェアがアクティベートされる。
【００３６】
一実施形態において、フェーズの各々はハッシュチェインエレメントを用いて署名される。
【００３７】
第１フェーズは、トラストセンターがソフトウェア署名のための有効な署名を送信し、全ノードがそれを正しく受信したかどうかをチェックすることにある。
【００３８】
従って、第１ステップにおいて、トラストセンターはトラストセンターハッシュチェインの次のエレメント
と、同じハッシュチェインの次のエレメント
と連結される新たなコードイメージＭのハッシュを含むメッセージをブロードキャストする。この最後のエレメントは受信したｐｒｅ‐ＭＡＣ（すなわちハッシュ）がよいものであり、誰もそれを変更していないことを確認するためにノードによって使用される。
【００３９】
本発明の意味の範囲内では、"次のエレメント"はチェインのシード（若しくはルート）へ向かうときにハッシュチェイン内の現在のエレメントの直後に位置するエレメントを指定する。
【００４０】
そして、第２ステップにおいて、ノードは、メッセージ１の受信後、ｐｒｅ‐ａｃｋ Ｐｒｅ‐ＡＣＫｊ＝ｈａｓｈ（Ｋｊ｜｜Ｍｅｓｓａｇｅ１）を作る。ノードは受信メッセージが有効な
と一緒に送信された場合のみｐｒｅ‐ａｃｋを作る。ｐｒｅ‐ａｃｋはメッセージ１をＫｊで暗号化することによって作られることもできる。
【００４１】
特定の実施形態において、ノードはｐｒｅ‐ａｃｋメッセージをトラストセンターへ直接送信せずにルータへ送信し、そしてこれは複数の端末装置からの複数のｐｒｅ‐ａｃｋを結合し、他のルータへ若しくはトラストセンターへ直接送信されるべき結合されたｐｒｅ‐ａｃｋを作る。
【００４２】
この場合、ノードはルータへメッセージ２．１を送信する：
ｐｒｅ‐ＡＣＫｊ＝ｈａｓｈ（Ｋｊ｜Ｍｅｓｓａｇｅ１）
【００４３】
ルータは以下の通り異なるメッセージを結合する：
ｈａｓｈ（Ｐｒｅ‐ＡＣＫｊ１｜Ｐｒｅ‐ＡＣＫｊ２｜…｜Ｐｒｅ‐ＡＣＫｊＭ），ｊ１，ｊ２，…，ｊＭ
【００４４】
ｐｒｅ‐ａｃｋが暗号化関数を用いて作られる場合、結合されたｐｒｅ‐ａｃｋもまたルータの鍵でｐｒｅ‐ａｃｋを暗号化することによって作られることができる。さらなるアプローチは同型暗号プリミティブの使用に言及する。
【００４５】
第３ステップにおいて、トラストセンターは全ノードがｐｒｅ‐ＭＡＣの受信を確認したかどうかをチェックする。このチェックは前述の通り第１フェーズを完了する。
【００４６】
プロトコルの第２フェーズはソフトウェア自体のブロードキャストに対応する。トラストセンターは全ノードによる正しい受信をチェックしたので、トラストセンターはトラストセンターハッシュチェインの次のエレメントと一緒にメッセージを公開する。
【００４７】
従ってメッセージ３は次の通りである：
ノードは
を所有するので、受信メッセージがトラストセンターによって作られたかどうかをチェックすることができる。従って、ノードはメッセージを安全に扱うことができ、例えばメッセージが実際に１本のソフトウェアのコードイメージをあらわす場合、ノードはそのソフトウェアをインストールすることができる。
【００４８】
いくらかのタイムアウト後にノードから何の確認も受信されていない場合、プロトコルは例外モードに入り、確認をしたノードで続行する。誤った値が見つかる場合、システムは続けて、さらに記載される方法を実行することによって動作のおかしいノードを見つけ出すことができる。
【００４９】
メッセージ３の受信後、ノードは確認応答メッセージＡＣＫｊ＝ｈａｓｈ（Ｍｅｓｓａｇｅ３｜Ｋｊ）を作り、それをトラストセンターへ直接若しくはルータを介して送り返す。ルータが使用される場合、ルータは複数のＷＳＮノード（若しくは端末装置）から複数のＡＣＫを結合し、結合されたＡＣＫを作る。ルータはそれを他のルータへ若しくはトラストセンターへ直接送信する。
ｈａｓｈ（ＡＣＫｊ１｜ＡＣＫｊ２…｜ＡＣＫｊＭ），ｊ１，ｊ２，…，ｊＭ
【００５０】
いくつかの実施形態において、メッセージ３は非常に大きくなり得る。従ってその場合ノードは代わりに、メッセージ１がメッセージ３のフィンガープリントであるため、ＡＣＫｊ＝ｈａｓｈ（Ｍｅｓｓａｇｅ１｜Ｋｊ）を送信し得る。ノードはまたＡＣＫｊ＝ｈａｓｈ（Ｍｅｓｓａｇｅ３ｆｉｒｓｔ ｂｙｔｅｓ｜Ｋｊ）も送信し得、Ｍｅｓｓａｇｅ３ｆｉｒｓｔ ｂｙｔｅｓはメッセージ３の第１バイトをあらわす。
【００５１】
そして、機密データが各ノードへ正しく送信され、確認応答メッセージが送り返された後、プロトコルのフェーズ２が完了する。
【００５２】
方法の第３フェーズは、送信データのタイプに依存するため、完全に任意である。ソフトウェア更新の場合、トラストセンターは新たなソフトウェアを均一にアクティベートするためにネットワーク内の全ノードへ安全なブロードキャストメッセージを送信し得る。
【００５３】
このメッセージが、異なるソフトウェアバージョンでネットワーク内のノードを取得しようとすることによってサービス妨害攻撃を実行しようとする攻撃者ではなく、トラストセンターによって送信されることを確認するために、トラストセンターはこの値と一緒にハッシュチェインの次の値
を公開する。このようにして、ノードがアクティベーションメッセージを得る場合、ノードは最初に付属のハッシュ値が正しいことを検証する。２つのノードが互いに通信し合う場合、さらにそれらのソフトウェアバージョンを検証することができる。それらが異なる場合、最新のソフトウェアバージョンを持つノードがソフトウェアアクティベーションメッセージを第二者へ転送し得る。第２のノードは上述の通りメッセージの妥当性を検証することができる。
【００５４】
本明細書に記載の完全なプロトコルは、ネットワーク内のトラストセンターが、メッセージがネットワーク内の全ノードによって安全に受信されることを確認することを可能にする。しかしながらソフトウェア更新の場合、前述の通り、このメッセージは非常に大きくなり得るので、通信オーバーヘッドにつながり得る。この問題を解決するために、本発明の特定の実施形態において、図２に示す通り、マークル木若しくはハッシュ木を使用することが決まっている。この木は以下のように構築される：
ソフトウェア若しくはソフトウェア更新のコードイメージが異なるページ（ページ１，ページ２…ページＰ）に分割され、異なるメモリ空間に保存される。
トラストセンターはメモリページの各々のハッシュ関数の計算を実行する；これらの値はマークル木の葉をあらわす。
そしてトラストセンターはマークル木のルートＭを計算する。
【００５５】
そしてマークル木を用いるソフトウェア更新のための方法は、以下の修正を伴って前述のものと同様である：
メッセージ１において、Ｍはメッセージ全体ではなく、マークル木のルートのみである。
メッセージ３において、木のルートはマークル木の全ノードと一緒に公開される。従って、木の中の全ノードが公開される場合、トラストセンターは新たなソフトウェアをブロードキャストすることができる。ノードは公開されたソフトウェア更新から作られるマークル木がマークル木のルートに一致することを検証した後にＡＣＫで応答する（メッセージ３において公開され、ｐｒｅ‐ＭＡＣを用いて検証される）。
【００５６】
こうしたアプローチは、システムが、マークル木のルートの安全な公開を可能にする上記セクションで記載されたメッセージで容易に拡張されることができるので、ＺｉｇＢｅｅ（登録商標）センサネットワークなどの無線センサネットワークにとって高度に有利である。ソフトウェア更新のメッセージの残りは既存プリミティブを用いることによって公開されることができる。
【００５７】
ＷＳＮなどの無線ネットワークにおいて、ソフトウェアは増分更新で定期的に更新される。こうした更新はネットワーク内の情報ブロードキャストの量の削減を可能にする。しかしながら、このアプローチはノード側でのソフトウェアの認証及び検証に関しては主要な欠点を提示する。実際、ソフトウェア更新は一般にコード若しくはコードのイメージの１つ若しくは複数の部分のわずかな変更にある。こうした変更は、わずかであっても、ノードのメモリページの全てに対する変更につながる。従って、受信データを検証するために、各ページごとに更新ハッシュ関数を計算し、そして更新されたルートを得るために木全体を再計算する必要がある。この重い計算は１ページずつベースで構築される既存認証スキームの性能の低下につながる。さらに、このアプローチはメモリ全体を書き換えることを必要とし、これは推奨されない。
【００５８】
この問題を克服するために、本発明の一実施形態において、ノードのメモリはＢ‐バイト長ページに分割されるが、情報はＢ'＜Ｂバイトにのみ保存される。
【００５９】
ここで、第１及び第２のページにおいて数バイトが変更されるソフトウェア更新が必要とされると仮定する。システムがＢ'バイトのバッファを含まなかった場合、変化は伝搬し得るのでメモリ全体が更新される必要がある。Ｂ'のバッファを持つことは、図３に見られる通り変更が局所領域に制限されるため、これを克服する。
【００６０】
同様に、プログラムコードがＭＡＣ、セキュリティなどに関連する複数のアプリケーションとソフトウェアを有する場合は、メモリを複数のアプリケーションセクションへ分割し得る。これらのアプリケーションの各々を保存するために使用されるページは上記の通り構成され得るが（Ｂ'バイトのバッファを持つＢバイトのページ)、さらに単独アプリケーションを更新するときのメモリ変化を最小限にするためにアプリケーション間に２〜３の空ページも含む。
【００６１】
本発明の文脈において、こうしたメモリ管理は、数ページのみが変更されるので、従ってマークル木のノードの一部しか再送される必要がないという主要な利点において高度に有利である。システムオペレーションは以下の通りである。まず、トラストセンターが第１フェーズにおける前記ステップに従い、メッセージのハッシュ（すなわちメモリ全体）を安全に公開する。そして、トラストセンターは増分メモリ更新を可能にする部分更新を公開する。第３に、ノードは公開されたメッセージに従ってそのメモリを再構築する。これは再プログラミング前に外部メモリにおいてなされるべきである。一旦これがなされると、ノードは得られるコードがマークル木構造を用いて同じ公開されたマークル木ルートとなるかどうかをチェックする。
【００６２】
方法の説明において、時々、いくつかのノードが第１のｐｒｅ‐Ｍａｃメッセージに応答してｐｒｅ‐ａｃｋメッセージを送り返さないということが起こり得ることが言及されている。これらのノードは従って非協調的とみなされるが、これらは危殆化の可能性もある。こうした場合、他のネットワークエレメントのさらなる危殆化を避けるために、危殆化エレメントを検出するための特徴を提供することが有用である。
【００６３】
危殆化ノードを検出することは、特に図１に示すようにノードとトラストセンターとの間の通信がルータを介して中継される場合、あまり容易でない。実際、たった１つのノードが誤ったＡＣＫ若しくはｐｒｅ‐ＡＣＫを作る場合、ルータは誤った結合されたＡＣＫ若しくはｐｒｅ‐ＡＣＫを作ることになる。トラストセンターはＡＣＫ及びｐｒｅ‐ＡＣＫを検証しようとし得るが、結合された値の生成に使用されるいかなる誤った値も最終結果を変更するので、これは失敗する。
【００６４】
この問題を克服するために、本発明の一実施形態において、非協調ノードを見つけ出すために、トラストセンターは結合されたＡＣＫ若しくはｐｒｅ‐ＡＣＫに寄与するノードを複数のセグメントに分割する。このために、基地局（若しくはトラストセンター）は関係するルータへ要求を送信する。ルータは各セグメントにおいてノードからＡＣＫ若しくはｐｒｅ‐ＡＣＫを収集する。そのようにして、トラストセンターはどのセグメントが正しく動作しどれが正しく動作しないかを見つけ出すことができる。トラストセンターはさらに危殆化した若しくは動作のおかしいノードを正確に決定するために二分探索を実行することができる。
【００６５】
従って、本発明において開示された異なる特徴の組み合わせは、ＷＳＮのセンサノードの物理的制約を考慮しながら、安全に無線でソフトウェアを更新するための方法を提供することを可能にする。
【００６６】
本発明は特に、医療センサネットワーク、照明システム、スマートエネルギー、ビルオートメーション、若しくは分散システムとセンサネットワークを含む任意の他の用途を専用とする。
【００６７】
本願の明細書及び請求項において、ある要素に先行する"ａ"若しくは"ａｎ"という語はかかる要素の複数の存在を除外しない。さらに、"有する"という語は列挙されたもの以外の要素若しくはステップの存在を除外しない。
【００６８】
請求項における括弧内の参照符号の包含は理解を助ける意図であり限定する意図ではない。
【００６９】
本開示の読解から、他の変更が当業者に明らかとなる。こうした変更は、無線センサネットワーク制御の分野において既知であり、本明細書に既に記載の特徴の代わりに若しくは加えて使用され得る他の特徴を含み得る。
【特許請求の範囲】
【請求項１】
トラストセンターと呼ばれる中央装置と複数のセンサノードを有する無線センサネットワークにおいて機密データを安全にブロードキャストするための方法であって、前記トラストセンターは暗号学的ハッシュチェインで初期化され、各ノードはノード鍵と前記トラストセンターハッシュチェインのアンカーで初期化され、前記方法は、
‐前記トラストセンターが第１の安全なメッセージを前記ノードへブロードキャストするステップと、
‐各ノードが前記第１のメッセージの受信後に第１の確認応答メッセージを作り、それを前記トラストセンターへ送り返すステップと、
‐前記トラストセンターが、全ノードが各自の第１の確認応答メッセージを送信したかどうかをチェックするステップと、及び全メッセージが受信されている場合、
前記トラストセンターが第３のメッセージにおいて機密データを安全にブロードキャストするステップと、
前記ノードが、前記第１のメッセージに含まれるエレメントに基づいて、機密データが実際に前記トラストセンターから来ているかどうかをチェックするステップとを有する、方法。
【請求項２】
２つのハッシュチェインエレメントが前記第１及び第３のメッセージを保証するために公開される、請求項１に記載の方法。
【請求項３】
前記ネットワークが複数のノードに接続されるルータ装置をさらに有し、前記ノードが第１の確認応答メッセージを前記トラストセンターへ送信するステップが、
‐各ノードが第１の確認応答メッセージを前記ルータ装置へ送信するステップと、
‐前記ルータ装置が前記メッセージを結合して完全な第１の確認応答メッセージを作るステップと、
‐前記ルータ装置が前記完全な第１の確認応答メッセージを前記トラストセンターへ送信するステップとを有する、請求項１又は２に記載の方法。
【請求項４】
以下の初期ステップ：
‐機密データを複数のサブセットに分割するステップと、
‐各サブセットのハッシュ関数を計算するステップと、
‐各サブセットのハッシュ関数をハッシュ木の葉とみなし、前記ハッシュ木のノードとルートを導き出すステップとを有する、請求項１乃至３のいずれか一項に記載の方法。
【請求項５】
‐第１のメッセージを前記ノードへブロードキャストするステップが、前記ハッシュ木のルートをブロードキャストするステップを有し、
‐機密データをブロードキャストするステップが、前記ハッシュ木のノードとルートを送信するステップを有する、請求項４に記載の方法。
【請求項６】
機密データをブロードキャストするステップが、以前に送信された機密データと比較して変更による影響を受けている前記ハッシュ木のノードのみをブロードキャストするステップを有する、請求項４又は５に記載の方法。
【請求項７】
前記第１のメッセージが、
‐次のエレメントと呼ばれる、最後に送信されたエレメントの直後に位置する前記トラストセンターハッシュチェインのエレメントと、
‐最後に送信された前記ハッシュチェインのエレメントと連結された、ブロードキャストされるべき機密データのハッシュ関数とを有する、請求項１乃至６のいずれか一項に記載の方法。
【請求項８】
送信されるべき機密データがソフトウェア若しくはソフトウェア更新のコードイメージに対応する、請求項１乃至７のいずれか一項に記載の方法。
【請求項９】
ソフトウェアを均一にアクティベートするための安全なメッセージを前記ノードへブロードキャストする、前記トラストセンターに対する最終ステップを有する、請求項８に記載の方法。
【請求項１０】
前記ハッシュチェインの第３のエレメントが前記ソフトウェアを安全にアクティベートするために使用される、請求項３又は８に記載の方法。
【請求項１１】
３つのハッシュチェインエレメントが各々の安全なソフトウェア更新のために公開される、請求項１、２又は９に記載の方法。
【請求項１２】
前記３つのハッシュチェインエレメントの各々が、前記ソフトウェアの安全な事前確認応答、前記ソフトウェアの安全な公開、及び前記ソフトウェアの安全なアクティベーションのために使用される、請求項１１に記載の方法。
【請求項１３】
前記ノードのメモリがメモリページに分割され、前記方法が、機密データを前記メモリページの長さよりも短い複数のデータサブセットに分割する初期ステップを有する、請求項１乃至１２のいずれか一項に記載の方法。
【請求項１４】
非協調ノードを見つけ出すために前記ネットワークがセグメントに分割される、請求項１乃至１３のいずれか一項に記載の方法。
【請求項１】
トラストセンターと呼ばれる中央装置と複数のセンサノードを有する無線センサネットワークにおいて機密データを安全にブロードキャストするための方法であって、前記トラストセンターは暗号学的ハッシュチェインで初期化され、各ノードはノード鍵と前記トラストセンターハッシュチェインのアンカーで初期化され、前記方法は、
‐前記トラストセンターが第１の安全なメッセージを前記ノードへブロードキャストするステップと、
‐各ノードが前記第１のメッセージの受信後に第１の確認応答メッセージを作り、それを前記トラストセンターへ送り返すステップと、
‐前記トラストセンターが、全ノードが各自の第１の確認応答メッセージを送信したかどうかをチェックするステップと、及び全メッセージが受信されている場合、
前記トラストセンターが第３のメッセージにおいて機密データを安全にブロードキャストするステップと、
前記ノードが、前記第１のメッセージに含まれるエレメントに基づいて、機密データが実際に前記トラストセンターから来ているかどうかをチェックするステップとを有する、方法。
【請求項２】
２つのハッシュチェインエレメントが前記第１及び第３のメッセージを保証するために公開される、請求項１に記載の方法。
【請求項３】
前記ネットワークが複数のノードに接続されるルータ装置をさらに有し、前記ノードが第１の確認応答メッセージを前記トラストセンターへ送信するステップが、
‐各ノードが第１の確認応答メッセージを前記ルータ装置へ送信するステップと、
‐前記ルータ装置が前記メッセージを結合して完全な第１の確認応答メッセージを作るステップと、
‐前記ルータ装置が前記完全な第１の確認応答メッセージを前記トラストセンターへ送信するステップとを有する、請求項１又は２に記載の方法。
【請求項４】
以下の初期ステップ：
‐機密データを複数のサブセットに分割するステップと、
‐各サブセットのハッシュ関数を計算するステップと、
‐各サブセットのハッシュ関数をハッシュ木の葉とみなし、前記ハッシュ木のノードとルートを導き出すステップとを有する、請求項１乃至３のいずれか一項に記載の方法。
【請求項５】
‐第１のメッセージを前記ノードへブロードキャストするステップが、前記ハッシュ木のルートをブロードキャストするステップを有し、
‐機密データをブロードキャストするステップが、前記ハッシュ木のノードとルートを送信するステップを有する、請求項４に記載の方法。
【請求項６】
機密データをブロードキャストするステップが、以前に送信された機密データと比較して変更による影響を受けている前記ハッシュ木のノードのみをブロードキャストするステップを有する、請求項４又は５に記載の方法。
【請求項７】
前記第１のメッセージが、
‐次のエレメントと呼ばれる、最後に送信されたエレメントの直後に位置する前記トラストセンターハッシュチェインのエレメントと、
‐最後に送信された前記ハッシュチェインのエレメントと連結された、ブロードキャストされるべき機密データのハッシュ関数とを有する、請求項１乃至６のいずれか一項に記載の方法。
【請求項８】
送信されるべき機密データがソフトウェア若しくはソフトウェア更新のコードイメージに対応する、請求項１乃至７のいずれか一項に記載の方法。
【請求項９】
ソフトウェアを均一にアクティベートするための安全なメッセージを前記ノードへブロードキャストする、前記トラストセンターに対する最終ステップを有する、請求項８に記載の方法。
【請求項１０】
前記ハッシュチェインの第３のエレメントが前記ソフトウェアを安全にアクティベートするために使用される、請求項３又は８に記載の方法。
【請求項１１】
３つのハッシュチェインエレメントが各々の安全なソフトウェア更新のために公開される、請求項１、２又は９に記載の方法。
【請求項１２】
前記３つのハッシュチェインエレメントの各々が、前記ソフトウェアの安全な事前確認応答、前記ソフトウェアの安全な公開、及び前記ソフトウェアの安全なアクティベーションのために使用される、請求項１１に記載の方法。
【請求項１３】
前記ノードのメモリがメモリページに分割され、前記方法が、機密データを前記メモリページの長さよりも短い複数のデータサブセットに分割する初期ステップを有する、請求項１乃至１２のいずれか一項に記載の方法。
【請求項１４】
非協調ノードを見つけ出すために前記ネットワークがセグメントに分割される、請求項１乃至１３のいずれか一項に記載の方法。
【図１】
【図２】
【図３】
【図２】
【図３】
【公表番号】特表２０１２−５３３７６１（Ｐ２０１２−５３３７６１Ａ）
【公表日】平成２４年１２月２７日（２０１２．１２．２７）
【国際特許分類】
【出願番号】特願２０１２−５２０１３９（Ｐ２０１２−５２０１３９）
【出願日】平成２２年７月９日（２０１０．７．９）
【国際出願番号】ＰＣＴ／ＩＢ２０１０／０５３１４４
【国際公開番号】ＷＯ２０１１／００７３０１
【国際公開日】平成２３年１月２０日（２０１１．１．２０）
【出願人】（５９００００２４８）コーニンクレッカ フィリップス エレクトロニクス エヌ ヴィ (12,071)
【Ｆターム（参考）】
【公表日】平成２４年１２月２７日（２０１２．１２．２７）
【国際特許分類】
【出願日】平成２２年７月９日（２０１０．７．９）
【国際出願番号】ＰＣＴ／ＩＢ２０１０／０５３１４４
【国際公開番号】ＷＯ２０１１／００７３０１
【国際公開日】平成２３年１月２０日（２０１１．１．２０）
【出願人】（５９００００２４８）コーニンクレッカ フィリップス エレクトロニクス エヌ ヴィ (12,071)
【Ｆターム（参考）】
[ Back to top ]