特表 2022-544423 安全な帯域外対称暗号化鍵配信

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公表特許公報(A)

(11)【公表番号】

(43)【公表日】2022-10-18

(54)【発明の名称】安全な帯域外対称暗号化鍵配信

(51)【国際特許分類】

   H04L 9/08 20060101AFI20221011BHJP

   H04L 9/12 20060101ALI20221011BHJP

【ＦＩ】

H04L9/08 C

H04L9/08 E

H04L9/12

【審査請求】未請求

【予備審査請求】未請求

(21)【出願番号】P 2022533051

(86)(22)【出願日】2020-05-15

(85)【翻訳文提出日】2022-03-22

(86)【国際出願番号】 US2020033293

(87)【国際公開番号】W WO2021025749

(87)【国際公開日】2021-02-11

(31)【優先権主張番号】16/530,987

(32)【優先日】2019-08-02

(33)【優先権主張国・地域又は機関】US

(81)【指定国・地域】

(71)【出願人】

【識別番号】522045925

【氏名又は名称】クアンタムエクスチェンジ インコーポレイテッド

(74)【代理人】

【識別番号】100094569

【弁理士】

【氏名又は名称】田中 伸一郎

(74)【代理人】

【識別番号】100103610

【弁理士】

【氏名又は名称】▲吉▼田 和彦

(74)【代理人】

【識別番号】100109070

【弁理士】

【氏名又は名称】須田 洋之

(74)【代理人】

【識別番号】100067013

【弁理士】

【氏名又は名称】大塚 文昭

(74)【代理人】

【識別番号】100086771

【弁理士】

【氏名又は名称】西島 孝喜

(74)【代理人】

【識別番号】100109335

【弁理士】

【氏名又は名称】上杉 浩

(74)【代理人】

【識別番号】100120525

【弁理士】

【氏名又は名称】近藤 直樹

(74)【代理人】

【識別番号】100139712

【弁理士】

【氏名又は名称】那須 威夫

(74)【代理人】

【識別番号】100176418

【弁理士】

【氏名又は名称】工藤 嘉晃

(72)【発明者】

【氏名】プリスコ ジョン

(72)【発明者】

【氏名】サフチュク ジーン

(72)【発明者】

【氏名】ベネデッティ ゲイリー

(72)【発明者】

【氏名】ヘイ エリック

(72)【発明者】

【氏名】マリノス アリキ

(72)【発明者】

【氏名】スウィーニー ステイシー

(57)【要約】

ネットワーク内の信頼できるノードは、ユーザデバイスへの安全な帯域外対称暗号化鍵配信を行う。第１の信頼できるノードは、第１のユーザデバイスから、対称暗号化鍵を一対のユーザデバイスとしての第１のユーザデバイスおよび第２のユーザデバイスへ配信する要求を受信する。第１の信頼できるノードは、信頼できるノードを介して、第２の対称暗号化鍵を第２のユーザデバイスへ配信する。第１の信頼できるノードは、第２の対称暗号化鍵を配信したことの確認を受信する。配信したことの確認に応答して、第１の信頼できるノードは、第１の対称暗号化鍵を第１のユーザデバイスへ配信する。
【選択図】図１

【特許請求の範囲】

【請求項1】

安全な帯域外対称暗号化鍵配信の方法であって、
ネットワーク内の第１の信頼できるノードにおいて、一対のユーザデバイスの第１のものから、対称暗号化鍵を前記一対のユーザデバイスへ配信する要求を受信するステップと、
前記第１の信頼できるノードから、前記ネットワーク内の信頼できるノードを介して、前記対称暗号化鍵の第２のものを前記一対のユーザデバイスの第２のものへ配信するステップと、
前記第１の信頼できるノードにおいて、前記ネットワーク内の前記信頼できるノードのうちの１つから、前記対称暗号化鍵の前記第２のものを前記一対のユーザデバイスの前記第２のものへ配信したことの確認を受信するステップと、
前記ネットワーク内の前記第１の信頼できるノードから、前記対称暗号化鍵の第１のものを前記一対のユーザデバイスの前記第１のものへ、前記対称暗号化鍵の前記第２のものを前記一対のユーザデバイスの前記第２のものへ配信したことの確認に応答して、配信するステップと
を含む方法。

【請求項2】

前記対称暗号化鍵の前記第１および第２のものが前記一対のユーザデバイスの前記第１および第２のものへだけ配信されることが、前記信頼できるノードによって保証される、請求項１に記載の方法。

【請求項3】

前記対称暗号化鍵の前記第２のものを配信する前記ステップが、信頼できるノードとして互いに信頼するように事前設定されているノード間で前記ネットワークを通して、前記対称暗号化鍵の前記第２のものを配信することを含む、請求項１に記載の方法。

【請求項4】

前記ネットワーク内の前記信頼できるノードは、１対１、１対多、または多対多の構成でそれぞれピアツーピアネットワークまたはメッシュネットワーク内にノードを含む、請求項１に記載の方法。

【請求項5】

前記対称暗号化鍵の前記第１および第２のものを配信中にジャストインタイム最適経路探索を行うステップをさらに含む、請求項１に記載の方法。

