JP2021526328A - 格子メッシュ - Google Patents

Abstract

【解決手段】格子メッシュ用システムは、インタフェースおよびプロセッサを備える。インタフェースは、ホストから登録リクエストを受信するように構成され、登録リクエストは、鍵、およびホストが要求したいと望む１組の資産ＩＤを含む。プロセッサは、鍵に署名して、資源局（ｒｅｓｏｕｒｃｅ ａｕｔｈｏｒｉｔｙ、ＲＡ）証明書を用いてＲＡ証明書署名鍵を生成し、ＲＡ証明書署名鍵を用いて資産データベースを更新し、ネットワークを通してＲＡ証明書署名ホスト公開鍵を分配し、ホストにＲＡ証明書署名鍵を提供するように構成される。いくつかの実施形態では、システムは、プロセッサに連結された、プロセッサに命令を提供するように構成されたメモリをさらに備える。【選択図】図１

Description

［関連出願の相互参照］
本出願は、参照により本明細書に事実上組み込まれる、２０１８年６月１１日に提出された、「ＡＵＴＯＮＯＭＯＵＳ ＳＥＮＳＯＲ ＳＹＳＴＥＭ ＡＲＣＨＩＴＥＣＴＵＲＥ ＡＮＤ ＩＮＴＥＲＦＡＣＥ（自律センサ・システム・アーキテクチャおよびインタフェース）」と題する米国仮特許出願第６２／６８３，５３３号明細書の優先権を主張する。

機器のネットワークは、典型的には安全であり、かつ所与のノードの破損による攻撃に脆弱ではないと考えられている。しかしながら、ノードは、この場合、危険にさらされると、次いでノードを通るデータトラフィックおよびノード上に記憶された他の情報をひそかに探ることができるときにネットワークセキュリティの問題になる。さらに、ネットワークはまた、典型的には、安定した通信を提供するように設計され、ネットワークトラフィックが失われる、または運ばれないという問題につながる。

以下の詳細な記述および添付図面で本発明のさまざまな実施形態について開示する。

メッシュネットワークの実施形態を例示する構成図である。

ハブの実施形態を例示する構成図である。

メッシュノードの実施形態を例示する構成図である。

ホストノードの実施形態を例示する構成図である。

収集シンクノード（ｃｏｌｌｅｃｔｉｏｎ ｓｉｎｋ ｎｏｄｅ）の実施形態を例示する構成図である。

ホストサービスの実施形態を例示する構成図である。

登録処理の実施形態を例示する流れ図である。

メッシュネットワーク通信の実施形態を例示する構成図である。

通信チャネルの実施形態を例示する図である。

通信チャネルの実施形態を例示する図である。

格子メッシュでの通信の実施形態を例示する図である。

格子メッシュでの通信の実施形態を例示する図である。

メッシュネットワーク上で公開するための処理の実施形態を例示する流れ図である。

メッセージを受信するための処理の実施形態を例示する流れ図である。

メッセージを伝送するための処理の実施形態を例示する流れ図である。

本発明は、処理として、装置として、システムとして、物質の構成物として、コンピュータ可読記憶媒体に組み込まれたコンピュータプログラム製品として、ならびに／またはプロセッサに連結したメモリに記憶される、および／もしくはプロセッサに連結したメモリにより提供される命令を実行するように構成されたプロセッサなどのプロセッサを含む、さまざまな方法で実装することができる。本明細書では、これらの実装形態、または本発明がとってよい任意の他の形態を技法と呼ぶことがある。一般に、開示する処理のステップの順序を本発明の範囲内で変えてよい。特に指定のない限り、タスクを遂行するように構成されていると記述されるプロセッサまたはメモリなどの構成要素は、所与の時間にタスクを遂行するように一時的に構成される一般的構成要素として、またはタスクを遂行するように製造された特殊な構成要素として実装されてよい。本明細書で使用するとき、「プロセッサ」という用語は、コンピュータプログラム命令などのデータを処理するように構成された１つもしくは複数の機器、回路、および／または処理コアを指す。

本発明の原理を例示する添付図と共に、本発明の１つまたは複数の実施形態の詳細な記述を以下に提供する。そのような実施形態に関連して本発明について記述するが、本発明はどの実施形態にも限定されない。本発明の範囲は、特許請求の範囲だけにより限定され、本発明は、数多くの代替形態、修正形態、および均等形態を包含する。本発明を十分に理解できるように、以下の記述では数多くの特有の詳細について示す。これらの詳細は、例示するために提供され、本発明は、これらの特有の詳細の一部またはすべてが欠けている場合でも特許請求の範囲に従って実施してよい。明確にするために、本発明に関係がある技術分野で公知の技術的題材については、本発明を不必要に不明瞭にしないように、詳細には記述していない。

格子メッシュ用システムについて開示する。システムは、インタフェースおよびプロセッサを備える。インタフェースは、ホストから登録リクエストを受信するように構成され、登録リクエストは、キー、およびホストが要求したいと望む１組の資産ＩＤを含む。プロセッサは、鍵に署名して、資源局（ｒｅｓｏｕｒｃｅ ａｕｔｈｏｒｉｔｙ、ＲＡ）証明書を用いてＲＡ証明書署名鍵を生成し、ＲＡ証明書署名鍵を用いて資産データベースを更新し、ネットワークを通してＲＡ証明書署名ホスト公開鍵を分配し、ＲＡ証明書署名鍵をホストに提供するように構成される。いくつかの実施形態では、システムは、プロセッサに連結された、命令をプロセッサに提供するように構成されたメモリをさらに備える。

格子メッシュ用システムは、格子メッシュ内部で通信するための安全機構を含む。ポイント・ツー・ポイント・モードと、メッセージが複数の宛先を対象とすることができる公開機構の両方で対象宛先を有するメッセージのためのノード間通信が可能になる。通信のセキュリティは、ノードが危険にさらされると、危険にさらされたノードを使用してネットワークから重要なメッセージを取得できないようにするように設計される。さらに、ネットワークは、ネットワークリンクの性能が変化するにもかかわらずリアル・タイム・データを優先させる。ネットワークはまた、ポイント・ツー・ポイント権限付与を使用して安全なルーティングを確立することによりセキュリティを確実にする。ネットワークはまた、チャネルが利用可能であるときにデータを送信することができるように、ネットワーク内を流れるデータを戦略的にキャッシュする。

格子メッシュは、改善されたセキュリティにより他のネットワークに比べて改善になっている。ネットワークは、不安定な通信リンク、およびノードが危険にさらされるようになる可能性を克服するように設計される。格子メッシュは、メッセージを安全にし、ルートを安全にし、かつネットワークを通って送信されるのを待つメッセージのバックフィリング（ｂａｃｋｆｉｌｌｉｎｇ）を安全にするセキュリティシステムを使用して潜在的問題を克服する。

図１は、メッシュネットワークの実施形態を例示する構成図である。図示する例では、メッシュネットワークは、複数のノード（たとえば、メッシュノード１００、メッシュノード１０２、メッシュノード１０４、メッシュノード１０６、メッシュノード１０８、メッシュノード１０８、メッシュノード１１０、メッシュノード１１２、収集シンクノード１１４、メッシュノード１１６など）を含む。ホストノード１１８は、メッシュネットワークに加わるように要求している新しい機器またはセンサまたはタワーを備える。ホストノード１１８は、メッシュノード１１６を発見し、ネットワークに加わるように要求する。メッシュネットワークは、ホストノード１１８にハブのアドレスを通知する、またはホストノード１１８は、ハブのアドレスを事前にロードされている。ホストノード１１８は、ハブ１２０と連絡をとって、ハブ１２０上で動作する資源局に登録する。収集シンクノード１１４は、バックフィルデータベースを含むメッシュノードを備える。バックフィルデータベースは、ネットワークを通過するデータを記憶し、伝送を完了することができない場合にそのデータを記憶する。バックフィルデータベースは、ノード間でデータを後で提供することができるためのリポジトリの役割を果たす。

図２は、ハブの実施形態を例示する構成図である。いくつかの実施形態では、図２のハブを使用して、図１のハブ１２０を実装する。図示する例では、ハブ２００は、資源局２０２を含む。資源局（ＲＡ）２０２は、認証局（ｃｅｒｔｉｆｉｃａｔｅ ａｕｔｈｏｒｉｔｙ、ＣＡ）２０４、鍵ストア２０６、資産データベース（ｄａｔａｂａｓｅ、ＤＢ）２０８、ホストから要求へのマップ２１０、および資産データベース共有者２１２を含む。資源局２０２は、ハブ２００上で動作する。いくつかの実施形態では、ハブ２００は、中央クラウドに基づくサーバまたは仮想機械上で動作する。ＣＡ２０４は、システム用の認証局の役割を果たし、新しい機器による登録リクエストに応答する。ＣＡ２０４はまた、サービスが機器を認証して、システムのメッシュネットワーク上で機器を許容するかどうかを検証できるようにする。ＣＡ２０４は、自己署名されることができる、またはより高いレベルの認証局から自身に権限を委任された信用を有することができる。鍵ストア２０６は、ネットワーク上で許容されたホストの公開鍵を保持し、固有数値のホストＩＤをホストに割り当てる。いくつかの実施形態では、鍵ストア２０６は、ハードウェア・セキュリティ・モジュール（ｈａｒｄｗａｒｅ ｓｅｃｕｒｉｔｙ ｍｏｄｕｌｅ、ＨＳＭ）２１４を使用して、鍵材料がソフトウェアに基づき危険にさらされるのを防止するだけではなく、物理的に危険にさらされたノードに耐タンパ性を提供する。いくつかの実施形態では、ＲＡ２０２については、クラウドベースのＨＳＭを使用して鍵を記憶し、新しい資産ＤＢおよびホスト証明書に署名することができる。資産ＤＢ２０８は、（たとえば、ホスト公開鍵→ホストＩＤ→資産ＩＤのリストへの）ホストのマッピングを記憶する。さらにまた資産ＤＢ２０８を使用して、資産ＩＤが全システムに固有であることを確実にする。いくつかの実例では、資産ＤＢ２０８はホストマップと呼ばれる。

いくつかの実施形態では、資産ＤＢ２０８は、近隣の資産ＤＢを使用すべきかどうかを安全に判断するために使用することができる、署名された単調増加バージョン番号を含む。たとえば、ホストは、近隣の資産ＤＢのどのバージョン番号が、近隣が有するバージョン番号よりも大きいかを近隣に問い合わせることができる。ある近隣がより大きなバージョン番号の資産ＤＢを有することに応答して、ホストノードは、近隣から自身へ資産ＤＢを移送させて、ホストノードに現在記憶された、現在のより低いバージョンの資産ＤＢの代わりにより高いバージョン番号の資産ＤＢを記憶することができる。

ホスト公開鍵→（ホストＩＤ，［資産ＩＤ］）のマッピングは、ＲＡ２０２により署名され、名前付けおよびアドレス指定の目的でシステムの至る所で使用される。ホストから要求へのマップ２１０は、ホストとホストが行うことができる要求との間のマッピングを含む。中央ハブに至る無線通信リンク（たとえば、ＬＴＥ、セルラー方式、ＷｉＦｉなど）を利用できない場合でさえホストマップが利用できるように、資産データベース共有者２１２を使用して、システム内の他のノードに資産ＤＢを安全に分配する、またはゴシップする。

図３Ａは、メッシュノードの実施形態を例示する構成図である。いくつかの実施形態では、メッシュネットワーク３００を使用して、図１のメッシュノード（たとえば、メッシュノード１００、メッシュノード１０２、メッシュノード１０４、メッシュノード１０６、メッシュノード１０８、メッシュノード１１０、メッシュノード１１２、収集シンクノード１１４、およびメッシュノード１１６）を実装する。図示する例では、メッシュノード３００は、ドローン、観察ステーション（たとえば、タワー）、小型自律センサ（たとえば、センサ、「ほこり」センサなど）、ヘリコプタ、または任意の他の適切な数のメッシュネットワークを備えてよい。メッシュノード３００はホストサービス３０２を含む。ホストサービス３０２は、プロセッサを使用してメッシュノード３００上で動作し、ＲＡの資産ＤＢだけではなく、ネットワーク到達可能性およびサービス発見情報に関するホスト署名された表明も分配するルーティング・ゴシップ・サービスを取り扱う。ホストサービス３０２はまた、異なるタイプの資産（たとえば、メッシュネットワーク上の他のメッシュノード、サブネットワーク上のノードなど）からの、待ち時間に影響されやすい時間順序メッセージストリーム（ビデオデータを含む）を公開し、それに加入する。ホストサービス３０２は、単一のネットワークサービスを動作させ、自身を識別する固有の秘密鍵／公開鍵対を有する。ＲＡは、許可された公開鍵ごとに固有数値のホストＩＤを割り当てる。メッシュノード３００は、メッシュノード３００にローカルに接続された１つまたは複数の資産を動作させてよく、この場合、メッシュノード３００は、公開／加入およびＨＴＴＰ／２プロキシへの（たとえば、ローカルホストまたは別のローカルサブネットを介した）ローカルにルーティング可能な接続を維持して、公開／加入リクエストを行い、１つまたは複数の安全な遠隔手続呼出（ｒｅｍｏｔｅ ｐｒｏｃｅｄｕｒｅ ｃａｌｌ、ＲＰＣ）を遂行する。資産は、関連する資産ＩＤ、および１組の資産特性（たとえば、ドローン、無人地上センサ（ｕｎａｔｔｅｎｄｅｄ ｇｒｏｕｎｄ ｓｅｎｓｏｒ、ＵＧＳ）、タワーなど）を有する。各資産特性は、提供されたＲＰＣサービスおよび作り出された公開／加入話題名からなるリストに対応する。

図３Ｂは、ホストノードの実施形態を例示する構成図である。いくつかの実施形態では、ホストノード３１０を使用して、図１のホストノード１１８を実装する。図示する例では、ホストノード３１０は、メッシュネットワークに加わって、メッシュノードになろうと試みているノードであり、ドローン、観察ステーション（たとえば、タワー）、小型自律センサ（たとえば、センサ、「ほこり」センサなど）、ヘリコプタ、または任意の適切な数のメッシュネットワークを備えてよい。ホストノード３１０は、ホストサービス３１２を含む。ホストサービス３１２は、プロセッサを使用してホストノード３１０上で動作し、ＲＡの資産ＤＢだけではなく、ネットワーク到達可能性およびサービス発見情報に関するホスト署名された表明も分配するルーティング・ゴシップ・サービスを取り扱う。ホストサービス３１２はまた、異なるタイプの資産（たとえば、メッシュネットワーク上の他のメッシュノード、サブネットワーク上のノードなど）からの、待ち時間に影響されやすい時間順序メッセージストリーム（ビデオデータを含む）を公開し、それに加入する。ホストサービス３１２は、単一のネットワークサービスを動作させ、自身を識別する固有の秘密鍵／公開鍵対を有する。ＲＡは、許可された公開鍵ごとに固有数値のホストＩＤを割り当てる。ホストノード３１０は、ホストノード３１０にローカルに接続された１つまたは複数の資産を動作させてよく、この場合、ホストノード３１０は、公開／加入およびＨＴＴＰ／２プロキシへの（たとえば、ローカルホストまたは別のローカルサブネットを介した）ローカルにルーティング可能な接続を維持して、公開／加入リクエストを行い、１つまたは複数の安全な遠隔手続呼出（ＲＰＣ）を遂行する。資産は、関連する資産ＩＤ、および１組の資産特性（たとえば、ドローン、ＵＧＳ、タワーなど）を有する。各資産特性は、提供されたＲＰＣサービスおよび作り出された公開／加入話題名からなるリストに対応する。