【請求項6】

前記対称暗号化鍵の前記第２のものを配信中にジャストインタイムロードバランシングを行うステップをさらに含む、請求項１に記載の方法。

【請求項7】

量子鍵を生成し、前記ネットワーク内の２つ以上の信頼できるノードのそれぞれに配信するステップをさらに含む、請求項１に記載の方法。

【請求項8】

前記対称暗号化鍵の前記第１および第２のものを配信中に、１つまたは複数のノード間伝送をそれぞれ量子鍵を用いて暗号化するステップをさらに含む、請求項１に記載の方法。

【請求項9】

前記対称暗号化鍵の前記第１および第２のものを配信中に、量子鍵の可用性に基づいてジャストインタイム最適経路探索を行うステップをさらに含む、請求項１に記載の方法。

【請求項10】

命令を有する有形で非一時的なコンピュータ可読媒体であって、前記命令は、プロセッサによって実行されると、前記プロセッサが、
ネットワーク内の第１の信頼できるノードにおいて、第１のユーザデバイスから、対称暗号化鍵を前記第１のユーザデバイスおよび第２のユーザデバイスへ配信する要求を受信するステップと、
前記第１の信頼できるノードから前記ネットワーク内の信頼できるノードを介して、第２の対称暗号化鍵を前記第２のユーザデバイスへ配信するステップと、
前記第１の信頼できるノードにおいて、前記ネットワーク内の前記信頼できるノードのうちの１つから、前記第２の対称暗号化鍵を前記第２のユーザデバイスへ配信したことの確認を受信するステップと、
前記ネットワーク内の前記第１の信頼できるノードから、第１の対称暗号化鍵、ならびに互いに対称の第１および第２の対称暗号化鍵を前記第１のユーザデバイスへ、前記第２の対称暗号化鍵を前記第２のユーザデバイスへ配信したことの確認に応答して、配信するステップと
を含む方法を実施する、有形で非一時的なコンピュータ可読媒体。

【請求項11】

前記方法が、
前記ネットワーク内のノードを、メッシュネットワークまたはピアツーピアネットワーク内の信頼できるノードとして互いに信頼するように事前設定するステップをさらに含む、請求項１０に記載の有形で非一時的なコンピュータ可読媒体。

【請求項12】

前記方法が、
前記ネットワークにおいてジャストインタイム最適経路探索を行うステップをさらに含む、請求項１０に記載の有形で非一時的なコンピュータ可読媒体。

【請求項13】

前記方法が、
前記ネットワークにおいてジャストインタイムロードバランシングを行うステップをさらに含む、請求項１０に記載の有形で非一時的なコンピュータ可読媒体。

【請求項14】

前記方法が、
隣接する２つ以上の信頼できるノードにおいて量子鍵を生成するステップと、
前記量子鍵を使用して、前記第１または前記第２の対称暗号化鍵を暗号化および復号化するステップとをさらに含む、請求項１０に記載の有形で非一時的なコンピュータ可読媒体。

【請求項15】

安全な帯域外対称暗号化鍵配信のための装置であって、
ピアツーピアネットワークまたはメッシュネットワークにおいて信頼できるノードを形成するためのネットワークの複数のノードと、
前記信頼できるノードの第１の信頼できるノードであって、
第１のユーザデバイスから、対称暗号化鍵を前記第１のユーザデバイスおよび第２のユーザデバイスへ配信する要求を受信し、
前記第１の信頼できるノードから前記信頼できるノードを介して、第２の対称暗号化鍵を前記第２のユーザデバイスへ配信し、
前記信頼できるノードのうちの１つから、前記第２の対称暗号化鍵を前記第２のユーザデバイスへ配信したことの確認を受信し、
前記第１の信頼できるノードから、前記第２の対称暗号化鍵と対称である第１の対称暗号化鍵を前記第１のユーザデバイスへ、前記第２の対称暗号化鍵を前記第２のユーザデバイスへ配信したことの確認に応答して、配信する
ための第１の信頼できるノードとを備える、装置。

【請求項16】

前記信頼できるノードがさらに、
前記ピアツーピアネットワークまたはメッシュネットワークにおいてジャストインタイム最適経路探索を行う、請求項１５に記載の装置。

【請求項17】

前記信頼できるノードがさらに、
前記ネットワークにおいてジャストインタイムロードバランシングを行う、請求項１５に記載の装置。

【請求項18】

前記信頼できるノードがさらに、
隣接する２つ以上の信頼できるノードにおいて量子鍵を生成し、
前記量子鍵を使用して、前記第１または前記第２の対称暗号化鍵を暗号化および復号化する、請求項１５に記載の装置。

【請求項19】

前記信頼できるノードがさらに、
前記第１および第２の対称暗号化鍵の配信中に、ノード間の伝送ごとに、量子鍵を用いて暗号化および復号化を使用する、請求項１５に記載の装置。

【請求項20】

前記信頼できるノードがさらに、
前記第１および第２の対称暗号化鍵の配信中に、量子鍵の可用性に基づいて、ジャストインタイム最適経路探索を行う、請求項１５に記載の装置。