図３Ｃは、収集シンクノードの実施形態を例示する構成図である。いくつかの実施形態では、ホストノード３２０を使用して、図１の収集シンクノード１１４を実装する。図示する例では、ホストノード３１０は、メッシュネットワークに加わって、メッシュノードになろうと試みているノードであり、ドローン、観察ステーション（たとえば、タワー）、小型自律センサ（たとえば、センサ、「ほこり」センサなど）、ヘリコプタ、または任意の適切な数のメッシュネットワークを備えてよい。ホストノード３１０はホストサービス３１２を含む。ホストサービス３１２は、プロセッサを使用してホストノード３１０上で動作し、ＲＡの資産ＤＢだけではなく、ネットワーク到達可能性およびサービス発見情報に関するホスト署名された表明も分配するルーティング・ゴシップ・サービスを取り扱う。ホストサービス３１２はまた、異なるタイプの資産（たとえば、メッシュネットワーク上の他のメッシュノード、サブネットワーク上のノードなど）からの、待ち時間に影響されやすい時間順序メッセージストリーム（ビデオデータを含む）を公開し、それに加入する。ホストサービス３１２は、単一のネットワークサービスを動作させ、自身を識別する固有の秘密鍵／公開鍵対を有する。ＲＡは、許可された公開鍵ごとに固有数値のホストＩＤを割り当てる。ホストノード３１０は、ホストノード３１０にローカルに接続された１つまたは複数の資産を動作させてよく、この場合、ホストノード３１０は、公開／加入およびＨＴＴＰ／２プロキシへの（たとえば、ローカルホストまたは別のローカルサブネットを介した）ローカルにルーティング可能な接続を維持して、公開／加入リクエストを行い、１つまたは複数の安全な遠隔手続呼出（ＲＰＣ）を遂行する。資産は、関連する資産ＩＤ、および１組の資産特性（たとえば、ドローン、ＵＧＳ、タワーなど）を有する。各資産特性は、提供されたＲＰＣサービスおよび作り出された公開／加入話題名からなるリストに対応する。

図３Ｄは、ホストサービスの実施形態を例示する構成図である。いくつかの実施形態では、ホストサービス３３０を使用して、図３Ａのホストサービス３０２、または図３Ｂのホストサービス３１２、または図３Ｃのホストサービス３２２を実装する。図示する例では、ホストサービス３３０は、登録要求元３３２、鍵ストア３３４、資産データベース３３６、および資産データベース共有者３３８を含む。登録要求元３３２は、最初に１つまたは複数のローカル・メッシュ・ノードを発見したことに応答して、またはホストサービスが動作しているノードに関連する新しい資産を追加もしくは削除したことに応答して、メッシュネットワークに登録リクエストを生じさせることができる。いくつかの実施形態では、ＲＡ公開鍵は、各ホストに事前にピン留めされ、登録のための適切なＲＡをホストノードが識別可能にする。鍵ストア３３４は、ネットワーク上で許可された、各ホストに固有数値のホストＩＤを割り当てる、ホストの秘密鍵を保持する。いくつかの実施形態では、鍵ストア３３４は、ハードウェア・セキュリティ・モジュール（ＨＳＭ）３４０を使用して、鍵材料がソフトウェアに基づき危険にさらされるのを防止するだけではなく、物理的に危険にさらされたノードに耐タンパ性を提供する。いくつかの実施形態では、取外し可能なＨＳＭをホストノードに取り付けて、秘密鍵材料を記憶および配布し、新しいホスト表明に署名することができる。資産ＤＢ３３６は、（たとえば、ホスト公開鍵→ホストＩＤ→資産ＩＤのリストへの）ホストのマッピングを記憶する。さらにまた資産ＤＢ３３６を使用して、資産ＩＤが全システムに固有であることを確実にする。資産ＤＢ３３６は、ホストマップと呼ばれる。ホスト公開鍵→（ホストＩＤ，［資産ＩＤ］）のマッピングは、ＲＡにより署名され、名前付けおよびアドレス指定の目的でシステムの至る所で使用される。中央ハブに至る無線通信リンク（たとえば、ＬＴＥ、セルラー方式、ＷｉＦｉなど）を利用できない場合でさえホストマップが利用できるように、資産データベース共有者３３８を使用して、システム内の他のノードに資産ＤＢを安全に分配する、またはゴシップする。いくつかの実施形態では、資産ＩＤ共有者３３８は、ホストサービス３３０の一部として記憶された現在の資産ＤＢよりも新しいバージョンの資産ＤＢを近接ノードが有するかどうかを判断することができる。

図４は、登録処理の実施形態を例示する流れ図である。いくつかの実施形態では、ホストノード（たとえば、図１のホストノード１１８）により図４の処理を使用して、メッシュネットワーク（たとえば、図１のメッシュノード、たとえば、メッシュノード１００、メッシュノード１０２、メッシュノード１０４、メッシュノード１０６、メッシュノード１０８、メッシュノード１１０、メッシュノード１１２、収集シンクノード１１４、およびメッシュノード１１６などの複数のメッシュノードから構成されたメッシュネットワーク）に登録する。いくつかの実施形態では、攻撃者が、欺く機器をシステムに付加すること、またはノードを危険にさらすこと、および資産から、危険にさらされたノードへのトラフィックまたはノード間のトラフィックの向きを変えることを防止するために、ホストノードは、メッシュネットワークに加わるように要求するときに登録処理を注意深く調べなければならない。図示する例では、４００で、メッシュネットワークに関する登録リクエストを受信する。たとえば（たとえばハブノードの）資源局は、メッシュネットワークに加わりたいと望むホストノードからリクエストを受信する。いくつかの実施形態では、ホストノードは、自身が識別することができるメッシュネットワークのローカルノードを発見し、ローカル・メッシュ・ノードの１つまたは複数を使用し、メッシュネットワークに加わるリクエストを適切な資源局に伝える。いくつかの実施形態では、登録処理は、ホストがリクエストを用いてＲＡに安全なＲＰＣを行うことを伴う。いくつかの実施形態では、リクエストは、ホストに新しい資産を付加することによりトリガされる。いくつかの実施形態では、リクエストは、ホストに対して資産を削除することによりトリガされ、すなわちたとえば、ホスト資産は（たとえば、ソフトウェア更新、ハードウェア更新、資産のプラグを抜くなどに起因して）取り除かれる、またはユーザは、資産を取り除く権限を確認した後、資産を遠隔に取り除く。ホストに関連する資産に変化があると、新しい資産ＤＢを分配する。４０２で、ホストノード公開鍵を受信する。たとえば、ホストノードは、（たとえば、資源局からの公開鍵のリクエストに応答して）資源局へのリンクが確立されると、メッシュネットワークに加わるリクエストの一部として、または別個の通信として提供する。４０４で、ホストノード公開鍵に署名する。たとえば、資源局は、ＲＡ証明書を使用してホストノード公開鍵に署名する。４０６で、ホストノードに関連する資産のリストを受信する。たとえば、資源局は、メッシュネットワークに加わるリクエストに関するホストノードに関連する、またはそのホストノードより要求される資産のリストを要求する、または資産のリストは、メッシュネットワークに加わるリクエストと共に受信される。４０８で、資産のリストの中の資産はＤＢに追加される。たとえば、資産のリストの中の資産の各々は、ホスト識別子に関連する資産ＤＢに追加される。４１０で、メッシュネットワークを通して資産データベースを分配する。たとえば、ネットワークを通して資産データベースをゴシップする、または分配する。４１２で、ＲＡにより署名されたホスト公開鍵を伴う証明書をホストに提供する。たとえば、証明書は、次いでホストにより受信され、ホストにより証明書を使用して、相互に認証されたＴＬＳ（ｔｒａｎｓｐｏｒｔ ｌａｙｅｒ ｓｅｃｕｒｉｔｙ、トランスポート層セキュリティ）接続を使用してメッシュネットワークに接続することができる。署名された公開鍵、およびホストノードと資産データベースに追加されたホスト資産の両方を用いて、ホストノードは、メッシュネットワークの他のノードと安全なＲＰＣを開始することができ、自身に配送されるメッセージを読むことができる。他のメッシュノードは、他のホストノードからの通信を受信するとき、ホストの公開鍵がＲＡにより署名されていることを確認して、ホストがメッシュネットワーク上で許可されていること、ならびに証明書の通し番号が資産データベース内の署名廃止リストに存在しないことを検証する。ホストノードに資産を追加するときはいつでも、登録処理は再開される。資産は、承認されると、（たとえば、ホスト公開鍵または任意の他の適切なホスト識別子に関連する）ホストに関連する資産データベースに追加され、資産データベースは、ゴシップまたは分配プロトコルを使用してメッシュネットワークを通して分配される。