【発明の詳細な説明】

【技術分野】

【0001】

本実施形態は、暗号通信システムおよびネットワーク内暗号通信の分野に関する。

【背景技術】

【0002】

暗号化および復号化は、様々なネットワークを介する暗号通信に一般的に使用される。典型的な暗号化通信では、２点間でデータを暗号化および復号化するのに対称鍵を使用する。これらの鍵は通常、同じリンクを利用するデータ交換の開始時にＤｉｆｆｉｅ－Ｈｅｌｌｍａｎネゴシエーションから得られる。十分な計算能力があれば、データリンクを盗聴することにより攻撃者は、その交換から対称鍵を推論できるようになるはずである。これまで、この危険性はあくまで理論的なものであったが、量子コンピュータの出現により、総当たり攻撃の脆弱性が非常に現実的なものになっている。

【発明の概要】

【発明が解決しようとする課題】

【0003】

ＱＫＤ（量子鍵配送）システムが、両当事者の対称鍵に盗聴に対する強力な物理的保証を提供するために現在開発されている。ＱＫＤシステムを実用に供するには現在のところ、距離に関する制限と、ネットワークをアリス／ボブ対よりも多く拡張する機能がないので一対のデバイス（アリス／ボブ）としてしか動作できないこととが妨げになっている。

【課題を解決するための手段】

【0004】

安全な帯域外対称暗号化鍵配信の方法が開示される。ネットワーク内の第１の信頼できるノードが要求を受信する。要求は、一対のユーザデバイスの第１のものからである。要求は、対称暗号化鍵を一対のユーザデバイスへ配信することである。第１の信頼できるノードは、対称暗号化鍵の第２のものを一対のユーザデバイスの第２のものへ配信する。対称暗号化鍵は、ネットワーク内の別の信頼できるノードを介して配信される。第１の信頼できるノードは、ネットワーク内の別の信頼できるノードのうちの１つから確認を受信する。確認は、対称暗号化鍵の第２のものを一対のユーザデバイスの第２のものへ配信したというものである。第１の信頼できるノードは、対称暗号化鍵の第１のものを一対のユーザデバイスの第１のものへ配信する。この配信は、対称暗号化鍵の第２のものを一対のユーザデバイスの第２のものへ配信したことの確認に応答するものである。

【0005】

有形で非一時的なコンピュータ可読媒体が開示される。この媒体は、プロセッサによって実行されるとプロセッサが１つの方法を実施する命令を有する。ネットワーク内の第１の信頼できるノードが、第１のユーザデバイスから要求を受信する。要求は、対称暗号化鍵を第１のユーザデバイスおよび第２のユーザデバイスへ配信することである。第１の信頼できるノードから、第２の対称暗号化鍵が第２のユーザデバイスへ配信される。鍵は、ネットワーク内の信頼できるノードを介して配信される。第１の信頼できるノードにおいて、確認が、ネットワーク内の信頼できるノードのうちの１つから受信される。これは、第２の対称暗号化鍵を第２のユーザデバイスへ配信したことの確認である。ネットワーク内の第１の信頼できるノードから、第１の対称暗号化鍵が配信される。第１と第２の対称暗号化鍵は互いに対称である。第１の対称暗号化鍵は第１のユーザデバイスへ、第２の対称暗号化鍵を第２のユーザデバイスへ配信したことの確認に応答して、配信される。

【0006】

安全な帯域外対称暗号化鍵配信のための装置が開示される。装置は、ピアツーピアネットワークまたはメッシュネットワークにおいて信頼できるノードを形成するネットワークの複数のノードを有する。信頼できるノードのうちの１つである第１の信頼できるノードが、第１のユーザデバイスから、対称暗号化鍵を第１のユーザデバイスおよび第２のユーザデバイスへ配信する要求を受信する。第１の信頼できるノードは、第２の対称暗号化鍵を第２のユーザデバイスへ配信する。鍵は、第１の信頼できるノードから、信頼できるノードを介して配信される。第１の信頼できるノードは、第２の対称暗号化鍵を第２のユーザデバイスへ配信したことの確認を受信する。この確認は、信頼できるノードのうちの１つから受信される。第１の信頼できるノードは、第１の対称鍵を第１のユーザデバイスへ配信する。この第１の対称鍵は、第２の対称暗号化鍵と対称である。この配信は、第２の対称暗号化鍵を第２のユーザデバイスへ配信したことの確認に応答するものである。

【0007】

実施形態の他の態様および利点は、記載された実施形態の原理を例示する添付の図面と併せ読めば、以下の発明を実施するための形態から明らかになろう。

【0008】

記載の実施形態およびその利点は、以下の説明を添付の図面と併せて参照することによって最もよく理解することができる。これらの図面は、記載された実施形態の趣旨および範囲から逸脱することなく、記載された実施形態に当業者によって加えられ得る形状および細部のいかなる変更も決して限定しない。

【図面の簡単な説明】

【0009】

【図1】本実施形態による暗号鍵の帯域外配信のシステムを示す図である。ＴＸ１からＴＸ７は、Ｔｒｕｓｔｅｄ Ｘｃｈａｎｇｅノード（ＴＸノード）を表す。Ｕ１～Ｕ４は、システムのユーザを表す。ＱＫＤアリス／ボブ対と同様の、ただしそれに限らない追加の暗号化鍵を提供できるシステムについての描写もある。

【図2】図１のＴＸノードネットワークの実施形態で使用するのに適している、ノードＴＸ１の視点からのＴＸノード情報収集ループ（「隣接ノードとのチャット」）を示す図である。

【図3】本実施形態によるＴＸノードのメッシュ内の帯域外暗号化鍵（「パーセル」）配信を示す図である。

【図4】図１の帯域外対称鍵配信システムおよび図３に示したパーセル配信の実施形態で使用するのに適している、経路計算プロセスの一実施形態を示す図である。

【発明を実施するための形態】

【0010】

データ交換に使用されるチャネル外で追加の鍵の対が配信されることは重要である。データチャネルと鍵配信チャネルを分離すると、総当たりによる量子コンピュータ攻撃が実質的に不可能になる。従来の方法によってインラインで配信される鍵と、本明細書に記載されたシステムおよび方法を使用することによって帯域外で配信される鍵とを組み合わせると、既存のネットワークに目立たずに配備することが、攻撃に対する暗号化チャネルの耐性を大幅に向上させながら可能になる。

【0011】

本明細書に開示されたシステムの様々な実施形態は、距離およびネットワーク拡張に関する制限を取り除き、ＱＫＤシステムと一緒でも一緒でなくても動作し、かつ、適応型ルーティングおよび耐障害性を持つＴｒｕｓｔｅｄ Ｘｃｈａｎｇｅノード（すなわち、Ｔｒｕｓｔｅｄ ＥｘｃｈａｎｇｅノードすなわちＴＸノード）の自己組織化メッシュネットワークを導入しており、このシステムはまた、利用可能な場合には、ＱＫＤアリス／ボブ対からの追加の送信中の鍵暗号化の利益を得ることもできる。

【0012】

本明細書では、メッシュネットワークおよびピアツーピアネットワークを含む様々なネットワークで実施される、鍵配信を用いる暗号通信システムについて説明する。ネットワーク内のＴＸノード同士は、強力な暗号化および相互証明書、すなわちサーバのクライアント検証およびクライアントのサーバ検証を用いるＴＬＳ（トランスポート層セキュリティ）を介して接続し、この場合、クライアントおよびサーバはＴＬＳ通信ごとに定義される。

【0013】

ＴＸノード同士は通信および協力して、隣接ノードを発見し、ユーザ要求ごとに鍵を生成し、要求されたＴＸノードに鍵を配信し、鍵の配信を確認し、最適な配信ルートを見つけ、隣接ノードのＴＸノードのうちの１つがアクセスできない場合には別のルートを見つけ、この手順を繰り返す。別々であり、変形形態であり、または様々な組み合わせであり得る特徴を持つ諸実施形態では、鍵は暗号化対称鍵（または対称暗号化鍵）であり、ネットワークはメッシュネットワークもしくはピアツーピアネットワークであり、かつ／または鍵は、各ホップツーホップ伝送において外部鍵によって追加的に暗号化することができる。外部鍵は、１つまたは複数の、またはすべてのネットワークホップにおいて、接続されたＱＫＤアリス／ボブ対によって生成することができる（たとえば、配信される各対称鍵は、その特定のホップにおいて外部鍵によってラップされる）。いくつかの実施形態では、ピアツーピア通信と組み合わせて帯域外対称鍵配信を行う。いくつかの実施形態では、ホップの最小化、外部鍵の可用性、または外部ＱＫＤ鍵の可用性などの、様々な基準で経路最適化を行う。ネットワーク内の近隣ノードは、証明書またはトークンの一方向または双方向の交換または検証を含む１つまたは複数のメカニズムによって、信頼を確立することができ、メッシュネットワークまたはピアツーピアネットワーク内の信頼できるノードになることができる。信頼を確立し、メッシュネットワークまたはピアツーピアネットワークを構築し、かつノードを事前構成して互いに信頼するための、さらなる機構またはプロトコルは、本明細書の教示に従って容易に考案される。

【0014】