いくつかの実施形態では、資産データベース（ＤＢ）は、近隣の資産ＤＢを使用すべきかどうかを安全に判断するために使用することができる、署名された単調増加バージョン番号を含む。たとえば、ホストは、近隣の資産ＤＢのどのバージョン番号が、近隣が有するバージョン番号よりも大きいかを近隣に問い合わせることができる。近隣がより大きなバージョン番号の資産ＤＢを有することに応答して、ホストノードは、近隣から自身に資産ＤＢを移送させて、ホストノードに現在記憶されている、現在のより低いバージョンの資産ＤＢの代わりにより高いバージョン番号の資産ＤＢを記憶することができる。

図５Ａは、メッシュネットワーク通信の実施形態を例示する構成図である。いくつかの実施形態では、図５Ａのメッシュノード（たとえば、メッシュノードＡ５００、メッシュノードＢ５０２、およびメッシュノードＣ５０４）は、図１のメッシュノード（たとえば、メッシュノード１００、メッシュノード１０２、メッシュノード１０４、メッシュノード１０６、メッシュノード１０８、メッシュノード１１０、メッシュノード１１２、収集シンクノード１１４、メッシュノード１１６）である。図示する例では、メッシュノードＣ５０４は、メッシュノードＢ５０２に第１のＲＰＣ５０６を送信して、通信を確立する。メッシュノードＣ５０４は、メッシュノードＡ５００に第２のＲＰＣ５０８を送信して、通信を確立する。

図５Ｂは、通信チャネルの実施形態を例示する図である。いくつかの実施形態では、図５Ｂに例示する通信チャネルは、図５ＡのメッシュノードＣ５０４とメッシュノードＢ５０２の間の通信で使用される。図示する例では、伝送制御プロトコル（ｔｒａｎｓｍｉｓｓｉｏｎ ｃｏｎｔｒｏｌ ｐｒｏｔｏｃｏｌ、ＴＣＰ）通信は、２つのメッシュノード間の通信（たとえば、メッシュノードＣ→メッシュノードＢ）で使用される。通信は、相互に認証されたトランスポート層セキュリティ（ｔｒａｎｓｐｏｒｔ ｌａｙｅｒ ｓｅｃｕｒｉｔｙ、ＴＬＳ）接続をホスティングする。ＴＬＳ接続の内部では、ストリーム指向マルチプレクサは、３種類のストリームを、すなわち、１）単一メッセージング・フレーミング・プロトコルを動作させる分配またはゴシップ／Ｐｕｂｓｕｂトラフィック、２）ローカルに終端された１ホップＲＰＣトラフィック用ＨＣ２（ＨＴＴＰ／２平文）、および３）マルチホップ・エンド・ツー・エンド暗号化ＲＰＣ接続（たとえばメッシュノードＣ→メッシュノードＡの通信）を容易にするためのＴＬＳトラフィックの簡単なパケット転送を動作させる。マルチプレクサプロトコルでのヘッダは、サービス品質（ｑｕａｌｉｔｙ ｏｆ ｓｅｒｖｉｃｅ、ＱｏＳ）情報を包含し、マルチホップＲＰＣについては、ヘッダは、意図する宛先に関するルーティング情報を含む。マルチホップ接続は、中間ノードが内容を盗聴することができないように、かつ各エンドポイントが相互に認証することができるように、エンド・ツー・エンドで暗号化される。これは、エンド・ポイント・ノードが、ＲＡにより提供された証明書を使用して、ＴＬＳ／ＡＥＳ−ＧＣＭ（ｔｒａｎｓｐｏｒｔ ｌａｙｅｒ ｓｅｃｕｒｉｔｙ ａｄｖａｎｃｅｄ ｅｎｃｒｙｐｔｉｏｎ ｓｔａｎｄａｒｄ Ｇａｌｏｉｓ ｃｏｕｎｔｅｒ ｍｏｄｅ、トランスポート層セキュリティＡＥＳガロアカウンタモード）を確立することにより達成される。証明書は、ホストが互いになりすますことができないようにＲＡ署名ホストＩＤを包含する。ＱｏＳを提供するために、各ホストは、単一ＴＣＰ接続、または各ホストの次のホップピアへの迅速なユーザ・データグラム・プロトコル（ｕｓｅｒ ｄａｔａｇｒａｍ ｐｒｏｔｏｃｏｌ、ＵＤＰ）インターネット接続（ｑｕｉｃｋ ＵＤＰ ｉｎｔｅｒｎｅｔ ｃｏｎｎｅｃｔｉｏｎ、ＱＵＩＣ）を維持する。ＴＣＰ接続は、ＴＣＰ接続を介した複数のストリームを多重化して、ストリームレベルで粗い優先順位付けをできるようにする。

図５Ｃは、通信チャネルの実施形態を例示する図である。いくつかの実施形態では、図５Ｃのメッシュノード（たとえば、メッシュノードＡ５１０、メッシュノードＢ５１２、およびメッシュノードＣ５１４）は、図１のメッシュノード（たとえば、メッシュノード１００、メッシュノード１０２、メッシュノード１０４、メッシュノード１０６、メッシュノード１０８、メッシュノード１１０、メッシュノード１１２、収集シンクノード１１４、メッシュノード１１６）である。図示する例では、メッシュノードＣ５１４は、メッシュノードＢ５１２へのＴＣＰ接続５１６を有する。メッシュノードＢ５１２は、メッシュノードＡ５１０へのＴＣＰ接続５１８を有する。ＴＬＳ接続５２２は、通信するためにメッシュノードＣ５１４およびメッシュノードＢ５１２を接続する。ＴＬＳ接続５２０は、通信用にメッシュノードＣ５１４およびメッシュノードＡ５１０を接続する。

いくつかの実施形態では、ＲＡは、ＪＳＯＮウェブトークン（ＪＳＯＮ ｗｅｂ ｔｏｋｅｎ、ＪＷＴ）の形をとるベアラトークンを分配する。ベアラトークンは、システム内のサービスが、同期して中央局を確認する必要なしに、ある種の動作を行う許可をクライアントが有することを検証するための仕組みである。ＪＷＴは、ｂａｓｅ６４で符号化された、ＲＡ証明書を使用して、暗号を使用して署名されたＪＳＯＮ（ＪａｖａＳｃｒｉｐｔ Ｏｂｊｅｃｔ Ｎｏｔａｔｉｏｎ）フォーマットの１組の要求である。サービスは、ＲＡ証明書を使用してペイロード署名を確認することによりＪＷＴでの要求を検証することができる。要求は、資源識別子（たとえば、資源／資産／ａｂｃｅ１２３４）および動作（たとえば、ｐｕｂｓｕｂ：閲覧）または許可を備える。ＪＷＴは、登録中にハブにより与えられ、（ハブと、古いＪＷＴを新しいＪＷＴに交換することにより）周期的にリフレッシュされなければならない。

いくつかの実施形態では、システムは、署名された資産ＤＢおよびホスト表明を使用して、システムのための名前付けおよびアドレス指定を提供する。たとえば、３ｅ．ｈｏｓｔ．ｌｏｃａｌは、ホストＩＤの３ｅにマッピングされ、５ｆｅ．ａｓｓｅｔ．ｌｏｃａｌは、資産ＩＤの５ｆｅにマッピングされ、ｐｔｕ．８ｂ２．ａｓｓｅｔ．ｌｏｃａｌは、資産ＩＤの８ｂ２上で動作している特性「ｐｔｕ」にマッピングされる。