図１は、本実施形態による暗号鍵の帯域外配信のシステムを示す。ＴＸ１～ＴＸ７は、Ｔｒｕｓｔｅｄ Ｘｃｈａｎｇｅノード（すなわち、Ｔｒｕｓｔｅｄ ＥｘｃｈａｎｇｅつまりＴＸノード１０６、１０８、１１０、１１２、１１４、１１６、１１８）を表し、Ｕ１～Ｕ４は、システムの対応するユーザデバイス１０２、１２０、１０４、１２２を持つユーザを表す。２つのユーザデバイスは、帯域外配信によって受信した暗号鍵を使用して、互いに帯域内暗号（すなわち、暗号化、復号化）通信を行う。ＱＫＤアリス／ボブ対と類似している、ただしそれに限らない追加の暗号化鍵を提供できるシステムについての描写もある。ピアツーピアネットワークまたはメッシュネットワークが、図１に個別に示されたＴＸノード１０６、１０８、１１０、１１２、１１４、１１６、１１８を含み、これらのノードは、その隣接ノードとピアツーピアモードで通信している。この通信は、クライアント－サーバとサーバ－クライアント両方の証明書検証を用いるＴＬＳによって暗号化される。ＴＸノードは、システム管理者によって設定された、かつ同じ認証局に所属している隣接ノードとしか交信しない。共同で、２つより多いＴＸノードが関与して、ＴＸノードはメッシュネットワークを生成することができる。ＴＸノード１０８、１１０、１１２、１１４の中には、ユーザデバイスが接続されていなく、たとえば転送またはルーティングに使用される移行ノードとしてのみ機能できるものもある。この機能は、システムが全体として耐障害性を得られるようにする重要な機能であり、また、限られた範囲のＱＫＤアリス／ボブ対からの外部鍵を用いて行われる二次暗号化を可能にもする。ピアツーピアネットワークまたはメッシュネットワークは、より具体的には、ネットワーク内のＴＸノード１０６、１０８、１１０、１１２、１１４、１１６、１１８は、ネットワークに接続されたユーザデバイス１０２、１２０、１０４、１２２のうちの任意の所与の対の間で暗号鍵を配信する処理を行う。ソフトウェア、ファームウェア、ハードウェア、およびこれらの様々な組み合わせを実行するプロセッサは、様々な実施形態において、このプロセスおよび他のプロセスの様々な動作を行うことができる。ピアツーピアネットワークまたはメッシュネットワークにおける接続は、様々な実施形態において、１対１（たとえば、末端ＴＸノード）、多対１、または多対多とすることができる。

【0015】

ＴＸノード１０６、１０８、１１０、１１２、１１４、１１６、１１８は、事前に設定されたその隣接ノードと定期的に通信して、隣接ノードの隣接ノードおよび接続されたすべてのユーザデバイスについての情報を引き込む。したがって、メッシュ設定の場合、各ＴＸノード１０６、１０８、１１０、１１２、１１４、１１６、１１８は、許可された隣接ノードからの情報だけを要求しながら、メッシュ内のすべてのノードと、すべてのアクティブなユーザデバイスとのほぼリアルタイムのマップを維持する。このマップは、新しいＴＸノード／ユーザデバイスがシステム管理者によって追加／除去された場合に、または一部のノードがアクセス不能になった場合に自動的に変化する。

【0016】

１つのシナリオでは、ユーザデバイス１０２のうちの１つ、たとえばＵ１が鍵を要求する。Ｕ１はまた、同じ鍵を受信すべき別の、たとえばＵ３のユーザデバイス１０４を指定する。鍵の要求は、このユーザデバイス１０２が接続されているＴＸノード１０６、この例ではＴＸ１に送信される。鍵要求は、相互に合意した仕様に従って行われ、ＴＬＳ暗号化および証明書検証を含むことができ、たとえばＲＥＳＴ ＡＰＩ（Ｒｅｐｒｅｓｅｎｔａｔｉｏｎａｌ Ｓｔａｔｅ Ｔｒａｎｓｆｅｒ Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）を介して行うことができる。別の変形形態として、鍵要求は、ユーザデバイスとＴＸノードの両方が同意するフォーマットでシリアル通信を介して行うこともできる。

【0017】

要求を受信すると、ＴＸノード１０６（この例ではＴＸ１）は、要求された鍵を生成し、要求者であるユーザデバイス１０２（Ｕ１）に鍵を返す前にまずＵ３に鍵を配信する準備をする。ＴＸ１は、Ｕ３が接続されているＴＸノード１１６の名前、この例ではＴＸ６を検索する。事前に設定された隣接ノード、この例ではＴＸノード１０８のＴＸ２およびＴＸノード１１２のＴＸ４と交信することしか許可されていないＴＸ１は、その現在のノードマップに基づいて次のホップを計算する。この例では、ＴＸノード１０６のＴＸ１には、いくつかの同じ長さの経路が見える。すなわち、ＴＸ２とＴＸ４の両方が同じ重みを有する。他の例では、経路の重み付けが異なり得る。この例では、ＴＸ１はロードバランシング動作を行い、前の鍵配信トランザクションがＴＸ２経由で行われた場合には、生成された鍵をＴＸ４に送信し、逆も同様である。内部データブロックはパーセルと呼ばれ、宛先ＴＸノードラベルが付けられている。ＴＸ１からこのパーセルを受信するとＴＸ４は、次のホップの同様の計算を行い、ＴＸ４には１つだけの選択肢、すなわちＴＸノード１１４のＴＸ５があることが分かる。最適経路計算および潜在的ロードバランシングの動作は、パーセルがその宛先ＴＸノード１１６（この例ではＴＸ６）に到達するまで、すべての移行ＴＸノード（ホップ）で行われる。チェーン内の各ＴＸノードは、前のピアからの接続をこのトランザクションで開いたままにしているので、潜在的エラーがもしあれば、このトランザクションのコンテキスト内で直ちに返される。鍵を用いたパーセルのＴＸ６への配信が成功すると、ＴＸ１は成功コードを返し、接続を閉じる。前の各ＴＸノードは、成功コードが発信者（この例ではＴＸ１）に届くまで同様のことを行う。成功コードを受信すると、ＴＸ１は最後に、要求された鍵をＵ１のユーザデバイス１０２へ返す。鍵がＴＸ６へ成功裏に配信されると、ここでＵ３は鍵を要求することができ、その後、鍵はＴＸ６から消去される。移行ＴＸノード内の配信された鍵の、パーセル配送トランザクションの時間を超える記憶はない。