図５Ｄは、格子メッシュでの通信の実施形態を例示する図である。図示する例では、ノード３の加入者は、公開者から公開されたメッセージをノード３が受信することを要望することを公開者に要求する。加入リクエストは、ノード１の公開者に向けて、たとえば、ノード１に到達するルートに沿ったノード２に送信される。ノード２は、リクエストを受信し、ルートに沿ってノード１に転送する。いくつかの事例では、ルートに沿って公開者ノードの最終宛先にリクエストを中継する複数のノードが存在する。ノード１の公開者は、次いでリクエストを受信し、要求している加入者であるノード３が加入することを許されているかどうかを判断する（たとえば、資産ＤＢに問い合わせて、ノード３の加入者がノード１から公開されたメッセージに加入することを許されているかどうかを確かめる、またはＲＡに問い合わせて、ノード３の加入者がノード１から公開されたメッセージに加入することを許されているかどうかを確かめる、または任意の他の適切な権限付与リストもしくは権限付与機構）。権限付与されたことに応答して、ルートに沿ったノード２を介してノード３の加入者にグループ鍵を提供する。ノード１の資産からデータストリームを受信する（たとえば、カメラがノード１にビデオストリームを提供する）場合、ノード１の公開者は署名をし、現在のグループ鍵を使用してメッセージ（たとえば署名され暗号化されたメッセージ（ｓｉｇｎｅｄ ｅｎｃｒｙｐｔｅｄ ｍｅｓｓａｇｅ、ＳＥＭ））の中にデータストリームを暗号化する。グループ鍵は、周期的に更新される（たとえば、公開しているノード１で変更されるだけではなく、加入者ノードにも再分配される、または加入リクエストもしくは再加入リクエストに応答して加入者ノードにも提供される）ことに留意されたい。ノード１は、ノード２によりノード３の加入者に中継されるＳＥＭを公開することにより加入者に提供される。ノード３の加入者は、ノードが公開者の公開ストリームに加入したときに受信したグループ鍵を使用して、公開されたＳＥＭを解読する。

図５Ｅは、格子メッシュでの通信の実施形態を例示する図である。図示する例では、ノード３の通信エンドポイントは、ノード３がノード間で直接通信することを要望することを通信エンドポイントであるノード１に要求する。ポイント・ツー・ポイント通信リクエストは、ノード１に向けて、たとえば、ノード１に到達するルートに沿ったノード２に送信される。ノード２は、リクエストを受信し、ルートに沿ってノード１に転送する。いくつかの事例では、ルートに沿って公開者ノードの最終宛先にリクエストを中継する複数のノードが存在する。ノード１は、次いでリクエストを受信し、要求しているノードであるノード３が通信することを許されているかどうかを判断する（たとえば、資産ＤＢに問い合わせて、ノード３がノード１と通信することを許されているかどうかを確かめる、またはＲＡに問い合わせて、ノード３がノード１と通信することを許されているかどうかを確かめる、または任意の他の適切な権限付与リストもしくは権限付与機構）。権限付与されたことに応答して、ルートに沿ったノード２を介してノード３の加入者にホスト公開鍵を提供する。ノード１の資産からデータストリームを受信する（たとえば、カメラがノード１にビデオストリームを提供する）場合、ノード１の公開者は、署名し、現在のホスト公開鍵を使用してメッセージ（たとえば、署名され暗号化されたメッセージ（ＳＥＭ））の中にデータストリームを暗号化する。ホスト公開鍵は、周期的に更新される（たとえば、ノード１で変更されるだけではなく、他のノードにも再分配される、または通信するリクエストに応答してノードにも提供される）ことに留意されたい。いくつかの事例では、ホスト公開鍵は、資産ＤＢ分配を介して分配される。ノード１のメッセージは、ノード２によりノード３の加入者に中継されるＳＥＭを公開することにより加入者に提供される。ノード３は、鍵のデータベースを伝達および／または受信するように要求するときに受信したホスト公開鍵を使用して、公開されたＳＥＭを解読する。

図６は、メッシュネットワーク上で公開するための処理の実施形態を例示する流れ図である。いくつかの実施形態では、図６の処理を使用して、図１のメッシュノード（たとえば、メッシュノード１００、メッシュノード１０２、メッシュノード１０４、メッシュノード１０６、メッシュノード１０８、メッシュノード１１０、メッシュノード１１２、収集シンクノード１１４、メッシュノード１１６）を通してメッセージを公開する。いくつかの実施形態では、マルチキャストを使用してｐｕｂ／ｓｕｂ（公開／加入）メッセージを配送することを確実にするために（すなわち、メッセージは、メッセージ配送のために使用されるノードのグラフのエッジあたり一度だけ出現する）、中間のｐｕｂ／ｓｕｂノードが他のノード行きのメッセージを解読することができることを要求するので、加入あたり別個のストリームを使用することはできない。これを達成するために、各ｐｕｂ／ｓｕｂメッセージは、話題用グループ鍵を用いて個々に解読される。グループ鍵を使用して、作り出されたメッセージを暗号化し、認証する。話題用グループ鍵を安全に獲得するために、クライアントｐｕｂ／ｓｕｂノードは、ＲＰＣを介してサーバｐｕｂ／ｓｕｂノードに１つのグループ鍵を要求する。ＲＰＣは、メッセージを解読するために使用する鍵Ｉｄ、およびクライアントがアクセスできることを証明するベアラトークンを指定する。サーバは、次いでＲＡ証明書を使用して要求を検証し、クライアントは、話題にアクセスすることを許されている場合、グループ鍵へのアクセス権を与えられる。グループ鍵は、（数１０分のオーダーの）比較的短い生存期間を有しなければならず、ノードの、話題へのアクセス権を取り消すことによりノードが合理的時間で読出アクセス権を失うことを確実にするために、定期的に交替させられなければならない。グループ鍵は、メッセージデータを暗号化するためのＡＥＳ−ＧＣＭ暗号化モードに提供される共有秘密だけではなく、短命の鍵対の公開鍵も備える。ＡＥＳ−ＧＣＭは、ＨＭＡＣの役割を果たす「タグ」を作り出し、ＨＭＡＣは、この場合、否認防止の性質を提供するために、すなわち、グループ鍵へのアクセス権を有する他のホストがメッセージをねつ造するのを防止するために、鍵対の秘密鍵により署名される。いくつかの実施形態では、ｐｕｂ／ｓｕｂサービスの要求は、資源識別子「資源／資産／＄｛資産Ｉｄ｝」およびパーミッション「許可／ｐｕｂｓｕｂ／閲覧」を使用する。

図示する例では、６００で、クライアントから公開グループに加わるリクエストを受信する。たとえば、生成ノードは、クライアントまたはメッシュノードから話題に関する公開グループに加わるリクエストを受信する。６０２で、グループ鍵を決定する。たとえば、ＲＡにより最初に提供された権限付与に関して資産ＤＢに問い合わせることにより、グループ鍵を決定する。６０４で、クライアントがグループの話題へのアクセス権を許可されているかどうかを判断する。たとえば、ＲＡは、クライアントまたはメッシュノードが公開グループに関連する所与の話題への許可またはアクセス権を有するかどうかをデータベースに問い合わせる。クライアントがグループの話題へのアクセス権を許可されていないことに応答して、処理は終了する。クライアントがグループの話題へのアクセス権を許可されていることに応答して、６０６で、クライアントにグループ鍵を提供する。たとえば、クライアント、またはクライアントに伝送すべきメッシュノードにグループ鍵を提供する。６０８で、メタデータを含むグループメッセージを公開する。たとえば、クライアントまたはメッシュノードでメッセージを適切にフィルタ処理するために使用することができるメタデータを含むグループ鍵を使用して、グループメッセージを公開する。６１０で、トークンを交替させる時間であるかどうかを判断する。たとえば、トークンを頻繁に交替させて、アクセス特権の取消しに対する合理的時間応答を（たとえば、数１０分で、時間で、数秒で、またはネットワークおよびネットワーク使用量に適合するように）可能にすべきである。トークンを交替させる時間であるという判断に応答して、制御を６０２に渡す。トークンを交替させる時間ではないという判断に応答して、６１２で、別のグループメッセージが存在するかどうかを判断する。別のグループメッセージが存在することに応答して、制御を６０８に渡す。別のグループメッセージが存在しないことに応答して、制御を６１０に渡す。

いくつかの実施形態では、ｐｕｂ／ｓｕｂ要求は、資産レベルにあり、資産が作り出すすべての話題をベアラが読むことができるようにする。

いくつかの実施形態では、資産は、話題から得られるメッセージのサブセットに加入することを望んでよい（たとえば、ドローンは、タワーから軌道に従うよう命令されてよい）。これを許可するためには、各メッセージは、フィルタ処理のために使用することができる、暗号化されていないメタデータをさらす。加入を開始するとき、メタデータは、メッセージに適用する１組のフィルタを指定することができる。メタデータは、１組の値への鍵のマップであり、フィルタは、鍵に対する正確な一致またはプレフィックス一致を可能にする。この枠組みを使用して、ジオハッシュ（ｇｅｏ−ｈａｓｈ）を使用する基本ジオフィルタリングが可能である。メッセージに関連するメタデータは、固有鍵（たとえば、メッセージの作成者に関連する鍵、時間／日付スタンプに関連する鍵など）、メディアタイプ（たとえば、ｐｒｏｔｏｂｕｆ（Ｐｒｏｔｏｃｏｌ Ｂｕｆｆｅｒ、プロトコルバッファ）、ｂｌｏｂ（Ｂｉｎａｒｙ Ｌａｒｇｅ Ｏｂｊｅｃｔ）、ファイルタイプ、たとえば、ビデオファイル（ＭＰＥＧ（ｍｏｖｉｎｇ ｐｉｃｔｕｒｅ ｅｘｐｅｒｔｓ ｇｒｏｕｐ）、ＭＰ４（ＭＰＥＧ−４）など）、テキストファイル、画像ファイル、ｐｄｆファイルなど）、および／またはタイムスタンプを含むことができる。画像に基づくメッセージについては、ｐｕｂ／ｓｕｂメッセージは、効率的転送および記憶のためにチャンキングされたＭＰＥＧストリームとして画像を符号化することができるべきである。

いくつかの実施形態では、各ホストは、（ＲＡおよびホストにより署名された）資産および（ホストだけにより署名された）特性からなる署名された表明リストを作り出す。特性は、ＲＰＣサービスおよび作り出された話題のグループ分けを記述する文字列である。ホスト表明リストでは、ホストはまた、システムの残りの部分により発見する目的で使用することができる文字列メタデータタグのリストを含むことができる。メッセージを公開するとき、資産は、話題名だけではなく、メッセージごとのメタデータタグのリストも含む。話題メタデータタグは、フィルタリングに有用な情報を包含することができる。複数の加入のルーティングに関与する中間ノードは、プレフィックス照合を使用して、複製された加入を組み合わせることができる。いくつかの実施形態では、準同形暗号化を使用して暗号化し、タグに対してプレフィックス照合を遂行して、中間ルーティングノードが、メタデータをフィルタ処理するときに盗聴することができる能力を取り除く。

いくつかの実施形態では、ｐｕｂ／ｓｕｂサービスは、話題へのメッセージを公開することができ、この場合、話題は（話題ＩＤ，資産ＩＤ）のタプルである。いくつかの実施形態では、ｐｕｂ／ｓｕｂサービスは、話題（話題ＩＤ，資産ＩＤ）タプル、配送タイプ（たとえば、完全な／バックフィルされた最新の、最後のメッセージなど）、および開始すべき時点（たとえば、ストリームの開始から０スタートする、「今」から−１スタートする、指定した時間に、指定した時間からメッセージを開始するなど）を指定するとき、任意の話題に関するメッセージに加入することができる。いくつかの実施形態では、ｐｕｂ／ｓｕｂサービスは、（たとえば、さらにまたタプルである話題ＩＤ、資産ＩＤを使用して指定された）任意の話題に関するメッセージへの加入をやめることができる。

いくつかの実施形態では、ｐｕｂ／ｓｕｂサービスは、履歴問合せに答える（たとえば、過去の時間からストリーム送信または公開を開始する）ことができるようにデータを記憶する。いくつかの実施形態では、ハブノードは、データベースにすべてのデータを格納する。いくつかの実施形態では、システム内の他のノードは、データの各々を（たとえば、ハードドライブなどの固定記憶装置に）格納する。

図７は、メッセージを受信するための処理の実施形態を例示する流れ図である。いくつかの実施形態では、図７の処理を使用して、プライベートメッセージまたは公開されたグループメッセージを受信する。図示する例では、７００で、クライアントまたはポイント・ツー・ポイント通信リンクから公開グループに加わるリクエストを提供する。たとえば、クライアント、または資産データベースへのポイント・ツー・ポイント通信リンクから公開グループに加わるリクエストを資産データベースに提供する。７０２で、グループ鍵またはホスト公開鍵を受信する。たとえば、資産データベースからグループ鍵を受信する。７０４で、メッセージが受信されたかどうかを判断する。メッセージが受信されなかったという判断に応答して、制御は７０４に渡される。メッセージが受信されたという判断に応答して、７０５で、メッセージを送信し続けるべきかどうかを判断する。メッセージを送信し続けるべきであると判断されたことに応答して、７１２で、メッセージを送信し続け、７１４で、メッセージがホスト宛てであるかどうかを判断する。メッセージがホスト宛てであることに応答して、制御は７０６に渡される。メッセージがホスト宛てではないことに応答して、制御は７０８に渡される。メッセージを送信し続けるべきではないという判断に応答して、制御は７０６に渡される。７０６で、グループ鍵を使用してメッセージを復号する。７０８で、バックフィルデータベースにメッセージを格納すべきかどうかを判断する。たとえば、ノードが収集シンクノードである場合、バックフィルデータベースにメッセージを格納する。いくつかの実施形態では、ノードにはバックフィルデータベースがなく、メッセージを復号した後、制御は７０６から７０４に渡される。バックフィルデータベースに格納するという判断に応答して、７１０で、復号されたメッセージをバックフィルデータベースに格納し、制御は７０４に渡される。バックフィルデータベースに格納しないという判断に応答して、制御は７０４に渡される。通常のノードの場合、グループ鍵またはホスト公開鍵をメモリに記憶させ、固定記憶装置が危険にさらされた場合、記憶された鍵を用いて、符号化されたメッセージを復号することができないように、グループ鍵またはホスト公開鍵を固定記憶装置に記憶させない。いくつかの事例では、ノードは、データシンク（ｄａｔａ ｓｉｎｋ）を備える。データシンクは、安全であると考えられているので選択される。

図８は、メッセージを伝送するための処理の実施形態を例示する流れ図である。いくつかの実施形態では、図８の処理を使用して、プライベートメッセージまたは公開されたグループメッセージを送信する。図示する例では、８００で、クライアントまたはポイント・ツー・ポイント通信リンクから公開グループに加わるリクエストを提供する。たとえば、クライアント、または資産データベースへのポイント・ツー・ポイント通信リンクから公開グループに加わるリクエストを資産データベースに提供する。８０２で、グループ鍵またはホスト公開鍵を受信する。たとえば、資産データベースからグループ鍵またはホスト公開鍵を受信する。８０４で、送信すべきメッセージが利用可能であるかどうかを判断する。送信すべきメッセージが利用可能ではないという判断に応答して、制御は８０４に渡される。送信すべきメッセージが利用可能であるという判断に応答して、８０６で、グループ鍵またはホスト公開鍵を使用してメッセージを符号化する。たとえば、メッセージは、グループ鍵を使用して暗号化される、またはホスト公開鍵を使用して署名される。グループ鍵とホスト公開鍵の間で留意すべき重要な違いは、グループ鍵は、メッセージを暗号化／復号するために使用する対称鍵であること、および周期的に交替させられることである。ホスト公開鍵は、ハードウェア・セキュリティ・モジュール上に格納される、決して交替させられることのない非対称鍵である（所与のホストは、製造時に単一のホスト公開鍵を割り当てられる）。（他のノードがメッセージを読もうと望むときにアクセスする）グループ鍵にアクセスできる他のノードがメッセージをねつ造することができないように、ホスト公開鍵を使用して、ホストが発するメッセージに署名する。８０８で、メッセージを送信し、制御は８０４に渡される。たとえば、メッセージは、ルーティングルートに沿って宛先に送信される、またはネットワークに公開される。生成ノードだけが公開グループに公開することができることに留意されたい。