【0018】

システムは、追加の暗号化鍵を供給されたＴＸノードが、たとえば、そのような経路に大きい重みを与えることによって、経路優先権を受信するように構成することができる。たとえばＱＫＤアリス／ボブ対からの追加の鍵の場合、ＴＸノードは、その特定のホップの両側でそれらの鍵を使用して、パーセルを追加的に暗号化／復号化する。このような量子鍵の暗号化および復号化は、様々な実施形態において、経路に沿ってパーセルの１つのホップ、２つ以上のホップ、または全部のホップについて行われ得る。

【0019】

配信の要求に対して鍵を生成するＴＸノードは、ＱＫＤシステムもしくは特殊なＱＲＮＧ（量子乱数発生器）をそれだけには限らないが含む、事前に設定されたＲＮＧ（乱数発生器）システムから、内部ハードウェアＲＮＧから、または標準的なソフトウェアエントロピーベースのＲＮＧから鍵材料を得ることができ、あるいは様々な実施形態において鍵を生成することができる。

【0020】

図２は、ＴＸノード１０６のＴＸ１の視点からの情報収集ループ（「ピアとのチャット」）の一実施形態を示す。ネットワーク内の各ノード１０６、１０８、１１０は、一意の名前を有していなければならない。この例では、ノードＴＸ１は、ＴＸ１がノードＴＸ２およびＴＸ３と交信できるようにシステム管理者によって事前設定されている。交換は、クライアント－サーバとサーバ－クライアントの両方の証明書検証を用いて、ＴＬＳの上でＲＥＳＴ ＡＰＩを介して実施される。この例では、ＴＸ１は、ＴＸ１が交信するように設定されている各ピアノードごとに、独立した「チャット」スレッドを実行する。ＴＸ１は、事前設定された間隔ＴでＴＸ２およびＴＸ３へのＲＥＳＴ「ＧＥＴ／ｃｈａｔ」要求を開始する。各ＴＸノードは、１回限りのＵＵＩＤ（汎用一意識別子）を生成し、このＵＵＩＤは、ＴＸノードのプロセスが実行されている間は継続し、プロセスが再起動すると置き換えられる。このＵＵＩＤのための長期の記憶はない。このＵＵＩＤは、「チャット」要求に対する各応答の際に、ＴＸノード名と一緒に供給される。この例では、ＴＸ１は、そのピアのそれぞれから、（［ＴＸ Ｎａｍｅ、ＴＸ ＵＵＩＤ］→（ピア名）の配列、（ユーザデバイス名）の配列）という配列として構造化されている情報を受信するが、この情報を整理および記録する他の方法は、本明細書の教示に従って容易に考案される。ＴＸ１は次に、ユーザデバイスがどこにあり、どのＴＸノードがどのピアを知っているかに関するルックアップのためのメモリ構造体を作成する。ＴＸ１はまた、ＴＸ名に関連するＵＵＩＤの変更を検査し、ＵＵＩＤが変更された場合には、適切なルックアップスロットを置き換える。ＴＸ１はまた、ＴＸ１にはその特定のＵＵＩＤがＴ×２の時間内の応答に見えなかった場合に、ＴＸ名／ＵＵＩＤ対を「失効」とマークする。Ｔ×２を超える時間中にそのＵＵＩＤが存在しないことは、問題のＴＸノードがアクセスできず、経路計算中に回避されなければならないことを示す。図２の例では、他のすべてのノードは、互いに同様のＲＥＳＴ「チャット」要求を行い、それによって、許可されたピアとのみ交信しながら、ＴＸノードネットワークの全体ピクチャを構築する。各ＴＸノード１０６、１０８、１１０は、この全体メモリのそれ自体のコピーを、ＴＸノードがそれと関連するので保持する。ＵＵＩＤ／ＴＸ名の対がＴ×１１の時間枠内に見えなかった場合には、問題のＴＸノードはピクチャから完全に除去される。さもなければ、そのＴＸノードには、動作可能なノードとして再びマークされる可能性がある。ネットワークに対してノードを除去および／または復元するための様々な別の時間枠または試験は、本明細書の教示に従って容易に考案される。

【0021】

ランタイムＵＵＩＤリフレッシュ法は、様々な実施形態に対して選択された。その理由は、この方法が、他の方法ではＴＸノードネットワーク全体で維持される必要があるグローバルタイムの概念に依拠しないからである。各ＴＸノード１０６、１０８、１１０は、「失効」タイムアウトを計算するのにそれ自体のクロックにだけ依拠しており、各ＴＸノードクロックは著しくスキューしてもよく、相互運用性および全体メモリに影響を与えることがない。いくつかの実施形態では、「チャット」要求／応答の際に交換されるタイムスタンプがない。

【0022】

ＲＥＳＴ ＡＰＩのＧＥＴメソッドが最も安全であるとして選択されたので、「詐称者」ＴＸノードがどうにかして証明書検証に合格したとしても、「詐称者」は、誤った情報をプッシュするだけで誤った情報を全体メモリに注入することはできない。

【0023】

こうして経路探索は、配信用の鍵を用いてパーセルを受信し、次の最適なピアＴＸノードを探索してこのパーセルを現在のＴＸノードネットワークピクチャに基づいて、メモリ内に作成されたＴＸノードに与えるというＴＸノードを具現化する。

【0024】

いくつかのバージョンでは、どのＴＸノードにもネットワークメモリからなる恒久的な記憶装置はない。

【0025】

新たに構成されたＴＸノードがネットワーク全体を伝搬するおおよその時間は、Ｔ×ＬとＴ×Ｌ×２の間の範囲にあり、ここでＬは、（図２の例のような）ＴＸ１から問題のＴＸノードまでのチェーンの長さである。すなわち、ネットワーク内の伝搬時間は、ＴＸノードのチェーンの長さに比例する。

【0026】

一方で、ノード（すなわち、ＴＸノード）を「失効」とマークするための時間は、あまり重要ではない。その理由は、鍵を用いてパーセルを現在保持し、次のホップを探索する必要があるＴＸノードに対して、次のホップ計算が、他のノードがネットワークの現在の状態について何を知っているかとは無関係に直ちに生じるからである。このノードに対して、この時間は一定であり、ＴとＴ×２の間の範囲にある。

【0027】

図３は、本実施形態によるＴＸノード１０６、１０８、１１０、１１２、１１４、１１６のメッシュ内の帯域外暗号化鍵（「パーセル」）配信を示す。この例は、ＴＸノード１１６のＴＸ６がごく最近に問題に遭遇している（または利用できなくなった）ので、この障害に関する情報が上述のメッシュ「チャット」を通じてまだ伝播していないときの稀な状況もカバーしている。

【0028】

図３の例によれば、ＴＸノードメッシュは以下のように設定されている。ＴＸ１はＴＸ４と交信し、ＴＸ４はＴＸ１およびＴＸ５と交信し、ＴＸ５はＴＸ２およびＴＸ６と交信し、ＴＸ２はＴＸ５およびＴＸ３と交信し、ＴＸ３はＴＸ２およびＴＸ６と交信し、ＴＸ６はＴＸ５およびＴＸ３と交信している。

【0029】

ユーザデバイス１０２のＵ１は、暗号化鍵をＴＸノード１０６のＴＸ１から要求し、また、同じ鍵を受信すべき相手ユーザデバイス１２０のＵ２を指定する。次に、Ｕ１は応答を待つ。ＴＸ１は要求された鍵を生成し、パーセルを生成する。ＴＸ１は、Ｕ２が接続しているＴＸノード１１０をＴＸ１の現在のノードマップから見つける。このＴＸノード１１０は、たまたまＴＸ３である。こうして、最終宛先がＴＸ３と指定されたパーセルが形成される。次に、ＴＸ１は、ステップ１として、その唯一のピアであるＴＸ４にパーセルを送信し、応答を待つ。ＴＸ４は、全く同じようにしてパーセルをＴＸ５にステップ２で送信し、応答を待つ。

【0030】

ＴＸ４およびＴＸ５はまた、たまたま外部デバイスから追加の対称暗号化鍵、たとえば、ＱＫＤアリス／ボブ対からの量子鍵を受信する。したがって、通信のためのＴＬＳ層に加えて、パーセル自体がこれらの量子鍵を使用して暗号化される。

【0031】

ＴＸ５は通常、時間間隔Ｔでチャットを行うことによって、そのピアＴＸ６に問題があることを認識するが、この非常に稀な事例では、ＴＸ６は、０とＴの間の範囲の時間枠内で困難に遭遇しているか利用できなくなっている。したがって、ＴＸ５は依然として、そのピアのＴＸ６が動作可能であり、ＴＸ２とＴＸ６の間に等経路ロードバランシングの機会があると考えている。ＴＸ６が最終的に次のホップとして選択された場合、ＴＸ５は、ステップ３でパーセルをＴＸ６に送信する。エラー応答３０２（またはタイムアウト）が生成され（応答矢印）、ＴＸ５は次に、ステップ４でパーセルをもう一方のピアのＴＸ２に送信し、応答を待つ。ＴＸ２は、ステップ５でパーセルをＴＸ３に送信し、応答を待つ。

【0032】

ＴＸ３は、パーセルの宛先がその名前と一致することを確かめ、たとえば、ユーザデバイス鍵配信用のアプリケーションプログラミングインターフェース（ＡＰＩ）を介して、この方法に従った動作を行う。パーセルは、鍵がユーザデバイス１２０のＵ２によって取得された直後に削除される。