いくつかの実施形態では、システムは、単一ノードが危険にさらされた場合、攻撃者が他の構成要素にアクセスすることができないようにセキュリティを提供するように設計される。いくつかの実施形態では、システムは、ノードがノードを通してルーティングされている、他のノード宛てのメッセージ／ＲＰＣを読むことができないようにする。いくつかの実施形態では、システムは、ノードが別のノードを通してルーティングされている、他のノード宛てのメッセージ／ＲＰＣを検出不能に修正することができないようにする。いくつかの実施形態では、システムは、他のノード向けのメッセージ／ＲＰＣを任意の所与のノードに向きを変える（すなわち、ルーティングテーブルのエントリに影響を及ぼす）ことができないようにする。

いくつかの実施形態では、システムは、任意のメッセージ／ＲＰＣが他のノード宛てである場合でさえ、ノードを通過する任意のメッセージ／ＲＰＣのためのサービスをノードが拒むことができるようにする。いくつかの実施形態では、システムが、ノード宛てのメッセージ／ＲＰＣをノードが傍受することができるようにする。いくつかの実施形態では、システムは、ノードになりすますメッセージをノードが送信することができるようにする。いくつかの実施形態では、システムは、ノードが見ることができるメッセージにノードが加入することができるようにする。いくつかの実施形態では、システムは、ノードを通過するすべてのメッセージ／ＰＣの宛先をノードが詳しく調べることができるようにする。

いくつかの実施形態では、鍵は、３３バイトの圧縮公開鍵サイズおよび６４バイトの署名サイズを有する米国国立標準技術研究所（Ｎａｔｉｏｎａｌ Ｉｎｓｔｉｔｕｔｅ ｏｆ Ｓｔａｎｄａｒｄ ａｎｄ Ｔｅｃｈｎｏｌｏｇｙ、ＮＩＳＴ）Ｐ−２５６曲線上で楕円曲線ＤＳＡ（Ｅｌｌｉｐｔｉｃ Ｃｕｒｖｅ Ｄｉｇｉｔａｌ Ｓｉｇｎａｔｕｒｅ Ａｌｇｏｒｉｔｈｍ、ＥＣＤＳＡ）を使用する。

いくつかの実施形態では、ＲＡは鍵対を有し、各ホストは、ＲＡ公開鍵をピン留めし、この場合、ピン留めされた鍵は、ホストに物理的にアクセスすることによってだけ変更可能である。いくつかの実施形態では、各ホストは、ハードウェアの修正を行わない限り変更することができない、ハードウェアに基づく鍵対を製造時に割り当てられる。ホストは、公開鍵のホスト識別子としても知られる自身の公開鍵を使用して識別される。

いくつかの実施形態では、ＲＡは、権限を与えられたメンバーのホストＩＤの集中リストを維持する。このリストは、登録処理を通して更新され、ネットワークを通して分配される。ホストが害を与えるようになった（たとえば、ホストが危険にさらされたという指示を受信した）場合、ＲＡは、そのホストから発せられた、活動状態の証明書を取り消すことができる。証明書の有効期限に到達するまで、取り消された証明書の通し番号は、署名されたホストリストの中に含まれる。各ホストは、ホストが有効期限と同時に、到達することができる他のホストに関する表明を広告する。表明は、ホストの秘密鍵により署名される。１つの署名された表明が存在するエッジは、「候補エッジ」と呼ばれる。２つの相互表明を伴うエッジは、「ルーティング可能なエッジ」と呼ばれる。ルーティング可能なエッジだけが、ネットワーク内で活動状態にある。

いくつかの実施形態では、アーキテクチャは、害を与えるノードが引き起こす可能性がある損害を限定するように設計される。たとえば、害のあるノードは、できるだけ多くの候補エッジを生み出す可能性があり、しかしながら、他の適正なホストが害のあるノードに到達することができない場合、適正なホストは、害のあるノードの候補エッジに関する表明を生み出さず、ルーティング可能なエッジはまったく生み出されない。したがって、害のあるノードは、そのノードが到達することができる適正なノードを伴うエッジを生み出すことに限定される。

いくつかの実施形態では、格子メッシュネットワーク内のルートは、相互到達可能性についての署名された表明により生み出される。ルーティングテーブルでリンクが生み出されるためには、リンクの両側は合意しなければならず、両側は署名されなければならない。リンクは、確立されると、ルーティングテーブルにローカルに記憶される。害のあるノードが負わせることができる、ルーティンテーブルへの損害は、害のあるノードが実際に直接到達することができるノードに限定される。その考えは、害のあるノードは、たとえば、ネットワーク内のあらゆるノードに直接接続されたことを広告することができず、その場合すべてのパケットを捨てることができず、その結果、ネットワークを破壊するということである。ノードが危険にさらされた場合、攻撃者は、ノード上で動作しているアプリケーションを依然として危険にさらすことがあることに留意されたい。しかしながら、標準的オペレーティングシステムのベストプラクティス（アプリケーションが最小特権の原理に従うユーザとして動作していることを確実にするなど）を使用してこれらの攻撃に対して保護されることがある。

いくつかの実施形態では、ルーティング可能なエッジを伴うルーティングテーブルは、以下を備える。
Ｔ２→Ｔ１
Ｔ２→Ｔ３
Ｔ１→Ｔ２
Ｔ１とＴ２の間のリンクは、Ｔ１とＴ２の両方が相互到達可能性についての表明に署名しているのでルーティング可能なエッジである。Ｔ３は候補エッジである。ルーティングテーブルは、従来のルーティングテーブルが有するような、いくつかのホストの順序のエントリではなく、ネットワーク内のいくつかのエッジの順序のエントリを含む。

いくつかの実施形態では、バックフィルは、履歴データが利用可能になるように、ノード上にデータをローカルに記録する処理を指すために使用される。この履歴データは、履歴データが他のノードにローカルにアクセス可能になるように、ネットワークのあちこちに移動させられる。バックフィルは、ｐｕｂ／ｓｕｂシステムに与える影響がまったくない、または少ないことが望ましい。存続するデータは、システムで優先され、バックフィルは、すべての存続するｐｕｂ／ｓｕｂ加入を取り扱った後に残る帯域幅を使用して動作する。別のノードに移動させられた、ノードのデータは、ノードが危険にさらされた場合、ノードに記憶される。ノードＢが、ノードＡへのアクセス権を与えられ、ディスク上に暗号化されたデータを記憶している場合、ノードＢがＡからのデータを復号するために使用する鍵は、時間制限される。鍵はメモリに記憶される（たとえば、短命ではない記憶領域に記憶されない）。これは、攻撃者がノードＢを危険にさらす場合、履歴データの時間制限された窓を見ることしかできないことを確実にする。ｐｕｂ／ｓｕｂマルチキャスト配送機構を使用して、バックフィルされたデータを配送する。複数のノードがバックフィルデータに関心がある場合、データをノード間の各エッジに沿って一度伝送する必要があるだけである。存続するｐｕｂ／ｓｕｂを通して配送されたデータはまた、中間ノードにより記憶され、データは存続するｐｕｂ／ｓｕｂのためにすでに伝送されているので、バックフィルのためにデータを再度伝送する必要がなくなる。機器上に記憶された履歴データは、任意の所与のノードの制御を支配する攻撃者により読み出すことができない。

いくつかの実施形態では、最終的にデータがユーザに利用できるように、ディスパッチサーバは、バックフィリングを使用して、ネットワーク接続性が悪い、またはまったくない期間の間に発生した、ノードからのデータを回復する。いくつかの実施形態では、１つまたは複数のディスパッチサーバが、ネットワーク上で動作しており、ディスパッチサーバのいくつかは、ネットワークのエッジに向けて導入され、危険にさらされる可能性があることがある。

いくつかの実施形態では、グローバルトラッカは、ネットワーク接続性およびサービス品質のデータを使用して、すべてのルートを大域的に精緻なものにする。グローバルトラッカは、信頼できないネットワークルートに直面してトラック融合を遂行する（たとえば、２つの別個のトラックを１つに組み合わせる）ことができる。