【0033】

ＴＸ３は次に、成功応答３０４（応答矢印）をＴＸ２に返し、トランザクションを閉じる。ＴＸ２は、成功応答３０６をＴＸ５に返し、トランザクションを終了する。ＴＸ５は、成功応答３０８をＴＸ４に返し、トランザクションを閉じる。ＴＸ４は、成功フィードバック３１０をＴＸ１に返し、トランザクションを終了する。ＴＸ１は、鍵をユーザデバイス鍵配信の方法に従って待機中のユーザデバイス１０２のＵ１に与え（たとえば、ＡＰＩを介して）、トランザクションを閉じる。

【0034】

典型的な配信は、ＴＸ５がチャットからＴＸ６の問題を知り、ＴＸ６を失効としてマークすることを伴う。この知識はまた、上述のチャットを介してメッシュ内のすべてのノードにわたって伝播する。この典型的な事例では、パーセル配送経路は、ステップ３を完全に回避して、ステップ１、２、４、５から成る。

【0035】

パーセル配信は、ＲＥＳＴメソッドの「ＰＯＳＴ／パーセル」を使用して実施される。パーセルは、ユーザデバイスへ移行する間、ＨＤＤ（ハードディスクドライブ）またはその他のストレージメモリには決して保存されず、ユーザデバイスによって取得後にメモリから直ちに削除される。

【0036】

ユーザデバイスとその関連するＴＸノードが、クライアント／サーバとサーバ／クライアントの両方の証明書検証を行い、かつ／または、たとえばシリアルインターフェースを介して実施できる別の安全性の高いリンクを介して、接続されることが一般的である。

【0037】

図４は、図１の帯域外対称鍵配信システムおよび図３に示したパーセル配信の実施形態で使用するのに適している、経路計算プロセスの一実施形態を示す。図４の例では、ＴＸノード１０６のＴＸ１が、ＴＸノード１１６のＴＸ６へのパーセル配信のイニシエータである。ＴＸノード１０６のＴＸ１は、メッシュ内のすべてのノードと、上述のチャットを介して取得されたそのピアとの現在のマップを保持する。

【0038】

ＴＸ１は、ステップ１を使用して、すべての可能な宛先と、それらの宛先をアクセス可能にするＴＸ１のピアと、特定のピアを介して特定の宛先へ配信するのに要するホップの数とから構成されるジャストインタイムマップを作成する。失効ＴＸノードは、マッピングから除外される。

【0039】

次に、ＴＸ１は、ステップ２を使用して、ＴＸ６だけが宛先として残るようにすべての無関係なレコードをフィルタ除去する。図４の例では、ホップの数が等しい２つのレコードが得られる。そうしてＴＸ１はロードバランシングモードに切り替わり、パーセルをラウンドロビン方式でＴＸ２とＴＸ４に交互に送信する。

【0040】

チャットから得られたオリジナルマップが変化すると、パーセル配送ごとに新たに作成されているジャストインタイムホップマップも変化する。一例として、ＴＸ２がＴＸ６宛のパーセルを受信すると、ＴＸ２は同一の計算を行って、チャットを介して取得されたすべてのノードおよびそのピアの現在のマップのコピーを取り込み、そのマップを、ここではＴＸノード１０８のＴＸ２（それ自体）にだけ関連して、可能性のあるすべての宛先マップにホップカウントを用いて変換し、次に宛先ＴＸ６によってフィルタ除去する。これにより、ＴＸ３とＴＸ５の間で再びロードバランシングラウンドロビンをトリガするＴＸ６→ＴＸ３→２およびＴＸ６→ＴＸ５→２の選択肢が得られる。１つが選択され、次の同一のステップの結果として、ＴＸノード１１６のＴＸ６にパーセルが配信される。

【0041】

経路計算は、上述のようにチャットから得られた最も新鮮な情報に基づいて、各ＴＸノード１０６、１０８、１１０、１１２、１１４、１１６、１１８に対してパーセル配信ごとに別個に生じる。

【0042】

上述の実施形態、例、およびシナリオは、対称暗号化鍵をユーザデバイスへ配信する要求が、ユーザデバイスに直接接続されていないが別のＴＸノードを介してユーザデバイスと通信するＴＸノードで受信される、別の実施形態に一般化可能なものである。ユーザデバイスから対称暗号化鍵の要求を受信したＴＸノードは、すべてＴＸノードを通して、対称暗号化鍵の一方を別の指定されたユーザデバイスへ配信し、配信の確認を受信し、次に、他方の対称暗号化鍵を、鍵を要求したユーザデバイスへ配信する。

【0043】

上述の明細書では、特定の例示的な実施形態を参照している。しかし、より広い意図された趣旨および範囲から逸脱することなく、様々な修正および変更が明細書に加えられ得ることは明らかであろう。したがって、本明細書および図面は、限定的な意味ではなく、例示的な意味で考慮されるべきものである。

【図1】

【図2】

【図3】

【図4】

【国際調査報告】