いくつかの実施形態では、バックフィルトラフィックは、より低い優先度のそのｐｕｂ／ｓｕｂを伴うＲＰＣストリームとして、ネットワークを介してルーティングされる。ＲＰＣバックフィルサービスが提供するデータは、存続するｐｕｂ／ｓｕｂネットワークを通して流れるのと同じデータ（たとえば、グループ鍵を使用して暗号化された、署名され暗号化されたメッセージ）である。これにより、中間ノードが、存続するｐｕｂ／ｓｕｂデータを記憶して、そのデータを使用してバックフィル・データ・リクエストの要求を満たすことが可能になる。データは、グループ鍵を使用して暗号化され、署名されるので、ノードは、作成者への安全なＲＰＣトンネルを要求するのではなく、他のノードに代わってバックフィルサービスＲＰＣに答えることができる。

いくつかの実施形態では、ＲＡは、バックフィルデータにアクセスする必要がある、ネットワーク内のホストである１組の「収集シンク」を規定する。ＲＡは、ＨｏｓｔＬｉｓｔ（ホストリスト）（この場合、ＲＡが署名する）内の１組の収集シンクを各ノードに割り当てる。すべてのノードは、（各収集シンクが受領者である）ＰＧＰまたは類似の枠組みを使用して、自身に割り当てられた収集シンク公開鍵を用いて休止時に暗号化された過去のグループ鍵を記憶する。この場合、ＰＧＰ−暗号化グループ鍵は、すべてのノードに対するバックフィルサービスを通して利用可能になる。

いくつかの実施形態では、ノードがハードウェア記憶モジュールを使用するときにかなりのスループットを確実にするために、収集シンクは、ＲＡに登録するとき、別個の収集シンク公開鍵／秘密鍵対を生成し、（ハードウェア記憶モジュールに記憶された）機器の秘密鍵を使用して休止時に暗号化された公開鍵部分をディスク上に格納する。収集シンクは、ＲＡに登録するとき、収集シンク公開鍵を提供する。次いで、この公開鍵を収集シンクの公開鍵としてＨｏｓｔＬｉｓｔに列挙することができる。始動時、収集シンクは、収集シンク秘密鍵を解読し、これをメモリに記憶させ、これを使用してグループ鍵を解読して、バックフィルされたデータにアクセスすることができる。

いくつかの実施形態では、取り込まれた機器上に記憶された履歴データは、攻撃者が、機器に割り当てられた収集シンクをさらにまた危険にさらさなければ、攻撃者にアクセスできない。攻撃者は、ＲＡＭから現在のグループ鍵を依然として読み出すことができるが、グループ鍵は最近交替させられたので、作り出されたデータを見るのを制限される。いくつかの実施形態では、当初の機器は、バックフィルされたデータにアクセスするためにアクセス可能である必要はなく、収集シンクの秘密鍵の１つへのアクセス権を必要とするだけである。これは、中間ノードが、暗号化されたグループ鍵だけではなく暗号化されたメッセージもキャッシュすることができるからである。いくつかの実施形態では、収集シンクは、事前に規定されていなければならず、これは、収集シンクは、追加されるとき、作成者ノードが自身のＰＧＰ受領者リストに収集シンクを含んでいなかったので、データをバックフィルすることができないことを意味する。いくつかの実施形態では、ＲＡは、収集シンクの状況を常に把握することができる必要があり、ホストに収集シンクを割り当てて、収集シンクに関する鍵対を維持する。

前述の実施形態について、理解を明確にするためにある程度詳細に記述してきたが、本発明は、提供した詳細に限定されない。本発明を実装する代替方法が多く存在する。開示する実施形態は例示的であり、制限的ではない。

Claims (21)

1. 格子メッシュ用システムであって、
   ホストから登録リクエストを受信するように構成されたインタフェースであって、前記登録リクエストは、鍵、および前記ホストが要求したいと望む１組の資産ＩＤを含むインタフェースと、
   プロセッサであって、
   前記鍵に署名して、ＲＡ証明書を用いてＲＡ証明書署名鍵を生成し、
   前記ＲＡ証明書署名鍵を用いて資産データベースを更新し、
   前記ネットワークを通して前記ＲＡ証明書署名鍵を分配し、
   前記ホストに前記ＲＡ証明書署名鍵を提供する
   ように構成されたプロセッサと
   を備えるシステム。
2. 請求項１に記載のシステムであって、グループ鍵、または、前記資産データベース内のホスト公開鍵を使用してメッセージが符号化され、前記メッセージを符号化することは、前記グループ鍵を使用して前記メッセージを暗号化すること、または前記ホスト公開鍵を使用して前記メッセージに署名すること、を備えるシステム。
3. 請求項２に記載のシステムであって、前記メッセージは、別のノードに送信される、または符号化後に複数のノードに公開されるシステム。
4. 請求項１に記載のシステムであって、メッセージが、鍵 グループ鍵または前記資産データベース内のホスト公開鍵を使用して復号されるシステム。
5. 請求項４に記載のシステムであって、前記メッセージは、明確に１つのノードに送信された、または複数のノードに公開されたシステム。
6. 請求項１に記載のシステムであって、前記インタフェースおよび前記プロセッサはハブに属するシステム。
7. 請求項６に記載のシステムであって、前記ハブは資源局を含むシステム。
8. 請求項７に記載のシステムであって、前記資源局は認証局を含むシステム。
9. 請求項７に記載のシステムであって、前記資源局は鍵ストアを含むシステム。
10. 請求項１０に記載のシステムであって、前記鍵ストアは、ハードウェア・セキュリティ・モジュールに鍵を格納するシステム。
11. 請求項７に記載のシステムであって、前記資源局は、資産データベースを含むシステム。
12. 請求項７に記載のシステムであって、前記資源局は、ホストから要求へのマップを含むシステム。
13. 請求項７に記載のシステムであって、前記資源局は、資産データベース共有者を含むシステム。
14. 請求項１に記載のシステムであって、前記ホストは、ホストサービスを含むシステム。
15. 請求項１４に記載のシステムであって、前記ホストサービスは、登録要求元を含むシステム。
16. 請求項１４に記載のシステムであって、前記ホストサービスは、鍵ストアを含むシステム。
17. 請求項１６に記載のシステムであって、前記鍵ストアは、ハードウェア・セキュリティ・モジュールに鍵を格納するシステム。
18. 請求項１４に記載のシステムであって、前記ホストサービスは、資産データベースを含むシステム。
19. 請求項１４に記載のシステムであって、前記ホストサービスは、資産データベース共有者を含むシステム。
20. 格子メッシュのための方法であって、
    ホストから登録リクエストを受信するステップであって、前記登録リクエストは、ホスト公開鍵、および前記ホストが要求したいと望む１組の資産ＩＤを含むステップと、
    プロセッサを使用して、前記鍵に署名して、ＲＡ証明書を用いてＲＡ証明書署名鍵を生成するステップと、
    前記ＲＡ証明書署名鍵を用いて資産データベースを更新するステップと、
    ネットワークを通して前記ＲＡ証明書署名鍵を分配するステップと、
    前記ホストに前記ＲＡ証明書署名鍵を提供するステップと
    を備える方法。
21. 格子メッシュ用コンピュータプログラム製品であって、前記コンピュータプログラム製品は、有形のコンピュータ可読記憶媒体の中に具体化され、
    ホストから登録リクエストを受信するステップであって、前記登録リクエストは、鍵、およびホストが要求したいと望む１組の資産ＩＤを含むステップ、
    前記鍵に署名して、ＲＡ証明書を用いてＲＡ証明書署名鍵を生成するステップ、
    前記ＲＡ証明書署名鍵を用いて資産データベースを更新するステップ、
    前記ネットワークを通して前記ＲＡ証明書署名鍵を分配するステップ、ならびに
    前記ホストに前記ＲＡ証明書署名鍵を提供するステップ
    のためのコンピュータ命令を備えるコンピュータプログラム製品。

Images